Discussion:
Start time for BIP141 (segwit)
(too old to reply)
Pieter Wuille via bitcoin-dev
2016-10-16 14:31:55 UTC
Permalink
Raw Message
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
Tom Zander via bitcoin-dev
2016-10-16 14:58:26 UTC
Permalink
Raw Message
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
Post by Pieter Wuille via 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
(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
Gavin Andresen via bitcoin-dev
2016-10-16 16:35:58 UTC
Permalink
Raw Message
On Sun, Oct 16, 2016 at 10:58 AM, Tom Zander via bitcoin-dev <
Post by Tom Zander via bitcoin-dev
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
Tom Zander via bitcoin-dev
2016-10-16 16:42:26 UTC
Permalink
Raw Message
Post by Gavin Andresen via bitcoin-dev
On Sun, Oct 16, 2016 at 10:58 AM, Tom Zander via bitcoin-dev <
Post by Tom Zander via bitcoin-dev
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
Johnson Lau via bitcoin-dev
2016-10-16 16:57:46 UTC
Permalink
Raw Message
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
Post by Tom Zander via bitcoin-dev
Post by Gavin Andresen via bitcoin-dev
On Sun, Oct 16, 2016 at 10:58 AM, Tom Zander via bitcoin-dev <
Post by Tom Zander via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Matt Corallo via bitcoin-dev
2016-10-16 17:04:59 UTC
Permalink
Raw Message
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
Post by Tom Zander via bitcoin-dev
Post by Gavin Andresen via bitcoin-dev
On Sun, Oct 16, 2016 at 10:58 AM, Tom Zander via bitcoin-dev <
Post by Tom Zander via bitcoin-dev
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.
Eric Voskuil via bitcoin-dev
2016-10-16 16:42:49 UTC
Permalink
Raw Message
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
Post by Tom Zander via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Douglas Roark via bitcoin-dev
2016-10-16 16:47:40 UTC
Permalink
Raw Message
Post by Gavin Andresen via bitcoin-dev
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
***@vt.edu
PGP key ID: 26623924
Tom Zander via bitcoin-dev
2016-10-16 18:20:50 UTC
Permalink
Raw Message
On Sunday, 16 October 2016 09:47:40 CEST Douglas Roark via bitcoin-dev
Post by Douglas Roark via bitcoin-dev
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
Jorge Timón via bitcoin-dev
2016-10-16 18:41:34 UTC
Permalink
Raw Message
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
Post by Tom Zander via bitcoin-dev
On Sunday, 16 October 2016 09:47:40 CEST Douglas Roark via bitcoin-dev
Post by Douglas Roark via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Tom Zander via bitcoin-dev
2016-10-16 18:54:04 UTC
Permalink
Raw Message
Post by Jorge Timón via bitcoin-dev
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
Johnson Lau via bitcoin-dev
2016-10-16 19:11:23 UTC
Permalink
Raw Message
Post by Tom Zander via bitcoin-dev
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.
Post by Tom Zander via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Tom Zander via bitcoin-dev
2016-10-16 20:08:29 UTC
Permalink
Raw Message
Post by Johnson Lau via bitcoin-dev
Post by Tom Zander via bitcoin-dev
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.
Post by Johnson Lau via bitcoin-dev
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
Johnson Lau via bitcoin-dev
2016-10-17 03:46:11 UTC
Permalink
Raw Message
Post by Tom Zander via bitcoin-dev
Post by Johnson Lau via bitcoin-dev
Post by Tom Zander via bitcoin-dev
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
Matt Corallo via bitcoin-dev
2016-10-16 19:35:52 UTC
Permalink
Raw Message
You keep calling flexible transactions "safer", and yet you haven't
mentioned that the current codebase is riddled with blatant and massive
security holes. For example, you seem to have misunderstood C++'s memory
model - you would have no less than three out-of-bound, probably
exploitable memory accesses in your 80-LoC deserialize method at
https://github.com/bitcoinclassic/bitcoinclassic/blob/develop/src/primitives/transaction.cpp#L119
if you were to turn on flexible transactions (and I only reviewed that
method for 2 minutes). If you want to propose an alternative to a
community which has been in desperate need of fixes to many problems for
several years, please do so with something which would not take at least
a year to complete given a large team of qualified developers.

You additionally have not yet bothered to address the discussion of
soft-fork security at
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html
which I believe answers all of your claims about upgrades required in a
much more detailed discussion than I will include here. Please take your
off-topic discussions there instead of this thread.
Post by Tom Zander via bitcoin-dev
On Sunday, 16 October 2016 09:47:40 CEST Douglas Roark via bitcoin-dev
Post by Douglas Roark via bitcoin-dev
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 via bitcoin-dev
2016-10-16 20:45:19 UTC
Permalink
Raw Message
Post by Matt Corallo via bitcoin-dev
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.
Post by Matt Corallo via bitcoin-dev
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!
Post by Matt Corallo via bitcoin-dev
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
Btc Drak via bitcoin-dev
2016-10-17 13:13:25 UTC
Permalink
Raw Message
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 <
Post by Tom Zander via bitcoin-dev
Post by Matt Corallo via bitcoin-dev
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.
Post by Matt Corallo via bitcoin-dev
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
Post by Matt Corallo via bitcoin-dev
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!
Post by Matt Corallo via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Douglas Roark via bitcoin-dev
2016-10-16 19:49:47 UTC
Permalink
Raw Message
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....
Post by Tom Zander via bitcoin-dev
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.
Post by Tom Zander via bitcoin-dev
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
***@vt.edu
PGP key ID: 26623924
Tom Zander via bitcoin-dev
2016-10-16 20:58:31 UTC
Permalink
Raw Message
On Sunday, 16 October 2016 12:49:47 CEST Douglas Roark via bitcoin-dev
Post by Douglas Roark via bitcoin-dev
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.
Post by Douglas Roark via bitcoin-dev
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...
Post by Douglas Roark via bitcoin-dev
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
gb via bitcoin-dev
2016-10-16 21:03:52 UTC
Permalink
Raw Message
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.
Post by Tom Zander via bitcoin-dev
On Sunday, 16 October 2016 12:49:47 CEST Douglas Roark via bitcoin-dev
Post by Douglas Roark via bitcoin-dev
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.
Post by Douglas Roark via bitcoin-dev
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...
Post by Douglas Roark via bitcoin-dev
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.
Marek Palatinus via bitcoin-dev
2016-10-16 21:08:08 UTC
Permalink
Raw Message
On Sun, Oct 16, 2016 at 10:58 PM, Tom Zander via bitcoin-dev <
Post by Tom Zander via bitcoin-dev
On Sunday, 16 October 2016 12:49:47 CEST Douglas Roark via bitcoin-dev
Post by Douglas Roark via bitcoin-dev
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
Post by Tom Zander via bitcoin-dev
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
Andrew C via bitcoin-dev
2016-10-16 21:19:37 UTC
Permalink
Raw Message
Post by Tom Zander via bitcoin-dev
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.
Tom Zander via bitcoin-dev
2016-10-17 11:17:39 UTC
Permalink
Raw Message
Post by Andrew C via bitcoin-dev
Post by Tom Zander via bitcoin-dev
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.
Post by Andrew C via bitcoin-dev
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
Peter Todd via bitcoin-dev
2016-10-17 13:09:27 UTC
Permalink
Raw Message
Post by Tom Zander via bitcoin-dev
Post by Andrew C via bitcoin-dev
Post by Tom Zander via bitcoin-dev
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
Andrew C via bitcoin-dev
2016-10-17 13:19:29 UTC
Permalink
Raw Message
Post by Tom Zander via bitcoin-dev
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.
Post by Tom Zander via bitcoin-dev
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.
Post by Tom Zander via bitcoin-dev
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.
Post by Tom Zander via bitcoin-dev
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.
Btc Drak via bitcoin-dev
2016-10-17 13:27:08 UTC
Permalink
Raw Message
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.
Jorge Timón via bitcoin-dev
2016-10-17 13:31:07 UTC
Permalink
Raw Message
On Mon, Oct 17, 2016 at 1:17 PM, Tom Zander via bitcoin-dev
Post by Tom Zander via bitcoin-dev
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.

Btc Drak via bitcoin-dev
2016-10-16 20:14:15 UTC
Permalink
Raw Message
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 <
Post by Tom Zander via bitcoin-dev
On Sunday, 16 October 2016 09:47:40 CEST Douglas Roark via bitcoin-dev
Post by Douglas Roark via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Chris Belcher via bitcoin-dev
2016-10-16 16:08:14 UTC
Permalink
Raw Message
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
Post by Pieter Wuille via 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
(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,
Matt Corallo via bitcoin-dev
2016-10-16 17:52:09 UTC
Permalink
Raw Message
This start time seems reasonable to me. It is mostly in line with BIP 9's proposed defaults, which seems like an appropriate choice.
Post by Pieter Wuille via 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
(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,
Peter Todd via bitcoin-dev
2016-10-16 21:49:57 UTC
Permalink
Raw Message
Post by Pieter Wuille via 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).
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
Loading...