Re: [bitcoin-dev] Start time for BIP141 (segwit)
On Mon, Oct 17, 2016 at 1:17 PM, Tom Zander via bitcoin-dev 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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Start time for BIP141 (segwit)
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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Start time for BIP141 (segwit)
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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] (no subject)
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 > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Start time for BIP141 (segwit)
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 signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Start time for BIP141 (segwit)
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
