Start time for BIP141 (segwit)

Start time for BIP141 (segwit)
2016-10-16 14:58 ` Tom Zander
                   ` (3 more replies)
  
From: Pieter Wuille @ 2016-10-16 14:31 UTC (permalink / raw)
  To: Bitcoin Dev

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


 permalink raw reply	[|nested]
2016-10-16 14:58 ` 
                   ` 
  
From: Pieter Wuille @ 2016-10-16 14:31 UTC (permalink / raw)
  To: Bitcoin Dev

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


 permalink raw reply	[|nested]
* 
  2016-10-16 14:31 [bitcoin-dev] Start time for BIP141 (segwit) Pieter Wuille

  2016-10-16 16:35   ` Gavin Andresen
  2016-10-16 16:08 ` 
                   ` 
  3 siblings, 1 reply; 31+ messages in thread
From: Tom Zander @ 2016-10-16 14:58 UTC (permalink / raw)
  To: bitcoin-dev, Pieter Wuille

The fallow period sounds waaaay 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


^ permalink raw reply	[|nested] 31+ messages in thread
2016-10-16 14:58 ` Tom Zander

  2016-10-16 16:42     ` Tom Zander
                       ` (2 more replies)
  
From: Gavin Andresen @ 2016-10-16 16:35 UTC (permalink / raw)
  To: Tom Zander, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

On Sun, Oct 16, 2016 at 10:58 AM, Tom Zander via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> The fallow period sounds waaaay 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

[-- Attachment #2: Type: text/html, Size: 1292 bytes --]

 permalink raw reply	[|nested]
2016-10-16 14:58 ` Tom Zander

  2016-10-16 16:42     ` 
                       ` 
  
From: Gavin Andresen @ 2016-10-16 16:35 UTC (permalink / raw)
  To: Tom Zander, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

On Sun, Oct 16, 2016 at 10:58 AM, Tom Zander via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> The fallow period sounds waaaay 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

[-- Attachment #2: Type: text/html, Size: 1292 bytes --]

 permalink raw reply	[|nested]
2016-10-16 16:35   ` Gavin Andresen
  2016-10-16 16:42     ` Tom Zander

  2016-10-16 16:47     ` Douglas Roark
  
From: Eric Voskuil @ 2016-10-16 16:42 UTC (permalink / raw)
  To: Gavin Andresen, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]

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 <bitcoin-dev@lists•linuxfoundation.org> 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 waaaay 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

[-- Attachment #2: Type: text/html, Size: 2315 bytes --]

 permalink raw reply	[|nested]
2016-10-16 16:35   ` Gavin Andresen
  2016-10-16 16:42     ` Tom Zander
  2016-10-16 16:42     ` [bitcoin-dev] Start time for BIP141 (segwit) Eric Voskuil

  2016-10-16 18:20       ` Tom Zander
  
From: Douglas Roark @ 2016-10-16 16:47 UTC (permalink / raw)
  To: bitcoin-dev


[-- Attachment #1.1: Type: text/plain, Size: 1333 bytes --]

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
joroark@vt•edu
PGP key ID: 26623924


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

 permalink raw reply	[|nested]
2016-10-16 16:42     ` Tom Zander

  2016-10-16 17:04       ` [bitcoin-dev] On the security of soft forks Matt Corallo
  
From: Johnson Lau @ 2016-10-16 16:57 UTC (permalink / raw)
  To: Tom Zander, bitcoin-dev

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 <bitcoin-dev@lists•linuxfoundation.org> 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 waaaay 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 
 > 




 permalink raw reply	[|nested]
2016-10-16 16:42     ` Tom Zander
  2016-10-16 16:57       ` Johnson Lau

  
From: Matt Corallo @ 2016-10-16 17:04 UTC (permalink / raw)
  To: Tom Zander, Bitcoin Protocol Discussion

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 waaaay 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.
>  
> 


 permalink raw reply	[|nested]
2016-10-16 14:31 [bitcoin-dev] Start time for BIP141 (segwit) Pieter Wuille
  2016-10-16 14:58 ` Tom Zander
  2016-10-16 16:08 ` Chris Belcher

  2016-10-16 21:49 ` Peter Todd
  
From: Matt Corallo @ 2016-10-16 17:52 UTC (permalink / raw)
  To: Pieter Wuille, Bitcoin Protocol Discussion,
	Pieter Wuille via bitcoin-dev, Bitcoin Dev

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 <bitcoin-dev@lists•linuxfoundation.org> 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,



 permalink raw reply	[|nested]
2016-10-16 16:47     ` Douglas Roark

  2016-10-16 18:41         ` Jorge Timón
                           ` (3 more replies)
  
From: Tom Zander @ 2016-10-16 18:20 UTC (permalink / raw)
  To: bitcoin-dev

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


 permalink raw reply	[|nested]
2016-10-16 16:47     ` Douglas Roark

  2016-10-16 18:41         ` 
                           ` 
  
From: Tom Zander @ 2016-10-16 18:20 UTC (permalink / raw)
  To: bitcoin-dev

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


 permalink raw reply	[|nested]
2016-10-16 18:41         ` Jorge Timón

  2016-10-16 19:11             ` Johnson Lau
  
From: Tom Zander @ 2016-10-16 18:54 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

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


 permalink raw reply	[|nested]
2016-10-16 18:54           ` Tom Zander

  2016-10-16 20:08               ` Tom Zander
  
From: Johnson Lau @ 2016-10-16 19:11 UTC (permalink / raw)
  To: Tom Zander, bitcoin-dev




 ---- On Mon, 17 Oct 2016 02:54:04 +0800 Tom Zander via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> 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 
 > 




 permalink raw reply	[|nested]
* 
  2016-10-16 18:20       ` Tom Zander

  2016-10-16 18:54           ` Tom Zander
  2016-10-16 19:35         `  Matt Corallo
                           ` 
  3 siblings, 1 reply; 31+ messages in thread
From: Jorge Timón @ 2016-10-16 18:41 UTC (permalink / raw)
  To: Tom Zander, Bitcoin Protocol Discussion

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
<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


^ permalink raw reply	[|nested] 31+ messages in thread
2016-10-16 18:20       ` Tom Zander
  2016-10-16 18:41         ` Jorge Timón
  2016-10-16 19:35         ` [bitcoin-dev] (no subject) Matt Corallo

  2016-10-16 20:58           ` Tom Zander
  2016-10-16 20:14         ` Btc Drak
  
From: Douglas Roark @ 2016-10-16 19:49 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion


[-- Attachment #1.1: Type: text/plain, Size: 3135 bytes --]

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
joroark@vt•edu
PGP key ID: 26623924


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

 permalink raw reply	[|nested]
2016-10-16 19:11             ` Johnson Lau

  2016-10-17  3:46                 ` Johnson Lau
  
From: Tom Zander @ 2016-10-16 20:08 UTC (permalink / raw)
  To: bitcoin-dev

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


 permalink raw reply	[|nested]
2016-10-16 18:20       ` Tom Zander
                           ` (2 preceding siblings ...)
  2016-10-16 19:49         ` [bitcoin-dev] Start time for BIP141 (segwit) Douglas Roark

  
From: Btc Drak @ 2016-10-16 20:14 UTC (permalink / raw)
  To: Tom Zander, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 3627 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 4926 bytes --]

 permalink raw reply	[|nested]
2016-10-16 19:35         ` [bitcoin-dev] (no subject) Matt Corallo

  2016-10-17 13:13             ` Btc Drak
  
From: Tom Zander @ 2016-10-16 20:45 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

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


 permalink raw reply	[|nested]
2016-10-16 19:49         ` [bitcoin-dev] Start time for BIP141 (segwit) Douglas Roark

  2016-10-16 21:03             ` gb
                               ` (2 more replies)
  
From: Tom Zander @ 2016-10-16 20:58 UTC (permalink / raw)
  To: bitcoin-dev

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


 permalink raw reply	[|nested]
2016-10-16 19:49         ` [bitcoin-dev] Start time for BIP141 (segwit) Douglas Roark

  2016-10-16 21:03             ` 
                               ` 
  
From: Tom Zander @ 2016-10-16 20:58 UTC (permalink / raw)
  To: bitcoin-dev

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


 permalink raw reply	[|nested]
2016-10-16 20:58           ` Tom Zander
  2016-10-16 21:03             ` gb

  2016-10-16 21:19             ` Andrew C
  
From: Marek Palatinus @ 2016-10-16 21:08 UTC (permalink / raw)
  To: Tom Zander, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1394 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2018 bytes --]

 permalink raw reply	[|nested]
2016-10-16 20:58           ` Tom Zander
  2016-10-16 21:03             ` gb
  2016-10-16 21:08             ` Marek Palatinus

  2016-10-17 11:17               ` Tom Zander
  
From: Andrew C @ 2016-10-16 21:19 UTC (permalink / raw)
  To: Tom Zander, Bitcoin Protocol Discussion



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.


 permalink raw reply	[|nested]
2016-10-16 14:31 [bitcoin-dev] Start time for BIP141 (segwit) Pieter Wuille
                   ` (2 preceding siblings ...)
  2016-10-16 17:52 ` Matt Corallo

  
From: Peter Todd @ 2016-10-16 21:49 UTC ( / )
  To: Pieter Wuille, Bitcoin Protocol Discussion



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
2016-10-16 20:08               ` Tom Zander

  
From: Johnson Lau @ 2016-10-17  3:46 UTC (permalink / raw)
  To: Tom Zander, bitcoin-dev




 ---- On Mon, 17 Oct 2016 04:08:29 +0800 Tom Zander via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> 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



 permalink raw reply	[|nested]
2016-10-16 21:19             ` Andrew C

  2016-10-17 13:09                 ` Peter Todd
                                   ` (2 more replies)
  
From: Tom Zander @ 2016-10-17 11:17 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

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


 permalink raw reply	[|nested]
2016-10-16 21:19             ` Andrew C

  2016-10-17 13:09                 ` 
                                   ` 
  
From: Tom Zander @ 2016-10-17 11:17 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

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


 permalink raw reply	[|nested]
2016-10-16 20:45           ` Tom Zander

  
From: Btc Drak @ 2016-10-17 13:13 UTC (permalink / raw)
  To: Tom Zander, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 2671 bytes --]

For continuity, Matt took the discussion to the bitcoin-discuss lists here
https://lists.linuxfoundation.org/pipermail/bitcoin-discuss/2016-October/000104.html

On Sun, Oct 16, 2016 at 9:45 PM, Tom Zander via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> 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
>

[-- Attachment #2: Type: text/html, Size: 4001 bytes --]

 permalink raw reply	[|nested]
2016-10-17 11:17               ` Tom Zander
  2016-10-17 13:09                 ` Peter Todd

  2016-10-17 13:27                   ` Btc Drak
  2016-10-17 13:31                 ` Jorge Timón
  
From: Andrew C @ 2016-10-17 13:19 UTC (permalink / raw)
  To: Tom Zander, Bitcoin Protocol Discussion



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.



 permalink raw reply	[|nested]
2016-10-17 13:19                 ` Andrew C

  
From: Btc Drak @ 2016-10-17 13:27 UTC (permalink / raw)
  To: Andrew C, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 222 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 403 bytes --]

 permalink raw reply	[|nested]
2016-10-17 11:17               ` Tom Zander
  2016-10-17 13:09                 ` Peter Todd
  2016-10-17 13:19                 ` Andrew C

  
From: Jorge Timón @ 2016-10-17 13:31 UTC (permalink / raw)
  To: Tom Zander, Bitcoin Protocol Discussion

On Mon, Oct 17, 2016 at 1:17 PM, Tom Zander via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> 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.


 permalink raw reply	[|nested]