* [bitcoin-dev] (no subject)
@ 2015-10-24 16:30 cAmiLLe miGnon tRixia P. Anecito
0 siblings, 0 replies; 4+ messages in thread
From: cAmiLLe miGnon tRixia P. Anecito @ 2015-10-24 16:30 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 39 bytes --]
Sent from Yahoo Mail on Android
[-- Attachment #2: Type: text/html, Size: 202 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* [bitcoin-dev] Start time for BIP141 (segwit)
@ 2016-10-16 14:31 Pieter Wuille
2016-10-16 16:35 ` Gavin Andresen
0 siblings, 1 reply; 4+ messages in thread
From: Pieter Wuille @ 2016-10-16 14:31 UTC (permalink / raw)
To: Bitcoin Dev
Hello all,
We're getting ready for Bitcoin Core's 0.13.1 release - the first one
to include segregated witness (BIP 141, 143, 144, 145) for Bitcoin
mainnet, after being extensively tested on testnet and in other
software. Following the BIP9 recommendation [1] to set the versionbits
start time a month in the future and discussion in the last IRC
meeting [2], I propose we set BIP 141's start time to November 15,
2016, 0:00 UTC (unix time 1479168000).
Note that this is just a lower bound on the time when the versionbits
signalling can begin. Activation on the network requires:
(1) This date to pass
(2) A full retarget window of 2016 blocks with 95% signalling the
version bit (bit 1 for BIP141)
(3) A fallow period consisting of another 2016 blocks.
[1] https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
[2] http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-13-19.04.log.html
Cheers,
--
Pieter
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Start time for BIP141 (segwit)
@ 2016-10-16 16:35 ` Gavin Andresen
2016-10-16 16:47 ` Douglas Roark
0 siblings, 1 reply; 4+ messages in thread
From: Gavin Andresen @ 2016-10-16 16:35 UTC (permalink / raw)
To: Tom Zander, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 637 bytes --]
On Sun, Oct 16, 2016 at 10:58 AM, Tom Zander via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> The fallow period sounds waaaay to short. I suggest 2 months at minimum
> since anyone that wants to be safe needs to upgrade.
>
I asked a lot of businesses and individuals how long it would take them to
upgrade to a new release over the last year or two.
Nobody said it would take them more than two weeks.
If somebody is running their own validation code... then we should assume
they're sophisticated enough to figure out how to mitigate any risks
associated with segwit activation on their own.
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 1292 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Start time for BIP141 (segwit)
2016-10-16 16:35 ` Gavin Andresen
@ 2016-10-16 16:47 ` Douglas Roark
2016-10-16 18:20 ` Tom Zander
0 siblings, 1 reply; 4+ messages in thread
From: Douglas Roark @ 2016-10-16 16:47 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1.1: Type: text/plain, Size: 1333 bytes --]
On 2016/10/16 09:35, Gavin Andresen via bitcoin-dev wrote:
> I asked a lot of businesses and individuals how long it would take them
> to upgrade to a new release over the last year or two.
>
> Nobody said it would take them more than two weeks.
>
> If somebody is running their own validation code... then we should
> assume they're sophisticated enough to figure out how to mitigate any
> risks associated with segwit activation on their own.
In addition, there has been a page up for several months
(https://bitcoincore.org/en/segwit_adoption/) that gauges whether or not
wallets are ready for SegWit. Unfortunately, it appears that the page
hasn't been updated since May. I do know that several wallets have
finished or are close to finishing their support, though.
Would I want anyone to lose money due to faulty wallets? Of course not.
By the same token, devs have had almost a year to tinker with SegWit and
make sure the wallet isn't so poorly written that it'll flame out when
SegWit comes along. It's not like this is some untested, mostly unknown
feature that's being slipped out at the last minute, unlike other
features I could name but won't. :)
--
---
Douglas Roark
Cryptocurrency, network security, travel, and art.
https://onename.com/droark
joroark@vt•edu
PGP key ID: 26623924
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Start time for BIP141 (segwit)
2016-10-16 16:47 ` Douglas Roark
@ 2016-10-16 18:20 ` Tom Zander
2016-10-16 19:35 ` [bitcoin-dev] (no subject) Matt Corallo
0 siblings, 1 reply; 4+ messages in thread
From: Tom Zander @ 2016-10-16 18:20 UTC (permalink / raw)
To: bitcoin-dev
On Sunday, 16 October 2016 09:47:40 CEST Douglas Roark via bitcoin-dev
wrote:
> Would I want anyone to lose money due to faulty wallets? Of course not.
> By the same token, devs have had almost a year to tinker with SegWit and
> make sure the wallet isn't so poorly written that it'll flame out when
> SegWit comes along. It's not like this is some untested, mostly unknown
> feature that's being slipped out at the last minute
There have been objections to the way that SegWit has been implemented for a
long time, some wallets are taking a "wait and see" approach. If you look
at the page you linked[1], that is a very very sad state of affairs. The
vast majority is not ready. Would be interesting to get a more up-to-date
view.
Wallets probably won't want to invest resources adding support for a feature
that will never be activated. The fact that we have a much safer alternative
in the form of Flexible Transactions may mean it will not get activated. We
won't know until its actually locked in.
Wallets may not act until its actually locked in either. And I think we
should respect that.
Even if all wallets support it (and thats a big if), they need to be rolled
out and people need to actually download those updates.
This takes time, 2 months after the lock-in of SegWit would be the minimum
safe time for people to actually upgrade.
1) https://bitcoincore.org/en/segwit_adoption/
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] (no subject)
2016-10-16 18:20 ` Tom Zander
@ 2016-10-16 19:35 ` Matt Corallo
2016-10-16 20:45 ` Tom Zander
0 siblings, 1 reply; 4+ 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] 4+ 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; 4+ 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] 4+ 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; 4+ 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] 4+ messages in thread
end of thread, other threads:[~2016-10-17 13:13 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-24 16:30 [bitcoin-dev] (no subject) cAmiLLe miGnon tRixia P. Anecito
2016-10-16 14:31 [bitcoin-dev] Start time for BIP141 (segwit) Pieter Wuille
2016-10-16 16:35 ` Gavin Andresen
2016-10-16 16:47 ` Douglas Roark
2016-10-16 18:20 ` Tom Zander
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox