* Re: [bitcoin-dev] Start time for BIP141 (segwit)
2016-10-16 18:20 ` Tom Zander
@ 2016-10-16 18:41 ` Jorge Timón
2016-10-16 18:54 ` Tom Zander
2016-10-16 19:35 ` [bitcoin-dev] (no subject) Matt Corallo
` (2 subsequent siblings)
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 [flat|nested] 31+ messages in thread* Re: [bitcoin-dev] Start time for BIP141 (segwit)
2016-10-16 18:41 ` Jorge Timón
@ 2016-10-16 18:54 ` Tom Zander
2016-10-16 19:11 ` Johnson Lau
0 siblings, 1 reply; 31+ messages in thread
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 [flat|nested] 31+ messages in thread
* Re: [bitcoin-dev] Start time for BIP141 (segwit)
2016-10-16 18:54 ` Tom Zander
@ 2016-10-16 19:11 ` Johnson Lau
2016-10-16 20:08 ` Tom Zander
0 siblings, 1 reply; 31+ messages in thread
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 [flat|nested] 31+ messages in thread
* Re: [bitcoin-dev] Start time for BIP141 (segwit)
2016-10-16 19:11 ` Johnson Lau
@ 2016-10-16 20:08 ` Tom Zander
2016-10-17 3:46 ` Johnson Lau
0 siblings, 1 reply; 31+ messages in thread
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 [flat|nested] 31+ messages in thread
* Re: [bitcoin-dev] Start time for BIP141 (segwit)
2016-10-16 20:08 ` Tom Zander
@ 2016-10-17 3:46 ` Johnson Lau
0 siblings, 0 replies; 31+ messages in thread
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 [flat|nested] 31+ messages in thread
* Re: [bitcoin-dev] (no subject)
2016-10-16 18:20 ` Tom Zander
2016-10-16 18:41 ` Jorge Timón
@ 2016-10-16 19:35 ` Matt Corallo
2016-10-16 20:45 ` Tom Zander
2016-10-16 19:49 ` [bitcoin-dev] Start time for BIP141 (segwit) Douglas Roark
2016-10-16 20:14 ` Btc Drak
3 siblings, 1 reply; 31+ messages in thread
From: Matt Corallo @ 2016-10-16 19:35 UTC (permalink / raw)
To: Tom Zander, Bitcoin Protocol Discussion
You keep calling flexible transactions "safer", and yet you haven't
mentioned that the current codebase is riddled with blatant and massive
security holes. For example, you seem to have misunderstood C++'s memory
model - you would have no less than three out-of-bound, probably
exploitable memory accesses in your 80-LoC deserialize method at
https://github.com/bitcoinclassic/bitcoinclassic/blob/develop/src/primitives/transaction.cpp#L119
if you were to turn on flexible transactions (and I only reviewed that
method for 2 minutes). If you want to propose an alternative to a
community which has been in desperate need of fixes to many problems for
several years, please do so with something which would not take at least
a year to complete given a large team of qualified developers.
You additionally have not yet bothered to address the discussion of
soft-fork security at
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html
which I believe answers all of your claims about upgrades required in a
much more detailed discussion than I will include here. Please take your
off-topic discussions there instead of this thread.
On 10/16/16 18:20, Tom Zander via bitcoin-dev wrote:
> On Sunday, 16 October 2016 09:47:40 CEST Douglas Roark via bitcoin-dev
> wrote:
>> Would I want anyone to lose money due to faulty wallets? Of course not.
>> By the same token, devs have had almost a year to tinker with SegWit and
>> make sure the wallet isn't so poorly written that it'll flame out when
>> SegWit comes along. It's not like this is some untested, mostly unknown
>> feature that's being slipped out at the last minute
>
> There have been objections to the way that SegWit has been implemented for a
> long time, some wallets are taking a "wait and see" approach. If you look
> at the page you linked[1], that is a very very sad state of affairs. The
> vast majority is not ready. Would be interesting to get a more up-to-date
> view.
> Wallets probably won't want to invest resources adding support for a feature
> that will never be activated. The fact that we have a much safer alternative
> in the form of Flexible Transactions may mean it will not get activated. We
> won't know until its actually locked in.
> Wallets may not act until its actually locked in either. And I think we
> should respect that.
>
> Even if all wallets support it (and thats a big if), they need to be rolled
> out and people need to actually download those updates.
> This takes time, 2 months after the lock-in of SegWit would be the minimum
> safe time for people to actually upgrade.
>
> 1) https://bitcoincore.org/en/segwit_adoption/
>
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoin-dev] (no subject)
2016-10-16 19:35 ` [bitcoin-dev] (no subject) Matt Corallo
@ 2016-10-16 20:45 ` Tom Zander
2016-10-17 13:13 ` Btc Drak
0 siblings, 1 reply; 31+ messages in thread
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 [flat|nested] 31+ messages in thread
* Re: [bitcoin-dev] (no subject)
2016-10-16 20:45 ` Tom Zander
@ 2016-10-17 13:13 ` Btc Drak
0 siblings, 0 replies; 31+ messages in thread
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 [flat|nested] 31+ messages in thread
* Re: [bitcoin-dev] Start time for BIP141 (segwit)
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 19:49 ` Douglas Roark
2016-10-16 20:58 ` Tom Zander
2016-10-16 20:14 ` Btc Drak
3 siblings, 1 reply; 31+ messages in thread
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 [flat|nested] 31+ messages in thread
* Re: [bitcoin-dev] Start time for BIP141 (segwit)
2016-10-16 19:49 ` [bitcoin-dev] Start time for BIP141 (segwit) Douglas Roark
@ 2016-10-16 20:58 ` Tom Zander
2016-10-16 21:03 ` gb
` (2 more replies)
0 siblings, 3 replies; 31+ messages in thread
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 [flat|nested] 31+ messages in thread* Re: [bitcoin-dev] Start time for BIP141 (segwit)
2016-10-16 20:58 ` Tom Zander
@ 2016-10-16 21:03 ` gb
2016-10-16 21:08 ` Marek Palatinus
2016-10-16 21:19 ` Andrew C
2 siblings, 0 replies; 31+ messages in thread
From: gb @ 2016-10-16 21:03 UTC (permalink / raw)
To: Tom Zander, Bitcoin Protocol Discussion
It's controversial not contriversial.
And it isn't controversial except among a small clique, which you seem
to be the sole representative of here. It might be time to consider
unsubscribing (again) if you don't seem to know when to shut up and the
moderators are letting you go on an inappropriate crusade here.
On Sun, 2016-10-16 at 22:58 +0200, Tom Zander via bitcoin-dev wrote:
> On Sunday, 16 October 2016 12:49:47 CEST Douglas Roark via bitcoin-dev
> wrote:
> > It's not the website's fault if wallet devs aren't updating their
> > statuses. Besides, "WIP" can mean an awful lot of things.
>
> As I said, it would be nice to get an updated version so we can see more
> than 20% readyness of wallets.
> The wallet devs not caring enough to update the status should be a worrying
> sign, though.
>
> > A lot of devs have already worked on SegWit support. This has been
> > covered. Even if they don't support SegWit, the wallets will probably
> > work just fine. (For awhile, Armory did crash when trying to read SegWit
>
> SegWit is probably the most disruptive and most invasive change ever made to
> Bitcoin. We have miners actively saying they don't like it and this makes it
> a contriversial upgrade which means the network may split and other issues.
>
> Your "wallets will probably work just fine" comment is honestly not the
> answer to make people put faith in the way that this is being vetted and
> checked...
>
> > Also, once again, FlexTrans is off-topic.
>
> Its an alternative and brought up in that vain. Nothing more. Feel free to
> respond to the BIP discussion (134) right on this list if you have any
> opinions on it. They will be on-topic there. No problems have been found so
> far.
>
> Lets get back to the topic. Having a longer fallow period is a simple way to
> be safe. Your comments make me even more scared that safety is not taken
> into account the way it would.
>
> People are not even acknowledging the damage a contriversial soft fork of
> the scope and magnitude of SegWit can have, and a simple request to extend
> the fallow time for safety is really not a big deal.
> SegWit has been in development for 18 months or so, what is a couple of
> extra week??
>
> I would just like to ask people to take the safety of Bitcoin serious. This
> discussion and refusal to extend the safety period is not a good sign.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoin-dev] Start time for BIP141 (segwit)
2016-10-16 20:58 ` Tom Zander
2016-10-16 21:03 ` gb
@ 2016-10-16 21:08 ` Marek Palatinus
2016-10-16 21:19 ` Andrew C
2 siblings, 0 replies; 31+ messages in thread
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 [flat|nested] 31+ messages in thread
* Re: [bitcoin-dev] Start time for BIP141 (segwit)
2016-10-16 20:58 ` Tom Zander
2016-10-16 21:03 ` gb
2016-10-16 21:08 ` Marek Palatinus
@ 2016-10-16 21:19 ` Andrew C
2016-10-17 11:17 ` Tom Zander
2 siblings, 1 reply; 31+ messages in thread
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 [flat|nested] 31+ messages in thread
* Re: [bitcoin-dev] Start time for BIP141 (segwit)
2016-10-16 21:19 ` Andrew C
@ 2016-10-17 11:17 ` Tom Zander
2016-10-17 13:09 ` Peter Todd
` (2 more replies)
0 siblings, 3 replies; 31+ messages in thread
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 [flat|nested] 31+ messages in thread* Re: [bitcoin-dev] Start time for BIP141 (segwit)
2016-10-17 11:17 ` Tom Zander
@ 2016-10-17 13:09 ` Peter Todd
2016-10-17 13:19 ` Andrew C
2016-10-17 13:31 ` Jorge Timón
2 siblings, 0 replies; 31+ messages in thread
From: Peter Todd @ 2016-10-17 13:09 UTC (permalink / raw)
To: Tom Zander, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2912 bytes --]
On Mon, Oct 17, 2016 at 01:17:39PM +0200, Tom Zander via bitcoin-dev wrote:
> On Sunday, 16 October 2016 17:19:37 CEST Andrew C wrote:
> > On 10/16/2016 4:58 PM, Tom Zander via bitcoin-dev wrote:
> > > Lets get back to the topic. Having a longer fallow period is a simple
> > > way to be safe. Your comments make me even more scared that safety is
> > > not taken into account the way it would.
> >
> > Can you please explain how having a longer grace period makes it any
> > safer? Once the fork reaches the LOCKED_IN status, the fork will become
> > active after the period is over. How does having a longer grace period
> > make this any safer besides just adding more waiting before it goes
> > active?
>
> As Marek wrote just minutes before your email came in; companies will not
> roll out their updates until it locks in. Peter Todd says the same thing.
> So your assumption that the lock-in time is the END of the upgrading is
> false. Thats only the case for miners.
>
> The entire point here is that SegWit is much bigger than just full nodes
> (including miner).
> An entire ecosystem of Bitconin will have a need to upgrade.
>
> I understand people saying that non-miners don't *need* to upgrade in order
> to avoid being kicked of the network, but truely, thats a bogus argument.
>
> People want to actually participate in Bitcoin and that means they need to
> understand all of it. Not just see anyone-can-spend transactions.
> I think its rather odd to think that developers on this list can decide
> the risk profile that Bitcoin using companies or individuals should have.
Please don't misleadingly reference/quote me.
I made it quite clear in my last post that because segwit is a backwards
compatible soft-fork, the vast majority of code out there will not have to
change; my own OpenTimestamps being a good example. All I'll have to do to
prepare for segwit is upgrade the (pruned) full nodes that the OpenTimestamps
servers depend on to determine what's the most-work valid chain, and in the
event I was concerned about compatibility issues, I could easily run my
existing nodes behind updated segwit-supporting (pruned) nodes.
Like most users, my OpenTimestamps code doesn't "fully understand" transactions
at all - I rely on my full node to do that for me. What it does understand
about transactions and blocks remains the same in segwit. I can receive
transactions from segwit users with lite-client security without any action at
all, and full-node security once I upgrade my full nodes (or run them behind
upgraded nodes).
Your proposed alternative to segwit - flexible transactions - has none of these
beneficial properties. And as Matt Corallo reported, it's no-where near ready
for deployment: three buffer overflows in 80 lines of code is a serious
problem.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [bitcoin-dev] Start time for BIP141 (segwit)
2016-10-17 11:17 ` Tom Zander
2016-10-17 13:09 ` Peter Todd
@ 2016-10-17 13:19 ` Andrew C
2016-10-17 13:27 ` Btc Drak
2016-10-17 13:31 ` Jorge Timón
2 siblings, 1 reply; 31+ messages in thread
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 [flat|nested] 31+ messages in thread
* Re: [bitcoin-dev] Start time for BIP141 (segwit)
2016-10-17 11:17 ` Tom Zander
2016-10-17 13:09 ` Peter Todd
2016-10-17 13:19 ` Andrew C
@ 2016-10-17 13:31 ` Jorge Timón
2 siblings, 0 replies; 31+ messages in thread
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 [flat|nested] 31+ messages in thread
* Re: [bitcoin-dev] Start time for BIP141 (segwit)
2016-10-16 18:20 ` Tom Zander
` (2 preceding siblings ...)
2016-10-16 19:49 ` [bitcoin-dev] Start time for BIP141 (segwit) Douglas Roark
@ 2016-10-16 20:14 ` Btc Drak
3 siblings, 0 replies; 31+ messages in thread
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 [flat|nested] 31+ messages in thread