Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - bytemaster

Pages: 1 2 3 4 5 [6] 7 8 9 10 11 12 13 ... 42
76


A margin call will occur any time the highest bid is less than the CALL PRICE and greater than SQP

FEED = Settlement Price
SWAN = DEBT / COLLATERAL  - the point at which the network is insolvent.
CALL   = SWAN * 1.75
SQP   = FEED / 1.5

1.75 and 1.5 are specified as two parameters to the price feed. 

If you would like the feed to provide additional protection to the shorts, then ask the witnesses to adjust their feed publishing scripts to use SQP of FEED / 1.1.

Just beware that the consequence of protecting the shorts against thin markets is the following:

1. Shorts will end up posting less collateral
2. Greater dependence upon the feed vs the market
3. If there are no bids above the SQP price then margin will not get called even if the Feed Price is below the Call price.


77
General Discussion / Witness Alerts and Status
« on: October 14, 2015, 08:54:33 pm »
This thread should be followed by anyone operating a full node or anyone interested in keeping tabs on network issues. 

If there are problems with witnesses that need coordination to resolve, that coordination should happen in this thread.   If you are a witness you should also post your skype ID to receive notifications / real time discussion of events.

78
General Discussion / Recent Network Split Analysis
« on: October 14, 2015, 08:48:20 pm »
Around 2015-10-14T19:21:39  dele-puppy attempted to claim a vesting balance (his witness pay) and as a result the network split 60/40 because 40% of the witnesses thought the transaction was invalid.

As a result the last irreversible block hung around block 33845 (the block prior to the one that forked the network).   The blockchain grew to 269 blocks before 2/3's of the witnesses managed to agree and extend the last irreversible block back to the typical 20 to 30 behind the head block number.

In this situation everyone on the network was accurately reporting the state and the user interfaces indicated to the users that their operations were pending confirmation.   Any / all exchanges following the last irreversible block would have been OK.

We have determined the cause is due to some non-deterministic behavior in witness pay that resolves itself with a replay.   After replaying the blockchain all witnesses agreed the transaction was valid. 

We will continue to monitor the blockchain for issues as we look for the underlying cause.   In the meantime this particular failure can be mitigated by witnesses periodically replaying their blockchain. 

Despite the "bug" everything is working just fine and your funds are safe.




79
General Discussion / 328,028 BTS Reduction in Supply since 2.0
« on: October 14, 2015, 12:37:40 pm »
It looks like the network is currently operating at a profit.   We will see if things continue this way.

80
General Discussion / https://bitshares.org/wallet
« on: October 13, 2015, 08:14:31 pm »
BitShares.org/wallet now has a copy of the light wallet sources.   

Behind the scenes it still uses OpenLedger to register accounts and serve blockchain data. 

In theory you can use https://bitshares.org/wallet to point at your own full node in the cloud.  It also serves as a basic block explorer.

81
General Discussion / Open Ledger is Now Operational
« on: October 13, 2015, 07:03:41 pm »
https://bitshares.openledger.info/

The main website will be updated when @cass wakes up from his beauty sleep.


82
General Discussion / BitShares 2 Release Coordination Thread
« on: October 13, 2015, 03:50:02 pm »
This thread is intended to for witnesses and individuals attempting to join the BitShares 2 network.   

I have just tagged a pre-release of 2.x

https://github.com/bitshares/bitshares-2/releases/tag/v2.15.286

It has a bundled light wallet for the Mac.   No faucets are up and running at this point in time, so this is for importing your keys only.   Only advanced users should be joining the network at this point in time.

85
General Discussion / BitShares 0.9.3c GUI Export
« on: October 12, 2015, 12:54:29 pm »
I have just double-checked that the BitShares 0.9.3c client for Mac OS X can export Graphene Compatible Wallets via the File->Export Wallet menu item. 

You can identify that it has exported a Graphene Compatible wallet .json file if the first few lines in the wallet look like this:

Code: [Select]
{
  "password_checksum": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "account_keys": [{
      "account_name": "",
      "encrypted_private_keys": [

I have heard reports that the Windows GUI wasn't doing this properly.  Can someone verify that for me?

86
General Discussion / Looking for BTS 2.0 Seed Node Operators
« on: October 12, 2015, 12:45:28 pm »
If you would like to be an official seed node provider for BTS 2.0 please post the IP/PORT that you will run your full node on.   We will be including these addresses in all clients by default to connect to on startup.

Those who are running these nodes should probably also be witnesses.  (Do not run witness on the seed node).   

The job requires that you monitor the seed node for responsiveness and restart it if necessary.   New users will depend upon these nodes being reliable.

87
General Discussion / Testnet Light Wallets for Mac & Windows
« on: October 05, 2015, 09:13:00 pm »
There are some new light wallets available for Mac and Windows

https://github.com/cryptonomex/graphene/releases

Enjoy!

88
General Discussion / October 5 Test Network
« on: October 05, 2015, 02:23:40 pm »
https://github.com/cryptonomex/graphene/releases/tag/test6

The goal of this test network is to test blockchain features rather than network throughput.   The network code has been intentionally rate limited by latency by only fetching one transaction at a time from each peer.  Low latency connections (10 ms) may be able to push up to 100 TPS along their link whereas high-latency connections (250ms) will only be able to push 4 TPS per second across their link.    This effectively rate limits how fast each PEER can broadcast.  The actual rate at which a witness can receive transactions will depend upon how many peers they are connected to, the latency to those peers, and the total number of unique transactions those peers know about.

A side effect of this rate limiting is that "flood attacks" could cause a traffic jam that prevent new transactions from getting included before they expire.   Users will have to try again later when the network is less busy.  If there was a sustained flood attack it would generate significant revenue for the network so it should be welcomed. 

89
General Discussion / New Metric for Blockchain Confirmation
« on: October 02, 2015, 08:53:19 pm »
Historically we have stated that a blockchain becomes irreversible after one round with greater than 51% participation.   This metric is a little bit fuzzy because of noise in how witnesses are ordered.  In an effort to provide stronger / absolute guarantees Ben and I have devised a new metric that will be used by all exchanges for determining the exact point at which a particular block becomes irreversible.

Sort N witnesses by the last block number they signed, then take the highest block number that is lower than 66% of all other witnesses.  This will indicate that said block has been confirmed by 66% of all witnesses and is clearly irreversible.

This particular metric is dynamic and can respond to changes in the order of witnesses and is immune to situations where the network fragments into more than two pieces.   In the event of a major disruption users are guaranteed that no block older than that number can ever be undone. 

If we have 17 witnesses and 3 second blocks then this will take an average of 34 seconds.
If we have 101 witnesses and 3 second blocks then this will take an average of 3.3 minutes.

We intend to propose a new transaction type that will allow a witness to increase their last produced block number at will.   Then witnesses can determine how often to broadcast these extra operations.  If 2/3 of witnesses broadcast every block then it is possible for the blockchain to become irreversible after just 3 seconds and we can take the lead in this particular metric from Ripple.  By making this extra speedy confirmation optional, witnesses can choose to only broadcast when there is enough volume / transfers which will mean that the blockchain will not get bloated while there are no meaningful transactions (high value orders or transfers).   

The delayed node used by exchanges will only process blocks up to the last irreversible block number.

Having this metric is important to give everyone in the network peace of mind in the unlikely event that a software bug or network issue causes all witnesses to fall out of sync and gives a clear measure of when they are considered back in sync.

Anyone accepting transactions as final prior to the most recent irreversible block is choosing to take some extra risk on their transaction.

90
General Discussion / October 2nd Test Network
« on: October 02, 2015, 01:17:03 pm »
The last test network died due to a poorly coordinated and rushed hardfork.  Mostly because I forgot to upgrade half the witnesses :*(

https://github.com/cryptonomex/graphene/releases

Lets try it again.   

Pages: 1 2 3 4 5 [6] 7 8 9 10 11 12 13 ... 42