BitShares Forum
Other => Graveyard => DevShares => Topic started by: theoreticalbts on December 17, 2014, 09:25:21 pm
-
We're working on implementing DevShares in the near future. My original proposal for DevShares (under my old account, drltc) had the following two features. AFAIK these are not currently slated for inclusion in DevShares, but I wanted to bring them up before launch:
- A terminal block as well as genesis block. In other words, clients are pre-programmed from Day 1 to halt on a fixed date/time. The plan is to take a snapshot of the final state and to initialize a new genesis block, and/or hardfork(s) which postpone the halt date. The reason for this is to have a better end-of-life process allowing the code for retired mechanics to eventually be removed (instead of having to stick around forever in order to correctly interpret older blocks).
- Value backed by inflationary BitShares. My original proposal had a promise to issue inflationary BitShares to the terminal snapshot with a BitShares hardfork. For a variety of reasons, I no longer think that is workable. Perhaps we could simply have a 100% BitShares delegate who promises to run both BitShares and DevShares clients and issues regular distributions to DevShares balances according to some algorithm?
-
Devshares! +5% Will it come before Christmas?
-
DevShares will launch this week. A snap shot of 33/33/33 AGS/PTS/BTS is being prepared by Toast.
DevShares will be identical to BitShares with the only difference being the "effective block number" of hard forks. In this way we can be sure that the problems experienced by the BitShares network this past week happen on DevShares and BitShares can enjoy a nice smooth upgrade cycle.
中文翻译:
DevShares将会在本周发布. Toast正在准备快照给AGS/PTS/BTS各33/33/33.
DevShares将会等同于比特股， 唯一的差别就是硬分岔的'有效区块数'. 这样一来就可以确定如果比特股网络出现像是过去一周的问题， 那么DevShares也会出现， 因此将来比特股可以有比较平顺的升级周期.
-
DevShares will launch this week. A snap shot of 33/33/33 AGS/PTS/BTS is being prepared by Toast.
+5%
Please allow me to ask one more question. When is the BTS snapshot date? Nov 5, as like AGS and PTS?
-
DevShares will launch this week. A snap shot of 33/33/33 AGS/PTS/BTS is being prepared by Toast.
+5%
Please allow me to ask one more question. When is the BTS snapshot date? Nov 5, as like AGS and PTS?
Hope not, the exchanges didn't take any snapshot.
Maybe use the PLAY snapshot?
-
Please allow me to ask one more question. When is the BTS snapshot date? Nov 5, as like AGS and PTS?
December 14.
-
Please allow me to ask one more question. When is the BTS snapshot date? Nov 5, as like AGS and PTS?
December 14.
The same as Sparkle one?
-
The same as Sparkle one?
Toast is working on the blockchain state dump right now. Perhaps he could give us a block number?
-
- A terminal block as well as genesis block. In other words, clients are pre-programmed from Day 1 to halt on a fixed date/time. The plan is to take a snapshot of the final state and to initialize a new genesis block, and/or hardfork(s) which postpone the halt date. The reason for this is to have a better end-of-life process allowing the code for retired mechanics to eventually be removed (instead of having to stick around forever in order to correctly interpret older blocks).
This brings up something that I really want to see in BitShares eventually, even though it is a significant restructuring of how the system works. I would love it if there was a process running in parallel that continuously takes snapshots of the essential subset of the client database in such a way that the entire database can be represented in a platform-agnostic way by a single hash and the memory and processing bounds for the proof of a particular (key, value) pair existing in the database is O(log(N)) where N is the number of unique keys in the database.
When one such snapshot of the state of the database as of block N1 is created, the delegates could coordinate to sign the hash of this state. Let's say the 90th unique active delegate to submit their signature confirming the hash submits that signature in block N2. At that point, the delegates all work on building up the new hash for the state of the database up to block N2 and repeat the process. Until the new hash is also confirmed, the old hash for the state of the database up to block N1 is referenced in each block (say by including it in the digest of the block that the delegate must sign).
Now say a client wants to synchronize with the network. Instead of starting from the genesis state, it can instead download a copy of the database snapshot as of block N1 as well as the blockchain from block N1 to the present. The client would also need a checkpoint of a block greater than or equal to N1. It can then update the database it downloaded from its state as of block N1 to its present state by only processing the part of the blockchain from block N1 to the present block. This also means that all legacy code that was necessary to process the blockchain prior to block N1 would no longer be necessary in this client (legacy code for understanding how to handle old database entries would still be needed however).
There is an added benefit if the snapshot process is fast and the memory and processing bounds for proofs I mentioned above hold true. Someone with a full client could construct a manageable-sized proof showing that a requested balance exists in the database as of a particular timestamp with a certain value and which can be withdrawn by certain addresses. The timestamp would have to be at the snapshot boundaries. If a user's client was also able to be confident of the current set of active delegates (there are ways this could be done cheaply on a lightweight client with very minimal trust), then the lightweight client could with very minimal trust verify the existence of funds owned by the user as of a time as recent as the latest snapshot timestamp. I would hope that properly optimized code could make this snapshot process regularly occur with a time period of 30 minutes or less to make this verification practical for the lightweight client user.
-
Value backed by inflationary BitShares. My original proposal had a promise to issue inflationary BitShares to the terminal snapshot with a BitShares hardfork. For a variety of reasons, I no longer think that is workable. Perhaps we could simply have a 100% BitShares delegate who promises to run both BitShares and DevShares clients and issues regular distributions to DevShares balances according to some algorithm?
I like this , DevShares is in Bitshares client. the different is using different regular to sign tx. create block . eg.
and I also don`t understand why we need a new chain. how attract people to join new chain
BM can you give more reason?
-
When one such snapshot of the state of the database as of block N1 is created, the delegates could coordinate to sign the hash of this state. Let's say the 90th unique active delegate to submit their signature confirming the hash submits that signature in block N2. At that point, the delegates all work on building up the new hash for the state of the database up to block N2 and repeat the process. Until the new hash is also confirmed, the old hash for the state of the database up to block N1 is referenced in each block (say by including it in the digest of the block that the delegate must sign).
The problem with this approach is that the client needs a way to authenticate the delegates who sign that snapshot. But the votes authorizing the delegates are part of the snapshot, i. e. you have a circular validation process without a solid anchor.
-
When one such snapshot of the state of the database as of block N1 is created, the delegates could coordinate to sign the hash of this state. Let's say the 90th unique active delegate to submit their signature confirming the hash submits that signature in block N2. At that point, the delegates all work on building up the new hash for the state of the database up to block N2 and repeat the process. Until the new hash is also confirmed, the old hash for the state of the database up to block N1 is referenced in each block (say by including it in the digest of the block that the delegate must sign).
The problem with this approach is that the client needs a way to authenticate the delegates who sign that snapshot. But the votes authorizing the delegates are part of the snapshot, i. e. you have a circular validation process without a solid anchor.
The problem you are describing only applies to the lightweight client validation benefit that I was describing. And indeed as I mentioned those clients do need a way to verify the set of active delegates who can sign the snapshot to break that circular loop:
If a user's client was also able to be confident of the current set of active delegates (there are ways this could be done cheaply on a lightweight client with very minimal trust), then the lightweight client could with very minimal trust verify the existence of funds owned by the user as of a time as recent as the latest snapshot timestamp.
I will describe that process in a moment.
But for a full client, they already have the entire up-to-date database will all of the delegate approval vote changes. The full clients know at any block who the 101 active delegates are through the same mechanism as they currently do. And so they know to treat the blocks where these 101 active delegates sign a valid database snapshot hash as a legitimate block.
Now consider a full client that is trying to bootstrap to the present state of the database starting with a copy of the database as of block N1, the portion of the blockchain from block N1 to the present, and a checkpoint in the client of a block M more recent than block N1 (M > N1). The client does not know whether to trust the database copy the blockchain receives from the network. But it is able to calculate its hash. It first assumes this is the right database for the sake of evolving the database state into the future, and then it will later verify if it was indeed correct. The blockchain also does not know if blocks N1 to (M-1) are legitimate, but the checkpoint does verify the validity of block M. Because of the hash link, this also necessarily validates blocks N1 to (M-1). The client can then process blocks N1 to M by evolving the state of the database. At some point during this evolution, the client reaches block N2. It is then able to see that the active delegates at that time validated the hash of the database that the client started with. While the active delegates at the point of block N2 are dependent on the starting state of the database as of block N1, the client knows the active delegates are the real active delegates because otherwise the checkpoint would not match. If the starting state of the database was modified to change even one active delegate, their block signatures would be different and therefore the checkpoint of block M would be different. Because the client knows the active delegates and because our security model already assumes the delegates will not double sign, the client can know that further evolution from block M to the present can be trusted as usual. So even if N2 > M, the client can still reach block N2 in a trust-free manner and verify that the starting database it received was in fact valid. Further evolution beyond that as usual can allow the client to reach the present state.
The above still provides the benefits of pruning the legacy code from the client over time and speeding up the process of restoring the database from scratch for full clients. But what about the added benefits I described for lightweight client validation? Lightweight clients cannot be expected to scan through the blockchain, even a recent portion of it. Therefore they cannot find out how the delegate votes evolve and thus who the active delegates are without some other added mechanism. It is important to clarify that if the lightweight client doesn't know who the active delegates should be during the several blocks leading up to block N2, then the lightweight client doesn't have any way to verify the proof that the hash of the database as of block N1 is indeed the correct one. Anyone could sign a hash of a fake database with 101 signatures claiming they were the active delegates. If the lightweight client believed that those were the set of active delegates, the attacker could supply the lightweight client with a database proof saying anything it wanted (such as the false existence of some balances in the victim's control in order to pull off a double spend).
To deal with this issue, the lightweight client would need some way of knowing the set of active delegates at any block. We could require that the hash of the ordered set of current active delegates could be included as part of the digest that the delegates must sign in every block in order for the block to be valid. A lightweight client could then download the block header of block M which it knows is valid because of the checkpoint in the client. This block header immediately proves to the client whether a given set of active delegates as of block M is correct. Then using only the small block headers, it could evolve this set of active delegates into the future. It can know which delegates are supposed to sign which blocks (using the active set and random numbers in block headers) and it can verify that the block headers it receives are properly signed by the intended delegate. In order for an attacker to supply fake block headers beyond block M that change the active set of delegates to a false one, it would require at least 51 delegates in one of the rounds to collude together to double sign fake blocks (which would by the way act as proof to get them fired, assuming they haven't been already). But that already breaks the security assumption that we hold in DPOS, so it is reasonable to assume this will not happen as long as the checkpoint block M is not too far in the past (not, for example, older than 6 months). The lightweight client can of course store an up-to-date copy of a checkpoint (derived from the evolution of block headers), so that it can resume this process whenever it wants to find the more recent set of active delegates. It would also store the database hash of the most recent verified database snapshot (which it is able to verify is the correct one because it checked the validation signatures of the active delegates at the time). With this information kept up-to-date, the lightweight client can then easily verify provided proofs of the existence of some (key, value) tuple in a recent database snapshot.
-
DevShares will launch this week. A snap shot of 33/33/33 AGS/PTS/BTS is being prepared by Toast.
Why do AGS+PTS get 33%? Isn't 10% the 'social contract'?
-
DevShares will launch this week. A snap shot of 33/33/33 AGS/PTS/BTS is being prepared by Toast.
Why do AGS+PTS get 33%? Isn't 10% the 'social contract'?
Look opposite, AGS and PTS brings funds to toolkit development, I think 50/50 AGS/PTS will be more fair than 33/33/33 AGS/PTS/BTS :)
PS: 'Social contract' says not less than 10%, 33% not less than 10%
-
DevShares will launch this week. A snap shot of 33/33/33 AGS/PTS/BTS is being prepared by Toast.
Why do AGS+PTS get 33%? Isn't 10% the 'social contract'?
Look opposite, AGS and PTS brings funds to toolkit development, I think 50/50 AGS/PTS will be more fair than 33/33/33 AGS/PTS/BTS :)
PS: 'Social contract' says not less than 10%, 33% not less than 10%
+5%
-
DevShares will launch this week. A snap shot of 33/33/33 AGS/PTS/BTS is being prepared by Toast.
Why do AGS+PTS get 33%? Isn't 10% the 'social contract'?
Look opposite, AGS and PTS brings funds to toolkit development, I think 50/50 AGS/PTS will be more fair than 33/33/33 AGS/PTS/BTS :)
PS: 'Social contract' says not less than 10%, 33% not less than 10%
'Social contract' says not less than 10% for new DACS. DevShares isn't a new DAC, it's a BTS test chain. It's part of BTS. This logic is infallible because otherwise it means the developers are working on something that is not BTS, which they said they wouldn't do. Therefore DevShares must be part of BTS, so there's no reason to give 66% of BTS test-chain shares to non-BTS holders.
Is this unreasonable?
As a BTS test chain it should be 100% BTS, or 10% each to AGS + PTS for the sake of peace keeping, even though that in itself would mean it was a new DAC which is not supposed to be happening.
-
BTW if there were too many complaints it will just go 100% to BM. If you're arguing the allocation you're missing the point
-
As a BTS test chain it should be 100% BTS, or 10% each to AGS + PTS for the sake of peace keeping, even though that in itself would mean it was a new DAC which is not supposed to be happening.
I thought we'd done with AGS/PTS and the value of those transfered to BTS albeit locked down.
Only if those old AGS/PTS values in BTS are not being acknowledged until they are released, should those BTS[AGS/PTS] values be acknowledged. Perhaps that's what is being suggested.. more accurately then BTS[PTS] and BTS[AGS].. in which case those allocations above should simply and only map directly to whatever the transfer snapshot into BTS was.. and then perhaps easier we all talk of 100% BTS.
-
'Social contract' says not less than 10% for new DACS. DevShares isn't a new DAC, it's a BTS test chain. It's part of BTS. This logic is infallible because otherwise it means the developers are working on something that is not BTS, which they said they wouldn't do. Therefore DevShares must be part of BTS, so there's no reason to give 66% of BTS test-chain shares to non-BTS holders.
Is this unreasonable?
As a BTS test chain it should be 100% BTS, or 10% each to AGS + PTS for the sake of peace keeping, even though that in itself would mean it was a new DAC which is not supposed to be happening.
DevShares its a test network of new features of BitShares toolkit which used in all BitShares DAC's (Play, Music, PTS-DPOS). Any reason why DevShares should be allocated only to BitShares (BTS) owners?
-
BTW if there were too many complaints it will just go 100% to BM. If you're arguing the allocation you're missing the point
I don't see any complaints yet - discussion. :)
PS: Building 33/33/33 14 Dec snapshot allocation you will help Sparkle as well :)
-
Reviewing sharedrop theory:
Allocations are not selected to be "fair", they are selected to attract the greatest amount of interest possible to a new offering.
You get share-dropped on in proportion to the perceived value of the demographic your coin represents. It's the developer's choice. It would be just as legitimate to do 10/10/10/10/10/10...10 and attract 10 diverse demographics, seven of which "deserve" nothing.
The simplest logic is to treat all three groups the same because they overlap anyway. This minimizes (obviously it does not eliminate) arguments about percentages. All three groups get more than they "deserve". :)
If you still want to argue, argue why your favorite demographic would give a bigger boost to the new DAC if its share of that DAC was somehow just a bit bigger.
-
Allocations are not selected to be "fair", they are selected to attract the greatest amount of interest possible to a new offering.
+5%
This week is Devshares week.
-
The reason for this is to have a better end-of-life process allowing the code for retired mechanics to eventually be removed (instead of having to stick around forever in order to correctly interpret older blocks).
Part of the purpose of DevShares is exactly that we want to keep the legacy code same as in current BitShares, so we can test upgrading around it.
-
Latest Blog Post:
http://bytemaster.github.io/update/2014/12/19/The-Value-of-DevShares.html
-
BTW if there were too many complaints it will just go 100% to BM. If you're arguing the allocation you're missing the point
I don't see any complaints yet - discussion. :)
PS: Building 33/33/33 14 Dec snapshot allocation you will help Sparkle as well :)
I approve and appreciate!
-
Reviewing sharedrop theory:
Allocations are not selected to be "fair", they are selected to attract the greatest amount of interest possible to a new offering.
You get share-dropped on in proportion to the perceived value of the demographic your coin represents. It's the developer's choice. It would be just as legitimate to do 10/10/10/10/10/10...10 and attract 10 diverse demographics, seven of which "deserve" nothing.
The simplest logic is to treat all three groups the same because they overlap anyway. This minimizes (obviously it does not eliminate) arguments about percentages. All three groups get more than they "deserve". :)
If you still want to argue, argue why your favorite demographic would give a bigger boost to the new DAC if its share of that DAC was somehow just a bit bigger.
I'm not going to make a fuss, but well reasoned criticism of important decisions shouldn't be discouraged. Like code, all decisions will be tested at some point the sooner they are tested the better. It looks like the decision has been made however so I'll keep it brief.
I favour 10/10/80 AGS/PTS/BTS
It probably makes no difference at all to the success of DevShares whether its 33/33/33 or 10/10/80. The default position should be the one that favours BTS. We did just give away half a billion BTS to AGS/PTS for the sake of getting (ex)i3 to be loyal to BTS alone. They should be fighting BTS's corner in every sphere including sharedrops, without breaking past commitments, in which case 10% honours the social contract.
Why were half a billion BTS given away only to share drop 66% on them a month later? It's not an even distribution at all - which is the aim because that maximises incentives - (you wouldn't do a giveaway where one half got $10 and half for got $1, you'd do $5 each).
It *appears*, even if this is not the case, that the allocation is chosen based on maximising developer incentive who may have large PTS/AGS stakes, not market incentive for network effect, which is just the cover story.
*-Prepares package for head shipment-* :P
As someone who needs the votes of Toast, Stan + everyone, I hope people appreciate me not hiding behind a sock puppet to say potentially controversial things. I am a BTS fighter.
-
It isn't controversial to argue for your economic interests using whatever logical arguments are available.
It really doesn't matter, just get devshares out there. It won't ever be worth much to begin with.
For effectiveness, one wants to maximize certain types of holders because it is a test-chain. If most of the technical supporters have larger stakes in PTS/AGS then it makes sense to weigh it in favor of PTS/AGS to gather that support. Thats the only reason I can think that matters. I plan to gamble mine off in the market.
-
Reviewing sharedrop theory:
Allocations are not selected to be "fair", they are selected to attract the greatest amount of interest possible to a new offering.
You get share-dropped on in proportion to the perceived value of the demographic your coin represents. It's the developer's choice. It would be just as legitimate to do 10/10/10/10/10/10...10 and attract 10 diverse demographics, seven of which "deserve" nothing.
The simplest logic is to treat all three groups the same because they overlap anyway. This minimizes (obviously it does not eliminate) arguments about percentages. All three groups get more than they "deserve". :)
If you still want to argue, argue why your favorite demographic would give a bigger boost to the new DAC if its share of that DAC was somehow just a bit bigger.
I'm not going to make a fuss, but well reasoned criticism of important decisions shouldn't be discouraged. Like code, all decisions will be tested at some point the sooner they are tested the better. It looks like the decision has been made however so I'll keep it brief.
I favour 10/10/80 AGS/PTS/BTS
It probably makes no difference at all to the success of DevShares whether its 33/33/33 or 10/10/80. The default position should be the one that favours BTS. We did just give away half a billion BTS to AGS/PTS for the sake of getting (ex)i3 to be loyal to BTS alone. They should be fighting BTS's corner in every sphere including sharedrops, without breaking past commitments, in which case 10% honours the social contract.
Why were half a billion BTS given away only to share drop 66% on them a month later? It's not an even distribution at all - which is the aim because that maximises incentives - (you wouldn't do a giveaway where one half got $10 and half for got $1, you'd do $5 each).
It *appears*, even if this is not the case, that the allocation is chosen based on maximising developer incentive who may have large PTS/AGS stakes, not market incentive for network effect, which is just the cover story.
*-Prepares package for head shipment-* :P
As someone who needs the votes of Toast, Stan + everyone, I hope people appreciate me not hiding behind a sock puppet to say potentially controversial things. I am a BTS fighter.
Agree with you Matt 110%. Keep up the good fight.