[bitcoin-dev] Sidechains pre-BIP Discussion
Dear list,
This message concerns pegged "sidechains", namely the Two Way Peg [1].
Specifically, it is to introduce a new OP Code (perhaps called
"OP_CheckVotesVerify"). This OP code can be deployed by soft fork, and
has (as we all probably know) many benefits, including:
1. ("Optional hard forks") Sidechains allow 'opt in' adoption of new
features. As a result, Bitcoin (the bearer asset, not the software) will
never need to worry about competing with an alternate system. This
includes competitors such as Ripple or Ethereum (supposedly
"innovative"), as well as BitcoinXT and Bitcoin Classic (supposedly
"popular").
2. ("Staging Upgrades") SCs allow complex updates to Bitcoin to be
tested, in a realistic environment (where actual BTC are at risk, and
utilizing actual network mining resources). If these updates fail, they
can be revised; if they succeed, they can be incorporated into the
mainchain.
3. Directing "blockchain resources" to Bitcoin. This includes money,
developer talent, public attention, etc.
4. Less time spent debating controversial features. Instead, we return
to a culture of "permissionless innovation".
Again, as we all know, the concept has generally received high interest
and favorable appraisal.
--
However, this feature has highly complex effects on the Bitcoin
ecosystem, and so the details should command our full attention.
First, the deployment of this OP Code involves new block validation
rules ("Drivechain") which are described on my blog [2].
In addition to that post, I intend to release short presentations:
1. On the overall design justification.
2. On "Enforcing Limits on Shared Resources". This explores the
potential for SCs to have a detrimental effect on users of vanilla BTC,
and how this proposal confronts these problems.
3. On the governance of SCs-- aka the degree of 'coupling',
inter-relatedness, and/or hierarchy --- and how Drivechain's design acts
to maximize the total value of the "chain portfolio".
My purpose, in emailing today, is to begin the conversation. The scope
of the concept is simply too large, to draft a readable BIP without
knowing what the actual points of interest are. Please express your
reactions!
Thank you for reading,
Paul
P.S. In assessing the proposal, you may find a recent technical paper
[3] by Sergio Demian Lerner to be of interest.
--
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-March/004724.html
[2] http://www.truthcoin.info/blog/drivechain/
[3] http://www.rootstock.io/#resources (
https://uploads.strikinglycdn.com/files/27311e59-0832-49b5-ab0e-2b0a73899561/Drivechains_Sidechains_and_Hybrid_2-way_peg_Designs_R9.pdf
)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Proposal to update BIP-32
Hello Bitcoin Developers, I would like to make a proposal to update BIP-32 in a small way. TL;DR: BIP-32 is hard to use right (due to its requirement to skip addresses). This proposal suggests a modification such that the difficulty can be encapsulated in the library. #MOTIVATION: The current BIP-32 specifies that if for some node in the hierarchy the computed hash I_L is larger or equal to the prime or 0, then the node is invalid and should be skipped in the BIP-32 tree. This has several unfortunate consequences: - All callers of CKDpriv or CKDpub have to check for errors and handle them appropriately. This shifts the burden to the application developer instead of being able to handle it in the BIP-32 library. - It is not clear what to do if an intermediate node is missing. E.g. for the default wallet layout, if m/i_H/0 is missing should m/i_H/1 be used for external chain and m/i_H/2 for internal chain? This would make the wallet handling much more difficult. - It gets even worse with standards like BIP-44. If m/44' is missing should we use m/45' instead? If m/44'/0' is missing should we use m/44'/1' instead, using the same addresses as for testnet? One could also restart with a different seed in this case, but this wouldn't work if one later wants to support another BIP-43 proposal and still keep the same wallet. I think the first point alone is reason enough to change this. I am not aware of a BIP-32 application that handles errors like this correctly in all cases. It is also very hard to test, since it is infeasible to brute-force a BIP-32 key and a path where the node does not exists. This problem can be avoided by repeating the hashing with slightly different input data until a valid private key is found. This would be in the same spirit as RFC-6979. This way, the library will always return a valid node for all paths. Of course, in the case where the node is valid according to the current standard the behavior should be unchanged. I think the backward compatibility issues are minimal. The chance that this affects anyone is less than 10^-30. Even if it happens, it would only create some additional addresses (that are not seen if the user downgrades). The main reason for suggesting a change is that we want a similar method for different curves where a collision is much more likely. #QUESTIONS: What is the procedure to update the BIP? Is it still possible to change the existing BIP-32 even though it is marked as final? Or should I make a new BIP for this that obsoletes BIP-32? What algorithm is preferred? (bike-shedding) My suggestion: --- Change the last step of the private -> private derivation functions to: . In case parse(I_L) >= n or k_i = 0, the procedure is repeated at step 2 with I = HMAC-SHA512(Key = c_par, Data = 0x01 || I_R || ser32(i)) --- I think this suggestion is simple to implement (a bit harder to unit test) and the string to hash with HMAC-SHA512 always has the same length. I use I_R, since I_L is obviously not very random if I_L >= n. There is a minimal chance that it will lead to an infinite loop if I_R is the same in two consecutive iterations, but that has only a chance of 1 in 2^512 (if the algorithm is used for different curves that make I_L >= n more likely, the chance is still less than 1 in 2^256). In theory, this loop can be avoided by incrementing i in every iteration, but this would make an implementation error in the "hard to test" path of the program more likely. The other derivation functions should be updated in a similar matter. Also the derivation of the root node from the seed should be updated in a similar matter to avoid invalid seeds. If you followed until here, thanks for reading this long posting. Jochen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
