Author [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: drltc's BitShares Engineering Recommendations  (Read 532 times)

0 Members and 1 Guest are viewing this topic.

Offline theoretical

drltc's BitShares Engineering Recommendations
« on: March 22, 2014, 09:19:07 AM »

I have solved several implementation problems for BitShares.  You can read all about it here:  https://github.com/drltc/xts-proposal

And you can discuss it in this thread.

EDIT:  This is very much a work-in-progress.  However, I thought it was better to get my proposal out there than wait for perfection.  The sooner it's published, the greater chance it'll be adopted, and the smaller the development resources sunk in dead ends that could have been avoided.
« Last Edit: March 22, 2014, 09:25:47 AM by drltc »
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline theoretical

Re: drltc's BitShares Engineering Recommendations
« Reply #1 on: March 22, 2014, 09:19:19 AM »
(reserved)
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline theoretical

Re: drltc's BitShares Engineering Recommendations
« Reply #2 on: March 22, 2014, 09:19:31 AM »
(reserved)
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline bytemaster

Re: drltc's BitShares Engineering Recommendations
« Reply #3 on: March 22, 2014, 06:57:05 PM »
Typo: In BitShares X, the minting reward comes solely from newly minted coins...  I don't believe that is what you meant to say.

Overall I would like to say this document represents significant thought and is much appreciated.   The major concept which I liked was the division of fees into two classes:  immediate and time delayed.    This allows production of blocks when there are no transactions.  My feeling on this point is that a successful network never has periods of no transactions.   And something like BTS X which has bids and asks should have many more transactions than bitcoin.   Therefore, this feature would have little long term benefit and much added complexity.

The reduction in hashing power to something that like 20 HPM based upon the output reference( trx_id +output index) would incentivize creating many small balances assuming the probability per satoshi was unchanged.   

The goal is to have large balances sign off.  The risk of fraud / theft / incompetence will be enough to keep the size of mining pools under control.   The rewards will be small enough that few will want to put their funds in such a pool.

So long as the best block chose based upon total votes (CDD) an attacker will have limited nonce search space because every time a new transaction comes in they will have to restart their search.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline toast

Re: drltc's BitShares Engineering Recommendations
« Reply #4 on: March 22, 2014, 06:59:14 PM »
Give this man some PTS!
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline theoretical

Re: drltc's BitShares Engineering Recommendations
« Reply #5 on: March 23, 2014, 01:26:36 AM »
Typo: In BitShares X, the minting reward comes solely from newly minted coins...  I don't believe that is what you meant to say.

Fixed.

Overall I would like to say this document represents significant thought and is much appreciated.   The major concept which I liked was the division of fees into two classes:  immediate and time delayed.    This allows production of blocks when there are no transactions.  My feeling on this point is that a successful network never has periods of no transactions.   And something like BTS X which has bids and asks should have many more transactions than bitcoin.   Therefore, this feature would have little long term benefit and much added complexity.

Reserve funds can be used for more than one purpose.  It's not necessary to track the reserve as a separate account; rather you can view it as a ceiling on the printing press.

The reduction in hashing power to something that like 20 HPM based upon the output reference( trx_id +output index) would incentivize creating many small balances assuming the probability per satoshi was unchanged.   

I had intended to include a section on why this objection doesn't matter, but I think it somehow got lost during editing.  The hash stream is modulated by your balance.  E.g. if you keep balance B in one address, B / k of your hashes pass (where k is much larger than B, depending on boost and network rate).  If you keep balance B in n addresses, you produce n times as many hashes, but the probability that each hash passes is reduced to B / (kn).  The two effects cancel; thus the small balance strategy doesn't give you an advantage or disadvantage with respect to minting speed (of course small balances suffer other penalties, e.g. doing anything with many small balances will probably involve large fees).  But you got me thinking and I realized there's a different incentive to create many small balances; to fix it, I make the boost function constant.  See the latest commit.

The goal is to have large balances sign off.

I have a feeling that the only reason you care about large balances is that the only *obvious* way to prove that N coins approve of the network state is to record signoffs from M individual coin holders who collectively hold N coins.  Making sure M is small is the only way this approach can keep blockchain storage required under control.

My proposal is a *non-obvious* way to prove that N coins approve of the network state:  Have each coin that approves produce a hash stream, and record the size of the smallest hash produced.  You should then be able to use standard probability theory to say N exceeds a certain size with high confidence.  The required blockchain storage is O(1) regardless of how many balances sign off.  Thus the total security (in terms of number of coins that approve the current state) can be increased because all balances are now allowed to participate in signoff, not just large ones.

The risk of fraud / theft / incompetence will be enough to keep the size of mining pools under control.   The rewards will be small enough that few will want to put their funds in such a pool.

The recent Mt. Gox situation gives me serious doubts about this assertion.

So long as the best block chose based upon total votes (CDD) an attacker will have limited nonce search space because every time a new transaction comes in they will have to restart their search.

I'm not quite sure what you're trying to say.  Could you clarify?
« Last Edit: March 23, 2014, 01:37:10 AM by drltc »
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

 

Google+