Re: [bitcoin-dev] A Segwit2x BIP
While BIP91 is probably not terribly harmful, because the vast majority of nodes and users are prepared for it - the hard fork portion of this BIP is being deployed like an emergency patch or quick bug fix to the system. Please consider updating the BIP to include some justification for the urgency of the consensus change, and the reasons for not delaying until a better engineered solution (spoonet, BIP103, etc.) can be deployed. On Thu, Jul 13, 2017 at 3:19 PM, Sergio Demian Lerner via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The BIP has been updated. > > Changes: > - The technical spec has been improved: now the block size increase is > specified in terms of weight and not in terms of bytes. > - The increase in the maximum block sigops after HF has been documented. > - Comments added about the worst case block size. > > Happy weekend! And don't forget to start signaling something before block > 475776 ! It's just 90 blocks away. > Bit 1 or 4,1 or whatever you wish, but please signal something. > > To the moon! > > > On Wed, Jul 12, 2017 at 2:38 PM, Jorge Timón via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> >> >> On 12 Jul 2017 2:31 pm, "Tom Zander via bitcoin-dev" < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> On Monday, 10 July 2017 20:38:08 CEST Jorge Timón via bitcoin-dev wrote: >> > I think anything less than 1 year after release of tested code by some >> > implementation would be irresponsible for any hardfork, even a very >> > simple one. >> >> Good news! >> >> Code to support 2x (the hard fork part of the proposal) has been out and >> tested for much longer than that. >> >> >> Not true. It's different code on top of segwit. The first attempt in btc1 >> (very recent) didn't even increased the size (because it changed the >> meaningless "base size" without touching the weight limit. As for the >> current code, I don't think it has been properly tested today, let alone >> "for mucj longer than 1 year. >> Anyway, I said, one year from tested release. Segwitx2 hasn't been >> released, has it? If so, too late to discuss a bip imo, the bip may end up >> being different from what has been released due to feedback (unless it is >> ignored again, of course). >> >> >> -- >> 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 >> >> > > ___ > 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] how to disable segwit in my build?
> sounds good, though I'm unclear on how exactly to achieve (2) given that any party I have ever transacted with (or otherwise knows an address of mine) can send me coins at any time. So it seems the only possible way to be certain is to run a node that has never published an address to a 3rd party. Is that accurate? Yes, as soon as you receive new Bitcoins, there's a chance that they have been in a SegWit transaction at some point. I'm not sure if you can see the chain of transactions for an address in bitcoin-cli, but if that is possible, you should be able to double check the transaction types. > Another thing that could be done is to modify my own node so that it actually rejects such tx, but then I have modified consensus rules myself, thus defeating the goal of remaining with status-quo rules, and anyway the rest of the network would accept the tx. I guess the benefit is that I could be certain of the remaining funds I have. Hmm yes, if you reject a such transaction, you'll hardfork the network. If you ignore it in your wallet, you'll be safe, but you'll lose those bitcoins ofc. It's a difficult situation. > I suppose that it would be possible without modifying any rule to construct a "certain balance" and an "uncertain balance". Should be possible. > Hampus, thanks for the explanation! You're welcome! I personally very much like and want SegWit, but I respect people that wants to maintain the status quo, it's what will make Bitcoin strong in the long run. Cheers Hampus 2017-07-14 1:20 GMT+02:00 Dan Libby via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org>: > Hampus, thanks for the explanation! > > On 07/13/2017 03:50 PM, Hampus Sjöberg wrote: > > > Yes. > > So you have two choices to be fully secure: > > 1. Validate using the new rules of the network (in other words, run a > > SegWit node) > > 2. Avoid any chain of transaction that contains a SegWit transaction > > sounds good, though I'm unclear on how exactly to achieve (2) given that > any party I have ever transacted with (or otherwise knows an address of > mine) can send me coins at any time. So it seems the only possible way > to be certain is to run a node that has never published an address to a > 3rd party. Is that accurate? > > Another thing that could be done is to modify my own node so that it > actually rejects such tx, but then I have modified consensus rules > myself, thus defeating the goal of remaining with status-quo rules, and > anyway the rest of the network would accept the tx. I guess the benefit > is that I could be certain of the remaining funds I have. > > I suppose that it would be possible without modifying any rule to > construct a "certain balance" and an "uncertain balance". > > I don't intend to do such modifications! just grasping for understanding. > > > > See > > https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Backward_ > compatibility > > So the witness program is encoded in a new format that old nodes do not > > understand. > > This means that for old nodes, a number >0 will be put on the stack. > > When the script is done, it will be evaluated to true (because of >0) > > and be counted as a valid spend. > > > > https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki also > > explains the new witness program more in detail (I left out some details > > in my explanation). > > I read the relevant parts, thanks! > ___ > 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] how to disable segwit in my build?
On Fri, Jul 14, 2017 at 12:20 AM, Dan Libby via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 07/13/2017 03:50 PM, Hampus Sjöberg wrote: > > 2. Avoid any chain of transaction that contains a SegWit transaction > > sounds good, though I'm unclear on how exactly to achieve (2) given that > any party I have ever transacted with (or otherwise knows an address of > mine) can send me coins at any time. So it seems the only possible way > to be certain is to run a node that has never published an address to a > 3rd party. Is that accurate? > You would also have to ensure that everyone you give your addresses to follows the same rule. As time passes, there would be fewer and fewer people who have "clean" outputs. >From the perspective of old nodes, segwit looks like lots of people are transferring money to "anyone-can-spend" outputs. This outputs are completely unprotected. Literally, anyone can spend them. (In practice, miners would spend them, since why would they include a transaction that sends "free money" to someone else). If you run an old node, then someone could send you a transaction that only spends segwit outputs and you would think it is a valid payment. Imagine that there are only 3 UTXOs (Alice, Bob and Carl have all the Bitcoins). UTXO-1: Requires signature by Alice (legacy output) UTXO-2: Anyone can pay (but is actually a segwit output that needs to be signed by Bob) UTXO-3: Anyone can pay (but is actually a segwit output that needs to be signed by Carl) Only Bob can spend UTXO-2, since it needs his signature. Anyone could create a transaction that spends UTXO-2 and it would look good to all legacy nodes. It is an "anyone can spend" output after all. However, if they submit the transaction to the miners, then it will be rejected, because according to the new rules, it is invalid (it needs to be signed by Bob). Once a soft fork goes through, then all miners will enforce the new rules. A miner who added the transaction to one of his blocks (since it is valid under the old rules) would find that no other miners would accept his block and he would get no fees for that block. This means that all miners have an incentive to upgrade once a soft fork activates. His block would be accepted by legacy nodes, for a short while. However, since 95% of the miners are on the main chain, their chain (which rejects his block) would end up the longest. If you are running a legacy client when a soft fork comes in, then you can be tricked with "zero confirm" transactions. The transaction will look good to you, but will be invalid under the new rules. This makes your client think you have received (a lot of) money, but in practice, the transaction will not be accepted by the miners. > Another thing that could be done is to modify my own node so that it > actually rejects such tx, but then I have modified consensus rules > myself, thus defeating the goal of remaining with status-quo rules, and > anyway the rest of the network would accept the tx. I guess the benefit > is that I could be certain of the remaining funds I have. > If you wanted, you could mark any transaction that has a segwit looking output as "dirty" and then all of its descendants as dirty. However, pretty quickly, only a tiny fraction of all bitcoins would be clean. I suppose that it would be possible without modifying any rule to > construct a "certain balance" and an "uncertain balance". > Right. I think a reasonably compromise would be to assume that all transactions buried more than a few hundred blocks deep are probably ok. Only segwit looking outputs would be marked as "uncertain". ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
