Re: [bitcoin-dev] Height based vs block time based thresholds
Luke's proposed changes to BIP8 (specifically, the FAILING state) seem designed to address the regression compared to BIP9 that there is no way to avoid activating a softfork that is shown to be suboptimal or flawed in some (serious enough) way - after deployment is well underway - without hardforking. I agree with your principle but we should also look at the circumstances in which this mechanism would be beneficial vs. when it would cause harm (compared to BIP8 without this mechanism). The scenario this was designed for is "miners refusing to activate, on non-technical grounds, a widely desired upgrade" - in which case the "wakeup call" would be in users' hands, not anyone in particular. Is there a hypothetical scenario in which the orphan risk outweighs the benefits of having this kind of upgrade mechanism that can (at deploy-time) be chosen to be optional by default with a deferred mechanism to make it mandatory? If so, is there any thought on how to realize the latter without the former? Sent with [ProtonMail](https://protonmail.com) Secure Email. > Original Message > Subject: Re: [bitcoin-dev] Height based vs block time based thresholds > Local Time: July 5, 2017 8:06 AM > UTC Time: July 5, 2017 8:06 AM > From: bitcoin-dev@lists.linuxfoundation.org > To: Bitcoin Dev > On Wed, Jul 5, 2017 at 3:50 AM, Luke Dashjr via bitcoin-dev > wrote: >> I"ve already opened a PR almost 2 weeks ago to do this and fix the other >> issues BIP 9 has. https://github.com/bitcoin/bips/pull/550 >> >> It just needs your ACK to merge. > These proposals for gratuitous orphaning are reckless and coersive. > We have a professional obligation to first do no harm, and amplifying > orphaning which can otherwise easily be avoided violates it. > It is not anyones position to decide who does and doesn"t need to be > "woken up" with avoidable finical harm, nor is it any of our right to > do so at the risk of monetary losses by any and all users users from > the resulting network instability. > It"s one thing to argue that some disruption is strictly needed for > the sake of advancement, it"s another to see yourself fit as judge, > jury, and executioner to any that does not jump at your command. > (which is exactly the tone I and at least some others extract from > your advocacy of these changes and similar activity around BIP148). > I for one oppose those changes strongly. >> Not having a mandatory signal turned out to be a serious bug in BIP 9, > I have seen no evidence or case for this. > ___ > 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] Replay attacks make BIP148 and BIP149 untennable
I was merely describing that the only failure mode of using "post-split coinbases from the legacy chain" as seedcoins for cointainting purposes would be a resolution of the coinsplit, thereby rendering the cointainting redundant, therefore this would be an entirely safe approach to cointainting, as the only way coins could become untainted (and therefore subject to the threat of replay attacks) would coincide with a disappearance of the situation that gave rise to such replay attacks in the first place. This should sufficiently answer your concerns regarding lack of replay protection in case of medium-to-long-term chainsplits in general. If you fail to grok, please read again until you don't. Sent with [ProtonMail](https://protonmail.com) Secure Email. Original Message Subject: Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable Local Time: June 7, 2017 3:38 AM UTC Time: June 7, 2017 12:38 AM From: cont...@taoeffect.com To: Kekcoin Anthony Towns , bitcoin-dev@lists.linuxfoundation.org Please read my email more carefully; the replay threat would be moot because there would be no alternative chain to replay the TX on, In order to *get to that point*, you need >51%. Not only that, but, if you started out with <51%, then you need >>51% in order to *catch up* and replace the large number of blocks added to the legacy chain in the mean time. So, since >51% is _required_ for BIP148 to succeed (and likely >>51%)... you might as well do as SegWit did originally, or lower the threshold to 80% or something (as BIP91 does). Without replay protection at the outset, BIP148, as far as I can tell, isn't a threat to miners. -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Jun 6, 2017, at 5:29 PM, Kekcoin wrote: Please read my email more carefully; the replay threat would be moot because there would be no alternative chain to replay the TX on, as the non-148 chain would have been reorganized into oblivion. Sent with [ProtonMail](https://protonmail.com/) Secure Email. Original Message Subject: Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable Local Time: June 7, 2017 3:26 AM UTC Time: June 7, 2017 12:26 AM From: cont...@taoeffect.com To: Kekcoin Anthony Towns , bitcoin-dev@lists.linuxfoundation.org I don't know what you mean by "render the replay threat moot." If you don't have replay protection, replay is always a threat. A very serious one. -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Jun 6, 2017, at 5:19 PM, Kekcoin wrote: Hmm, that's not the difference I was talking about. I was referring to the fact that using "post-chainsplit coinbases from the non-148 chain" to unilaterally (ie. can be done without action on the 148-chain) taint coins is more secure in extreme-adverserial cases such as secret-mining reorg attacks (as unfeasibly expensive they may be); the only large-scale (>100 block) reorganization the non-148 chain faces should be a resolution of the chainsplit and therefore render the replay threat moot.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable
Please read my email more carefully; the replay threat would be moot because there would be no alternative chain to replay the TX on, as the non-148 chain would have been reorganized into oblivion. Sent with [ProtonMail](https://protonmail.com) Secure Email. Original Message Subject: Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable Local Time: June 7, 2017 3:26 AM UTC Time: June 7, 2017 12:26 AM From: cont...@taoeffect.com To: Kekcoin Anthony Towns , bitcoin-dev@lists.linuxfoundation.org I don't know what you mean by "render the replay threat moot." If you don't have replay protection, replay is always a threat. A very serious one. -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Jun 6, 2017, at 5:19 PM, Kekcoin wrote: Hmm, that's not the difference I was talking about. I was referring to the fact that using "post-chainsplit coinbases from the non-148 chain" to unilaterally (ie. can be done without action on the 148-chain) taint coins is more secure in extreme-adverserial cases such as secret-mining reorg attacks (as unfeasibly expensive they may be); the only large-scale (>100 block) reorganization the non-148 chain faces should be a resolution of the chainsplit and therefore render the replay threat moot.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable
Hmm, that's not the difference I was talking about. I was referring to the fact that using "post-chainsplit coinbases from the non-148 chain" to unilaterally (ie. can be done without action on the 148-chain) taint coins is more secure in extreme-adverserial cases such as secret-mining reorg attacks (as unfeasibly expensive they may be); the only large-scale (>100 block) reorganization the non-148 chain faces should be a resolution of the chainsplit and therefore render the replay threat moot. Sent with [ProtonMail](https://protonmail.com) Secure Email. Original Message Subject: Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable Local Time: June 7, 2017 3:04 AM UTC Time: June 7, 2017 12:04 AM From: cont...@taoeffect.com To: Kekcoin Anthony Towns , bitcoin-dev@lists.linuxfoundation.org You keep referring to 148 coinbase coins, what is the rationale behind this? Why would you prefer using 148 coinbases over legacy coinbases for this purpose? OK, maybe "post-UASF coinbase coins" is a better term? I just wanted to make it clear that this refers to coins that come from blocks generated after the UASF is activated. -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Jun 6, 2017, at 4:59 PM, Kekcoin wrote: You keep referring to 148 coinbase coins, what is the rationale behind this? Why would you prefer using 148 coinbases over legacy coinbases for this purpose? Sent with [ProtonMail](https://protonmail.com/) Secure Email.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable
You keep referring to 148 coinbase coins, what is the rationale behind this? Why would you prefer using 148 coinbases over legacy coinbases for this purpose? Sent with [ProtonMail](https://protonmail.com) Secure Email. Original Message Subject: Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable Local Time: June 7, 2017 2:27 AM UTC Time: June 6, 2017 11:27 PM From: bitcoin-dev@lists.linuxfoundation.org To: Anthony Towns bitcoin-dev@lists.linuxfoundation.org CoinJoin works as a method of both improving fungibility and mixing with coinbase transactions. My understanding is that the two situations are quite different. Unlike mixing to coin-split, CoinJoin doesn't create a high demand exclusively for coinbase transactions. However, of the proposed methods, coin-mixing seems the better option, because it might be reasonably easy (I don't know) for exchanges to obtain 148 coinbase coins, and mix their coins with them, extending the coin-splitting capability beyond just miner coins and then using that to split incoming coins. That seems like the most reasonable approach I've heard so far. Whether exchanges would be willing to do that is a separate question. When it's confirmed on one chain, but not on the other, you can then "double-spend" on the lower hashrate chain with a higher fee, to end up with different coins on both chains. This method is time consuming and not guaranteed to work. CPFP can be used by an attacker to get your original txn into the 148 chain. (also, no double-n in untenable) Why thank you aj, you're so good at spelling. :-) Cheers, Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Jun 6, 2017, at 4:20 PM, Anthony Towns via bitcoin-dev wrote: On Tue, Jun 06, 2017 at 03:39:28PM -0700, Tao Effect via bitcoin-dev wrote:- Mixing with 148 coinbase txns destroys fungibility. CoinJoin works as a method of both improving fungibility and mixing with coinbase transactions. You probably don't need to do anything clever to split a coin though: if you send a transaction with a standard fee it will get confirmed in a normal time on the higher hashrate chain, but won't confirm as quickly on the lower hashrate chain (precisely because transactions are valid on both chains, but blocks are found more slowly with the lower hashrate). When it's confirmed on one chain, but not on the other, you can then "double-spend" on the lower hashrate chain with a higher fee, to end up with different coins on both chains. (also, no double-n in untenable) Cheers, aj ___ 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] Reduced signalling threshold activation of existing segwit deployment
I think there may be merit to this idea, allowing for political compromise
without sacrificing the technological integrity of Bitcoin. There are a few
mechanical problems I see with it, though.
1. It should change its activation logic from BIP9-style to BIP8-style with a
flagday of August 1. This to maintain backwards compatibility with the current
deployment of BIP148 nodes. This proposal seems to be a measure to prevent a
chainsplit, so it must make sure to avoid triggering one.
2. This should be for miners only; non-miners should not enforce this. It
severely weakens the block-signalling activation mechanism in several ways
(lowered threshold, short deployment timeframe, no "locked in" delay before
activation) and by doing so opens up attack vectors for consensus-partitioning
attacks using malicious false signalling. For non-miners that seek to take
their fate into their own hands, enforcing BIP148 is enough.
3. Even for miners this is more risky than usual; only 31% of hashrate is
required to false-signal the activation to fork-off honest miners. This attack
vector is magnified by the lack of "locked in" delay that would allow laggards
to upgrade before activation. I suggest adding in at least a 1-week lock-in
period (given the shorter timeframes 2 weeks may eat up too much of the
available voting time before the brick wall of BIP148 activation on August 1).
Under the assumption that this is indeed compatible with the terms of the
Silbert agreement, we can presume the involved miners are willing to trust
eachother more than usual so such a short lock-in period should be acceptable.
Original Message
Subject: [bitcoin-dev] Reduced signalling threshold activation of existing
segwit deployment
Local Time: May 23, 2017 1:40 AM
UTC Time: May 22, 2017 10:40 PM
From: bitcoin-dev@lists.linuxfoundation.org
To: Bitcoin Dev
I would like to propose an implementation that accomplishes the first
part of the Barry Silbert proposal independently from the second:
"Activate Segregated Witness at an 80% threshold, signaling at bit 4"
in a way that
The goal here is to minimize chain split risk and network disruption
while maximizing backwards compatibility and still providing for rapid
activation of segwit at the 80% threshold using bit 4.
By activating segwit immediately and separately from any HF we can
scale quickly without risking a rushed combined segwit+HF that would
almost certainly cause widespread issues.
Draft proposal:
https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.mediawiki
Proposal text:
BIP: segsignal
Layer: Consensus (soft fork)
Title: Reduced signalling threshold activation of existing segwit deployment
Author: James Hilliard
Status: Draft
Type: Standards Track
Created: 2017-05-22
License: BSD-3-Clause
CC0-1.0
==Abstract==
This document specifies a method to activate the existing BIP9 segwit
deployment with a majority hashpower less than 95%.
==Definitions==
"existing segwit deployment" refer to the BIP9 "segwit" deployment
using bit 1, between November 15th 2016 and November 15th 2017 to
activate BIP141, BIP143 and BIP147.
==Motivation==
Segwit increases the blocksize, fixes transaction malleability, and
makes scripting easier to upgrade as well as bringing many other
[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].
This BIP provides a way for a simple majority of miners to coordinate
activation of the existing segwit deployment with less than 95%
hashpower. For a number of reasons a complete redeployment of segwit
is difficulty to do until the existing deployment expires. This is due
to 0.13.1+ having many segwit related features active already,
including all the P2P components, the new network service flag, the
witness-tx and block messages, compact blocks v2 and preferential
peering. A redeployment of segwit will need to redefine all these
things and doing so before expiry would greatly complicate testing.
==Specification==
While this BIP is active, all blocks must set the nVersion header top
3 bits to 001 together with bit field (1<<1) (according to the
existing segwit deployment). Blocks that do not signal as required
will be rejected.
==Deployment==
This BIP will be deployed by a "version bits" with an 80%(this can be
adjusted if desired) activation threshold BIP9 with the name
"segsignal" and using bit 4.
This BIP will have a start time of midnight June 1st, 2017 (epoch time
1496275200) and timeout on midnight November 15th 2017 (epoch time
1510704000). This BIP will cease to be active when segwit is
locked-in.
=== Reference implementation ===
// Check if Segregated Witness is Locked In
bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
Consensus::Params& params)
{
LOCK(cs_main);
return (VersionBitsState(pindexPrev, params,
Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
THRESHOLD_LOCKED_IN);
}
// SEGSIGNAL mandatory segwit signalling.
if ( VersionBitsState(pindex->pprev, chainpar
Re: [bitcoin-dev] Draft BIP: Version bits extension with guaranteed lock-in
> After some thought I managed to simplify the original uaversionbits proposal > introducing a simple boolean flag to guarantee lock-in of a BIP9 deployment > by the timeout. This seems to be the simplest form combining optional flag > day activation with BIP9. This brings the best of both worlds allowing user > activated soft forks that can be activated early by the hash power. After mulling over this proposal I think it is quite elegant; however there is one big "regression" in functionality in regards to BIP9 which it extends upon; a lack of back-out procedure. That is to say, if a protocol change is deployed using this BIP9-with-lock-in-on-timeout method, it is no longer possible to abstain from activating it if it is shown to contain a critical flaw. I suggest that a second version bit can be used as an abandonment vote; with sufficient hashpower (50% might be enough since it is no longer about safe coordination of protocol change deployment) the proposed protocol change is abandoned. This changes the dynamic from BIP9's "opt-in" to an "opt-out" system, still governed by hashpower, but far less susceptible to minority miner veto.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
