Kekcoin [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-04-18 to 2017-07-05
💬 Posted a total of 7 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:03:56

- reply

📅 Original date posted:2017-07-05
📝 Original message: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 at lists.linuxfoundation.org
> To: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
> On Wed, Jul 5, 2017 at 3:50 AM, Luke Dashjr via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170705/afa1c3a5/attachment.html>

2023-06-07 18:02:28

- reply

📅 Original date posted:2017-06-06
📝 Original message: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: contact at taoeffect.com
To: Kekcoin <kekcoin at protonmail.com>
Anthony Towns <aj at erisian.com.au>, bitcoin-dev at lists.linuxfoundation.org <bitcoin-dev at 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 <kekcoin at protonmail.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/c710f263/attachment-0001.html>

2023-06-07 18:02:28

- reply

📅 Original date posted:2017-06-06
📝 Original message: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: contact at taoeffect.com
To: Kekcoin <kekcoin at protonmail.com>
Anthony Towns <aj at erisian.com.au>, bitcoin-dev at lists.linuxfoundation.org <bitcoin-dev at 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 <kekcoin at protonmail.com> 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: contact at taoeffect.com
To: Kekcoin <kekcoin at protonmail.com>
Anthony Towns <aj at erisian.com.au>, bitcoin-dev at lists.linuxfoundation.org <bitcoin-dev at 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 <kekcoin at protonmail.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/c5ac4a0c/attachment-0001.html>

2023-06-07 18:02:27

- reply

📅 Original date posted:2017-06-06
📝 Original message: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: contact at taoeffect.com
To: Kekcoin <kekcoin at protonmail.com>
Anthony Towns <aj at erisian.com.au>, bitcoin-dev at lists.linuxfoundation.org <bitcoin-dev at 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 <kekcoin at protonmail.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/2a247527/attachment.html>

2023-06-07 18:02:26

- reply

📅 Original date posted:2017-06-06
📝 Original message: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 at lists.linuxfoundation.org
To: Anthony Towns <aj at erisian.com.au>
bitcoin-dev at 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 <bitcoin-dev at lists.linuxfoundation.org> 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 at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/6b251954/attachment-0001.html>

2023-06-07 18:01:39

- reply

📅 Original date posted:2017-05-23
📝 Original message: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 at lists.linuxfoundation.org
To: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
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:
<pre>
BIP: segsignal
Layer: Consensus (soft fork)
Title: Reduced signalling threshold activation of existing segwit deployment
Author: James Hilliard <james.hilliard1 at gmail.com>
Status: Draft
Type: Standards Track
Created: 2017-05-22
License: BSD-3-Clause
CC0-1.0
</pre>
==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 ===
<pre>
// 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, chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) == THRESHOLD_ACTIVE
&&
!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
// Segwit is not locked in
!IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
and is not active.
{
bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
VERSIONBITS_TOP_BITS;
bool fSegbit = (pindex->nVersion &
VersionBitsMask(chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SEGWIT)) != 0;
if (!(fVersionBits && fSegbit)) {
return state.DoS(0, error("ConnectBlock(): relayed block must
signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
}
}
</pre>
https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard:segsignal-v0.14.1
==Backwards Compatibility==
This deployment is compatible with the existing "segwit" bit 1
deployment scheduled between midnight November 15th, 2016 and midnight
November 15th, 2017. Miners will need to upgrade their nodes to
support segsignal otherwise they may build on top of an invalid block.
While this bip is active users should either upgrade to segsignal or
wait for additional confirmations when accepting payments.
==Rationale==
Historically we have used IsSuperMajority() to activate soft forks
such as BIP66 which has a mandatory signalling requirement for miners
once activated, this ensures that miners are aware of new rules being
enforced. This technique can be leveraged to lower the signalling
threshold of a soft fork while it is in the process of being deployed
in a backwards compatible way.
By orphaning non-signalling blocks during the BIP9 bit 1 "segwit"
deployment, this BIP can cause the existing "segwit" deployment to
activate without needing to release a new deployment.
==References==
*[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013714.html
Mailing list discussion]
*[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283
P2SH flag day activation]
*[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]]
*[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]
*[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]]
*[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for
Version 0 Witness Program]]
*[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element malleability]]
*[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit deployment]]
*[[bip-0149.mediawiki|BIP149 Segregated Witness (second deployment)]]
*[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit benefits]
==Copyright==
This document is dual licensed as BSD 3-clause, and Creative Commons
CC0 1.0 Universal.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170523/803c74dc/attachment-0001.html>

2023-06-07 17:59:32

- reply

📅 Original date posted:2017-04-18
📝 Original message:> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170418/7599c704/attachment.html>