adam3us





Offline



Activity: 402

Merit: 265





in bitcoin we trust







Sr. MemberActivity: 402Merit: 265in bitcoin we trust bitcoin "unlimited" seeks review January 02, 2016, 05:58:17 PM #1 The proposers of bitcoin unlimited said they would like to get some review which seems reasonable, if others would like to help.



The proposal seems at first skim to be a copy of a few existing technologies from Bitcoin's roadmap and were first proposed by Greg Maxwell and others*: weak-blocks & network-compression/IBLT to reduce orphan risk, and flexcap (or a variant of it perhaps).



Perhaps they could start by explaining what it is & how it works. This might include unimplemented ideas, and a summary of what the code currently for download on the manifesto page does.



To review it will be clearer if you state your assumptions, and claimed benefits, and why you think those benefits hold. (Bear in mind if input assumptions are theoretical and known to not hold in practice, while that can be fine for theoretical results, it will be difficult to use the resulting conclusions in a real system). Particularly claimed compatibilities with Bitcoin and how the dynamic block-size game-theory is expected to work and remain secure with SPV mining, selfish-mining, block-withholding and fair (progress-free) mining could also use explaining.



I suggest the sensible thing is if there is something new or insightful, that Bitcoin consider adopting the technology and the BU proponents get behind that.



Maintaining a new coin is a rather complex undertaking and screwing up, as something like 40% of projects that have tried it have done, is very expensive of other peoples money.



To make progress on review it would be helpful to separate technical from political opinions.



Adam



* some citations seem to be notably missing, I trust this is unintentional.

hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity

The forum was founded in 2009 by Satoshi and Sirius. It replaced a SourceForge forum. Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertised sites are not endorsed by the Bitcoin Forum. They may beunsafe, untrustworthy, or illegal iyour jurisdiction. Advertise here.

BitUsher



Offline



Activity: 994

Merit: 1027







LegendaryActivity: 994Merit: 1027 Re: bitcoin "unlimited" seeks review January 02, 2016, 07:07:44 PM #5 Quote from: LiteCoinGuy on January 02, 2016, 06:38:48 PM i hope this thread will not waste too much dev-time for nothing in the end. PR is necessary but time is limited too.



We shouldn't assume the Core developers or anyone else is immune from review and I believe there is always something to learn my looking over other implementations. I think it is both extremely healthy for there to be multiple implementations in our ecosystem with different project maintainers and for them to both collaborate and review each others work. We should support Core, BU , libbitcoin , and others with testing.





To add to the discussion Gavin represents a qualified outside developer that conducted a very brief review of the code and this was his response-



https://bitco.in/forum/threads/i-really-want-to-like-bitcoin-unlimited.684/



Quote from: Gavin



Examples:



https://github.com/gandrewstone/BitcoinUnlimited/commit/9b05e2e9f7eb4d8e847c57ae06d8bd34b1f03552



... which is a commit with title 'wip' (work in progress). Un-descriptive commit titles/messages are bad... as is committing a work in progress before it is finished.



Or commits which comment out code, which is, in general, bad practice (if code isn't needed it should be removed-- your version control system keeps old code if you change your mind and decide later if you need it).



The most critical commit:

https://github.com/gandrewstone/BitcoinUnlimited/commit/b126b10a1675c52acd0d7df857afe8057cfb6fb3



... doesn't seem to have any unit or regression tests. I would expect the commit message to at least say something about how the code was tested.



Andrew, do you have experience leading an open source software project? Ideally Bitcoin Unlimited would be lead by somebody who has a track record in projects that produce very high quality, reliable code (on time and under budget ) (and no, I'm not volunteering....)

I love the idea of Bitcoin Unlimited, but after doing a quick code review I just can't recommend that people run it -- there are too many "bad code smells."Examples:... which is a commit with title 'wip' (work in progress). Un-descriptive commit titles/messages are bad... as is committing a work in progress before it is finished.Or commits which comment out code, which is, in general, bad practice (if code isn't needed it should be removed-- your version control system keeps old code if you change your mind and decide later if you need it).The most critical commit:... doesn't seem to have any unit or regression tests. I would expect the commit message to at least say something about how the code was tested.Andrew, do you have experience leading an open source software project? Ideally Bitcoin Unlimited would be lead by somebody who has a track record in projects that produce very high quality, reliable code (on time and under budget) (and no, I'm not volunteering....)

More review of both core and BU is recommended and encouraged.

We shouldn't assume the Core developers or anyone else is immune from review and I believe there is always something to learn my looking over other implementations. I think it is both extremely healthy for there to be multiple implementations in our ecosystem with different project maintainers and for them to both collaborate and review each others work. We should support Core, BU , libbitcoin , and others with testing.To add to the discussion Gavin represents a qualified outside developer that conducted a very brief review of the code and this was his response-More review of both core and BU is recommended and encouraged.

adam3us





Offline



Activity: 402

Merit: 265





in bitcoin we trust







Sr. MemberActivity: 402Merit: 265in bitcoin we trust Re: bitcoin "unlimited" seeks review January 02, 2016, 07:27:16 PM #8 If you can stay on topic as I suggested: "To make progress on review it would be helpful to separate technical from political opinions." I dont see a problem. People have been discussing bitcoin NG ideas on here for years.



Are you able to explain what BU is and how you think it works? I gave some reviewer questions in the OP.



Adam

hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity

achow101

Legendary





Offline



Activity: 2254

Merit: 3454





bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl







ModeratorLegendaryActivity: 2254Merit: 3454bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl Re: bitcoin "unlimited" seeks review January 02, 2016, 07:37:06 PM #9 From what I understand, BU moves the block size limit from consensus rules to a node policy rule. Instead of having the limit hard coded in, the user chooses their own block size limit. Also if a BU node detects a blockchain that has a higher block size (up to a certain user configurable threshold), after that chain is a number of blocks deep (user configurable), then it will switch to use that blockchain and set its block size limit higher. GitHub | GPG Key Fingerprint 0x17565732E08E5E41 Bitcoin Core contributor | Tip Me!: bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl

adam3us





Offline



Activity: 402

Merit: 265





in bitcoin we trust







Sr. MemberActivity: 402Merit: 265in bitcoin we trust Re: bitcoin "unlimited" seeks review January 02, 2016, 07:41:01 PM #10 Quote from: knightdk on January 02, 2016, 07:37:06 PM From what I understand, BU moves the block size limit from consensus rules to a node policy rule. Instead of having the limit hard coded in, the user chooses their own block size limit. Also if a BU node detects a blockchain that has a higher block size (up to a certain user configurable threshold), after that chain is a number of blocks deep (user configurable), then it will switch to use that blockchain and set its block size limit higher.



So what happens if I left my node at 1MB +10% user threshold and a 1.2MB block comes - does my node reject it?



How will the network not split into a myriad little shards which diverge following accidental and/or intentional double-spends without manual human coordination?



Adam

So what happens if I left my node at 1MB +10% user threshold and a 1.2MB block comes - does my node reject it?How will the network not split into a myriad little shards which diverge following accidental and/or intentional double-spends without manual human coordination?Adam hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity

Zangelbert Bingledack



Offline



Activity: 1036

Merit: 1000







LegendaryActivity: 1036Merit: 1000 Re: bitcoin "unlimited" seeks review January 02, 2016, 08:33:32 PM

Last edit: January 02, 2016, 08:52:02 PM by Zangelbert Bingledack #11 Quote from: adam3us on January 02, 2016, 05:58:17 PM The proposal seems at first skim to be a copy of a few existing technologies from Bitcoin's roadmap and were first proposed by Greg Maxwell and others*: weak-blocks & network-compression/IBLT to reduce orphan risk, and flexcap (or a variant of it perhaps).

That is something else, perhaps from one of the research papers on future areas of interest.



Bitcoin Unlimited's main change at present is simply that, for better or worse, it makes it more convenient for miners and nodes to adjust the blocksize cap settings . This is done through a GUI menu, meaning users don't have to mod the Core code themselves like some do now. Planned improvements to BU include options that automatically mimic the blocksize settings of some Core BIPs, as well as blocksize proposals recommended by other luminaries.



The idea is that users would converge on a consensus Schelling point through various communication channels because of the overwhelming economic incentive to do so. The situation in a BU world would be no different than now except that there would be no reliance on Core (or XT) to determine from on high what the options are. BU rejects the idea that it is the job of Core (or XT, or BU) developers to govern policy on consensus or restrict the conveniently available policy options on blocksize.



BU supporters believe that to have it otherwise is the tail wagging the dog: the finding of market-favored consensus is not aided, but rather hindered, by attempts to spoonfeed consensus parameters to the users. (This is putting it gently. Having a controversial parameter set at a specific number by default would be spoonfeeding, not even having the option to change it is more like force-feeding.)



Widespread adoption of BU, or adoption of BU-like configurability of settings within Core/XT, would relegate developer-led BIPs on controversial changes to the status of mere recommendations. Proposals like 2-4-8 would be taken into consideration, but would have to compete in the market on their own without the artificial advantage of the current barrier of inconvenience and technical ability (users having to mod their code to deviate from Core settings).



BU does not support bigger blocks, nor smaller blocks; it is rather a tool for consensus on blocksize to emerge in a more natural, market-driven way - free of market intervention as it were.



Adam, if you are confident that, for instance, 2-4-8 scaling is the best option and would be supported by the market, I think you should either support BU or support a Core BIP to make the blocksize settings configurable within the Core client.



Right now the leaders of the dominant Bitcoin implementation are for a low blocksize cap, but imagine if the situation reverses and big blockists are in control, to the consternation of many in the community. I think you would not want them locking down the settings. You might say, "You folks are doing fine otherwise, but you are off on the blocksize cap. Why try to play central planner? Please leave it up to the market if you are so sure the market will like your huge blocks. People will follow your recommendations if they like them anyway, so what are you worried about?"



If I were Core maintainer, I would do the same. Perhaps I would set a higher default, but I would not take the option away from the user. To do so risks sudden consensus shocks due to friction effects, risks my position being undermined silently, and most of all assumes I know better than everyone else. I might set it at 10MB. But I may be wrong; I'd rather trust in the market, because none of us knows better than a million people all with skin in the game.



As for how communication to settle on a Schelling consensus happens, besides the usual out-of-band communication that happens now in the debate, there is also interest in adding a tool within BU to efficiently communicate information about blocksize settings across the network, thereby facilitating an emergent consensus.



Quote from: adam3us on January 02, 2016, 05:58:17 PM dynamic block-size game-theory

The game theory is the same as that arising in the choice of Core vs. XT vs. whatever (or among the BIPs by the miners and other stakeholders; if we look at the game theoretic considerations applying to the Core dev consensus process I'm sure you realize that problem is intractable). Miners and nodes have all the same choices now, except there is some additional friction introduced by Core's locking down of the blocksize settings, forcing miners and nodes to mod the Core code if they want to change them.



The question ought to be turned around: what are the game-theoretic considerations involved in having a monolithic reference client causing complicated issues of inertia, authority, and potential power grabs on top of the cleaner game theory? If tractability of a game theory analysis is the goal, surely BU is at least no more complicated than the situation under Core in the event of a hard fork.



Quote from: adam3us on January 02, 2016, 05:58:17 PM How will the network not split into a myriad little shards without manual human coordination?

Ah. This is good. What I believe you are not noticing is that "manual human coordination" need not be top-down. Coordination can emerge, and it can be just as solid as any. Are you familiar with That is something else, perhaps from one of the research papers on future areas of interest.Bitcoin Unlimited's main change at present is simply that, for better or worse, it. This is done through a GUI menu, meaning users don't have to mod the Core code themselves like some do now. Planned improvements to BU include options that automatically mimic the blocksize settings of some Core BIPs, as well as blocksize proposals recommended by other luminaries.The idea is that users would converge on a consensus Schelling point through various communication channels because of the overwhelming economic incentive to do so. The situation in a BU world would be no different than now except that there would be no reliance on Core (or XT) to determine from on high what the options are. BU rejects the idea that it is the job of Core (or XT, or BU) developers to govern policy on consensus or restrict the conveniently available policy options on blocksize.BU supporters believe that to have it otherwise is the tail wagging the dog: the finding of market-favored consensus is not aided, but rather hindered, by attempts to spoonfeed consensus parameters to the users. (This is putting it gently. Having a controversial parameter set at a specific number by default would be spoonfeeding, not even having the option to change it is more like force-feeding.)Widespread adoption of BU, or adoption of BU-like configurability of settings within Core/XT, would relegate developer-led BIPs on controversial changes to the status of mere recommendations. Proposals like 2-4-8 would be taken into consideration, but would have to compete in the market on their own without the artificial advantage of the current barrier of inconvenience and technical ability (users having to mod their code to deviate from Core settings).BU does not support bigger blocks, nor smaller blocks; it is rather a tool for consensus on blocksize to emerge in a more natural, market-driven way - free of market intervention as it were.Adam, if you are confident that, for instance, 2-4-8 scaling is the best option and would be supported by the market, I think you should either support BU or support a Core BIP to make the blocksize settings configurable within the Core client.Right now the leaders of the dominant Bitcoin implementation are for a low blocksize cap, but imagine if the situation reverses and big blockists are in control, to the consternation of many in the community. I think you would not want them locking down the settings. You might say, "You folks are doing fine otherwise, but you are off on the blocksize cap. Why try to play central planner? Please leave it up to the market if you are so sure the market will like your huge blocks. People will follow your recommendations if they like them anyway, so what are you worried about?"If I were Core maintainer, I would do the same. Perhaps I would set a higher default, but I would not take the option away from the user. To do so risks sudden consensus shocks due to friction effects, risks my position being undermined silently, and most of all assumes I know better than everyone else. I might set it at 10MB. But I may be wrong; I'd rather trust in the market, because none of us knows better than a million people all with skin in the game.As for how communication to settle on a Schelling consensus happens, besides the usual out-of-band communication that happens now in the debate, there is also interest in adding a tool within BU to efficiently communicate information about blocksize settings across the network, thereby facilitating an emergent consensus.The game theory is the same as that arising in the choice of Core vs. XT vs. whatever (or among the BIPs by the miners and other stakeholders; if we look at the game theoretic considerations applying to the Core dev consensus process I'm sure you realize that problem is intractable). Miners and nodes have all the same choices now, except there is some additional friction introduced by Core's locking down of the blocksize settings, forcing miners and nodes to mod the Core code if they want to change them.The question ought to be turned around: what are the game-theoretic considerations involved in having a monolithic reference client causing complicated issues of inertia, authority, and potential power grabs on top of the cleaner game theory? If tractability of a game theory analysis is the goal, surely BU is at least no more complicated than the situation under Core in the event of a hard fork.Ah. This is good. What I believe you are not noticing is that "manual human coordination" need not be top-down. Coordination can emerge, and it can be just as solid as any. Are you familiar with situations where it does? That would save a lot of ink.

JackH



Offline



Activity: 381

Merit: 250







Sr. MemberActivity: 381Merit: 250 Re: bitcoin "unlimited" seeks review January 02, 2016, 08:40:38 PM #12 From a pure tech point of view, what is stopping the sybil attack on BU?



Without having dug much into it, can you answer what there is in place to stop me from setting up 2000+ nodes and adjusting the blocksize to 200MB per block, and thus subverting the entire network to form consensus on a smaller size? <helo> funny that this proposal grows the maximum block size to 8GB, and is seen as a compromise

<helo> oh, you don't like a 20x increase? well how about 8192x increase?

<JackH> lmao

sAt0sHiFanClub



Offline



Activity: 532

Merit: 500





Warning: Confrmed Gavinista







Hero MemberActivity: 532Merit: 500Warning: Confrmed Gavinista Re: bitcoin "unlimited" seeks review January 02, 2016, 08:55:58 PM #13 Quote from: JackH on January 02, 2016, 08:40:38 PM From a pure tech point of view, what is stopping the sybil attack on BU?



Without having dug much into it, can you answer what there is in place to stop me from setting up 2000+ nodes and adjusting the blocksize to 200MB per block, and thus subverting the entire network to form consensus on a smaller size?



Nodes decide how they play the game. If they feel that 2000 nodes suddenly appearing on the horizon demanding 200MB blocks is the way forward, then thats what they do. If, on the other hand, they are rational, then they wont.



I thought we were discussing how it works, you are discussing how to attack it. Nodes decide how they play the game. If they feel that 2000 nodes suddenly appearing on the horizon demanding 200MB blocks is the way forward, then thats what they do. If, on the other hand, they are rational, then they wont.I thought we were discussing how it works, you are discussing how to attack it. We must make money worse as a commodity if we wish to make it better as a medium of exchange

Zangelbert Bingledack



Offline



Activity: 1036

Merit: 1000







LegendaryActivity: 1036Merit: 1000 Re: bitcoin "unlimited" seeks review January 02, 2016, 09:02:55 PM #14 There's nothing stopping an attacker from modding the Core client themselves and setting up 2000 nodes with 200MB blocks. Or at least, it's not the little bit of C++ coding that's likely going to be what stops them.



Bitcoin Unlimited is NOT a big blocks client, let alone an "unlimited blocksize" client. The "unlimited" only refers to unlimited options. At this time, BU is simply Core + a few options. They can all be turned off to mimic Core exactly.

BitUsher



Offline



Activity: 994

Merit: 1027







LegendaryActivity: 994Merit: 1027 Re: bitcoin "unlimited" seeks review January 02, 2016, 09:05:55 PM #15 Quote from: sAt0sHiFanClub on January 02, 2016, 08:55:58 PM



I thought we were discussing how it works, you are discussing how to attack it.

Nodes decide how they play the game. If they feel that 2000 nodes suddenly appearing on the horizon demanding 200MB blocks is the way forward, then thats what they do. If, on the other hand, they are rational, then they wont.I thought we were discussing how it works, you are discussing how to attack it.

Discussing its strengths and weaknesses is one of the best ways to understand how it works. Isn't it rational for many to attack the network? Don't we have to prepare for sybil attacks in a hostile environment? Shouldn't we design a network that isn't dependent upon rational actors with goodwill intent and is protected against both irrational actors, actors with malicious intent, and mistakes due to incompetance, shortcuts, or ignorance?



Quote from: Zangelbert Bingledack on January 02, 2016, 09:02:55 PM



BU is NOT a big blocks client, let alone an "unlimited blocksize" client. The "unlimited" only refers to unlimited options. At this time, BU is simply Core + a few options. They can all be turned off to mimic Core.

There's nothing stopping an attacker from modding the Core client themselves and setting up 2000 nodes with 200MB blocks. Or at least, it's not the little bit of C++ coding that's likely going to be what stops themBU is NOT a big blocks client, let alone an "unlimited blocksize" client. The "unlimited" only refers to unlimited options. At this time, BU is simply Core + a few options. They can all be turned off to mimic Core.

Isn't the difference being that BU will allow maxBlockSize to be determined by nodes and core/xt/ect... insures that miners make that decision, or am I missing something? Discussing its strengths and weaknesses is one of the best ways to understand how it works. Isn't it rational for many to attack the network? Don't we have to prepare for sybil attacks in a hostile environment? Shouldn't we design a network that isn't dependent upon rational actors with goodwill intent and is protected against both irrational actors, actors with malicious intent, and mistakes due to incompetance, shortcuts, or ignorance?Isn't the difference being that BU will allow maxBlockSize to be determined by nodes and core/xt/ect... insures that miners make that decision, or am I missing something?

Zangelbert Bingledack



Offline



Activity: 1036

Merit: 1000







LegendaryActivity: 1036Merit: 1000 Re: bitcoin "unlimited" seeks review January 02, 2016, 09:10:17 PM

Last edit: January 02, 2016, 09:23:28 PM by Zangelbert Bingledack #17 Quote from: BitUsher on January 02, 2016, 09:05:55 PM Isn't the difference being that BU will allow maxBlockSize to be determined by nodes and core/xt/ect... insures that miners make that decision, or am I missing something?

Well, that is already the case. BU just makes it more convenient. And granular: you don't just have a choice between Core@1MB and XT@8MB+, but rather anything - but the increased number of options doesn't mean users can't converge on a Schelling point; more options doesn't mean more viable options.



I imagine a series of jumps from one Schelling-point consensus to the next. For example, first everyone warily converges on Pieter's very conservative BIP (+17%/year), then as capacity increases faster than expected people jump to Adam's 2-4-8, then an unforeseen adoption surge induces a jump to BIP101, and finally people see where this is going and nodes/miners - as the foremost experts on the network - move independently of the devs to create their own Schelling points.



A specialization and division of labor would occur as it should in any mature industry, with consensus-parameter-setting unbundled from the software offerings of Core/etc. People would "hire" the Core/etc. devs for their secure code, not for their determining of consensus parameters. Those would be set by the larger market, reacting dynamically to market conditions. To do otherwise is arguably a security risk as it concentrates power in one team of devs. Well, that is already the case. BU just makes it more convenient. And granular: you don't just have a choice between Core@1MB and XT@8MB+, but rather anything - but the increased number of options doesn't mean users can't converge on a Schelling point; more options doesn't mean moreoptions.I imagine a series of jumps from one Schelling-point consensus to the next. For example, first everyone warily converges on Pieter's very conservative BIP (+17%/year), then as capacity increases faster than expected people jump to Adam's 2-4-8, then an unforeseen adoption surge induces a jump to BIP101, and finally people see where this is going and nodes/miners - as the foremost experts on the network - move independently of the devs to create their own Schelling points.A specialization and division of labor would occur as it should in any mature industry, with consensus-parameter-setting unbundled from the software offerings of Core/etc. People would "hire" the Core/etc. devs for their secure code, not for their determining of consensus parameters. Those would be set by the larger market, reacting dynamically to market conditions. To do otherwise is arguably a security risk as it concentrates power in one team of devs.

BitUsher



Offline



Activity: 994

Merit: 1027







LegendaryActivity: 994Merit: 1027 Re: bitcoin "unlimited" seeks review January 02, 2016, 09:15:11 PM #18 Quote from: Zangelbert Bingledack on January 02, 2016, 09:10:17 PM Quote from: BitUsher on January 02, 2016, 09:05:55 PM Isn't the difference being that BU will allow maxBlockSize to be determined by nodes and core/xt/ect... insures that miners make that decision, or am I missing something?

Well, that is already the case. BU just makes it more convenient.

Well, that is already the case. BU just makes it more convenient.

True, I suppose nodes can already break off from the main chain with little to no hashing security and create their own chain. You are suggesting that in BU a sybil attack is made easier though as the incentive structures under core and xt is to stay on the chain with the majority hashing security? It is far easier and less expensive to spin up a bunch of nodes than replicate replicate the hashing power. Would you agree or disagree? True, I suppose nodes can already break off from the main chain with little to no hashing security and create their own chain. You are suggesting that in BU a sybil attack is made easier though as the incentive structures under core and xt is to stay on the chain with the majority hashing security? It is far easier and less expensive to spin up a bunch of nodes than replicate replicate the hashing power. Would you agree or disagree?

Zangelbert Bingledack



Offline



Activity: 1036

Merit: 1000







LegendaryActivity: 1036Merit: 1000 Re: bitcoin "unlimited" seeks review January 02, 2016, 09:17:56 PM #19 I would say a Sybil attacker with the resources to cook up 1000 nodes will have no trouble modding a bit of C++ code or hiring a coder to do that. That's the least of the barriers, and even if it were to be relied on, that would be a losing battle. If inconvenience were all that is keeping Bitcoin secure, we would have a problem. Also see my edit to the post immediately above yours.