Re: [bitcoin-dev] Start time for BIP141 (segwit)
On Mon, 17 Oct 2016 04:08:29 +0800 Tom Zander via bitcoin-dev wrote > On Monday, 17 October 2016 03:11:23 CEST Johnson Lau wrote: > > > Honestly, if the reason for the too-short-for-safety timespan is that > > > you > > > want to use BIP9, then please take a step back and realize that SegWit > > > is a contriversial soft-fork that needs to be deployed in a way that is > > > extra safe because you can't roll the feature back a week after > > > deployment. All transactions that were made in the mean time turn into > > > everyone-can- spent transactions. > > > > No one should use, nor anyone is advised to use, segwit transactions > > before it is fully activated. > > Naturally, I fully agree. > > It seems I choose the wrong words, let me rephrase; > > You can't roll the SegWit back a week after people are allowed to send > segwit transactions (lock-in + fallow period). All transactions that were > made in the mean time turn into everyone-can- spent transactions. > > Because the network as a whole and any implementation is unable to roll back > > in an environment where SegWit is a contriversial soft-fork, it is super > important to make sure that it is properly supported by all miners. This > takes time and the risk you take by pushing this is that actual real people > loose actual real money because of the issue I outlined inthe previous > paragraph. It would only happen if a large proportion of miners are false-signalling, like how BU did with BIP109 and forked your Classic away on testnet But this is a egg-and-chicken problem and extending the grace period would not have any improvement. Until the rules are fully activated, it is totally impossible to tell if some miners are false signalling. The only method to prevent it, as usual, is the majority of miners will orphan the blocks of malicious miners. Like in the last year, some miners did not correctly implement BIP66 and got punished by losing many blocks. If your are suggesting >51% of miners may false-signal (like in the BIP109 case), we already have a much bigger problem. If people are really worrying about that, I would advise them not to use segwit extensively at the beginning, and wait for at least a week to see any sign of false signalling (which will be shown as invalid orphaned blocks). If the grace period was 2 weeks, they need to wait for 3 weeks; if the grace period was 2 months, they need to wait for 2 months and a week. Pre-activation consensus-imposed grace period could never replace post-activation self-imposed observation period ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Start time for BIP141 (segwit)
On Sun, Oct 16, 2016 at 04:31:55PM +0200, Pieter Wuille via bitcoin-dev wrote: > Hello all, > > We're getting ready for Bitcoin Core's 0.13.1 release - the first one > to include segregated witness (BIP 141, 143, 144, 145) for Bitcoin > mainnet, after being extensively tested on testnet and in other > software. Following the BIP9 recommendation [1] to set the versionbits > start time a month in the future and discussion in the last IRC > meeting [2], I propose we set BIP 141's start time to November 15, > 2016, 0:00 UTC (unix time 1479168000). Speaking as maintainer of python-bitcoinlib, ACK. Currently python-bitcoinlib doesn't have any support for segwit, although Bob McElrath has had a pull-req open for it since July: https://github.com/petertodd/python-bitcoinlib/pull/112 I may or may not get time to finishing reviewing and merging that pull-req before segwit activates - I've been a rather distracted maintainer. But either way, as has been explained elsewhere ad nauseam, segwit is backwards compatible with existing nodes and wallets so there's no rush to upgrade. For example, another project of mine - OpenTimestamps - also makes use of python-bitcoinlib for the relatively complex and hairy low-level code that extracts timestamp proofs from blocks, among other things. In fact, in the development of OpenTimestamps I had to fix a few minor bugs in python-bitcoinlib, because it exercised parts of the codebase that few other projects do. Yet the impact on segwit for OpenTimestamps will be zero - since segwit is a softfork it's 100% backwards compatible with existing software. Of course, at some point in the future I'll probably get around to adding segwit support to the software to reduce transaction fees, but there's no rush to do so. All I'll be doing for segwit in the near future is upgrading the full nodes on the two redundant OpenTimestamps calendar servers to v0.13.1, and even there I'll be able to stagger the upgrades to protect against the unlikely occurance of v0.13.1 having a bug that v0.13.0 doesn't. Again, staggering full-node upgrades is only possible because segwit is a soft-fork. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Start time for BIP141 (segwit)
On 10/16/2016 4:58 PM, Tom Zander via bitcoin-dev wrote: > Lets get back to the topic. Having a longer fallow period is a simple way to > be safe. Your comments make me even more scared that safety is not taken > into account the way it would. Can you please explain how having a longer grace period makes it any safer? Once the fork reaches the LOCKED_IN status, the fork will become active after the period is over. How does having a longer grace period make this any safer besides just adding more waiting before it goes active? You said something about rolling back the changes. There is no mechanism for roll backs, and the whole point of the soft fork signalling is such that there is no need to roll back anything because miners have signaled that they are supporting the fork. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Start time for BIP141 (segwit)
On Sun, Oct 16, 2016 at 10:58 PM, Tom Zander via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Sunday, 16 October 2016 12:49:47 CEST Douglas Roark via bitcoin-dev > wrote: > > It's not the website's fault if wallet devs aren't updating their > > statuses. Besides, "WIP" can mean an awful lot of things. > > As I said, it would be nice to get an updated version so we can see more > than 20% readyness of wallets. > The wallet devs not caring enough to update the status should be a worrying > sign, though. > WIP for TREZOR means that we've made that hard part already (firwmare) so we know it is feasible, yet we didn't spend enough time on finalizing all the stack like our web wallet because we don't see any actual release date yet. Considering current battles on BU hashpower, we decided simply sit and watch (I already have popocorn). SegWit is probably the most disruptive and most invasive change ever made to > Bitcoin. We have miners actively saying they don't like it and this makes > it > a contriversial upgrade which means the network may split and other issues. > > There're also many wallets which are impatiently waiting for segwit to be released. Segwit is blessing for hardware wallets for many reasons. I actually think that rolling out Segwit will increase security, because it will reduce huge complexity in hardware wallets as it is today. Slush ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Start time for BIP141 (segwit)
It's controversial not contriversial. And it isn't controversial except among a small clique, which you seem to be the sole representative of here. It might be time to consider unsubscribing (again) if you don't seem to know when to shut up and the moderators are letting you go on an inappropriate crusade here. On Sun, 2016-10-16 at 22:58 +0200, Tom Zander via bitcoin-dev wrote: > On Sunday, 16 October 2016 12:49:47 CEST Douglas Roark via bitcoin-dev > wrote: > > It's not the website's fault if wallet devs aren't updating their > > statuses. Besides, "WIP" can mean an awful lot of things. > > As I said, it would be nice to get an updated version so we can see more > than 20% readyness of wallets. > The wallet devs not caring enough to update the status should be a worrying > sign, though. > > > A lot of devs have already worked on SegWit support. This has been > > covered. Even if they don't support SegWit, the wallets will probably > > work just fine. (For awhile, Armory did crash when trying to read SegWit > > SegWit is probably the most disruptive and most invasive change ever made to > Bitcoin. We have miners actively saying they don't like it and this makes it > a contriversial upgrade which means the network may split and other issues. > > Your "wallets will probably work just fine" comment is honestly not the > answer to make people put faith in the way that this is being vetted and > checked... > > > Also, once again, FlexTrans is off-topic. > > Its an alternative and brought up in that vain. Nothing more. Feel free to > respond to the BIP discussion (134) right on this list if you have any > opinions on it. They will be on-topic there. No problems have been found so > far. > > Lets get back to the topic. Having a longer fallow period is a simple way to > be safe. Your comments make me even more scared that safety is not taken > into account the way it would. > > People are not even acknowledging the damage a contriversial soft fork of > the scope and magnitude of SegWit can have, and a simple request to extend > the fallow time for safety is really not a big deal. > SegWit has been in development for 18 months or so, what is a couple of > extra week?? > > I would just like to ask people to take the safety of Bitcoin serious. This > discussion and refusal to extend the safety period is not a good sign. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Start time for BIP141 (segwit)
On Sunday, 16 October 2016 12:49:47 CEST Douglas Roark via bitcoin-dev wrote: > It's not the website's fault if wallet devs aren't updating their > statuses. Besides, "WIP" can mean an awful lot of things. As I said, it would be nice to get an updated version so we can see more than 20% readyness of wallets. The wallet devs not caring enough to update the status should be a worrying sign, though. > A lot of devs have already worked on SegWit support. This has been > covered. Even if they don't support SegWit, the wallets will probably > work just fine. (For awhile, Armory did crash when trying to read SegWit SegWit is probably the most disruptive and most invasive change ever made to Bitcoin. We have miners actively saying they don't like it and this makes it a contriversial upgrade which means the network may split and other issues. Your "wallets will probably work just fine" comment is honestly not the answer to make people put faith in the way that this is being vetted and checked... > Also, once again, FlexTrans is off-topic. Its an alternative and brought up in that vain. Nothing more. Feel free to respond to the BIP discussion (134) right on this list if you have any opinions on it. They will be on-topic there. No problems have been found so far. Lets get back to the topic. Having a longer fallow period is a simple way to be safe. Your comments make me even more scared that safety is not taken into account the way it would. People are not even acknowledging the damage a contriversial soft fork of the scope and magnitude of SegWit can have, and a simple request to extend the fallow time for safety is really not a big deal. SegWit has been in development for 18 months or so, what is a couple of extra week?? I would just like to ask people to take the safety of Bitcoin serious. This discussion and refusal to extend the safety period is not a good sign. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] (no subject)
On Sunday, 16 October 2016 19:35:52 CEST Matt Corallo wrote: > You keep calling flexible transactions "safer", and yet you haven't > mentioned that the current codebase is riddled with blatant and massive > security holes. I am not afraid of people finding issues with my code, I'm only human. Would appreciate you reporting actual issues instead of hinting at things here. Can't fix things otherwise :) But, glad you brought it up, the reason that FT is safer is because of the amount of conceps that SegWit changes in a way that anyone doing development on Bitcoin later will need to know about them in order to do proper development. I counted 10 in my latest vlog entry. FT only changes 2. Its safer because its simpler. > For example, you seem to have misunderstood C++'s memory > model - you would have no less than three out-of-bound, probably > exploitable memory accesses in your 80-LoC deserialize method at > https://github.com/bitcoinclassic/bitcoinclassic/blob/develop/src/primitiv > es/transaction.cpp#L119 if you were to turn on flexible transactions (and > I only reviewed that method for 2 minutes). The unit test doesn't hit any of them. Valgrind only reports such possibly exploitable issues in secp256k and CKey::MakeNewKey. The same as in Core. I don't doubt that your 2 minute look shows stuff that others missed, and that valgrind doesn't find either, but I'd be really grateful if you can report them specifically to me in an email off list (or github, you know the drill). More feedback will only help to make the proposal stronger and even better. Thanks! > If you want to propose an > alternative to a community which has been in desperate need of fixes to > many problems for several years, please do so with something which would > not take at least a year to complete given a large team of qualified > developers. I think FT fits the bill just fine :) After your 2 minute look, take a bit longer and check the rest of the code. You may be surprised with the simplicity of the approach. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Start time for BIP141 (segwit)
I can see how it looks but actually most of the underlying libraries have already been adapted or are almost finished being adapted for segwit. Since segwit is not live on mainnet, most are not released (either still in PR form or merged to a development branch). As a software developer, I think you can appreciate that libraries cant actually release a segwit supported versions until segwit is released as final in 0.13.1. Obviously consumers of the libraries cant update for segwit until the libraries are released - you get the idea. I wouldn't be too concerned about the adoption chart, it's just very difficult to reflect the actual state of affairs. For example Trezor is marked as wip, but they have had an updated, but unreleased firmware version for many months[1]. We are in the process of planning a migration guide and updating the existing development notes[2]. Additionally, many companies are already planning to update their services for segwit. Regarding BIP9, it's purpose is to co-ordinate *miner upgrade* and activation. The starttime delay is simply designed to avoid miners signalling before the soft fork has been made available for general release; so the starttime prevents unreleased software from setting the version bit prematurely. The whole BIP9 state machine allows predictable activation. Non mining full nodes are under no constraints to upgrade on a specific schedule, which is by design of soft forks. Signalling will not begin until the first diff retarget period after the starttime of 15th Nov. Practically it means there will be a minimum of 4-6 weeks at the very least before activation can happen. [1] https://github.com/bitcoin-core/bitcoincore.org/pull/30#issu ecomment-217329474 [2] https://bitcoincore.org/en/segwit_wallet_dev/ On Sun, Oct 16, 2016 at 7:20 PM, Tom Zander via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Sunday, 16 October 2016 09:47:40 CEST Douglas Roark via bitcoin-dev > wrote: > > Would I want anyone to lose money due to faulty wallets? Of course not. > > By the same token, devs have had almost a year to tinker with SegWit and > > make sure the wallet isn't so poorly written that it'll flame out when > > SegWit comes along. It's not like this is some untested, mostly unknown > > feature that's being slipped out at the last minute > > There have been objections to the way that SegWit has been implemented for > a > long time, some wallets are taking a "wait and see" approach. If you look > at the page you linked[1], that is a very very sad state of affairs. The > vast majority is not ready. Would be interesting to get a more up-to-date > view. > Wallets probably won't want to invest resources adding support for a > feature > that will never be activated. The fact that we have a much safer > alternative > in the form of Flexible Transactions may mean it will not get activated. We > won't know until its actually locked in. > Wallets may not act until its actually locked in either. And I think we > should respect that. > > Even if all wallets support it (and thats a big if), they need to be rolled > out and people need to actually download those updates. > This takes time, 2 months after the lock-in of SegWit would be the minimum > safe time for people to actually upgrade. > > 1) https://bitcoincore.org/en/segwit_adoption/ > -- > Tom Zander > Blog: https://zander.github.io > Vlog: https://vimeo.com/channels/tomscryptochannel > ___ > 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] Start time for BIP141 (segwit)
On Monday, 17 October 2016 03:11:23 CEST Johnson Lau wrote: > > Honestly, if the reason for the too-short-for-safety timespan is that > > you > > want to use BIP9, then please take a step back and realize that SegWit > > is a contriversial soft-fork that needs to be deployed in a way that is > > extra safe because you can't roll the feature back a week after > > deployment. All transactions that were made in the mean time turn into > > everyone-can- spent transactions. > > No one should use, nor anyone is advised to use, segwit transactions > before it is fully activated. Naturally, I fully agree. It seems I choose the wrong words, let me rephrase; You can't roll the SegWit back a week after people are allowed to send segwit transactions (lock-in + fallow period). All transactions that were made in the mean time turn into everyone-can- spent transactions. Because the network as a whole and any implementation is unable to roll back in an environment where SegWit is a contriversial soft-fork, it is super important to make sure that it is properly supported by all miners. This takes time and the risk you take by pushing this is that actual real people loose actual real money because of the issue I outlined inthe previous paragraph. > Having 2 months or 2 weeks of grace period > makes totally no difference in this regard. If anyone tried to use segwit > tx during your proposed 2 months grace period, all those txs were still > everyone-can-spent. > > All you are advocating is just stalling the process with no improvement in > security. I hope the above explains the actual security issue better. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Start time for BIP141 (segwit)
Before getting to my reply to Tom's message, I forgot to give my thoughts on the Nov. 15 date. I think it's a reasonable date. With various holidays coming up in the West, it's probably best to get the word out now so that work can progress before some people get sucked into family obligations and such. A month gives a bit of time without dragging out the waiting game, IMO. Now then On 2016/10/16 11:20, Tom Zander via bitcoin-dev wrote: > There have been objections to the way that SegWit has been implemented for a > long time, some wallets are taking a "wait and see" approach. If you look > at the page you linked[1], that is a very very sad state of affairs. The > vast majority is not ready. Would be interesting to get a more up-to-date > view. It's not the website's fault if wallet devs aren't updating their statuses. Besides, "WIP" can mean an awful lot of things. For example, I know Armory made significant progress with SegWit support as part of their upcoming 0.95 release. I have full confidence they'll be ready relatively soon. Other wallets may be ready. Other wallets may be stuck where they were in the spring. In any event, it's a free country. Unlike consensus rules and such, it's trivial to move one's funds to a wallet that fully supports SegWit if that's what one desires. In addition, I was at the wallet workshop at Scaling Bitcoin last week. An awful lot of things were on the board as potential discussion points. I think SegWit was mentioned but wasn't really discussed. I don't think FlexTrans was even mentioned (and it's off-topic anyway). Wallet devs are far more concerned about things like UI and standards for HW wallets than they are about their ability to support SegWit. I think wallet devs are quite capable of making noise if they felt that SegWit was a bad feature, or a difficult-to-support feature. > Wallets probably won't want to invest resources adding support for a feature > that will never be activated. The fact that we have a much safer alternative > in the form of Flexible Transactions may mean it will not get activated. We > won't know until its actually locked in. A lot of devs have already worked on SegWit support. This has been covered. Even if they don't support SegWit, the wallets will probably work just fine. (For awhile, Armory did crash when trying to read SegWit data in Core's blockchain files. That problem was fixed, and it was probably a rarity since very few wallets rely directly on Core.) As long as devs use testnet or regtest to iron out their kinks before hitting mainnet, I can't think of a single good reason to hold back SegWit solely due to wallet support. Also, once again, FlexTrans is off-topic. As others have said, you're basically being stubborn at this point. If you insist on discussing FlexTrans, start another thread. It sounds like quite a few devs would be more than happy to say a word or two about your proposal. -- --- Douglas Roark Cryptocurrency, network security, travel, and art. https://onename.com/droark joro...@vt.edu PGP key ID: 26623924 signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] (no subject)
You keep calling flexible transactions "safer", and yet you haven't mentioned that the current codebase is riddled with blatant and massive security holes. For example, you seem to have misunderstood C++'s memory model - you would have no less than three out-of-bound, probably exploitable memory accesses in your 80-LoC deserialize method at https://github.com/bitcoinclassic/bitcoinclassic/blob/develop/src/primitives/transaction.cpp#L119 if you were to turn on flexible transactions (and I only reviewed that method for 2 minutes). If you want to propose an alternative to a community which has been in desperate need of fixes to many problems for several years, please do so with something which would not take at least a year to complete given a large team of qualified developers. You additionally have not yet bothered to address the discussion of soft-fork security at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html which I believe answers all of your claims about upgrades required in a much more detailed discussion than I will include here. Please take your off-topic discussions there instead of this thread. On 10/16/16 18:20, Tom Zander via bitcoin-dev wrote: > On Sunday, 16 October 2016 09:47:40 CEST Douglas Roark via bitcoin-dev > wrote: >> Would I want anyone to lose money due to faulty wallets? Of course not. >> By the same token, devs have had almost a year to tinker with SegWit and >> make sure the wallet isn't so poorly written that it'll flame out when >> SegWit comes along. It's not like this is some untested, mostly unknown >> feature that's being slipped out at the last minute > > There have been objections to the way that SegWit has been implemented for a > long time, some wallets are taking a "wait and see" approach. If you look > at the page you linked[1], that is a very very sad state of affairs. The > vast majority is not ready. Would be interesting to get a more up-to-date > view. > Wallets probably won't want to invest resources adding support for a feature > that will never be activated. The fact that we have a much safer alternative > in the form of Flexible Transactions may mean it will not get activated. We > won't know until its actually locked in. > Wallets may not act until its actually locked in either. And I think we > should respect that. > > Even if all wallets support it (and thats a big if), they need to be rolled > out and people need to actually download those updates. > This takes time, 2 months after the lock-in of SegWit would be the minimum > safe time for people to actually upgrade. > > 1) https://bitcoincore.org/en/segwit_adoption/ > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Start time for BIP141 (segwit)
On Mon, 17 Oct 2016 02:54:04 +0800 Tom Zander via bitcoin-dev wrote > Honestly, if the reason for the too-short-for-safety timespan is that you > want to use BIP9, then please take a step back and realize that SegWit is a > contriversial soft-fork that needs to be deployed in a way that is extra > safe because you can't roll the feature back a week after deployment. > All transactions that were made in the mean time turn into everyone-can- > spent transactions. No one should use, nor anyone is advised to use, segwit transactions before it is fully activated. Having 2 months or 2 weeks of grace period makes totally no difference in this regard. If anyone tried to use segwit tx during your proposed 2 months grace period, all those txs were still everyone-can-spent. All you are advocating is just stalling the process with no improvement in security. > > I stand by the minimum of 2 months. There is no reason to use BIP9 as it was > > coded in an older client. That is an excuse that I don't buy. > -- > Tom Zander > Blog: https://zander.github.io > Vlog: https://vimeo.com/channels/tomscryptochannel > ___ > 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] Start time for BIP141 (segwit)
On Sunday, 16 October 2016 20:41:34 CEST Jorge Timón wrote: > You keep insisting on "2 months after activation", but that's not how > BIP9 works. We could at most change BIP9's initial date, but if those > who haven't started to work on supporting segwit will keep waiting for > activation, then changing the initial date won't be of any help to > them can only delay those who are ready and waiting. Then don't use BIP9... Honestly, if the reason for the too-short-for-safety timespan is that you want to use BIP9, then please take a step back and realize that SegWit is a contriversial soft-fork that needs to be deployed in a way that is extra safe because you can't roll the feature back a week after deployment. All transactions that were made in the mean time turn into everyone-can- spent transactions. I stand by the minimum of 2 months. There is no reason to use BIP9 as it was coded in an older client. That is an excuse that I don't buy. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Start time for BIP141 (segwit)
As has been mentioned there have been a lot of time to upgrade software to support segwit. Furthermore, since it is a softfork, there will be plenty of time after activation too for those taking a "wait and see" approach. You keep insisting on "2 months after activation", but that's not how BIP9 works. We could at most change BIP9's initial date, but if those who haven't started to work on supporting segwit will keep waiting for activation, then changing the initial date won't be of any help to them can only delay those who are ready and waiting. The new features are not a requirement after activation. And although it may take some time after activation for the new features to really get to the users, that's just a fact of life that won't change by changing the initial BIP9 date. On Sun, Oct 16, 2016 at 8:20 PM, Tom Zander via bitcoin-dev wrote: > On Sunday, 16 October 2016 09:47:40 CEST Douglas Roark via bitcoin-dev > wrote: >> Would I want anyone to lose money due to faulty wallets? Of course not. >> By the same token, devs have had almost a year to tinker with SegWit and >> make sure the wallet isn't so poorly written that it'll flame out when >> SegWit comes along. It's not like this is some untested, mostly unknown >> feature that's being slipped out at the last minute > > There have been objections to the way that SegWit has been implemented for a > long time, some wallets are taking a "wait and see" approach. If you look > at the page you linked[1], that is a very very sad state of affairs. The > vast majority is not ready. Would be interesting to get a more up-to-date > view. > Wallets probably won't want to invest resources adding support for a feature > that will never be activated. The fact that we have a much safer alternative > in the form of Flexible Transactions may mean it will not get activated. We > won't know until its actually locked in. > Wallets may not act until its actually locked in either. And I think we > should respect that. > > Even if all wallets support it (and thats a big if), they need to be rolled > out and people need to actually download those updates. > This takes time, 2 months after the lock-in of SegWit would be the minimum > safe time for people to actually upgrade. > > 1) https://bitcoincore.org/en/segwit_adoption/ > -- > Tom Zander > Blog: https://zander.github.io > Vlog: https://vimeo.com/channels/tomscryptochannel > ___ > 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] Start time for BIP141 (segwit)
On Sunday, 16 October 2016 09:47:40 CEST Douglas Roark via bitcoin-dev wrote: > Would I want anyone to lose money due to faulty wallets? Of course not. > By the same token, devs have had almost a year to tinker with SegWit and > make sure the wallet isn't so poorly written that it'll flame out when > SegWit comes along. It's not like this is some untested, mostly unknown > feature that's being slipped out at the last minute There have been objections to the way that SegWit has been implemented for a long time, some wallets are taking a "wait and see" approach. If you look at the page you linked[1], that is a very very sad state of affairs. The vast majority is not ready. Would be interesting to get a more up-to-date view. Wallets probably won't want to invest resources adding support for a feature that will never be activated. The fact that we have a much safer alternative in the form of Flexible Transactions may mean it will not get activated. We won't know until its actually locked in. Wallets may not act until its actually locked in either. And I think we should respect that. Even if all wallets support it (and thats a big if), they need to be rolled out and people need to actually download those updates. This takes time, 2 months after the lock-in of SegWit would be the minimum safe time for people to actually upgrade. 1) https://bitcoincore.org/en/segwit_adoption/ -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Start time for BIP141 (segwit)
This start time seems reasonable to me. It is mostly in line with BIP 9's proposed defaults, which seems like an appropriate choice. On October 16, 2016 10:31:55 AM EDT, Pieter Wuille via bitcoin-dev wrote: >Hello all, > >We're getting ready for Bitcoin Core's 0.13.1 release - the first one >to include segregated witness (BIP 141, 143, 144, 145) for Bitcoin >mainnet, after being extensively tested on testnet and in other >software. Following the BIP9 recommendation [1] to set the versionbits >start time a month in the future and discussion in the last IRC >meeting [2], I propose we set BIP 141's start time to November 15, >2016, 0:00 UTC (unix time 1479168000). > >Note that this is just a lower bound on the time when the versionbits >signalling can begin. Activation on the network requires: >(1) This date to pass >(2) A full retarget window of 2016 blocks with 95% signalling the >version bit (bit 1 for BIP141) >(3) A fallow period consisting of another 2016 blocks. > > [1] https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki >[2] >http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-13-19.04.log.html > >Cheers, ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Start time for BIP141 (segwit)
On 2016/10/16 09:35, Gavin Andresen via bitcoin-dev wrote: > I asked a lot of businesses and individuals how long it would take them > to upgrade to a new release over the last year or two. > > Nobody said it would take them more than two weeks. > > If somebody is running their own validation code... then we should > assume they're sophisticated enough to figure out how to mitigate any > risks associated with segwit activation on their own. In addition, there has been a page up for several months (https://bitcoincore.org/en/segwit_adoption/) that gauges whether or not wallets are ready for SegWit. Unfortunately, it appears that the page hasn't been updated since May. I do know that several wallets have finished or are close to finishing their support, though. Would I want anyone to lose money due to faulty wallets? Of course not. By the same token, devs have had almost a year to tinker with SegWit and make sure the wallet isn't so poorly written that it'll flame out when SegWit comes along. It's not like this is some untested, mostly unknown feature that's being slipped out at the last minute, unlike other features I could name but won't. :) -- --- Douglas Roark Cryptocurrency, network security, travel, and art. https://onename.com/droark joro...@vt.edu PGP key ID: 26623924 signature.asc Description: OpenPGP digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On the security of soft forks
I highly recommend you read the excellent thread on soft fork risks at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html and respond there instead of getting off topic for this thread. Matt On 10/16/16 16:42, Tom Zander via bitcoin-dev wrote: > On Sunday, 16 October 2016 12:35:58 CEST Gavin Andresen wrote: >> On Sun, Oct 16, 2016 at 10:58 AM, Tom Zander via bitcoin-dev < >> >> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> The fallow period sounds wy to short. I suggest 2 months at minimum >>> since anyone that wants to be safe needs to upgrade. >> >> I asked a lot of businesses and individuals how long it would take them to >> upgrade to a new release over the last year or two. >> >> Nobody said it would take them more than two weeks. > > The question you asked them was likely about the block size. The main > difference is that SPV users do not need to update after BIP109, but they do > need to have a new wallet when SegWit transactions are being sent to them. > > This upgrade affects also end users, not just businesses etc. > > Personally, I'd say that 2 months is even too fast. > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Start time for BIP141 (segwit)
This is completely wrong. SPV wallets will work as normal without upgrade. Full nodes will only provide transactions to SPV in a format they understand, and SPV will accept the transaction since they are not doing any validation anyway. The only reason an end user may want to upgrade is for lower transaction fee when they are sending transaction. If they don't upgrade, that means the fee is too low for them to care, which is a good news On Mon, 17 Oct 2016 00:42:26 +0800 Tom Zander via bitcoin-dev wrote > On Sunday, 16 October 2016 12:35:58 CEST Gavin Andresen wrote: > > On Sun, Oct 16, 2016 at 10:58 AM, Tom Zander via bitcoin-dev < > > > > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > The fallow period sounds wy to short. I suggest 2 months at minimum > > > since anyone that wants to be safe needs to upgrade. > > > > I asked a lot of businesses and individuals how long it would take them to > > upgrade to a new release over the last year or two. > > > > Nobody said it would take them more than two weeks. > > The question you asked them was likely about the block size. The main > difference is that SPV users do not need to update after BIP109, but they do > > need to have a new wallet when SegWit transactions are being sent to them. > > This upgrade affects also end users, not just businesses etc. > > Personally, I'd say that 2 months is even too fast. > > -- > Tom Zander > Blog: https://zander.github.io > Vlog: https://vimeo.com/channels/tomscryptochannel > ___ > 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] Start time for BIP141 (segwit)
If somebody is not "running their own validation code" then they aren't actually using Bitcoin, so their ease in transition is irrelevant. For all they know they are accepting random numbers. e > On Oct 16, 2016, at 9:35 AM, Gavin Andresen via bitcoin-dev > wrote: > >> On Sun, Oct 16, 2016 at 10:58 AM, Tom Zander via bitcoin-dev >> wrote: >> The fallow period sounds wy to short. I suggest 2 months at minimum >> since anyone that wants to be safe needs to upgrade. > > I asked a lot of businesses and individuals how long it would take them to > upgrade to a new release over the last year or two. > > Nobody said it would take them more than two weeks. > > If somebody is running their own validation code... then we should assume > they're sophisticated enough to figure out how to mitigate any risks > associated with segwit activation on their own. > > -- > -- > Gavin Andresen > > ___ > 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] Start time for BIP141 (segwit)
On Sunday, 16 October 2016 12:35:58 CEST Gavin Andresen wrote: > On Sun, Oct 16, 2016 at 10:58 AM, Tom Zander via bitcoin-dev < > > bitcoin-dev@lists.linuxfoundation.org> wrote: > > The fallow period sounds wy to short. I suggest 2 months at minimum > > since anyone that wants to be safe needs to upgrade. > > I asked a lot of businesses and individuals how long it would take them to > upgrade to a new release over the last year or two. > > Nobody said it would take them more than two weeks. The question you asked them was likely about the block size. The main difference is that SPV users do not need to update after BIP109, but they do need to have a new wallet when SegWit transactions are being sent to them. This upgrade affects also end users, not just businesses etc. Personally, I'd say that 2 months is even too fast. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Start time for BIP141 (segwit)
On Sun, Oct 16, 2016 at 10:58 AM, Tom Zander via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The fallow period sounds wy to short. I suggest 2 months at minimum > since anyone that wants to be safe needs to upgrade. > I asked a lot of businesses and individuals how long it would take them to upgrade to a new release over the last year or two. Nobody said it would take them more than two weeks. If somebody is running their own validation code... then we should assume they're sophisticated enough to figure out how to mitigate any risks associated with segwit activation on their own. -- -- Gavin Andresen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Start time for BIP141 (segwit)
Hello, Excellent news that segregated witness is nearing release for the mainnet. I know I don't only speak for myself in saying that this has been eagerly awaited for some time. For the timing, I'd support segwit being usable on the network as soon as is technically and safely possible. We at JoinMarket are very interested in eventually using schnorr which would allow signature aggregation and so reduce the cost of coinjoins. Chris Belcher On 16/10/16 15:31, Pieter Wuille via bitcoin-dev wrote: > Hello all, > > We're getting ready for Bitcoin Core's 0.13.1 release - the first one > to include segregated witness (BIP 141, 143, 144, 145) for Bitcoin > mainnet, after being extensively tested on testnet and in other > software. Following the BIP9 recommendation [1] to set the versionbits > start time a month in the future and discussion in the last IRC > meeting [2], I propose we set BIP 141's start time to November 15, > 2016, 0:00 UTC (unix time 1479168000). > > Note that this is just a lower bound on the time when the versionbits > signalling can begin. Activation on the network requires: > (1) This date to pass > (2) A full retarget window of 2016 blocks with 95% signalling the > version bit (bit 1 for BIP141) > (3) A fallow period consisting of another 2016 blocks. > > [1] https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki > [2] > http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-13-19.04.log.html > > Cheers, > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Start time for BIP141 (segwit)
The fallow period sounds wy to short. I suggest 2 months at minimum since anyone that wants to be safe needs to upgrade. Also, please comment on why you won't use the much more safe and much smaller Flexible Transactions. On Sunday, 16 October 2016 16:31:55 CEST Pieter Wuille via bitcoin-dev wrote: > Hello all, > > We're getting ready for Bitcoin Core's 0.13.1 release - the first one > to include segregated witness (BIP 141, 143, 144, 145) for Bitcoin > mainnet, after being extensively tested on testnet and in other > software. Following the BIP9 recommendation [1] to set the versionbits > start time a month in the future and discussion in the last IRC > meeting [2], I propose we set BIP 141's start time to November 15, > 2016, 0:00 UTC (unix time 1479168000). > > Note that this is just a lower bound on the time when the versionbits > signalling can begin. Activation on the network requires: > (1) This date to pass > (2) A full retarget window of 2016 blocks with 95% signalling the > version bit (bit 1 for BIP141) > (3) A fallow period consisting of another 2016 blocks. > > [1] https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki > [2] > http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev. > 2016-10-13-19.04.log.html > > Cheers, -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP 2 revival and rework
On Saturday, 15 October 2016 17:02:30 CEST Marco Falke wrote: > >> BIP 2 does not forbid you to release your work under PD in > >> legislations where this is possible > > > > It does, actually. > > Huh, I can't find it in the text I read. The text mentions "not > acceptable", but I don't read that as "forbidden". You suggest that a person can dual license something under both CC-BY-SA as well as under public domain. That means you don't understand copyright, See, all licenses are based on you having copyright. In contrast; public domain is not a license, it means a certain text does not have copyright. Public domain is the lack of copyright. One text can not at the same time have copyright and not have copyright, making your assumption impossible. Hence, with PD not explicitly being allowed, you can't use PD. Personally I prefer copyleft licenses, so the lack of PD is fine with me. The lack of a good copyleft we can use in BIPs is what got me involved in this discussion in the first place. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Start time for BIP141 (segwit)
Hello all, We're getting ready for Bitcoin Core's 0.13.1 release - the first one to include segregated witness (BIP 141, 143, 144, 145) for Bitcoin mainnet, after being extensively tested on testnet and in other software. Following the BIP9 recommendation [1] to set the versionbits start time a month in the future and discussion in the last IRC meeting [2], I propose we set BIP 141's start time to November 15, 2016, 0:00 UTC (unix time 1479168000). Note that this is just a lower bound on the time when the versionbits signalling can begin. Activation on the network requires: (1) This date to pass (2) A full retarget window of 2016 blocks with 95% signalling the version bit (bit 1 for BIP141) (3) A fallow period consisting of another 2016 blocks. [1] https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki [2] http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-13-19.04.log.html Cheers, -- Pieter ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
