Re: [bitcoin-dev] libconsensus and bitcoin development process
I also share a lot of Jeff's concerns about refactoring and have voiced them several times on IRC and in private to Jorge, Wladamir and Greg. I meant to do a write up but never got around to it. Jeff has quite eloquently stated the various problems. I would like to share my thoughts on the matter because we really do need to come up with a plan on how this issue is dealt with. Obviously, Bitcoin Core is quite tightly coupled at the moment and definitely needs extensive modularisation. Such work will inevitably require lots of bulk code moves and then finer refactoring. However, it requires proper planning because there are lots of effects and consequences for other people contributing to Core and also downstream projects relying on Core: 1. Refactoring often causes other pull requests to diverge and require rebasing. Continual refactoring can put PRs in "rebase hell" and puts a big stress on contributors (many of whom are part time). 2. Version to version, Bitcoin Core changes significantly in structure. 0.9 to 0.10 is unrecognisable. 0.10 to 0.11 is even more so. This makes makes it hard to follow release to release and the net result is less people upgrade (especially think of miners trying to keep their patch sets working while trying not to disrupt or risk their mining operations). 3. Continual refactoring increases risk: we're human, and mistakes will slip through peer review. This is especially concerning with consensus critical code and this makes it difficult to merge such refactoring often, which of course exacerbates the problem. The net negative consequence is it is harder to contribute to Core, harder for the Core maintainers to merge and harder for downstream/dependent projects/implementations to keep up. Suggested Way Forward - With the understanding that refactored code by definition must not change behaviour. There are three major kinds of refactoring: 1. code moves (e.g. separating concerns into different files); 2. code style; 3. structural optimisation and consolidation (reducing LOC, separating concerns, encapsulation etc). Code moves(1) and CS(2) are easy to peer review and merge quickly. The third kind(3) requires deeper analysis to ensure that while the code changed, the behaviour (including any bugs) did not. We must resist all temptation to fix bugs or tack on minor fixes and tweaks during refactoring: pull requests should only be refactoring only, with no net change to behaviour. Keeping discipline makes it much easier to verify and peer review and this faster to merge. With respect to Code moves and CS, I believe we should have a "refactoring fortnight" where we so the bulk of code move-only refactoring plus CS where necessary. This is by fat the most disruptive kind of change because it widely affects other PRs mergeability. We should aim to get most of this done in one go, so that it's not happening in dribs and drabs over months and many releases. Once done, it gives everyone a good idea to the overall new structure and where one can expect to find things in the future. The idea here is to help orientation and not have to continuously hunt for where things have moved to. To be clear, I am strongly suggesting code move-only refactoring PRs not be mixed with anything else. Same for CS changes. This makes the PRs extremely easy to vet and thus quick to merge. Towards this end, maybe there should be an IRC meeting to agree the initial moves, then someone who has the stomach for it can get on and do it - during that time, we do not merge anything else. We need to bite the bullet and break the back out of code moves. With regards to CS, I think we do need to get CS right, because a continual dribble of CS changes also makes diffs between releases less easy to follow. Much of CS checking can be automated by the continuous integration so authors can get it right easily. It can be just like a Travis check. With respect to the 3rd kind of refactoring, we need to set some standards and goals and aim for some kind of consistency. Refactoring needs to fulfil certain goals and criterion otherwise contributors will always find a reason to fiddle over and over forever. Obvious targets here can be things like proper encapsulation and separation of concerns. Overall, refactoring should be merged quickly, but only on a schedule so it doesn't cause major disruption to others. Obviously the third kind of refactoring more complex and time consuming and will need to occur over time, but it should happen in defined steps. As Jeff said, one week a month, or maybe one month a release. In any case, refactoring changes should be quickly accepted or rejected by the project maintainer and not left hanging. Finally, refactoring should *always* be uncontroversial because essentially functionality is not changing. If functionality changes (e.g. you try to sneak in a big fix or feature tweak "because it's small") the PR should be rejected outright. Additionally
Re: [bitcoin-dev] URI scheme for signing and verifying messages
September 15 2015 6:04 AM, "Luke Dashjr" wrote: > I think probably the whole signed message thing needs to be rethought. The > most common "uses" today seem to be insecure cases that it doesn't actually > work in: people trying to prove ownership of bitcoins and/or that they sent > bitcoins (current signed messages can do neither). Ideally, whatever the new > method is should also avoid using the same key as for signing transactions, > since the public key is technically private information. Furthermore, since > addresses are semi-deprecated (by the payment protocol), I'm not sure it > makes sense to do this without designing an entire authentication system, > which may be rather complex. > > Luke My proposal is about the current signing process (which exists event it it's not perfect) but it could also work with a new signing message system tomorrow. It more about give users an easier way to access existing tools than the "sign message thing" itself. BTW I'm aware of privacy issues, but could you elaborate on why the use case your are referring to doesn't actually work? Here are a use of bitcoin signatures ( https://bitcointalk.org/index.php?topic=497545.0 ) to speak about a real case. -- Arthur ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Instant exchange rates URI scheme
Hello, I'd like to propose a BIP for a standard URI scheme to allow wallet operators that implement instant exchange or pegging to other currencies, cryptocurrencies or asset classes to allow for interoperable communications of rates and other pertinent information. The idea is to include in the wallet address as parameters information that supplements the presentation of a proposed transaction. For example, a wallet operator that instantly exchanges bitcoin to gold would present a wallet address as follows: bitcoin:1JohnxNT6jRzhu3H1wgVFbSGKmHP4EUjUV?currency=xau&rate=0.2084&expires=1458432000 Wherein: : the currency, cryptocurrency or asset that the transaction will end up as encoded in ISO 4217 if applicable. : the bitcoin to rate as dictated by receiving wallet : unix timestamp of when the rate loses validity This would allow the sending wallet the ability to present up-to-date exchange rates. When, for example, a wallet operator that pegs to the USD scans the address above, it would be able to present to the user the following information: 1. USD to XAU rate 2. How much XAU will be received by the address 3. How long before the rates expires Thoughts? Regards, John ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] URI scheme for signing and verifying messages
On Tuesday, September 15, 2015 10:49:36 AM Arthur - bitcoin-fr.io wrote: > September 15 2015 6:04 AM, "Luke Dashjr" wrote: > > I think probably the whole signed message thing needs to be rethought. > > The most common "uses" today seem to be insecure cases that it doesn't > > actually work in: people trying to prove ownership of bitcoins and/or > > that they sent bitcoins (current signed messages can do neither). > > Ideally, whatever the new method is should also avoid using the same key > > as for signing transactions, since the public key is technically private > > information. Furthermore, since addresses are semi-deprecated (by the > > payment protocol), I'm not sure it makes sense to do this without > > designing an entire authentication system, which may be rather complex. > > > > Luke > > My proposal is about the current signing process (which exists event it > it's not perfect) but it could also work with a new signing message system > tomorrow. It more about give users an easier way to access existing tools > than the "sign message thing" itself. One of my concerns is that making the existing signatures even easier will cause incompatible uses to become more prolific and accepted, increasing the overall risk. Hence my recommendation to satisfy these clearly-existing use cases with a safe signature *first*. > BTW I'm aware of privacy issues, but could you elaborate on why the use > case your are referring to doesn't actually work? The signed message proves that the person who *receives* payment with the address agrees to a given message/contract. It is therefore appropriate and a best practice for web wallet providers (inherent problems with webwallets aside) to allow users to sign messages with their deposit addresses. When bitcoins are received by this address, the transaction creates a low-level UTXO representing the bitcoins *in the wallet*, but this UTXO is not associated with the address itself. Therefore, it is entirely possible that this UTXO remains unspent/valid on the blockchain even after the user in question has spent their entire balance at the webwallet and therefore such a signature proves only that they once received the payment, but *not* that they presently still have the bitcoins received. Furthermore, it is proper for the UTXO to be redeemed at a low-level by the wallet when an entirely unrelated user is sending a transaction. In such a circumstance, the original recipient of the bitcoins would still be able to sign a message, even though they have nothing to do with nor any right to the goods/services purchased with the transaction redeeming that UTXO. > Here are a use of > bitcoin signatures ( https://bitcointalk.org/index.php?topic=497545.0 ) to > speak about a real case. Yes, there are a few good use cases for the current signed messages, but they appear to be a minority at the moment. I suspect implementing any URI-based signing would actually make them more difficult as well, since it is additional code on the requester's part. Luke ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Instant exchange rates URI scheme
might want to specify there that the rate being sent is out of USD. http://twitter.com/gubatron On Tue, Sep 15, 2015 at 7:10 AM, John Bailon via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello, > > I'd like to propose a BIP for a standard URI scheme to allow wallet > operators that implement instant exchange or pegging to other currencies, > cryptocurrencies or asset classes to allow for interoperable communications > of rates and other pertinent information. > > The idea is to include in the wallet address as parameters information > that supplements the presentation of a proposed transaction. > > For example, a wallet operator that instantly exchanges bitcoin to gold > would present a wallet address as follows: > > bitcoin:1JohnxNT6jRzhu3H1wgVFbSGKmHP4EUjUV?currency=xau&rate=0.2084&expires=1458432000 > > Wherein: > : the currency, cryptocurrency or asset that the transaction > will end up as encoded in ISO 4217 if applicable. > : the bitcoin to rate as dictated by receiving wallet > : unix timestamp of when the rate loses validity > > This would allow the sending wallet the ability to present up-to-date > exchange rates. When, for example, a wallet operator that pegs to the USD > scans the address above, it would be able to present to the user the > following information: > > 1. USD to XAU rate > 2. How much XAU will be received by the address > 3. How long before the rates expires > > > Thoughts? > > > Regards, > John > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Instant exchange rates URI scheme
Wouldn't need to. The is of BTC to . BTC is the intermediary currency, as is basically how it becomes in this "payment rails" method. To the receiver, it wouldn't matter what currency the transaction came from. On Tue, Sep 15, 2015 at 8:48 PM, Angel Leon wrote: > might want to specify there that the rate being sent is out of USD. > http://twitter.com/gubatron > On Tue, Sep 15, 2015 at 7:10 AM, John Bailon via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: >> Hello, >> >> I'd like to propose a BIP for a standard URI scheme to allow wallet >> operators that implement instant exchange or pegging to other currencies, >> cryptocurrencies or asset classes to allow for interoperable communications >> of rates and other pertinent information. >> >> The idea is to include in the wallet address as parameters information >> that supplements the presentation of a proposed transaction. >> >> For example, a wallet operator that instantly exchanges bitcoin to gold >> would present a wallet address as follows: >> >> bitcoin:1JohnxNT6jRzhu3H1wgVFbSGKmHP4EUjUV?currency=xau&rate=0.2084&expires=1458432000 >> >> Wherein: >> : the currency, cryptocurrency or asset that the transaction >> will end up as encoded in ISO 4217 if applicable. >> : the bitcoin to rate as dictated by receiving wallet >> : unix timestamp of when the rate loses validity >> >> This would allow the sending wallet the ability to present up-to-date >> exchange rates. When, for example, a wallet operator that pegs to the USD >> scans the address above, it would be able to present to the user the >> following information: >> >> 1. USD to XAU rate >> 2. How much XAU will be received by the address >> 3. How long before the rates expires >> >> >> Thoughts? >> >> >> Regards, >> John >> >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >>___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] URI scheme for signing and verifying messages
September 15 2015 2:10 PM, "Luke Dashjr" wrote: > On Tuesday, September 15, 2015 10:49:36 AM Arthur - bitcoin-fr.io wrote: > >> September 15 2015 6:04 AM, "Luke Dashjr" wrote: >>> I think probably the whole signed message thing needs to be rethought. >>> The most common "uses" today seem to be insecure cases that it doesn't >>> actually work in: people trying to prove ownership of bitcoins and/or >>> that they sent bitcoins (current signed messages can do neither). >>> Ideally, whatever the new method is should also avoid using the same key >>> as for signing transactions, since the public key is technically private >>> information. Furthermore, since addresses are semi-deprecated (by the >>> payment protocol), I'm not sure it makes sense to do this without >>> designing an entire authentication system, which may be rather complex. >>> >>> Luke >> >> My proposal is about the current signing process (which exists event it >> it's not perfect) but it could also work with a new signing message system >> tomorrow. It more about give users an easier way to access existing tools >> than the "sign message thing" itself. > > One of my concerns is that making the existing signatures even easier will > cause incompatible uses to become more prolific and accepted, increasing the > overall risk. Hence my recommendation to satisfy these clearly-existing use > cases with a safe signature *first*. > Ideally yes, but it will take some time to make a new signature system. I could also propose a URI scheme that will work with a future implementation but be compatible with the current one explaining its limitations (ex: sigversion=1 to use the current system, default value is sigversion=2 which won't work until a new system is developped). >> BTW I'm aware of privacy issues, but could you elaborate on why the use >> case your are referring to doesn't actually work? > > The signed message proves that the person who *receives* payment with the > address agrees to a given message/contract. > > It is therefore appropriate and a best practice for web wallet providers > (inherent problems with webwallets aside) to allow users to sign messages > with their deposit addresses. When bitcoins are received by this address, the > transaction creates a low-level UTXO representing the bitcoins *in the > wallet*, but this UTXO is not associated with the address itself. Therefore, > it is entirely possible that this UTXO remains unspent/valid on the > blockchain even after the user in question has spent their entire balance at > the webwallet and therefore such a signature proves only that they once > received the payment, but *not* that they presently still have the bitcoins > received. > > Furthermore, it is proper for the UTXO to be redeemed at a low-level by the > wallet when an entirely unrelated user is sending a transaction. In such a > circumstance, the original recipient of the bitcoins would still be able to > sign a message, even though they have nothing to do with nor any right to the > goods/services purchased with the transaction redeeming that UTXO. > >> Here are a use of >> bitcoin signatures ( https://bitcointalk.org/index.php?topic=497545.0 ) to >> speak about a real case. > > Yes, there are a few good use cases for the current signed messages, but they > appear to be a minority at the moment. I suspect implementing any URI-based > signing would actually make them more difficult as well, since it is > additional code on the requester's part. Ok,thx for your answer, I actually agree with you up until the last sentence. (if not I wouldn't propose this URI scheme :-) -- Arthur ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Instant exchange rates URI scheme
Something very similar was posted not too long ago. Long and sort of it is, there is no point in saying you priced in GBP, etc, because it can vary from exchange to exchange. To be honest, adding more things to consider at checkout time confuses things; why not just specify the amount of Bitcoin you wish to be paid? On 15 Sep 2015 11:11 am, "John Bailon via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello, > > I'd like to propose a BIP for a standard URI scheme to allow wallet > operators that implement instant exchange or pegging to other currencies, > cryptocurrencies or asset classes to allow for interoperable communications > of rates and other pertinent information. > > The idea is to include in the wallet address as parameters information > that supplements the presentation of a proposed transaction. > > For example, a wallet operator that instantly exchanges bitcoin to gold > would present a wallet address as follows: > > bitcoin:1JohnxNT6jRzhu3H1wgVFbSGKmHP4EUjUV?currency=xau&rate=0.2084&expires=1458432000 > > Wherein: > : the currency, cryptocurrency or asset that the transaction > will end up as encoded in ISO 4217 if applicable. > : the bitcoin to rate as dictated by receiving wallet > : unix timestamp of when the rate loses validity > > This would allow the sending wallet the ability to present up-to-date > exchange rates. When, for example, a wallet operator that pegs to the USD > scans the address above, it would be able to present to the user the > following information: > > 1. USD to XAU rate > 2. How much XAU will be received by the address > 3. How long before the rates expires > > > Thoughts? > > > Regards, > John > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Instant exchange rates URI scheme
This scheme would mostly be beneficial to end users of instant exchange wallets and would be implemented by the operators. None of the parameters would be filled up by the user by hand. It's more of enabling different wallet operators to communicate with each other and to be able to present to their end users the rates they are getting when sending from their pegged wallet to another pegged wallet. Abstracting bitcoin rates from both end users. To illustrate, imagine Alice who has a USD wallet wants to send JPY 10,000 to Bob who has a JPY pegged wallet. Alice's wallet scans Bob's wallet which tells Alice's wallet the following info: 1. Bob's BTC address 2. Bob's wallet currency is JPY 3. Bob's wallet operator is pricing BTC 1 at JPY 27,779 for the next 5 minutes. With these info, Alice's wallet can already derive the following: Alice needs to send 0.35998416 BTC to send JPY 10,000. Alice's wallet can also show how much 0.35998416 BTC is in USD, which is USD 83.27. Alice's wallet can present it as follows; "You are sending JPY 10,000 for USD 83.27 to Bob's wallet." On Tue, Sep 15, 2015 at 10:40 PM, Thomas Kerin wrote: > Something very similar was posted not too long ago. > Long and sort of it is, there is no point in saying you priced in GBP, etc, > because it can vary from exchange to exchange. > To be honest, adding more things to consider at checkout time confuses > things; why not just specify the amount of Bitcoin you wish to be paid? > On 15 Sep 2015 11:11 am, "John Bailon via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org> wrote: >> Hello, >> >> I'd like to propose a BIP for a standard URI scheme to allow wallet >> operators that implement instant exchange or pegging to other currencies, >> cryptocurrencies or asset classes to allow for interoperable communications >> of rates and other pertinent information. >> >> The idea is to include in the wallet address as parameters information >> that supplements the presentation of a proposed transaction. >> >> For example, a wallet operator that instantly exchanges bitcoin to gold >> would present a wallet address as follows: >> >> bitcoin:1JohnxNT6jRzhu3H1wgVFbSGKmHP4EUjUV?currency=xau&rate=0.2084&expires=1458432000 >> >> Wherein: >> : the currency, cryptocurrency or asset that the transaction >> will end up as encoded in ISO 4217 if applicable. >> : the bitcoin to rate as dictated by receiving wallet >> : unix timestamp of when the rate loses validity >> >> This would allow the sending wallet the ability to present up-to-date >> exchange rates. When, for example, a wallet operator that pegs to the USD >> scans the address above, it would be able to present to the user the >> following information: >> >> 1. USD to XAU rate >> 2. How much XAU will be received by the address >> 3. How long before the rates expires >> >> >> Thoughts? >> >> >> Regards, >> John >> >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >>___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] libconsensus and bitcoin development process
Drak, I would say that the refactoring does actually fulfill some conditions you mention: - move-only is almost always clearly separated out - the refactoring is not controversial _in minimis_ - meaning, the individual pull request is not controversial. The problem comes with the impact of an unfocused stream of refactors to key code. For example, there is much less long term developer impact if refactoring were _accelerated_, scheduled to be performed in a one-week sprint. There is a lot of breakage, yes, but after that week the average level of downstream patch breakage is significantly lower. A "rip the band-aid off quickly rather than slowly" approach. On Tue, Sep 15, 2015 at 5:55 AM, Btc Drak wrote: > I also share a lot of Jeff's concerns about refactoring and have voiced > them several times on IRC and in private to Jorge, Wladamir and Greg. I > meant to do a write up but never got around to it. Jeff has quite > eloquently stated the various problems. I would like to share my thoughts > on the matter because we really do need to come up with a plan on how this > issue is dealt with. > > Obviously, Bitcoin Core is quite tightly coupled at the moment and > definitely needs extensive modularisation. Such work will inevitably > require lots of bulk code moves and then finer refactoring. However, it > requires proper planning because there are lots of effects and consequences > for other people contributing to Core and also downstream projects relying > on Core: > > 1. Refactoring often causes other pull requests to diverge and require > rebasing. Continual refactoring can put PRs in "rebase hell" and puts a big > stress on contributors (many of whom are part time). > > 2. Version to version, Bitcoin Core changes significantly in structure. > 0.9 to 0.10 is unrecognisable. 0.10 to 0.11 is even more so. This makes > makes it hard to follow release to release and the net result is less > people upgrade (especially think of miners trying to keep their patch sets > working while trying not to disrupt or risk their mining operations). > > 3. Continual refactoring increases risk: we're human, and mistakes will > slip through peer review. This is especially concerning with consensus > critical code and this makes it difficult to merge such refactoring often, > which of course exacerbates the problem. > > The net negative consequence is it is harder to contribute to Core, harder > for the Core maintainers to merge and harder for downstream/dependent > projects/implementations to keep up. > > Suggested Way Forward > - > > With the understanding that refactored code by definition must not change > behaviour. There are three major kinds of refactoring: > > 1. code moves (e.g. separating concerns into different files); > 2. code style; > 3. structural optimisation and consolidation (reducing LOC, separating > concerns, encapsulation etc). > > Code moves(1) and CS(2) are easy to peer review and merge quickly. The > third kind(3) requires deeper analysis to ensure that while the code > changed, the behaviour (including any bugs) did not. > > We must resist all temptation to fix bugs or tack on minor fixes and > tweaks during refactoring: pull requests should only be refactoring only, > with no net change to behaviour. Keeping discipline makes it much easier to > verify and peer review and this faster to merge. > > With respect to Code moves and CS, I believe we should have a "refactoring > fortnight" where we so the bulk of code move-only refactoring plus CS where > necessary. This is by fat the most disruptive kind of change because it > widely affects other PRs mergeability. We should aim to get most of this > done in one go, so that it's not happening in dribs and drabs over months > and many releases. Once done, it gives everyone a good idea to the overall > new structure and where one can expect to find things in the future. The > idea here is to help orientation and not have to continuously hunt for > where things have moved to. > > To be clear, I am strongly suggesting code move-only refactoring PRs not > be mixed with anything else. Same for CS changes. This makes the PRs > extremely easy to vet and thus quick to merge. > > Towards this end, maybe there should be an IRC meeting to agree the > initial moves, then someone who has the stomach for it can get on and do it > - during that time, we do not merge anything else. We need to bite the > bullet and break the back out of code moves. > > With regards to CS, I think we do need to get CS right, because a > continual dribble of CS changes also makes diffs between releases less easy > to follow. Much of CS checking can be automated by the continuous > integration so authors can get it right easily. It can be just like a > Travis check. > > With respect to the 3rd kind of refactoring, we need to set some standards > and goals and aim for some kind of consistency. Refactoring needs to fulfil > certain goals and criterion ot
Re: [bitcoin-dev] libconsensus and bitcoin development process
I basically agree with what has been said here. Refactoring efforts should be well-coordinated. Their short-term impact can be quite disruptive, although if done correctly, longer-term they make it even easier for downstream developers to add and merge changes. By scheduling move-only changes, others can avoid making PRs immediately prior to or during these changes (which ironically involve considerable disruption to PRs while changing nothing for endusers). Furthermore, it would be useful to document the changes in ways that help other developers rebase properly. On September 15, 2015 11:26:50 AM EDT, Jeff Garzik via bitcoin-dev wrote: >Drak, > >I would say that the refactoring does actually fulfill some conditions >you >mention: >- move-only is almost always clearly separated out >- the refactoring is not controversial _in minimis_ - meaning, the >individual pull request is not controversial. > >The problem comes with the impact of an unfocused stream of refactors >to >key code. > >For example, there is much less long term developer impact if >refactoring >were _accelerated_, scheduled to be performed in a one-week sprint. >There >is a lot of breakage, yes, but after that week the average level of >downstream patch breakage is significantly lower. A "rip the band-aid >off >quickly rather than slowly" approach. > > > > >On Tue, Sep 15, 2015 at 5:55 AM, Btc Drak wrote: > >> I also share a lot of Jeff's concerns about refactoring and have >voiced >> them several times on IRC and in private to Jorge, Wladamir and Greg. >I >> meant to do a write up but never got around to it. Jeff has quite >> eloquently stated the various problems. I would like to share my >thoughts >> on the matter because we really do need to come up with a plan on how >this >> issue is dealt with. >> >> Obviously, Bitcoin Core is quite tightly coupled at the moment and >> definitely needs extensive modularisation. Such work will inevitably >> require lots of bulk code moves and then finer refactoring. However, >it >> requires proper planning because there are lots of effects and >consequences >> for other people contributing to Core and also downstream projects >relying >> on Core: >> >> 1. Refactoring often causes other pull requests to diverge and >require >> rebasing. Continual refactoring can put PRs in "rebase hell" and puts >a big >> stress on contributors (many of whom are part time). >> >> 2. Version to version, Bitcoin Core changes significantly in >structure. >> 0.9 to 0.10 is unrecognisable. 0.10 to 0.11 is even more so. This >makes >> makes it hard to follow release to release and the net result is less >> people upgrade (especially think of miners trying to keep their patch >sets >> working while trying not to disrupt or risk their mining operations). >> >> 3. Continual refactoring increases risk: we're human, and mistakes >will >> slip through peer review. This is especially concerning with >consensus >> critical code and this makes it difficult to merge such refactoring >often, >> which of course exacerbates the problem. >> >> The net negative consequence is it is harder to contribute to Core, >harder >> for the Core maintainers to merge and harder for downstream/dependent >> projects/implementations to keep up. >> >> Suggested Way Forward >> - >> >> With the understanding that refactored code by definition must not >change >> behaviour. There are three major kinds of refactoring: >> >> 1. code moves (e.g. separating concerns into different files); >> 2. code style; >> 3. structural optimisation and consolidation (reducing LOC, >separating >> concerns, encapsulation etc). >> >> Code moves(1) and CS(2) are easy to peer review and merge quickly. >The >> third kind(3) requires deeper analysis to ensure that while the code >> changed, the behaviour (including any bugs) did not. >> >> We must resist all temptation to fix bugs or tack on minor fixes and >> tweaks during refactoring: pull requests should only be refactoring >only, >> with no net change to behaviour. Keeping discipline makes it much >easier to >> verify and peer review and this faster to merge. >> >> With respect to Code moves and CS, I believe we should have a >"refactoring >> fortnight" where we so the bulk of code move-only refactoring plus CS >where >> necessary. This is by fat the most disruptive kind of change because >it >> widely affects other PRs mergeability. We should aim to get most of >this >> done in one go, so that it's not happening in dribs and drabs over >months >> and many releases. Once done, it gives everyone a good idea to the >overall >> new structure and where one can expect to find things in the future. >The >> idea here is to help orientation and not have to continuously hunt >for >> where things have moved to. >> >> To be clear, I am strongly suggesting code move-only refactoring PRs >not >> be mixed with anything else. Same for CS changes. This makes the PRs >> extremely easy to vet and thus q
Re: [bitcoin-dev] libconsensus and bitcoin development process
On Tue, Sep 15, 2015 at 4:26 PM, Jeff Garzik wrote: > The problem comes with the impact of an unfocused stream of refactors to > key code. > > For example, there is much less long term developer impact if refactoring > were _accelerated_, scheduled to be performed in a one-week sprint. There > is a lot of breakage, yes, but after that week the average level of > downstream patch breakage is significantly lower. A "rip the band-aid off > quickly rather than slowly" approach. > My sentiments exactly... ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Proof of unique blockchain storage revised
One possible way to incentivize the existence of more Bitcoin network nodes is by paying peers when they provide data in the blokcchain. One of the problems is that it is not easy to tell if the peer is really providing a useful service by storing the blockchain or it is just relying the request to some other peers as a proxy. In this post I review the use of asymmetric-time functions to be able to prove unique (IP-tied) blockchain storage and propose improvements to make it fully practical. Full post here: https://bitslog.wordpress.com/2015/09/16/proof-of-unique-blockchain-storage-revised/ Best regards, Sergio. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
