[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
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] 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)
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)
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)
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)
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)
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] 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 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)
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 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)
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)
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] 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)
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 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] 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 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)
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 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 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 Sunday, 16 October 2016 17:19:37 CEST Andrew C wrote: > 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? As Marek wrote just minutes before your email came in; companies will not roll out their updates until it locks in. Peter Todd says the same thing. So your assumption that the lock-in time is the END of the upgrading is false. Thats only the case for miners. The entire point here is that SegWit is much bigger than just full nodes (including miner). An entire ecosystem of Bitconin will have a need to upgrade. I understand people saying that non-miners don't *need* to upgrade in order to avoid being kicked of the network, but truely, thats a bogus argument. People want to actually participate in Bitcoin and that means they need to understand all of it. Not just see anyone-can-spend transactions. I think its rather odd to think that developers on this list can decide the risk profile that Bitcoin using companies or individuals should have. > 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. There are a bunch of really large assumptions in there that I disagree with. First of all, miners running the latest software doesn't mean the software is free from flaws. Everyone makes mistakes. People that see a way to abuse the system may have found things and are not reporting it because they want to abuse the flaw for their own gains. Which is exactly what happened with Etherium. The amount of code and the amount of changes in SegWit makes this a very dangerous change in (of?) Bitcoin. I counted 10 core concepts in Bitcoin being changed with it. We don't yet know how they will interact. We can’t. You are asking people to create everyone-can-spend transactions that would mean a loss of funds to everyone that used it if we do find a major flaw and need to rollback. The gamble is rather uncomforable to many... -- 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 Mon, Oct 17, 2016 at 01:17:39PM +0200, Tom Zander via bitcoin-dev wrote: > On Sunday, 16 October 2016 17:19:37 CEST Andrew C wrote: > > 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? > > As Marek wrote just minutes before your email came in; companies will not > roll out their updates until it locks in. Peter Todd says the same thing. > So your assumption that the lock-in time is the END of the upgrading is > false. Thats only the case for miners. > > The entire point here is that SegWit is much bigger than just full nodes > (including miner). > An entire ecosystem of Bitconin will have a need to upgrade. > > I understand people saying that non-miners don't *need* to upgrade in order > to avoid being kicked of the network, but truely, thats a bogus argument. > > People want to actually participate in Bitcoin and that means they need to > understand all of it. Not just see anyone-can-spend transactions. > I think its rather odd to think that developers on this list can decide > the risk profile that Bitcoin using companies or individuals should have. Please don't misleadingly reference/quote me. I made it quite clear in my last post that because segwit is a backwards compatible soft-fork, the vast majority of code out there will not have to change; my own OpenTimestamps being a good example. All I'll have to do to prepare for segwit is upgrade the (pruned) full nodes that the OpenTimestamps servers depend on to determine what's the most-work valid chain, and in the event I was concerned about compatibility issues, I could easily run my existing nodes behind updated segwit-supporting (pruned) nodes. Like most users, my OpenTimestamps code doesn't "fully understand" transactions at all - I rely on my full node to do that for me. What it does understand about transactions and blocks remains the same in segwit. I can receive transactions from segwit users with lite-client security without any action at all, and full-node security once I upgrade my full nodes (or run them behind upgraded nodes). Your proposed alternative to segwit - flexible transactions - has none of these beneficial properties. And as Matt Corallo reported, it's no-where near ready for deployment: three buffer overflows in 80 lines of code is a serious problem. -- 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/17/2016 7:17 AM, Tom Zander via bitcoin-dev wrote: > As Marek wrote just minutes before your email came in; companies will not > roll out their updates until it locks in. Peter Todd says the same thing. > So your assumption that the lock-in time is the END of the upgrading is > false. Thats only the case for miners. But again, how does having a longer fallow period make this any safer? As was mentioned before, a lot of the wallets listed as WIP have code ready and tested, just not officially released, so not listed as ready. It doesn't take 2 months to roll out a software update that is already prepared beforehand. > The entire point here is that SegWit is much bigger than just full nodes > (including miner). > An entire ecosystem of Bitconin will have a need to upgrade. > > I understand people saying that non-miners don't *need* to upgrade in order > to avoid being kicked of the network, but truely, thats a bogus argument. > > People want to actually participate in Bitcoin and that means they need to > understand all of it. Not just see anyone-can-spend transactions. > I think its rather odd to think that developers on this list can decide > the risk profile that Bitcoin using companies or individuals should have. I think it's rather odd that no major Bitcoin companies have raised any such issues with Segwit and in fact many already have the upgrade in the works. I think it's rather odd that individuals who are not opposed to segwit would choose to not upgrade even though it has been actively discussed for the past year. > There are a bunch of really large assumptions in there that I disagree with. > First of all, miners running the latest software doesn't mean the software > is free from flaws. Everyone makes mistakes. People that see a way to abuse > the system may have found things and are not reporting it because they want > to abuse the flaw for their own gains. Which is exactly what happened with > Etherium. While flaws can still be found, unlike the DAO, Segwit has been tested extensively for a much longer period of time. Waiting any longer isn't likely to help given that so much testing and review has already been done. Even so, that is a pointless argument as it is impossible to know whether waiting a little longer would reveal an issue. > > The amount of code and the amount of changes in SegWit makes this a very > dangerous change in (of?) Bitcoin. I counted 10 core concepts in Bitcoin > being changed with it. We don't yet know how they will interact. We can’t. Really? How so? It's been active on 4 different segwit specific testnets and it has been active on the Testnet for the past several months. People have been spamming segwit transactions and extensively testing Segwit since its deployment on Testnet. I think we know how segwit transactions and all aspects of the changes work together as it has been tested as such for several months now. ___ 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 thread has strayed extensively off topic from the OP which asked a simple question about BIP141 signalling start params. Please move to another thread, or take more general discussion to bitcoin-discuss. Thank you. ___ 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, Oct 17, 2016 at 1:17 PM, Tom Zander via bitcoin-dev wrote: > You are asking people to create everyone-can-spend transactions that would > mean a loss of funds to everyone that used it if we do find a major flaw and > need to rollback. Please, nobody is asking for this. Nobody should produce segwit transactions until the softfork is activated, after which those transactions aren't anyone-can-spend anymore. After activation, nobody can be forced to use the new format immediately (or ever) if they don't want to reduce their tx fees. Maybe because they want to be additionally cautious or maybe because they haven't implemented the new features yet. Either way, it is fine that some people upgrade later since, as repeated by many, this is a backward compatible change. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
