[bitcoin-dev] (no subject)

[bitcoin-dev] (no subject)

[cAmiLLe miGnon tRixia P. Anecito]

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



Sent from Yahoo Mail on Android


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

[bitcoin-dev] Start time for BIP141 (segwit)

[Pieter Wuille]

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

Re: [bitcoin-dev] Start time for BIP141 (segwit)

[Gavin Andresen]

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

Re: [bitcoin-dev] Start time for BIP141 (segwit)

[Douglas Roark]

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

Re: [bitcoin-dev] Start time for BIP141 (segwit)

[Tom Zander]

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

Re: [bitcoin-dev] (no subject)

[Matt Corallo]

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

Re: [bitcoin-dev] (no subject)

[Tom Zander]

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

Re: [bitcoin-dev] (no subject)

[Btc Drak]

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