Tao Effect [ARCHIVE]

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

Public Key

npub1r0g954grld59fuphzsypmuuhpdunq67f729afmp44h2mxvth2hts4vdpg3

Profile Code

nprofile1qqsph5z625plk6z57qm3gzqa7wtsk7fsd0yl9z75as66m4dnx9m4t4cejcc5v

Author Public Key

npub1r0g954grld59fuphzsypmuuhpdunq67f729afmp44h2mxvth2hts4vdpg3

Show more details

Last Notes

2023-06-07 22:55:57

- reply

📅 Original date posted:2021-07-17
📝 Original message:Hi Raymo,
I personally am excited about what you’re working on, and wish you the best of luck with it!
Cheers,
Greg
> On Jul 17, 2021, at 8:50 AM, raymo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> After introducing Sabu protocol as a solution for Bitcoin scaling
> (https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180),
> I shared this idea with Bitcoin developers through the bitcoin-dev
> mailing list.
> I got some constructive feedbacks and critiques leading me to add this
> part to the proposal which I was skipped due to brevity of proposal
> introduction.
> [..]

2023-06-07 22:55:04

- reply

📅 Original date posted:2021-06-28
📝 Original message:Hi ZmnSCPxj & Raymo,
> On Jun 28, 2021, at 8:28 AM, ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Good morning Raymo,
>
>> Hi ZmnSCPxj,
>> […]
> What prevents the creditor from signing a transaction that is neither a valid MT nor a GT?
>
> Nothing.
How would the creditor create such a transaction? They need the issuer’s private key, so they can’t create it? Am I misunderstanding the scenario you’re describing? If so could you give a more detailed description?
Cheers,
Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210628/11ed8db2/attachment.html>

2023-06-07 18:10:57

- reply

📅 Original date posted:2018-02-19
📝 Original message:Real quick (I've received some off-list replies and do plan to respond to those), want to be clear: this thread is not meant to be interpreted as a proposal to modify Bitcoin (it is not a BIP), it is just, exactly as the subject says, some thoughts I had that I hadn't seen expressed elsewhere, that I felt like sharing, in case they are at all useful/interesting to anyone.
Cheers,
Greg
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Feb 19, 2018, at 12:10 AM, Ryan J Martin <rjmarti2 at millersville.edu <mailto:rjmarti2 at millersville.edu>> wrote:
>
> To be frank, this kind of thing would be better off attempted as a fork to a new coin. Changing the max number of coins, the block reward, the difficulty algo, mining policy and protocol is going to be a non-starter. Also, what are the proposed quantifiavle benefits from removing timestamps? How would this be done at the protocol level? Are these other changes related to removing timestamps/rationale for other supply changes?
>
> Regards,
> Ryan J. Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180219/e9eb9acd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180219/e9eb9acd/attachment.sig>

2023-06-07 18:10:56

- reply

📅 Original date posted:2018-02-21
📝 Original message:> What you are suggesting, unless I am mistaken, is that new full nodes should have no way of knowing if an output is spent or even if it exists. Since large sections of the blockchain will potentially be skipped, the full node will not have complete knowledge of utxo's just for starters.
So, this might not have been clear, but by "if we are given the liberty of modifying the protocol as we wish" I meant that I was discussing a protocol where these sorts of concerns are not an issue because we are not limited by the constraints of Bitcoin's current design.
There have been plenty of proposals across the web for how to design a blockchain where what you're referring to is not an issue because of merkle commitments, etc., and some blockchains already do this (e.g. I believe Ethereum does this via parity).
Cheers,
Greg
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Feb 19, 2018, at 4:04 AM, Damian Williamson <willtech at live.com.au> wrote:
>
> >1. Introducing state checkpoints into the chain itself could make it possible for full nodes to skip verification of large sections of historical data when booting up.
>
> What you are suggesting, unless I am mistaken, is that new full nodes should have no way of knowing if an output is spent or even if it exists. Since large sections of the blockchain will potentially be skipped, the full node will not have complete knowledge of utxo's just for starters.
>
> Regards,
> Damian Williamson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180221/1f9f0f49/attachment.sig>

2023-06-07 18:10:55

- reply

📅 Original date posted:2018-02-18
📝 Original message:Copied from: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/pull/13 <https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/pull/13>
# Blockchain Timestamps Unnecessary In Proof-of-Work?
*Author: Greg Slepak ([@taoeffect at mastodon.social <mailto:taoeffect at mastodon.social>](https://mastodon.social/@taoeffect <https://mastodon.social/@taoeffect>))*
----
The Bitcoin blockchain has a 10-minute target blocktime that is achieved by a difficulty adjustment algorithm.
I assert, or rather, pose the hypothesis, that the use of timestamps in Bitcoin's blockchain may be unnecessary, and that Bitcoin can operate with the same security guarantees without it (except as noted in [Risks and Mitigations](#risks-and-mitigations)), and therefore does not need miners to maintain global clock synchronization.
The alternative difficulty adjustment algorithm would work according to the following principles:
- The incentive for miners is and always has been to maximize profit.
- The block reward algorithm is now modified to issue coins into perpetuity (no maximum). Any given block can issue _up to_ `X` number of coins per block.
- The number of coins issued per block is now tied directly to the difficulty of the block, and the concept of "epocs" or "block reward halving" is removed.
- The chain selection rule remains "chain with most proof of work"
- The difficulty can be modified by miners in an arbitrary direction (up or down), but is limited in magnitude by some maximum percentage (e.g. no more than 20% deviation from the previous block), we call this `Y%`.
### Observations
- Miners are free to mine blocks of whatever difficulty they choose, up to a maximum deviation
- The blockchain may at times produce blocks very quickly, and at other times produce blocks more slowly
- Powerful miners are incentivized to raise the difficulty to remove competitors (as is true today)
- Whether miners choose to produce blocks quickly or slowly is entirely up to them. If they produce blocks quickly, each block has a lower reward, but there are more of them. If they produce blocks slowly, each block has a higher reward, but there are fewer of them. So an equilibrium will be naturally reached to produce blocks at a rate that should minimize orphans.
A timestamp may still be included in blocks, but it no longer needs to be used for anything, or represent anything significant other than metadata about when the miner claims to have produced the block.
### Risks and Mitigations
Such a system may introduce risks that require further modification of the protocol to mitigate.
The most straightforward risk comes from the potential increase in total transaction throughput that such a change would introduce (these are the same concerns that exist with respect to raising the blocksize). The removal of timestamps would allow a cartel of miners to produce high-difficulty blocks at a fast rate, potentially resulting in additional centralization pressures not only on miners but also on full nodes who then would have greater difficulty keeping up with the additional bandwidth and storage demands.
Two equally straightforward mitigations exist to address this if we are given the liberty of modifying the protocol as we wish:
1. Introducing state checkpoints into the chain itself could make it possible for full nodes to skip verification of large sections of historical data when booting up.
2. A sharded protocol, where each shard uses a "sufficiently different" PoW algorithm, would create an exit for users should the primary blockchain become captured by a cartel providing poor quality-of-service.
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180218/89e66ce8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180218/89e66ce8/attachment-0001.sig>

2023-06-07 18:09:49

- reply

📅 Original date posted:2018-01-16
📝 Original message:The DCS Triangle was independently discovered by myself and Trent McConaghy.
It is a useful tool for clearing confusion about blockchain scalability and blocksize-related debates.
The DCS Theorem is a probability proof of the triangle, and it's now on arXiv:
https://arxiv.org/abs/1801.04335 <https://arxiv.org/abs/1801.04335>
Cheers,
Greg
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180116/e3a21433/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180116/e3a21433/attachment.sig>

2023-06-07 18:08:01

- reply

📅 Original date posted:2017-11-30
📝 Original message:Check out Blockstack, they're doing something like that.
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Nov 30, 2017, at 2:20 PM, mandar mulherkar via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Hello,
>
> I am new, so apologies if this has been asked before.
>
> Here are a few questions to start with -
>
> I was wondering in terms of mass adoption, instead of long wallet addresses, maybe there should be a DNS-like decentralized mapping service to provide a user at crypto address?
>
> This address translation can happen with confirmations from the network. So instead of providing a long string, or a QR code that needs an app, you simply type in a human readable address, and the wallet software converts it to a wallet address.
>
> Please let me know where I can research this more - if there already is literature about this somewhere.
>
> thanks!
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto: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/20171130/a79f414b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171130/a79f414b/attachment-0001.sig>

2023-06-07 18:07:23

- reply

📅 Original date posted:2017-11-02
📝 Original message:Just going to throw in my support for a POW change, not any particular implementation, but the idea.
Bitcoin is technically owned by China now. That's not acceptable.
- Greg
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Oct 31, 2017, at 10:48 PM, Devrandom via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Hi all,
>
> Feedback is welcome on the draft below. In particular, I want to see if there is interest in further development of the idea and also interested in any attack vectors or undesirable dynamics.
>
> (Formatted version available here: https://github.com/devrandom/btc-papers/blob/master/aux-pow.md <https://github.com/devrandom/btc-papers/blob/master/aux-pow.md> )
>
> # Soft-fork Introduction of a New POW
>
> ## Motivation:
>
> - Mitigate mining centralization pressures by introducing a POW that does not have economies of scale
> - Introduce an intermediary confirmation point, reducing the impact of mining power fluctuations
>
> Note however that choice of a suitable POW will require deep analysis. Some pitfalls include: botnet mining, POWs that seem ASIC resistant but are not, unexpected/covert optimization.
>
> In particular, unexpected/covert optimizations, such as ASCIBOOST, present a potential centralizing and destabilizing force.
>
> ## Design
>
> ### Aux POW intermediate block
>
> Auxiliary POW blocks are introduced between normal blocks - i.e. the chain alternates between the two POWs.
> Each aux-POW block points to the previous normal block and contains transactions just like a normal block.
> Each normal block points to the previous aux-POW block and must contain all transactions from the aux-POW block.
> Block space is not increased.
>
> The new intermediate block and the pointers are introduced via a soft-fork restriction.
>
> ### Reward for aux POW miners
>
> The reward for the aux POW smoothly increases from zero to a target value (e.g. 1/2 of the total reward) over time.
> The reward is transferred via a soft-fork restriction requiring a coinbase output to an address published in the
> aux-POW block.
>
> ### Aux POW difficulty adjustment
>
> Difficulty adjustments remain independent for the two POWs.
>
> The difficulty of the aux POW is adjusted based on the average time between normal block found
> to aux block found.
>
> Further details are dependent on the specific POW.
>
> ### Heaviest chain rule change
>
> This is a semi-hard change, because non-upgraded nodes can get on the wrong chain in case of attack. However,
> it might be possible to construct an alert system that notifies non-upgraded nodes of an upcoming rule change.
> All blocks are still valid, so this is not a hardforking change.
>
> The heaviest chain definition changes from sum of `difficulty` to sum of:
>
> mainDifficulty ^ x * auxDifficulty ^ y
>
> where we start at:
>
> x = 1; y = 0
>
> and end at values of x and y that are related to the target relative rewards. For example, if the target rewards
> are equally distributed, we will want ot end up at:
>
> x = 1/2; y = 1/2
>
> so that both POWs have equal weight. If the aux POW is to become dominant, x should end small relative to y.
>
>
> ## Questions and Answers
>
> - What should be the parameters if we want the aux POW to have equal weight? A: 1/2 of the reward should be transferred
> to aux miners and x = 1/2, y = 1/2.
>
> - What should be the parameters if we want to deprecate the main POW? A: most of the reward should be transferred to
> aux miners and x = 0, y = 1. The main difficulty will tend to zero, and aux miners will just trivially generate the
> main block immediately after finding an aux block, with identical content.
>
> - Wasted bandwidth to transfer transactions twice? A: this can be optimized by skipping transactions already
> transferred.
>
> - Why would miners agree to soft-fork away some of their reward? A: they would agree if they believe that
> the coins will increase in value due to improved security properties.
>
> ## Open Questions
>
> - After a block of one type is found, we can naively assume that POW will become idle while a block of the other type is being mined. In practice, the spare capacity can be used to find alternative ("attacking") blocks or mine other coins. Is that a problem?
> - Is selfish mining amplified by this scheme for miners that have both types of hardware?
>
> ## POW candidates
>
> - SHA256 (i.e. use same POW, but introduce an intermediate block for faster confirmation)
> - Proof of Space and Time (Bram Cohen)
> - Equihash
> - Ethash
>
> ## Next Steps
>
> - evaluate POW candidates
> - evaluate difficulty adjustment rules
> - simulate miner behavior to identify if there are incentives for detrimental behavior patterns (e.g. block withholding / selfish mining)
> - Protocol details
>
> ## Credits
>
> Bram Cohen came up with a similar idea back in March:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013744.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013744.html>_______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto: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/20171102/7d5311c6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171102/7d5311c6/attachment-0001.sig>

2023-06-07 18:07:03

- reply

📅 Original date posted:2017-10-10
📝 Original message:What?
That is not correct.
There is a fixed amount of Bitcoin, as I said.
The only difference is what chain it is on.
It is precisely because there is a fixed amount that when you burn-to-withdraw you mint on another chain.
I will not respond to any more emails unless they’re from core developers. Gotta run.
--
Sent from my mobile device.
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Oct 10, 2017, at 1:23 PM, James Hudon <jameshudon at gmail.com> wrote:
>
> You're asking for newly minted bitcoin to go to you but you burned the bitcoin used in the peg. You're effectively losing your money and then stealing from the miners to gain it back. The miners had to issue your amount of bitcoin 2 times (once for your original bitcoin, again to make you whole). Why would they agree to this?
> --
> hudon
>
>> On Oct 10, 2017, at 13:13, Tao Effect via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> It would not change the number of Bitcoins in existence.
>>
>> --
>> Sent from my mobile device.
>> Please do not email me anything that you are not comfortable also sharing with the NSA.
>>
>>> On Oct 10, 2017, at 12:50 PM, CryptAxe <cryptaxe at gmail.com> wrote:
>>>
>>> Your method would change the number of Bitcoins in existence. Why?
>>>
>>> On Oct 10, 2017 12:47 PM, "Tao Effect via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> Is that what passes for a technical argument these days? Sheesh.
>>>
>>> Whereas in Drivechain users are forced to give up their coins to a single group for whatever sidechains they interact with, the generic sharding algo lets them (1) keep their coins, (2) trust whatever group they want to trust (the miners of the various sidechains).
>>>
>>> Drivechain offers objectively worse security.
>>>
>>> --
>>> Sent from my mobile device.
>>> Please do not email me anything that you are not comfortable also sharing with the NSA.
>>>
>>>> On Oct 10, 2017, at 8:09 AM, Paul Sztorc via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>> I think this response speaks for itself.
>>>>
>>>>> On 10/10/2017 10:09 AM, Tao Effect wrote:
>>>>> Hi Paul,
>>>>>
>>>>> I thought it was clear, but apparently you are getting stuck on the semantics of the word "burn".
>>>>>
>>>>> The "burning" applies to the original coins you had.
>>>>>
>>>>> When you transfer them back, you get newly minted coins, equivalent to the amount you "burned" on the chain you're transferring from ― as stated in the OP.
>>>>>
>>>>> If you don't like the word "burn", pick another one.
>>>>>
>>>>> --
>>>>> Please do not email me anything that you are not comfortable also sharing with the NSA.
>>>>>
>>>>>> On Oct 10, 2017, at 4:20 AM, Paul Sztorc <truthcoin at gmail.com> wrote:
>>>>>>
>>>>>> Haha, no. Because you "burned" the coins.
>>>>>>
>>>>>> On Oct 10, 2017 1:20 AM, "Tao Effect" <contact at taoeffect.com> wrote:
>>>>>> Paul,
>>>>>>
>>>>>> It's a two-way peg.
>>>>>>
>>>>>> There's nothing preventing transfers back to the main chain.
>>>>>>
>>>>>> They work in the exact same manner.
>>>>>>
>>>>>> Cheers,
>>>>>> Greg
>>>>>>
>>>>>> --
>>>>>> Please do not email me anything that you are not comfortable also sharing with the NSA.
>>>>>>
>>>>>>> On Oct 9, 2017, at 6:39 PM, Paul Sztorc <truthcoin at gmail.com> wrote:
>>>>>>>
>>>>>>> That is only a one-way peg, not a two-way.
>>>>>>>
>>>>>>> In fact, that is exactly what drivechain does, if one chooses parameters for the drivechain that make it impossible for any side-to-main transfer to succeed.
>>>>>>>
>>>>>>> One-way pegs have strong first-mover disadvantages.
>>>>>>>
>>>>>>> Paul
>>>>>>>
>>>>>>> On Oct 9, 2017 9:24 PM, "Tao Effect via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>>>> Dear list,
>>>>>>>
>>>>>>> In previous arguments over Drivechain (and Drivechain-like proposals) I promised that better scaling proposals ― that do not sacrifice Bitcoin's security ― would come along.
>>>>>>>
>>>>>>> I planned to do a detailed writeup, but have decided to just send off this email with what I have, because I'm unlikely to have time to write up a detailed proposal.
>>>>>>>
>>>>>>> The idea is very simple (and by no means novel*), and I'm sure others have mentioned either exactly it, or similar ideas (e.g. burning coins) before.
>>>>>>>
>>>>>>> This is a generic sharding protocol for all blockchains, including Bitcoin.
>>>>>>>
>>>>>>> Users simply say: "My coins on Chain A are going to be sent to Chain B".
>>>>>>>
>>>>>>> Then they burn the coins on Chain A, and create a minting transaction on Chain B. The details of how to ensure that coins do not get lost needs to be worked out, but I'm fairly certain the folks on this list can figure out those details.
>>>>>>>
>>>>>>> - Thin clients, nodes, and miners, can all very easily verify that said action took place, and therefore accept the "newly minted" coins on B as valid.
>>>>>>> - Users client software now also knows where to look for the other coins (if for some reason it needs to).
>>>>>>>
>>>>>>> This doesn't even need much modification to the Bitcoin protocol as most of the verification is done client-side.
>>>>>>>
>>>>>>> It is fully decentralized, and there's no need to give our ownership of our coins to miners to get scale.
>>>>>>>
>>>>>>> My sincere apologies if this has been brought up before (in which case, I would be very grateful for a link to the proposal).
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Greg Slepak
>>>>>>>
>>>>>>> * This idea is similar in spirit to Interledger.
>>>>>>>
>>>>>>> --
>>>>>>> Please do not email me anything that you are not comfortable also sharing with the NSA.
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> bitcoin-dev mailing list
>>>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 18:07:02

- reply

📅 Original date posted:2017-10-10
📝 Original message:It would not change the number of Bitcoins in existence.
--
Sent from my mobile device.
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Oct 10, 2017, at 12:50 PM, CryptAxe <cryptaxe at gmail.com> wrote:
>
> Your method would change the number of Bitcoins in existence. Why?
>
>> On Oct 10, 2017 12:47 PM, "Tao Effect via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Is that what passes for a technical argument these days? Sheesh.
>>
>> Whereas in Drivechain users are forced to give up their coins to a single group for whatever sidechains they interact with, the generic sharding algo lets them (1) keep their coins, (2) trust whatever group they want to trust (the miners of the various sidechains).
>>
>> Drivechain offers objectively worse security.
>>
>> --
>> Sent from my mobile device.
>> Please do not email me anything that you are not comfortable also sharing with the NSA.
>>
>>> On Oct 10, 2017, at 8:09 AM, Paul Sztorc via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> I think this response speaks for itself.
>>>
>>>> On 10/10/2017 10:09 AM, Tao Effect wrote:
>>>> Hi Paul,
>>>>
>>>> I thought it was clear, but apparently you are getting stuck on the semantics of the word "burn".
>>>>
>>>> The "burning" applies to the original coins you had.
>>>>
>>>> When you transfer them back, you get newly minted coins, equivalent to the amount you "burned" on the chain you're transferring from ― as stated in the OP.
>>>>
>>>> If you don't like the word "burn", pick another one.
>>>>
>>>> --
>>>> Please do not email me anything that you are not comfortable also sharing with the NSA.
>>>>
>>>>> On Oct 10, 2017, at 4:20 AM, Paul Sztorc <truthcoin at gmail.com> wrote:
>>>>>
>>>>> Haha, no. Because you "burned" the coins.
>>>>>
>>>>>> On Oct 10, 2017 1:20 AM, "Tao Effect" <contact at taoeffect.com> wrote:
>>>>>> Paul,
>>>>>>
>>>>>> It's a two-way peg.
>>>>>>
>>>>>> There's nothing preventing transfers back to the main chain.
>>>>>>
>>>>>> They work in the exact same manner.
>>>>>>
>>>>>> Cheers,
>>>>>> Greg
>>>>>>
>>>>>> --
>>>>>> Please do not email me anything that you are not comfortable also sharing with the NSA.
>>>>>>
>>>>>>> On Oct 9, 2017, at 6:39 PM, Paul Sztorc <truthcoin at gmail.com> wrote:
>>>>>>>
>>>>>>> That is only a one-way peg, not a two-way.
>>>>>>>
>>>>>>> In fact, that is exactly what drivechain does, if one chooses parameters for the drivechain that make it impossible for any side-to-main transfer to succeed.
>>>>>>>
>>>>>>> One-way pegs have strong first-mover disadvantages.
>>>>>>>
>>>>>>> Paul
>>>>>>>
>>>>>>> On Oct 9, 2017 9:24 PM, "Tao Effect via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>>>> Dear list,
>>>>>>>
>>>>>>> In previous arguments over Drivechain (and Drivechain-like proposals) I promised that better scaling proposals ― that do not sacrifice Bitcoin's security ― would come along.
>>>>>>>
>>>>>>> I planned to do a detailed writeup, but have decided to just send off this email with what I have, because I'm unlikely to have time to write up a detailed proposal.
>>>>>>>
>>>>>>> The idea is very simple (and by no means novel*), and I'm sure others have mentioned either exactly it, or similar ideas (e.g. burning coins) before.
>>>>>>>
>>>>>>> This is a generic sharding protocol for all blockchains, including Bitcoin.
>>>>>>>
>>>>>>> Users simply say: "My coins on Chain A are going to be sent to Chain B".
>>>>>>>
>>>>>>> Then they burn the coins on Chain A, and create a minting transaction on Chain B. The details of how to ensure that coins do not get lost needs to be worked out, but I'm fairly certain the folks on this list can figure out those details.
>>>>>>>
>>>>>>> - Thin clients, nodes, and miners, can all very easily verify that said action took place, and therefore accept the "newly minted" coins on B as valid.
>>>>>>> - Users client software now also knows where to look for the other coins (if for some reason it needs to).
>>>>>>>
>>>>>>> This doesn't even need much modification to the Bitcoin protocol as most of the verification is done client-side.
>>>>>>>
>>>>>>> It is fully decentralized, and there's no need to give our ownership of our coins to miners to get scale.
>>>>>>>
>>>>>>> My sincere apologies if this has been brought up before (in which case, I would be very grateful for a link to the proposal).
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Greg Slepak
>>>>>>>
>>>>>>> * This idea is similar in spirit to Interledger.
>>>>>>>
>>>>>>> --
>>>>>>> Please do not email me anything that you are not comfortable also sharing with the NSA.
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> bitcoin-dev mailing list
>>>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
>> 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/20171010/f093139f/attachment-0001.html>

2023-06-07 18:07:01

- reply

📅 Original date posted:2017-10-10
📝 Original message:Is that what passes for a technical argument these days? Sheesh.
Whereas in Drivechain users are forced to give up their coins to a single group for whatever sidechains they interact with, the generic sharding algo lets them (1) keep their coins, (2) trust whatever group they want to trust (the miners of the various sidechains).
Drivechain offers objectively worse security.
--
Sent from my mobile device.
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Oct 10, 2017, at 8:09 AM, Paul Sztorc via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I think this response speaks for itself.
>
>> On 10/10/2017 10:09 AM, Tao Effect wrote:
>> Hi Paul,
>>
>> I thought it was clear, but apparently you are getting stuck on the semantics of the word "burn".
>>
>> The "burning" applies to the original coins you had.
>>
>> When you transfer them back, you get newly minted coins, equivalent to the amount you "burned" on the chain you're transferring from ― as stated in the OP.
>>
>> If you don't like the word "burn", pick another one.
>>
>> --
>> Please do not email me anything that you are not comfortable also sharing with the NSA.
>>
>>> On Oct 10, 2017, at 4:20 AM, Paul Sztorc <truthcoin at gmail.com> wrote:
>>>
>>> Haha, no. Because you "burned" the coins.
>>>
>>>> On Oct 10, 2017 1:20 AM, "Tao Effect" <contact at taoeffect.com> wrote:
>>>> Paul,
>>>>
>>>> It's a two-way peg.
>>>>
>>>> There's nothing preventing transfers back to the main chain.
>>>>
>>>> They work in the exact same manner.
>>>>
>>>> Cheers,
>>>> Greg
>>>>
>>>> --
>>>> Please do not email me anything that you are not comfortable also sharing with the NSA.
>>>>
>>>>> On Oct 9, 2017, at 6:39 PM, Paul Sztorc <truthcoin at gmail.com> wrote:
>>>>>
>>>>> That is only a one-way peg, not a two-way.
>>>>>
>>>>> In fact, that is exactly what drivechain does, if one chooses parameters for the drivechain that make it impossible for any side-to-main transfer to succeed.
>>>>>
>>>>> One-way pegs have strong first-mover disadvantages.
>>>>>
>>>>> Paul
>>>>>
>>>>> On Oct 9, 2017 9:24 PM, "Tao Effect via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>> Dear list,
>>>>>
>>>>> In previous arguments over Drivechain (and Drivechain-like proposals) I promised that better scaling proposals ― that do not sacrifice Bitcoin's security ― would come along.
>>>>>
>>>>> I planned to do a detailed writeup, but have decided to just send off this email with what I have, because I'm unlikely to have time to write up a detailed proposal.
>>>>>
>>>>> The idea is very simple (and by no means novel*), and I'm sure others have mentioned either exactly it, or similar ideas (e.g. burning coins) before.
>>>>>
>>>>> This is a generic sharding protocol for all blockchains, including Bitcoin.
>>>>>
>>>>> Users simply say: "My coins on Chain A are going to be sent to Chain B".
>>>>>
>>>>> Then they burn the coins on Chain A, and create a minting transaction on Chain B. The details of how to ensure that coins do not get lost needs to be worked out, but I'm fairly certain the folks on this list can figure out those details.
>>>>>
>>>>> - Thin clients, nodes, and miners, can all very easily verify that said action took place, and therefore accept the "newly minted" coins on B as valid.
>>>>> - Users client software now also knows where to look for the other coins (if for some reason it needs to).
>>>>>
>>>>> This doesn't even need much modification to the Bitcoin protocol as most of the verification is done client-side.
>>>>>
>>>>> It is fully decentralized, and there's no need to give our ownership of our coins to miners to get scale.
>>>>>
>>>>> My sincere apologies if this has been brought up before (in which case, I would be very grateful for a link to the proposal).
>>>>>
>>>>> Cheers,
>>>>> Greg Slepak
>>>>>
>>>>> * This idea is similar in spirit to Interledger.
>>>>>
>>>>> --
>>>>> Please do not email me anything that you are not comfortable also sharing with the NSA.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>>>
>>>>
>>
>
> _______________________________________________
> 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/20171010/a217ed4f/attachment-0001.html>

2023-06-07 18:07:00

- reply

📅 Original date posted:2017-10-10
📝 Original message:Hi Paul,
I thought it was clear, but apparently you are getting stuck on the semantics of the word "burn".
The "burning" applies to the original coins you had.
When you transfer them back, you get newly minted coins, equivalent to the amount you "burned" on the chain you're transferring from — as stated in the OP.
If you don't like the word "burn", pick another one.
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Oct 10, 2017, at 4:20 AM, Paul Sztorc <truthcoin at gmail.com <mailto:truthcoin at gmail.com>> wrote:
>
> Haha, no. Because you "burned" the coins.
>
> On Oct 10, 2017 1:20 AM, "Tao Effect" <contact at taoeffect.com <mailto:contact at taoeffect.com>> wrote:
> Paul,
>
> It's a two-way peg.
>
> There's nothing preventing transfers back to the main chain.
>
> They work in the exact same manner.
>
> Cheers,
> Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing with the NSA.
>
>> On Oct 9, 2017, at 6:39 PM, Paul Sztorc <truthcoin at gmail.com <mailto:truthcoin at gmail.com>> wrote:
>>
>> That is only a one-way peg, not a two-way.
>>
>> In fact, that is exactly what drivechain does, if one chooses parameters for the drivechain that make it impossible for any side-to-main transfer to succeed.
>>
>> One-way pegs have strong first-mover disadvantages.
>>
>> Paul
>>
>> On Oct 9, 2017 9:24 PM, "Tao Effect via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>> Dear list,
>>
>> In previous arguments over Drivechain (and Drivechain-like proposals) I promised that better scaling proposals — that do not sacrifice Bitcoin's security — would come along.
>>
>> I planned to do a detailed writeup, but have decided to just send off this email with what I have, because I'm unlikely to have time to write up a detailed proposal.
>>
>> The idea is very simple (and by no means novel*), and I'm sure others have mentioned either exactly it, or similar ideas (e.g. burning coins) before.
>>
>> This is a generic sharding protocol for all blockchains, including Bitcoin.
>>
>> Users simply say: "My coins on Chain A are going to be sent to Chain B".
>>
>> Then they burn the coins on Chain A, and create a minting transaction on Chain B. The details of how to ensure that coins do not get lost needs to be worked out, but I'm fairly certain the folks on this list can figure out those details.
>>
>> - Thin clients, nodes, and miners, can all very easily verify that said action took place, and therefore accept the "newly minted" coins on B as valid.
>> - Users client software now also knows where to look for the other coins (if for some reason it needs to).
>>
>> This doesn't even need much modification to the Bitcoin protocol as most of the verification is done client-side.
>>
>> It is fully decentralized, and there's no need to give our ownership of our coins to miners to get scale.
>>
>> My sincere apologies if this has been brought up before (in which case, I would be very grateful for a link to the proposal).
>>
>> Cheers,
>> Greg Slepak
>>
>> * This idea is similar in spirit to Interledger.
>>
>> --
>> Please do not email me anything that you are not comfortable also sharing with the NSA.
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171010/0b61b6ae/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171010/0b61b6ae/attachment-0001.sig>

2023-06-07 18:06:59

- reply

📅 Original date posted:2017-10-10
📝 Original message:Paul,
It's a two-way peg.
There's nothing preventing transfers back to the main chain.
They work in the exact same manner.
Cheers,
Greg
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Oct 9, 2017, at 6:39 PM, Paul Sztorc <truthcoin at gmail.com <mailto:truthcoin at gmail.com>> wrote:
>
> That is only a one-way peg, not a two-way.
>
> In fact, that is exactly what drivechain does, if one chooses parameters for the drivechain that make it impossible for any side-to-main transfer to succeed.
>
> One-way pegs have strong first-mover disadvantages.
>
> Paul
>
> On Oct 9, 2017 9:24 PM, "Tao Effect via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> Dear list,
>
> In previous arguments over Drivechain (and Drivechain-like proposals) I promised that better scaling proposals — that do not sacrifice Bitcoin's security — would come along.
>
> I planned to do a detailed writeup, but have decided to just send off this email with what I have, because I'm unlikely to have time to write up a detailed proposal.
>
> The idea is very simple (and by no means novel*), and I'm sure others have mentioned either exactly it, or similar ideas (e.g. burning coins) before.
>
> This is a generic sharding protocol for all blockchains, including Bitcoin.
>
> Users simply say: "My coins on Chain A are going to be sent to Chain B".
>
> Then they burn the coins on Chain A, and create a minting transaction on Chain B. The details of how to ensure that coins do not get lost needs to be worked out, but I'm fairly certain the folks on this list can figure out those details.
>
> - Thin clients, nodes, and miners, can all very easily verify that said action took place, and therefore accept the "newly minted" coins on B as valid.
> - Users client software now also knows where to look for the other coins (if for some reason it needs to).
>
> This doesn't even need much modification to the Bitcoin protocol as most of the verification is done client-side.
>
> It is fully decentralized, and there's no need to give our ownership of our coins to miners to get scale.
>
> My sincere apologies if this has been brought up before (in which case, I would be very grateful for a link to the proposal).
>
> Cheers,
> Greg Slepak
>
> * This idea is similar in spirit to Interledger.
>
> --
> Please do not email me anything that you are not comfortable also sharing with the NSA.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171009/f3c63867/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171009/f3c63867/attachment-0001.sig>

2023-06-07 18:06:58

- reply

📅 Original date posted:2017-10-09
📝 Original message:Dear list,
In previous arguments over Drivechain (and Drivechain-like proposals) I promised that better scaling proposals — that do not sacrifice Bitcoin's security — would come along.
I planned to do a detailed writeup, but have decided to just send off this email with what I have, because I'm unlikely to have time to write up a detailed proposal.
The idea is very simple, and I'm sure others have mentioned either exactly it, or similar ideas (e.g. burning coins) before.
This is a generic sharding protocol for all blockchains, including Bitcoin.
Users simply say: "My coins on Chain A are going to be sent to Chain B".
Then they burn the coins on Chain A, and create a minting transaction on Chain B. The details of how to ensure that coins do not get lost needs to be worked out, but I'm fairly certain the folks on this list can figure out those details.
- Thin clients, nodes, and miners, can all very easily verify that said action took place, and therefore accept the "newly minted" coins on B as valid.
- Users client software now also knows where to look for the other coins (if for some reason it needs to).
This doesn't even need much modification to the Bitcoin protocol as most of the verification is done client-side.
It is fully decentralized, and there's no need to give our ownership of our coins to miners to get scale.
My sincere apologies if this has been brought up before (in which case, I would be very grateful for a link to the proposal).
Cheers,
Greg Slepak
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171009/261e847b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171009/261e847b/attachment.sig>

2023-06-07 18:06:58

- reply

📅 Original date posted:2017-10-09
📝 Original message:Dear list,
In previous arguments over Drivechain (and Drivechain-like proposals) I promised that better scaling proposals — that do not sacrifice Bitcoin's security — would come along.
I planned to do a detailed writeup, but have decided to just send off this email with what I have, because I'm unlikely to have time to write up a detailed proposal.
The idea is very simple (and by no means novel*), and I'm sure others have mentioned either exactly it, or similar ideas (e.g. burning coins) before.
This is a generic sharding protocol for all blockchains, including Bitcoin.
Users simply say: "My coins on Chain A are going to be sent to Chain B".
Then they burn the coins on Chain A, and create a minting transaction on Chain B. The details of how to ensure that coins do not get lost needs to be worked out, but I'm fairly certain the folks on this list can figure out those details.
- Thin clients, nodes, and miners, can all very easily verify that said action took place, and therefore accept the "newly minted" coins on B as valid.
- Users client software now also knows where to look for the other coins (if for some reason it needs to).
This doesn't even need much modification to the Bitcoin protocol as most of the verification is done client-side.
It is fully decentralized, and there's no need to give our ownership of our coins to miners to get scale.
My sincere apologies if this has been brought up before (in which case, I would be very grateful for a link to the proposal).
Cheers,
Greg Slepak
* This idea is similar in spirit to Interledger.
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171009/2ff1f35a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171009/2ff1f35a/attachment-0001.sig>

2023-06-07 18:04:35

- reply

📅 Original date posted:2017-07-13
📝 Original message:Dear Paul,
> In point of fact, he is wrong, because nodes do the counting. When miners find a block, they can choose to move the counter up, down, or not at all. But nodes do the counting.
I may very well have confused who counts what, but for this discussion on *theft* it's irrelevant, so I won't push further on this.
Let's move on to the theft.
> Again, keep in mind that Greg continually conflates two different things:
> 1. Whether the soft fork rules have been followed, and
> 2. Whether the WT^ submitted by a majority hashrate matches the one calculated by sidechain nodes.
>
> The first case is exactly equal to P2SH. Just as old nodes accept every P2SH transaction, so too will [DC#0] users accept every WT^ transaction.
To be crystal clear: I am entirely uninterested in the un-upgraded nodes, what you call [DC#0].
They are irrelevant to my argument.
> In the second case, it so happens that [DC#1], [DC#2], and [DC#3] would also accept any WT^ *that followed the Drivechain rules*, even if they did not like the outcome (because the outcome in question was arbitrarily designated as a "theft" of funds -- again, see the second case in the list above). In this way, it is exactly similar to P2SH because nodes will accept *any* p2sh txn **that follows the p2sh rules**, even if they don't "like" the specific script contained within (for example, because it is a theft of "their" BitFinex funds, or a donation to a political candidate they dislike, etc).
This is false.
For miners to steal P2SH funds, the P2SH script would have to be coded to explicitly allow them to do it.
How many P2SH scripts are you aware of that are used for the purpose of facilitating such theft?
I know of none, and I bet there are none.
Whereas in DC, every single usage of DC allows miners to steal funds.
>> In P2SH, all upgraded nodes will reject invalid P2SH transactions, period.
>
> In DC, all upgraded nodes will reject invalid DC transactions, period.
It appears you are playing games with the meaning of "invalid" here, so that sentence is invalid.
I was very clear what I meant by "invalid" in my email: WT^ transactions that represent miners stealing funds. Please stick to that and do not play word games.
> The [DC#2] and [DC#3] nodes would do exactly what the [DC#0] and [DC#1] nodes do. This is what I mean by "every withdrawal is valid".
So, here you are again re-affirming that WT^ transactions representing stolen funds are allowed in DC, and by tying them all together you are also affirming that the SPV proofs mentioned in DC are completely irrelevant / pointless / unused.
>> Again, in P2SH miners cannot steal funds, because all full nodes have a fully automatic enforcement policy.
>
> In DC, miners cannot steal funds, because all full nodes have a fully automatic enforcement policy.
>
> However, DC *allows* users to choose to place some of their BTC at the relative mercy of the miners in creative ways, if they wish (as does P2SH -- someone could write a script which donates funds to miners, and then fund it... "paying" to that script). This is another example of conflating [DC#1] and [DC#3].
So in the first sentence you say they "cannot steal funds", but everything else you've said, including the following paragraph, and your specification, indicates they can.
I've finally collected all my thoughts / concerns and have also summarized them in this document:
https://gist.github.com/taoeffect/9ff64cf78cf1408ec29f13ed39e534c9 <https://gist.github.com/taoeffect/9ff64cf78cf1408ec29f13ed39e534c9>
Kind regards,
Greg Slepak
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jul 12, 2017, at 7:58 PM, Paul Sztorc via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> I will repeat that Drivechain can sometimes be confusing because it is different things to different people.
>
> Here is my attempt to break it down into different modes:
>
> [DC#0] -- Someone who does not upgrade their Bitcoin software (and is running, say, 0.13). However, they experience the effects of the new rules which miners add (as per the soft fork[s] to add drivechain functionality and individual drivechains).
> [DC#1] -- Someone who always upgrades to the latest version of the Bitcoin software, but otherwise has no interest in running/using sidechains.
> [DC#2] -- Someone who upgrades to the latest Bitcoin version, and decides to also become a full node of one or more sidechains, but who ever actually uses the sidechains.
> [DC#3] -- Someone who upgrades their software, runs sidechain full nodes, and actively moves money to and from these.
>
> Greg is still conflating modes [DC#1] and [DC#3]. Specifically, he equivocates on the team "steal", using it to mean two different things: [a] spending an invalid transaction, and [b] a withdrawal that would not match the report given by a sidechain node.
>
> The two are quite different, see my comments below:
>
>
> On 7/12/2017 9:15 PM, Tao Effect wrote:
>>> FYI that document is nearly two years old, and although it is still overwhelmingly accurate, new optimizations allow us (I think) to push the waiting period to several weeks and the total ACK counting period up to several months.
>>
>> What does that have to do with my question? The counting period, if I understood correctly, is something miners do, not full nodes.
>
> Greg quoted a passage that contained an older parameter estimate of "a few days", and I thought it would be helpful and informative if I clarified that the parameter estimate had been updated to a new (more secure) value.
>
> In point of fact, he is wrong, because nodes do the counting. When miners find a block, they can choose to move the counter up, down, or not at all. But nodes do the counting.
>
>
>> Also, if the document is old and/or outdated, do you happen to have a link to a more update-to-date version of the spec? It would be helpful for review.
>
> As I stated above, the document is mostly accurate. There is no other more up to date version.
>
>
>>> Because if a node doesn't have the sidechain's information, it will just assume every withdrawal is valid. This is comparable to someone who still hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
>>
>> Right, for [DC#0] and [DC#1], but for [DC#2] an [DC#3] you marked it as "Yes" without substantiating why you did so.
>
>
> Above, Greg omitted his original question. For reference, it was:
>
>> The Drivechain spec seems to claim that its use of anyone-can-pay is the same as P2SH
>
> The answer is that both DC and P2SH use transactions which are 'always valid' to some group of people (un-upgraded users) but which are sometimes invalid to new users. So the only difference would be for [DC#0] vs other versions, but this difference is trivial as miners will censor invalid txns.
>
> It is your classic soft fork situation.
>
>
>>> Again, from the perspective of a mainchain user, every withdrawal is valid.
>>
>> And that is not how P2SH works.
>
> Again, keep in mind that Greg continually conflates two different things:
> 1. Whether the soft fork rules have been followed, and
> 2. Whether the WT^ submitted by a majority hashrate matches the one calculated by sidechain nodes.
>
> The first case is exactly equal to P2SH. Just as old nodes accept every P2SH transaction, so too will [DC#0] users accept every WT^ transaction.
>
> In the second case, it so happens that [DC#1], [DC#2], and [DC#3] would also accept any WT^ *that followed the Drivechain rules*, even if they did not like the outcome (because the outcome in question was arbitrarily designated as a "theft" of funds -- again, see the second case in the list above). In this way, it is exactly similar to P2SH because nodes will accept *any* p2sh txn **that follows the p2sh rules**, even if they don't "like" the specific script contained within (for example, because it is a theft of "their" BitFinex funds, or a donation to a political candidate they dislike, etc).
>
>
>>> [DC#2] and [DC#3] would certainly have an interest in understanding what is going on, but that has absolutely nothing whatsoever to do with Bitcoin Core and so is off-topic for this mailing list.
>>
>> How is that an answer to my question?
>
> Greg is, of course, not entitled to an answer to irrelevant questions -- just as he would not be entitled to an answer if he asked for my favorite color or my home address. And such answers would needlessly consume the mailing list's scarce time.
>
>
>> What does "[DC#2] and [DC#3] would certainly have an interest in understanding what is going on" mean?
>
> It is clear to me that, if we are not clear on the basics first, we cannot hope to tackle anything intermediate. We will come back to this after clearing up soft fork part.
>
>
>> In P2SH, all upgraded nodes will reject invalid P2SH transactions, period.
>
> In DC, all upgraded nodes will reject invalid DC transactions, period.
>
>
>> What exactly would [DC#2] and [DC#3] nodes do when faced with an invalid WT^ transaction — invalid in the sense that it contains funds which miners are stealing?
>
> The [DC#2] and [DC#3] nodes would do exactly what the [DC#0] and [DC#1] nodes do. This is what I mean by "every withdrawal is valid".
>
>
>> Again, in P2SH miners cannot steal funds, because all full nodes have a fully automatic enforcement policy.
>
> In DC, miners cannot steal funds, because all full nodes have a fully automatic enforcement policy.
>
> However, DC *allows* users to choose to place some of their BTC at the relative mercy of the miners in creative ways, if they wish (as does P2SH -- someone could write a script which donates funds to miners, and then fund it... "paying" to that script). This is another example of conflating [DC#1] and [DC#3].
>
> Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/abb2b4f4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/abb2b4f4/attachment-0001.sig>

2023-06-07 18:04:33

- reply

📅 Original date posted:2017-07-12
📝 Original message:Paul,
I'm assuming it's OK with you that I pick up from where we left off in the "Scaling Roadmap" thread [1], so as to be on-topic per your request. (For others reading, part of my reply to the previous email in this thread is here [2]).
For reference, I said:
> Isn't it different in the case of P2SH and SegWit, don't full nodes validate the script?
>
> In other words, miners don't have complete control over the coins, full nodes keep a check on them.
>
> At least that was my understanding, and if that's not the case then it doesn't make sense to me why Pieter would earlier in this thread object to Drivechain on the grounds that it's a different security model.
CryptAxe's response was in part:
> You guys are both right that it is a different security model, with the important distinction that it is opt-in. What I disagree with about what you said is only that we are encouraging more risky behavior by adding consensus rules via softfork. There are additional risks with drivechains, but not because of how the new consensus rules would be added (it would be the same risk as the P2SH softfork).
I am now looking closer again at step number 4 in the Drivechain specification [2]:
4. Everyone waits for a period of, say, 3 days. This gives everyone an opportunity to make sure the same WT^ is in both the Bitcoin coinbase and the Sidechain header. If they’re different, everyone has plenty of time to contact each other, figure out what is going on, and restart the process until its right.
It seems to me that where our disagreement lies is in this point.
The Drivechain spec seems to claim that its use of anyone-can-pay is the same as P2SH (and in later emails you reference SegWit as well). Is this really true?
The following suggests to me it isn't:
1. Pieter Wuille's email suggests he disagrees [4]
2. Per the question in [1], it's my understanding that P2SH transactions contain all of the information within themselves for full nodes to act as a check on miners mishandling the anyone-can-spend nature of P2SH transactions. However, that does not seem to be the case with WT^ transactions.
In P2SH txns, there is no need for anyone to, as the Drivechain spec says, "to contact each other, figure out what is going on". Everything just automatically works.
If the security of WT^ transactions could be brought up to actually be in line with the security of P2SH and SegWit transactions, then I would have far less to object to.
Kind regards,
Greg Slepak
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014763.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014763.html>
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014745.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014745.html>
[3] http://www.truthcoin.info/blog/drivechain/ <http://www.truthcoin.info/blog/drivechain/>
[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014721.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014721.html>
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jun 19, 2017, at 9:04 AM, Paul Sztorc <truthcoin at gmail.com <mailto:truthcoin at gmail.com>> wrote:
>
> Hi Greg,
>
> Responses below:
>
> On 6/18/2017 5:30 PM, Tao Effect wrote:
>> In Drivechain, 51% of miners have total control and ownership over all
>> of the sidechain coins.
>
> It would not be accurate to say that miners have "total" control. Miners
> do control the destination of withdrawals, but they do not control the
> withdrawal-duration nor the withdrawal-frequency.
>
[ ...snip.. ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/d949a60c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/d949a60c/attachment.sig>

2023-06-07 18:04:33

- reply

📅 Original date posted:2017-07-12
📝 Original message:Paul,
> The confusion below stems from his conflation of several different ideas.
I'm right here, are you having a conversation with me or are you on a stage talking to an audience?
> FYI that document is nearly two years old, and although it is still overwhelmingly accurate, new optimizations allow us (I think) to push the waiting period to several weeks and the total ACK counting period up to several months.
What does that have to do with my question? The counting period, if I understood correctly, is something miners do, not full nodes.
Also, if the document is old and/or outdated, do you happen to have a link to a more update-to-date version of the spec? It would be helpful for review.
> Because if a node doesn't have the sidechain's information, it will just assume every withdrawal is valid. This is comparable to someone who still hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
Right, for [DC#0] and [DC#1], but for [DC#2] an [DC#3] you marked it as "Yes" without substantiating why you did so.
> Again, from the perspective of a mainchain user, every withdrawal is valid.
And that is not how P2SH works.
> [DC#2] and [DC#3] would certainly have an interest in understanding what is going on, but that has absolutely nothing whatsoever to do with Bitcoin Core and so is off-topic for this mailing list.
How is that an answer to my question?
What does "[DC#2] and [DC#3] would certainly have an interest in understanding what is going on" mean?
In P2SH, all upgraded nodes will reject invalid P2SH transactions, period.
What exactly would [DC#2] and [DC#3] nodes do when faced with an invalid WT^ transaction — invalid in the sense that it contains funds which miners are stealing?
Again, in P2SH miners cannot steal funds, because all full nodes have a fully automatic enforcement policy.
Kind regards,
Greg Slepak
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jul 12, 2017, at 5:26 PM, Paul Sztorc <truthcoin at gmail.com <mailto:truthcoin at gmail.com>> wrote:
>
> The confusion below stems from his conflation of several different ideas.
>
> I will try to explicitly clarify a distinction between several types of user (or, "modes" of use if you prefer):
>
> [DC#0] -- Someone who does not upgrade their Bitcoin software (and is running, say, 0.13). However, they experience the effects of the new rules which miners add (as per the soft fork[s] to add drivechain functionality and individual drivechains).
> [DC#1] -- Someone who always upgrades to the latest version of the Bitcoin software, but otherwise has no interest in running/using sidechains.
> [DC#2] -- Someone who upgrades to the latest Bitcoin version, and decides to also become a full node of one or more sidechains, but who ever actually uses the sidechains.
> [DC#3] -- Someone who upgrades their software, runs sidechain full nodes, and actively moves money to and from these.
>
>
> On 7/12/2017 6:43 PM, Tao Effect wrote:
>>
>> I am now looking closer again at step number 4 in the Drivechain specification [2]:
>>
>> 4. Everyone waits for a period of, say, 3 days. This gives everyone an opportunity to make sure the same WT^ is in both the Bitcoin coinbase and the Sidechain header. If they’re different, everyone has plenty of time to contact each other, figure out what is going on, and restart the process until its right.
>> It seems to me that where our disagreement lies is in this point.
>> The Drivechain spec seems to claim that its use of anyone-can-pay is the same as P2SH (and in later emails you reference SegWit as well). Is this really true?
> FYI that document is nearly two years old, and although it is still overwhelmingly accurate, new optimizations allow us (I think) to push the waiting period to several weeks and the total ACK counting period up to several months.
>
> [DC#0] Yes
> [DC#1] Yes
> [DC#2] Yes
> [DC#3] Yes
>
> Because if a node doesn't have the sidechain's information, it will just assume every withdrawal is valid. This is comparable to someone who still hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
>
> (And this is the main advantage of DC over extension blocks).
>
>
>> 2. Per the question in [1], it's my understanding that P2SH transactions contain all of the information within themselves for full nodes to act as a check on miners mishandling the anyone-can-spend nature of P2SH transactions. However, that does not seem to be the case with WT^ transactions.
> [DC#0] They do.
> [DC#1] They do.
> [DC#2] They do.
> [DC#3] They do.
>
> Again, from the perspective of a mainchain user, every withdrawal is valid.
>
>
>> In P2SH txns, there is no need for anyone to, as the Drivechain spec says, "to contact each other, figure out what is going on". Everything just automatically works.
> There is no *need* to this in Drivechain, either, for [DC#0] or [DC#1].
>
> [DC#2] and [DC#3] would certainly have an interest in understanding what is going on, but that has absolutely nothing whatsoever to do with Bitcoin Core and so is off-topic for this mailing list.
>
>
>> If the security of WT^ transactions could be brought up to actually be in line with the security of P2SH and SegWit transactions, then I would have far less to object to.
> Somehow I doubt it.
>
>
> Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/f6cbca08/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/f6cbca08/attachment.sig>

2023-06-07 18:04:20

- reply

📅 Original date posted:2017-07-12
📝 Original message:That's a fair point, I confused anyone-can-spend with anyone-can-pay [1].
Isn't it different in the case of P2SH and SegWit, don't full nodes validate the script?
In other words, miners don't have complete control over the coins, full nodes keep a check on them.
At least that was my understanding, and if that's not the case then it doesn't make sense to me why Pieter would earlier in this thread object to Drivechain on the grounds that it's a different security model.
- Greg
[1] https://steemit.com/bitcoin/@jl777/bitcoin-spinoff-fork-how-to-make-a-clean-fork-without-any-replay-attack-and-no-blockchain-visible-changes <https://steemit.com/bitcoin/@jl777/bitcoin-spinoff-fork-how-to-make-a-clean-fork-without-any-replay-attack-and-no-blockchain-visible-changes>
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jul 12, 2017, at 12:54 PM, CryptAxe via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Are we just pulling numbers out of thin air now? https://p2sh.info/ <https://p2sh.info/> BIP16 for example is widely used. It would be difficult to find a single wallet that doesn't support BIP16 I have no idea what you are talking about.
>
> On 07/12/2017 12:42 PM, Tao Effect via bitcoin-dev wrote:
>> ...
>> In the present situation, anyone-can-spend outputs are used by probably less than 0.1% of users, and most software doesn't even allow for the possibility.
>>
>> In Drivechain it's *encouraged-by-design*!
>>
>> - Greg
>>
>> --
>> Please do not email me anything that you are not comfortable also sharing with the NSA.
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto: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/20170712/a5ecbb2f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/a5ecbb2f/attachment-0001.sig>

2023-06-07 18:04:19

- reply

📅 Original date posted:2017-07-12
📝 Original message:> I think Paul has been pretty upfront about the risks of his model.
I think he has been rather misleading in his presentation of the risks.
He outlines them in a very technical manner, yes, but then goes on to promote them to lay people as if they're no big deal, which is completely misleading.
> By your account bitcoin is already insecure then -- it allows anyone can spend outputs that can be claimed by miners.
That is completely different.
It is disingenuous to say the two are remotely similar. The two situations have little-to-nothing in common.
In the present situation, anyone-can-spend outputs are used by probably less than 0.1% of users, and most software doesn't even allow for the possibility.
In Drivechain it's *encouraged-by-design*!
- Greg
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jul 12, 2017, at 12:34 PM, Chris Stewart <chris at suredbits.com <mailto:chris at suredbits.com>> wrote:
>
> Hi Greg,
>
> The safest way to ensure everyone's protection to make sure *no one can do anything*. Then we will ALL be safe ;).
>
> >If so, please leave, you are compromising Bitcoin's security.
>
> Ok, let's calm down.
>
> >If I design a car that has a button that randomly causes the brakes to give out if pressed, is that a good idea? Can I justify pushing for such a "feature" just because it's "opt-in"?
>
> It would be more like "should we allow a car on the road if we know statistically that our brakes give out in every 1/100,000,000 cars"? There is security risks with everything in life -- we need to quantify the risk to see if it is worth taking. I think Paul has been pretty upfront about the risks of his model. I think you did a good job of demonstrating it in the email I cited too.
>
> >It is how *insecure* systems are designed.
>
> By your account bitcoin is already insecure then -- it allows anyone can spend outputs that can be claimed by miners.
>
> >Sure, happy to, as soon as I have it written up in detail.
>
> I look forward to this!
>
> -Chris
>
> On Wed, Jul 12, 2017 at 2:24 PM, Tao Effect <contact at taoeffect.com <mailto:contact at taoeffect.com>> wrote:
> Dear Chris,
>
>> I think this is an unfair characterization. You have to opt into using drivechains.
>
> I have heard this nonsense repeated countless times in order to justify adopting Drivechain.
>
> This is not how security works.
>
> A child can "opt-in" to using a loaded gun, but is it a good idea to make it easy for them to do that?
>
> No.
>
> This is effectively the same thing Drivechains is doing.
>
> It is a request to modify the Bitcoin protocol to make it easy for Bitcoin users to give their Bitcoins to miners.
>
> Does that sound like a good idea to anyone?
>
> If so, please leave, you are compromising Bitcoin's security.
>
> Security is about making it difficult to shoot yourself in the face.
>
> If I design a car that has a button that randomly causes the brakes to give out if pressed, is that a good idea? Can I justify pushing for such a "feature" just because it's "opt-in"?
>
> No. That is fallacy.
>
> It is not how secure systems are designed.
>
> It is how *insecure* systems are designed.
>
>> Care to share? I'm unaware if there is.
>
>
> Sure, happy to, as soon as I have it written up in detail.
>
> Kind regards,
> Greg Slepak
>
> --
> Please do not email me anything that you are not comfortable also sharing with the NSA.
>
>> On Jul 12, 2017, at 12:19 PM, Chris Stewart <chris at suredbits.com <mailto:chris at suredbits.com>> wrote:
>>
>> Hi Greg,
>>
>> >Here, you admit that the security of the sidechains allows miners to steal bitcoins, something they cannot do currently.
>>
>> If I put my coins in an anyone can spend output, a miner will take them. They can do this today. I suggest you try it if you don't believe me :-). You have to be more specific with contract types instead of generically talking about 'all contracts ever'.
>>
>> > Drivechain is an unmistakeable weakening of Bitcoin's security guarantees. This you have not denied.
>>
>> I think this is an unfair characterization. You have to opt into using drivechains. Other outputs such as P2PKH/Multisig etc are unaffected by a drivechain output. As Pieter Wuille stated earlier in this thread (and Paul has stated all along), drivechain outputs have a different security model than other contracts. Namely they are controlled by miners. I think we can all agree this is unfortunate, but it is the current reality we live in. I look forward to the day we can solve the 'ownership' problem so we can have trustless interoperable blockchains, but that day is not today.
>>
>> As a reminder, most users will not have to go through the drivechain withdrawal process. Most withdrawals will be done via atomic swaps.
>>
>> >There is no reason to weaken Bitcoin's security in such a dramatic fashion. Better options are being worked on, they just take time.
>>
>> Care to share? I'm unaware if there is.
>>
>> >https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.html>
>>
>> Everyone should re-read this email though, this is something that could happen. Paul's design makes it so that if this occurs it is *VERY* obvious. I guess we can argue if there is any difference between an obvious robbery vs a hidden robbery, but I think if we have to pick one or the other the choice is clear to me. Other designs (that I'm aware of) for sidechains had attack vectors that weren't so obvious.
>>
>> -Chris
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/3f3a9f44/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/3f3a9f44/attachment.sig>

2023-06-07 18:04:18

- reply

📅 Original date posted:2017-07-12
📝 Original message:Dear Chris,
> I think this is an unfair characterization. You have to opt into using drivechains.
I have heard this nonsense repeated countless times in order to justify adopting Drivechain.
This is not how security works.
A child can "opt-in" to using a loaded gun, but is it a good idea to make it easy for them to do that?
No.
This is effectively the same thing Drivechains is doing.
It is a request to modify the Bitcoin protocol to make it easy for Bitcoin users to give their Bitcoins to miners.
Does that sound like a good idea to anyone?
If so, please leave, you are compromising Bitcoin's security.
Security is about making it difficult to shoot yourself in the face.
If I design a car that has a button that randomly causes the brakes to give out if pressed, is that a good idea? Can I justify pushing for such a "feature" just because it's "opt-in"?
No. That is fallacy.
It is not how secure systems are designed.
It is how *insecure* systems are designed.
> Care to share? I'm unaware if there is.
Sure, happy to, as soon as I have it written up in detail.
Kind regards,
Greg Slepak
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jul 12, 2017, at 12:19 PM, Chris Stewart <chris at suredbits.com <mailto:chris at suredbits.com>> wrote:
>
> Hi Greg,
>
> >Here, you admit that the security of the sidechains allows miners to steal bitcoins, something they cannot do currently.
>
> If I put my coins in an anyone can spend output, a miner will take them. They can do this today. I suggest you try it if you don't believe me :-). You have to be more specific with contract types instead of generically talking about 'all contracts ever'.
>
> > Drivechain is an unmistakeable weakening of Bitcoin's security guarantees. This you have not denied.
>
> I think this is an unfair characterization. You have to opt into using drivechains. Other outputs such as P2PKH/Multisig etc are unaffected by a drivechain output. As Pieter Wuille stated earlier in this thread (and Paul has stated all along), drivechain outputs have a different security model than other contracts. Namely they are controlled by miners. I think we can all agree this is unfortunate, but it is the current reality we live in. I look forward to the day we can solve the 'ownership' problem so we can have trustless interoperable blockchains, but that day is not today.
>
> As a reminder, most users will not have to go through the drivechain withdrawal process. Most withdrawals will be done via atomic swaps.
>
> >There is no reason to weaken Bitcoin's security in such a dramatic fashion. Better options are being worked on, they just take time.
>
> Care to share? I'm unaware if there is.
>
> >https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.html>
>
> Everyone should re-read this email though, this is something that could happen. Paul's design makes it so that if this occurs it is *VERY* obvious. I guess we can argue if there is any difference between an obvious robbery vs a hidden robbery, but I think if we have to pick one or the other the choice is clear to me. Other designs (that I'm aware of) for sidechains had attack vectors that weren't so obvious.
>
> -Chris
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/f5dded92/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170712/f5dded92/attachment.sig>

2023-06-07 18:04:17

- reply

📅 Original date posted:2017-07-11
📝 Original message:Paul,
There is a difference between replying to an email, and addressing the issues that were brought up in it.
I did read your reply, and I chose not to respond to it because it did not address anything I said.
Here's an example:
> It would not be accurate to say that miners have "total" control. Miners
> do control the destination of withdrawals, but they do not control the
> withdrawal-duration nor the withdrawal-frequency.
>
> So, if miners wish to 'steal' from a sidechain, they _can_ initiate a
> theft, but they can not change the fact that their malfeasance will be
> [a] obvious, and [b] on display for a long period of time.
Here, you admit that the security of the sidechains allows miners to steal bitcoins, something they cannot do currently.
You next tried to equate three different types of theft, what you called "Classic Theft", "Channel Theft", and "Drivechain Theft", saying:
> I do not think that any of the three stands out as being categorically
> worse than the others
To anyone who understands bitcoin, there is a very clear, unmistakeable difference between double-spending ("Classic Theft"), and *ownership* of the private key controlling the bitcoins.
Similarly, to anyone who understands bitcoin, there is also a very clear, unmistakeable difference between censorship ("Channel Theft"), and *ownership* of the private key controlling the bitcoins.
The entire email was a very long-form way of admitting to all of the issues that were raised in the previous email, while making it sound like you had addressed the issues.
I am not sure how else to respond to that email, given that none of the issues were really addressed.
Drivechain is an unmistakeable weakening of Bitcoin's security guarantees. This you have not denied.
There is no reason to weaken Bitcoin's security in such a dramatic fashion. Better options are being worked on, they just take time.
Kind regards,
Greg Slepak
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jul 11, 2017, at 3:57 PM, Paul Sztorc <truthcoin at gmail.com <mailto:truthcoin at gmail.com>> wrote:
>
> On 7/11/2017 6:41 PM, Tao Effect wrote:
>> Dear Paul,
>>
>> Drivechain has several issues that you've acknowledged but have not,
>> IMO, adequately (at all really) addressed [1].
>
> I replied to your email at length, at [2]. You should read that email,
> and then reply to it with your outstanding objections, if you still have
> them (per the usual customs of a mailing list).
>
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014609.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014609.html>
>
>> Adopting DC would be an irreversible course of action,
>
> This is false -- it is easily reversible with a second soft fork.
>
> Also, I would say to everyone that, (in my opinion as the OP) this
> conversation will go off-topic if it veers exclusively into 'drivechain
> review'.
>
> Paul
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170711/3aef0c56/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170711/3aef0c56/attachment-0001.sig>

2023-06-07 18:04:16

- reply

📅 Original date posted:2017-07-11
📝 Original message:Dear Paul,
Drivechain has several issues that you've acknowledged but have not, IMO, adequately (at all really) addressed [1].
I think there are far safer solutions for scaling Bitcoin and integrating it with other chains than DC, which is again, a serious security risk to the whole network, as per [1].
Adopting DC would be an irreversible course of action, and one that in my opinion would unnecessarily damage not only other sidechains, but the main chain as well.
There is no rush, a proper solution is likely to present itself (I even have one that I'm toying with, but it's not quite ready yet for publication). I'm sure others are thinking similar thoughts too.
Kind regards,
Greg Slepak
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.html>
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jul 11, 2017, at 3:17 PM, Paul Sztorc via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Hi Greg,
>
>
> On 7/11/2017 5:11 PM, Gregory Maxwell wrote:
>> I think it's great that people want to experiment with things like
>> drivechains/sidechains and what not, but their security model is very
>> distinct from Bitcoin's and, given the current highly centralized
>> mining ecosystem, arguably not very good. So positioning them as a
>> major solution for the Bitcoin project is the wrong way to go. Instead
>> we should support people trying cool stuff, at their own risk.
>>
>> So, given that although the vast majority of the things in the document
>> are things I've been supporting for months (Please see Note 1 way down
>> at the bottom) I cannot support your document.
> Is this the only reason you do not support the document? If so I would
> be happy to take out the section, if enough people share such a view.
>
> As to your specific complaints, I have addressed both the security model
> and the concept of mining centralization on this list in the recent
> past. I would like to hear your responses to my claims, if you are
> willing to share them. As for positioning DC as a major solution, it is
> a little confusing because Luke-Jr and Adam back seem to feel it is at
> least worth discussing on those terms (and I know of no reason why it
> would not be discussed on those terms). The peer review here on
> [bitcoin-dev] seemed to be moving forward without any serious
> objections. And it seems unsportsmanlike for you to object, for reasons
> which you keep only to yourself.
>
>
>> On a more meta-subject, I think grandly stated "top down" roadmaps
>> in highly collaborative development are of minimal utility at best
> I'm aiming for minimal utility.
>
>> IMO the way to do "roadmaps" in Bitcoin is to roadmap the finalization
>> and release process once the basic technology is done; because it's
>> only past that point that guarantees can really start being made.
>>
>> But that isn't what your document does-- it names a lot of things which
>> are still various shades of research at this point
> I don't understand this at all. This document attempts to do exactly
> what its predecessor did -- nothing more or less.
>
>> This was an incredible benefit to our customers, but the only way it was
>> possible was because _features_ were not guaranteed in a release.
> No one is suggesting that features be guaranteed, either ever or in
> releases.
>
>
>> One of the big screwups with segwit handling was people sticking
>> some random unrealistic date on it it which was done AFAIK,
>> by well meaning folks who took some random numbers from people
>> working on it for when they'd be done with the development-- not the
>> testing, not the integration, and certainly not deployment and published
>> it as The Date. Then even though the development was actually done
>> by them, segwit was portrayed as massively delayed, because what
>> matters to the users is deployment-- which we can't control.
> I really don't think they are related. For a start, software is almost
> always delayed. An obvious second is that this entire scaling
> conversation is polarized to the hilt and everyone that can be blamed
> for something has been blamed for something.
>
> No one likes to be held to a certain deadline, but this roadmap is just
> about producing some clarity for people who do not do this 24/7.
>
>> I see you've done this yourself with signature aggregation, sticking Q4 2016
>> right on it, which as far as I can tell is a figure that comes from mars.
> I asked Adam Back for it.
>
>> It's also not really appropriate to ask people to sign onto stuff when they
>> can't even review it. Perhaps the signature aggregation stuff is insecure,
>> patent encumbered, or practically useless... (It won't be but no one could
>> tell that from your post; because it doesn't even exist as a concrete proposal)
> Again, I think you're missing the point. If there is a problem with SA,
> you can just suggest it be removed from the document.
>
>
>> I think people would rightly protest about a number of these things-- especially
>> things like the the agg sigs and tx compaction, "wtf, I've not heard
>> of this. Who
>> are you to insist this goes into Bitcoin?"
> This is a very strange argument. I would consider it a benefit if people
> learned from the document, and discovered things that they had not heard
> of before.
>
> There is no "insisting" of any kind.
>
>
>> [ Note 1: I think it is important to disclose that several of the
>> items in this list appear to be more or less quoted out of my own
>> blockstream-internal descriptions of things we've been working on in
>> Bitcoin.
>> A while back Adam Back asked me to publish something which contained
>> significant chunks of this document more or less verbatim,
> He probably showed you an earlier draft. But I wrote almost all of this
> myself, and I can only recall 2 or 3 phrases (not even complete
> sentences) included from Adam Back. And most of the phrases are
> themselves just boring descriptions that I'm sure anyone could write.
> Some phrases may have simply been taken from bitcoincore.org <http://bitcoincore.org/> or
> somewhere similar.
>
> I am not exactly sure what you are insinuating but I encourage you to
> clarify it.
>
>> and I
>> declined saying that I personally disagree with some of his points and
>> didn't think that Blockstream attempting to redirect the Bitcoin
>> project (esp towards drivechains) was appropriate-- along with my
>> (above) views on roadmaps (which I have included here a private email
>> thread on the subject). I feel it's important to disclose this, and
>> that the document was not otherwise created with the input of project
>> contributors (except Luke-Jr, apparently). I wasn't previously aware
>> that Adam had been working with Paul on this, had I been I would have
>> also encouraged people to be a little more transparent about it. ]
> I really don't understand what you are disclosing. That Adam asked you
> for feedback on the draft? And then, in the next sentence, that not
> enough experts were asked for feedback on the draft? I'm legitimately
> confused by this part.
>
> As I stated, we can remove the drivechain section. But surely you can
> appreciate how bizarre your position on roadmaps is. What exactly, did
> you intended to create at [1]? Since it is described explicitly as "the
> roadmap in Capacity increases for the Bitcoin system", have you been
> disagreeing with it's characterization as a 'roadmap' this entire time?
> One wonders why you haven't said anything until now.
>
> [1] https://bitcoincore.org/en/2015/12/21/capacity-increase/ <https://bitcoincore.org/en/2015/12/21/capacity-increase/>
>
> In my first email I list the benefits of having a roadmap. One benefit
> is that, without one, it is likely that a large majority of outsiders
> have almost no idea at all what is being worked on, what effect it will
> have, or when it might be ready, or to whom/what they should turn to for
> advice on such matters. Do you have a different way of addressing this
> communication problem?
>
> Paul
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org <mailto: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/20170711/386bfc83/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170711/386bfc83/attachment-0001.sig>

2023-06-07 18:02:58

- reply

📅 Original date posted:2017-06-18
📝 Original message:In Drivechain, 51% of miners have total control and ownership over all of the sidechain coins. The vision of Drivechain is to have many blockchains "plugged in" to the main chain.
Today, well over 51% of miners are under the jurisdiction of a single government.
Thus the effect of Drivechain appears to be the creation of a new kind of digital border imposed onto the network where everyone hands over ownership of their Bitcoins to a /single/ mining cartel when they wish to interact with /any/ sidechain.
Drivechain would be a reasonable idea if that weren't the case, but since it is, Drivechain now introduces a very real possible future where Bitcoins can be confiscated by the Chinese government in exactly the same manner that the Chinese government today confiscates financial assets in other financial networks within China.
One argument is that the psuedo-anonymity granted by Bitcoin addresses could theoretically make this less likely to happen, and while that is true, it is also true that every day Bitcoin becomes less and less psuedo-anonymous as governments invest in blockchain analysis tech [1].
How many high-profile confiscations — now via the Bitcoin-blockchain itself (no longer being able to blame a 3rd-party exchange) — is Bitcoin willing to tolerate and open itself up to?
In a world before Drivechain: the worst that a 51% coalition can do is prevent you from spending your coins (censorship).
In a world with Drivechain three things become true:
1. The Bitcoin network centralizes more, because more power (both financial power and power in terms of capability/control) is granted to miners. This is likely to have secondary consequences on the main-chain network as well (in terms of its price and ability to evolve).
2. A 51% coalition — and/or the government behind it — is now able to financially profit by confiscating coins. No longer is it just censorship, "asset forfeiture" — theft — becomes a real possibility for day-to-day Bitcoin users.
3. Drivechain limits user's existing choice when it comes to who is acting as custodian of their Bitcoins, from any trustworthy exchange, down to a single mining cartel under the control of a single set of laws.
The argument given to this is that a UASF could be initiated to wrest control away from this cartel. I do not believe this addresses the concern at all.
A UASF is a very big deal and extremely difficult to pull off correctly. Even when you have users behind you, it *requires* significant support from the miners themselves [2]. Therefore, I do not believe a UASF is a realistic possibility for recovery.
I would only support Drivechain if all of these issue were addressed.
Kind regards,
Greg Slepak
[1] EU Commits €5 Million to Fund Blockchain Surveillance Research — http://www.coindesk.com/eu-commits-e5-million-fund-blockchain-surveillance-research/ <http://www.coindesk.com/eu-commits-e5-million-fund-blockchain-surveillance-research/>
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014497.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014497.html>
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jun 10, 2017, at 10:04 AM, Paul Sztorc via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Hi everyone,
>
> It has been 3 weeks -- responses so far have been really helpful. People
> jumped right in, and identified unfinished or missing parts much faster
> than I thought they would (ie, ~two days). Very impressive.
>
> Currently, we are working on the sidechain side of blind merged mining.
> As you know, most of the Bitcoin cryptosystem is about finding the
> longest chain, and displaying information about this chain. CryptAxe is
> editing the sidechain code to handle reorganizations in a new way (an
> even bigger departure than Namecoin's, imho).
>
> I believe that I have responded to all the on-list objections that were
> raised. I will 1st summarize the on-list objections, and 2nd summarize
> the off-list discussion (focusing on three key themes).
>
>
> On-List Objection Summary
> ---------------------------
>
> In general, they were:
>
> * Peter complained about the resources required for the BMM 'crisis
> audit', I pointed out that it is actually optional (and, therefore,
> free), and that it doesn't affect miners relative to each other, and
> that it can be done in an ultra-cheap semi-trusted way with high
> reliability.
> * Peter also asked about miner incentives, I replied that it is profit
> maximizing to BMM sidechains, because the equation (Tx Fees - Zero Cost)
> is always positive.
> * ZmnSCPxj asked a long series of clarifying questions, and I responded.
> * Tier Nolan complained about my equivocation of the "Bitcoin: no block
> subsidy" case and the "sidechain" case. He cites the asymmetry I point
> out below (in #2). I replied, and I give an answer below.
> * ZmnSCPxj pointed out an error in our OP Code (that we will fix).
> * ZmnSCPxj also asked a number of new questions, I responded. Then he
> responded again, in general he seemed to raise many of the points
> addressed in #1 (below).
> * ZmnSCPxj wanted reorg proofs, to punish reorgers, but I pointed out
> that if 51% can reorg, they can also filter out the reorg proof. We are
> at their mercy in all cases (for better or worse).
> * ZmnSCPxj also brought up the fact that a block size limit is necessary
> for a fee market, I pointed out that this limit does not need to be
> imposed on miners by nodes...miners would be willing-and-able to
> self-impose such a limit, as it maximizes their revenues.
> * ZmnSCPxj also protested the need to soft fork in each individual
> sidechain, I pointed out my strong disagreement ("Unrestrained smart
> contract execution will be the death of most of the interesting
> applications...[could] destabilize Bitcoin itself") and introduced my
> prion metaphor.
> * ZmnSCPxj and Tier Nolan both identified the problem solved by our
> 'ratchet' concept. I explained it to ZmnSCPxj in my reply. We had not
> coded it at the time, but there is code for it now [1]. Tier proposed a
> rachet design, but I think ours is better (Tier did not find ours at
> all, because it is buried in obscure notes, because I didn't think
> anyone would make it this far so quickly).
> * Tier also advised us on how to fix the problem that ZmnSCPxj had
> identified with our NOP earlier.
> * Tier also had a number of suggestions about the real-time negotiation
> of the OP Bribe amount between nodes and miners. I'm afraid I mostly
> ignored these for now, as we aren't there yet.
> * Peter complained that ACKing the sidechain could be exploited for
> political reasons, and I responded that in such a case, miners are free
> to simply avoid ACKing, or to acquiesce to political pressure. Neither
> affect the mainchain.
> * Peter complained that sidechains might provide some miners with the
> opportunity to create a pretext to kick other miners off the network. I
> replied that it would not, and I also brought up the fact that my
> Bitcoin security model was indifferent to which people happened to be
> mining at any given time. I continue to believe that "mining
> centralization" does not have a useful definition.
> * Peter questioned whether or not sidechains would be useful. I stated
> my belief that they would be useful, and linked to my site
> (drivechain.info/projects <http://drivechain.info/projects>) which contains a number of sidechain
> use-cases, and cited my personal anecdotal experiences.
> * Peter wanted to involve miners "as little as possible", I pointed out
> that I felt that I had indeed done this minimization. My view is that
> Peter felt erroneously that it was possible to involve miners less,
> because he neglected [1] that a 51% miner group is already involved
> maximally, as they can create most messages and filter any message, and
> [2] that there are cases where we need miners to filter out harmful
> interactions among multiple chains (just as they filter out harmful
> interactions among multiple txns [ie, "double spends"]). Peter has not
> yet responded to this rebuttal.
> * Peter also suggested client-side validation as "safer", and I pointed
> out that sidechains+BMM _is_ client-side validation. I asked Peter for
> CS-V code, so that we can compare the safety and other features.
> * Sergio reminded us of his version of drivechain. Sergio and I disagree
> over the emphasis on frequency/speed of withdrawals. Also Sergio
> emphasizes a hybrid model, which does not interest me.
>
> If I missed any objections, I hope someone will point them out.
>
>
> Off-List / Three Points of Ongoing Confusion
> ---------------------------------------------
>
> Off list, I have repeated the a similar conversation perhaps 6-10 times
> over the past week. There is a cluster of remaining objections which
> centers around three topics -- speed, theft, and antifragility. I will
> reply here, and add the answers to my FAQ (drivechain.info/faq <http://drivechain.info/faq>).
>
> 1. Speed
>
> This objection is voiced after I point out that side-to-main transfers
> ("withdrawals") will probably take a long time, for example 5 months
> each ( these are customizable parameters, and open for debate -- but if
> withdrawals are every x=3 months, and only x=1 withdrawal can make
> forward progress [on the mainchain] at a time, and only x=1 prospective
> withdrawal can be assembled [by the sidechain] at a time, then we can
> expect total withdrawal time to average 4.5 months [(.5)*3+3] ). The
> response is something like "won't such a system be too slow, and
> therefore unusable?".
>
> Imho, replies of this kind disregard the effect of atomic cross-chain
> swaps, which are instant.
>
> ( In addition, while side-to-main transfers are slow, main-to-side
> transfers are quite fast, x~=10 confirmations. I would go as far as to
> say that, just as the Lightning Network is enabled by SegWit and CSV,
> Drivechain is enabled by the atomic swaps and of Counterparty-like
> embedded consensus. )
>
> Thanks to atomic swaps, someone can act as an investment banker or
> custodian, and purchase side:BTC at a (tiny, competitive discount) and
> then transfer those side-to-main at a minimal inconvenience (comparable
> to that of someone who buys a bank CD). Through market activities, the
> _entire system_ becomes exactly as patient as its most-patient members.
> As icing on the cake, people who aren't planning on using their BTC
> anytime soon (ie "the patient") can even get a tiny investment yield, in
> return for providing this service.
>
>
> 2. Security
>
> This objection usually says something like "Aren't you worried that 51%
> [hashrate] will steal the coins, given that mining is so centralized
> these days?"
>
> The logic of drivechain is to take a known fact -- that miners do not
> steal from exchanges (by coordinating to doublespend deposits to those
> exchanges) -- and generalize it to a new situation -- that [hopefully]
> miners will not steal from sidechains (by coordinating to make 'invalid'
> withdrawals from them).
>
> My generalization is slightly problematic, because "a large mainchain
> reorg today" would hit the entire Bitcoin system and de-confirm *all* of
> the network's transactions, whereas a sidechain-theft would hit only a
> small portion of the system. This asymmetry is a problem because of the
> 1:1 peg, which is explicitly symmetrical -- the thief makes off coins
> that are worth _just as much_ as those coins that he did _not_ attack.
> The side:BTC are therefore relatively more vulnerable to theft, which
> harms the generalization.
>
> As I've just explained, to correct this relative deficiency, we add
> extra inconvenience for any sidechain thievery, which is in this case
> the long long withdrawal time of several months. (Which is also the main
> distinction between DC and extension blocks).
>
> I cannot realistically imagine an erroneous withdrawal persisting for
> several weeks, let alone several months. First, over a timeframe of this
> duration, there can be no pretense of 'we made an innocent mistake', nor
> one that 'it is too inconvenient for us to fix this problem'. This
> requires the attacker to be part of an explicitly malicious conspiracy.
> Even in the conspiring case, I do not understand how miners would
> coordinate the distribution of the eventual "theft" payout, ~3 months
> from now -- if new hashrate comes online between now and then, does it
> get a portion? -- if today's hashrate closes down, does it get a reduced
> portion? -- who decides? I don't think that an algorithm can decide
> (without creating a new mechanism, which -I believe- would have to be
> powered by ongoing sustainable theft [which is impossible]), because the
> withdrawal (ie the "theft") has to be initiated, with a known
> destination, *before* it accumulates 3 months worth of acknowledgement.
>
> Even if hashrate were controlled exclusively by one person, such a theft
> would obliterate the sidechain-tx-fee revenue from all sidechains, for a
> start. It would also greatly reduce the market price of [mainchain] BTC,
> I feel, as it ends the sidechain experiment more-or-less permanently.
>
> And even _that_ dire situation can be defeated by UASF-style maneuvers,
> such as checkpointing. Even the threat of such maneuvers can be
> persuasive enough for them never to be needed (especially over long
> timeframes, which make these maneuvers convenient).
>
> A slightly more realistic worst-case scenario is that a monopolist
> imposes large fees on side-to-main transfers (which he contrives so that
> only he can provide). Unless the monopoly is permanent, market forces
> (atomic swaps) will still lower the fee to ultra-competitive levels,
> making this mostly pointless.
>
>
> 3. Antifragility
>
> There is an absolutely crucial distinction of "layers", which is often
> overlooked. Which is a shame, because its importance really cannot be
> understated.
>
> Taleb's concept of antifragility is explicitly fractal -- it has layers,
> and an upper layer can only be antifragile if it is composed of
> individual members of a lower layer who are each *fragile*. In one of my
> videos I give the example of NYC food providers -- it is _because_ the
> competition is so brutal, and because each individual NYC
> restaurant/supermarket/food-truck is so likely to fail, (and because
> there is no safety net to catch them if they do fail), that the
> consumer's experience is so positive (in NYC, you can find almost any
> kind of food, at any hour of the day, at any price, despite the fact
> that a staggering ~15 million people will be eating there each day).
>
> By this, I mean there is an absolutely crucial distinction between:
>
> 1. A problem with a sidechain that negatively impacts its parent chain.
> 2. A problem with a sidechain that only impacts the sidechain users.
>
> The first type of problem is unacceptable, but the second type of
> problem is actually _desirable_.
>
> If we wanted to have the best BTC currency unit possible, we would want
> everyone to try all kinds of things out, _especially_ the things that we
> think are terrible. We'd want lots of things to be tried, and for the
> losers to "fail fast".
>
> In practice I highly doubt the sidechain ecosystem would be anywhere
> near as dynamic as NYC or Silicon Valley. But certain questions, such as
> "What if a sidechain breaks / has DAO-like problems?"; "What if the
> sidechain has only a few nodes? Who will run them?"; "Who will maintain
> these projects?"; -- really just miss the point, I think.
>
> Ultimately, users can vote with their feet -- if the benefits of a
> sidechain outweigh its risks, some users will send some BTC there. It is
> a strict improvement over the current situation, where users would need
> to use an Altcoin to achieve as much. Users who aren't comfortable with
> the risks of new chains / new features, can simply decline to use them.
>
>
> Another Objection
> ------------------
>
> Finally, two people raised an objection which I will call the "too
> popular" objection or "too big to fail (tbtf)". Something like "what if
> a *majority* of BTC is moved to one sidechain, and then that sidechain
> has some kind of problem?".
>
> One simple step would be to cap the quantity of BTC that can be moved to
> each sidechain, (at x=10% ? aka 210,000).
>
> Other than that, I would point out that Bitcoin has always been the
> "money of principle", and that we survived the MtGox announcement (in
> which ~850,000/12,400,000 = 6.85% of the total BTC were assumed to be
> stolen).
>
> I look forward to the continued feedback! Thank you all very much!
>
> Paul
>
> [1]
> https://github.com/drivechain-project/bitcoin/commit/c4beef5c2aa8e52d2c1e11de7c044528bbde6c60 <https://github.com/drivechain-project/bitcoin/commit/c4beef5c2aa8e52d2c1e11de7c044528bbde6c60>
>
>
> On 5/22/2017 2:17 AM, Paul Sztorc wrote:
>> Dear list,
>>
>> I've been working on "drivechain", a sidechain enabling technology, for
>> some time.
>>
>> * The technical info site is here: www.drivechain.info
>> * The changes to Bitcoin are here:
>> https://github.com/drivechain-project/bitcoin/tree/mainchainBMM
>> * A Blank sidechain template is here:
>> https://github.com/drivechain-project/bitcoin/tree/sidechainBMM
>>
>> As many of you know, I've been seeking feedback in person, at various
>> conferences and meetups over the past year, most prominently Scaling
>> Milan. And I intend to continue to seek feedback at Consensus2017 this
>> week, so if you are in NYC please just walk up and start talking to me!
>>
>> But I also wanted to ask the list for feedback. Initially, I was
>> hesitant because I try not to consume reviewers' scarce time until the
>> author has put in a serious effort. However, I may have waiting too
>> long, as today it is actually quite close to a working release.
>>
>>
>> Scaling Implications
>> ---------------------
>>
>> This upgrade would have significant scaling implications. Since it is
>> the case that sidechains can be added by soft fork, and since each of
>> these chains will have its own blockspace, this theoretically removes
>> the blocksize limit from "the Bitcoin system" (if one includes
>> sidechains as part of such a system). People who want a LargeBlock
>> bitcoin can just move their BTC over to such a network [1], and their
>> txns will have no longer have an impact on "Bitcoin Core". Thus, even
>> though this upgrade does not actually increase "scalability" per se, it
>> may in fact put an end to the scalability debate...forever.
>>
>> This work includes the relatively new concept of "Blind Merged Mining"
>> [2] which I developed in January to allow SHA256^2 miners to merge-mine
>> these "drivechains", even if these miners aren't running the actual
>> sidechain software. The goal is to prevent sidechains from affecting the
>> levelness of the mining "playing field". BMM is conceptually similar to
>> ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not
>> required for drivechain, but it would address some of the last remaining
>> concerns.
>>
>>
>> Total Transaction Fees in the Far Future
>> -----------------------------------------
>>
>> Some people feel that a maximum blocksize limit is needed to ensure that
>> future total equilibrium transaction fees are non-negligible. I
>> presented [4] on why I don't agree, 8 months ago. The reviewers I spoke
>> to over the last year have stopped bringing this complaint up, but I am
>> not sure everyone feels that way.
>>
>>
>> Juxtaposition with a recent "Scaling Compromise"
>> -------------------------------------------------
>>
>> Recently, a scalability proposal began to circulate on social media. As
>> far as I could tell, it goes something like "immediately activate
>> SegWit, and then HF to double the nonwitness blockspace to 2MB within 12
>> months". But such a proposal is quite meager, compared to a "LargeBlock
>> Drivechain". The drivechain is better on both fronts, as it would not
>> require a hardfork, and could *almost immediately* add _any_ amount of
>> extra blockspace (specifically, I might expect a BIP101-like LargeBlock
>> chain that has an 8 MB maxblocksize, which doubles every two years).
>>
>> In other words, I don't know why anyone would support that proposal over
>> mine. The only reasons would be either ignorance (ie, unfamiliarity with
>> drivechain) or because there are still nagging unspoken complaints about
>> drivechain which I apparently need to hear and address.
>>
>>
>> Other Thoughts
>> ---------------
>>
>> Unfortunately, anyone who worked on the "first generation" of sidechain
>> technology (the skiplist) or the "second generation" (federated /
>> Liquid), will find that this is very different.
>>
>> I will admit that I am very pessimistic about any conversation that
>> involves scalability. It is often said that "talking politics lowers
>> your IQ by 25 points". Bitcoin scalability conversations seem to drain
>> 50 points. (Instead of conversing, I think people should quietly work on
>> whatever they are passionate about until their problem either is solved,
>> or it goes away for some other reason, or until we all agree to just
>> stop talking about it.)
>>
>> Cheers,
>> Paul
>>
>> [1] http://www.drivechain.info/faq/#can-sidechains-really-help-with-scaling
>> [2] http://www.truthcoin.info/blog/blind-merged-mining/
>> [3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log
>> [4]
>> https://www.youtube.com/watch?v=YErLEuOi3xU&list=PLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=4
>>
> _______________________________________________
> 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/20170618/afbca0d1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170618/afbca0d1/attachment-0001.sig>

2023-06-07 18:02:34

- reply

📅 Original date posted:2017-06-07
📝 Original message:See thread on replay attacks for why activating regardless of threshold is a bad idea [1].
BIP91 OTOH seems perfectly reasonable. 80% instead of 95% makes it more difficult for miners to hold together in opposition to Core. It gives Core more leverage in negotiations.
If they don't activate with 80%, Core can release another BIP to reduce it to 75%.
Each threshold reduction makes it both more likely to succeed, but also increases the likelihood of harm to the ecosystem.
Cheers,
Greg
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014497.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014497.html>
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jun 6, 2017, at 6:54 PM, James Hilliard <james.hilliard1 at gmail.com <mailto:james.hilliard1 at gmail.com>> wrote:
>
> This is a BIP8 style soft fork so mandatory signalling will be active
> after Aug 1st regardless.
>
> On Tue, Jun 6, 2017 at 8:51 PM, Tao Effect <contact at taoeffect.com <mailto:contact at taoeffect.com>> wrote:
>> What is the probability that a 65% threshold is too low and can allow a
>> "surprise miner attack", whereby miners are kept offline before the
>> deadline, and brought online immediately after, creating potential havoc?
>>
>> (Nit: "simple majority" usually refers to >50%, I think, might cause
>> confusion.)
>>
>> -Greg Slepak
>>
>> --
>> Please do not email me anything that you are not comfortable also sharing
>> with the NSA.
>>
>> On Jun 6, 2017, at 5:56 PM, James Hilliard via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> Due to the proposed calendar(https://segwit2x.github.io/ <https://segwit2x.github.io/>) for the
>> SegWit2x agreement being too slow to activate SegWit mandatory
>> signalling ahead of BIP148 using BIP91 I would like to propose another
>> option that miners can use to prevent a chain split ahead of the Aug
>> 1st BIP148 activation date.
>>
>> The splitprotection soft fork is essentially BIP91 but using BIP8
>> instead of BIP9 with a lower activation threshold and immediate
>> mandatory signalling lock-in. This allows for a majority of miners to
>> activate mandatory SegWit signalling and prevent a potential chain
>> split ahead of BIP148 activation.
>>
>> This BIP allows for miners to respond to market forces quickly ahead
>> of BIP148 activation by signalling for splitprotection. Any miners
>> already running BIP148 should be encouraged to use splitprotection.
>>
>> <pre>
>> BIP: splitprotection
>> Layer: Consensus (soft fork)
>> Title: User Activated Soft Fork Split Protection
>> Author: James Hilliard <james.hilliard1 at gmail.com <mailto:james.hilliard1 at gmail.com>>
>> Comments-Summary: No comments yet.
>> Comments-URI:
>> Status: Draft
>> Type: Standards Track
>> Created: 2017-05-22
>> License: BSD-3-Clause
>> CC0-1.0
>> </pre>
>>
>> ==Abstract==
>>
>> This document specifies a coordination mechanism for a simple majority
>> of miners to prevent a chain split ahead of BIP148 activation.
>>
>> ==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==
>>
>> The biggest risk of BIP148 is an extended chain split, this BIP
>> provides a way for a simple majority of miners to eliminate that risk.
>>
>> This BIP provides a way for a simple majority of miners to coordinate
>> activation of the existing segwit deployment with less than 95%
>> hashpower before BIP148 activation. Due to time constraints unless
>> immediately deployed BIP91 will likely not be able to enforce
>> mandatory signalling of segwit before the Aug 1st activation of
>> BIP148. This BIP provides a method for rapid miner activation of
>> SegWit mandatory signalling ahead of the BIP148 activation date. Since
>> the primary goal of this BIP is to reduce the chance of an extended
>> chain split as much as possible we activate using a simple miner
>> majority of 65% over a 504 block interval rather than a higher
>> percentage. This BIP also allows miners to signal their intention to
>> run BIP148 in order to prevent a chain split.
>>
>> ==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 "version bits" with a 65%(this can be
>> adjusted if desired) activation threshold BIP9 with the name
>> "splitprotecion" and using bit 2.
>>
>> This BIP starts immediately and is a BIP8 style soft fork since
>> mandatory signalling will start on midnight August 1st 2017 (epoch
>> time 1501545600) regardless of whether or not this BIP has reached its
>> own signalling threshold. 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);
>> }
>>
>> // SPLITPROTECTION mandatory segwit signalling.
>> if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
>> Consensus::DEPLOYMENT_SPLITPROTECTION, versionbitscache) ==
>> THRESHOLD_LOCKED_IN &&
>> !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");
>> }
>> }
>>
>> // BIP148 mandatory segwit signalling.
>> int64_t nMedianTimePast = pindex->GetMedianTimePast();
>> if ( (nMedianTimePast >= 1501545600) && // Tue 01 Aug 2017 00:00:00 UTC
>> (nMedianTimePast <= 1510704000) && // Wed 15 Nov 2017 00:00:00 UTC
>> (!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:splitprotection-v0.14.1 <https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard:splitprotection-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. This deployment is also compatible with the
>> existing BIP148 deployment. This BIP is compatible with BIP91 only if
>> BIP91 activates before it and before BIP148. Miners will need to
>> upgrade their nodes to support splitprotection otherwise they may
>> build on top of an invalid block. While this bip is active users
>> should either upgrade to splitprotection 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. We also use a BIP8 style timeout to
>> ensure that this BIP is compatible with BIP148 and that BIP148
>> compatible mandatory signalling activates regardless of miner
>> signalling levels.
>>
>> 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. As we approach
>> BIP148 activation it may be desirable for a majority of miners to have
>> a method that will ensure that there is no chain split.
>>
>> ==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-0091.mediawiki|BIP91 Reduced threshold Segwit MASF]]
>> *[[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/20170606/1871ce5a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/1871ce5a/attachment-0001.sig>

2023-06-07 18:02:31

- reply

📅 Original date posted:2017-06-06
📝 Original message:What is the probability that a 65% threshold is too low and can allow a "surprise miner attack", whereby miners are kept offline before the deadline, and brought online immediately after, creating potential havoc?
(Nit: "simple majority" usually refers to >50%, I think, might cause confusion.)
-Greg Slepak
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jun 6, 2017, at 5:56 PM, James Hilliard via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Due to the proposed calendar(https://segwit2x.github.io/ <https://segwit2x.github.io/>) for the
> SegWit2x agreement being too slow to activate SegWit mandatory
> signalling ahead of BIP148 using BIP91 I would like to propose another
> option that miners can use to prevent a chain split ahead of the Aug
> 1st BIP148 activation date.
>
> The splitprotection soft fork is essentially BIP91 but using BIP8
> instead of BIP9 with a lower activation threshold and immediate
> mandatory signalling lock-in. This allows for a majority of miners to
> activate mandatory SegWit signalling and prevent a potential chain
> split ahead of BIP148 activation.
>
> This BIP allows for miners to respond to market forces quickly ahead
> of BIP148 activation by signalling for splitprotection. Any miners
> already running BIP148 should be encouraged to use splitprotection.
>
> <pre>
> BIP: splitprotection
> Layer: Consensus (soft fork)
> Title: User Activated Soft Fork Split Protection
> Author: James Hilliard <james.hilliard1 at gmail.com <mailto:james.hilliard1 at gmail.com>>
> Comments-Summary: No comments yet.
> Comments-URI:
> Status: Draft
> Type: Standards Track
> Created: 2017-05-22
> License: BSD-3-Clause
> CC0-1.0
> </pre>
>
> ==Abstract==
>
> This document specifies a coordination mechanism for a simple majority
> of miners to prevent a chain split ahead of BIP148 activation.
>
> ==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==
>
> The biggest risk of BIP148 is an extended chain split, this BIP
> provides a way for a simple majority of miners to eliminate that risk.
>
> This BIP provides a way for a simple majority of miners to coordinate
> activation of the existing segwit deployment with less than 95%
> hashpower before BIP148 activation. Due to time constraints unless
> immediately deployed BIP91 will likely not be able to enforce
> mandatory signalling of segwit before the Aug 1st activation of
> BIP148. This BIP provides a method for rapid miner activation of
> SegWit mandatory signalling ahead of the BIP148 activation date. Since
> the primary goal of this BIP is to reduce the chance of an extended
> chain split as much as possible we activate using a simple miner
> majority of 65% over a 504 block interval rather than a higher
> percentage. This BIP also allows miners to signal their intention to
> run BIP148 in order to prevent a chain split.
>
> ==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 "version bits" with a 65%(this can be
> adjusted if desired) activation threshold BIP9 with the name
> "splitprotecion" and using bit 2.
>
> This BIP starts immediately and is a BIP8 style soft fork since
> mandatory signalling will start on midnight August 1st 2017 (epoch
> time 1501545600) regardless of whether or not this BIP has reached its
> own signalling threshold. 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);
> }
>
> // SPLITPROTECTION mandatory segwit signalling.
> if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
> Consensus::DEPLOYMENT_SPLITPROTECTION, versionbitscache) ==
> THRESHOLD_LOCKED_IN &&
> !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");
> }
> }
>
> // BIP148 mandatory segwit signalling.
> int64_t nMedianTimePast = pindex->GetMedianTimePast();
> if ( (nMedianTimePast >= 1501545600) && // Tue 01 Aug 2017 00:00:00 UTC
> (nMedianTimePast <= 1510704000) && // Wed 15 Nov 2017 00:00:00 UTC
> (!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:splitprotection-v0.14.1 <https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard:splitprotection-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. This deployment is also compatible with the
> existing BIP148 deployment. This BIP is compatible with BIP91 only if
> BIP91 activates before it and before BIP148. Miners will need to
> upgrade their nodes to support splitprotection otherwise they may
> build on top of an invalid block. While this bip is active users
> should either upgrade to splitprotection 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. We also use a BIP8 style timeout to
> ensure that this BIP is compatible with BIP148 and that BIP148
> compatible mandatory signalling activates regardless of miner
> signalling levels.
>
> 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. As we approach
> BIP148 activation it may be desirable for a majority of miners to have
> a method that will ensure that there is no chain split.
>
> ==References==
>
> *[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013714.html <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 <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-0091.mediawiki|BIP91 Reduced threshold Segwit MASF]]
> *[[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 <https://bitcoincore.org/en/2016/01/26/segwit-benefits/%20Segwit%20benefits>]
>
> ==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 <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <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/9d3cbc4a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/9d3cbc4a/attachment-0001.sig>

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,
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 <mailto: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 <mailto:contact at taoeffect.com>
>> To: Kekcoin <kekcoin at protonmail.com <mailto:kekcoin at protonmail.com>>
>> Anthony Towns <aj at erisian.com.au <mailto:aj at erisian.com.au>>, bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org> <bitcoin-dev at lists.linuxfoundation.org <mailto: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 <mailto: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/99784c2b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/99784c2b/attachment-0001.sig>

2023-06-07 18:02:27

- 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?
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 <mailto: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/e69fcaa4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/e69fcaa4/attachment-0001.sig>

2023-06-07 18:02:27

- reply

📅 Original date posted:2017-06-06
📝 Original message: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 <mailto: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/b2d1e1e6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/b2d1e1e6/attachment-0001.sig>

2023-06-07 18:02:26

- reply

📅 Original date posted:2017-06-06
📝 Original message:> 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 <mailto: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 <mailto: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/ddaf726e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/ddaf726e/attachment-0001.sig>

2023-06-07 18:02:26

- reply

📅 Original date posted:2017-06-06
📝 Original message:> CPFP can be used by an attacker to get your original txn into the 148 chain.
*err, my bad that's unlikely to happen, if I remember correctly CPFP can only be done by the person you're sending the coins to. Coin-mixing seems the better option of the two, but shouldn't the BIP148 folks wait until it's clear that will be supported by exchanges?
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jun 6, 2017, at 4:27 PM, Tao Effect <contact at taoeffect.com <mailto:contact at taoeffect.com>> wrote:
>
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/35a6f6dc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/35a6f6dc/attachment.sig>

2023-06-07 18:02:25

- reply

📅 Original date posted:2017-06-06
📝 Original message:> Replay is a solved problem.
Point to this solved problem?
Your "solution" here is not a solution:
https://www.reddit.com/r/Bitcoin/comments/6f1urd/i_think_its_time_we_have_an_educated_discussion/diey21t/?context=3 <https://www.reddit.com/r/Bitcoin/comments/6f1urd/i_think_its_time_we_have_an_educated_discussion/diey21t/?context=3>
> This is nothing but unfounded FUD. It is very simple to implement and
> guaranteed to work eventually. It may be time consuming, but that is the only
> truth here. The only risk is that of a long reorg, the same as double spend
> attacks.
Let's assume you invented a simple way to double-spend txns to self (which you haven't, fyi), then that is an issue in of itself as the point of bitcoin is to *prevent* double-spending to self.
There would need to be much more time for the community to discuss the implications of wallets have a "double-spend to self" button in them.
> What kind of "fungibility" does this FUD claim it destroys? Destroying cross-
> chain fungibility is the very *intent* of replay protection. And it does not
> destroy same-chain fungibility any more than any other miner spending.
Yes it does destroy same-chain fungibility, as discussed on twitter [1], you're making miner coins special on both chains.
> Lack of replay protection does not mean there is no coin.
It effectively does. If people want to proceed blindly, ignoring replay, they're welcome to read about the consequences [2].
[1] https://twitter.com/taoeffect/status/872226556571131905 <https://twitter.com/taoeffect/status/872226556571131905>
[2] http://gist.github.com/taoeffect/c910ebb16d9f6d248e9f1f3c6e10b1b8 <http://gist.github.com/taoeffect/c910ebb16d9f6d248e9f1f3c6e10b1b8>
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jun 6, 2017, at 4:08 PM, Luke Dashjr <luke at dashjr.org <mailto:luke at dashjr.org>> wrote:
>
> On Tuesday 06 June 2017 10:39:28 PM Tao Effect via bitcoin-dev wrote:
>> I believe the severity of replay attacks is going unvoiced and is not
>> understood within the bitcoin community because of their lack of
>> experience with them.
>
> Replay is a solved problem. It can be improved on and made simpler, but at
> this point, replay only occurs when the sender is either negligent or
> intending it.
>
>> Both of the coin-splitting techniques given so far by the proponents BIP148
>> are also untenable:
>>
>> - Double-spending to self with nLockTime txns is insanely complicated,
>> risky, not guaranteed to work, extremely time consuming, and would likely
>> result in a massive increase in backlogged transactions and increased
>> fees.
>
> This is nothing but unfounded FUD. It is very simple to implement and
> guaranteed to work eventually. It may be time consuming, but that is the only
> truth here. The only risk is that of a long reorg, the same as double spend
> attacks.
>
>> - Mixing with 148 coinbase txns destroys fungibility.
>
> What kind of "fungibility" does this FUD claim it destroys? Destroying cross-
> chain fungibility is the very *intent* of replay protection. And it does not
> destroy same-chain fungibility any more than any other miner spending.
>
>> Without a coin, there is no real threat from BIP148.
>
> Lack of replay protection does not mean there is no coin. Replay protection is
> equally a concern for the main (BIP148) chain and any legacy chains malicious
> miners might choose to split off. And none of this changes the fact that such
> miners will be unable to sell their legacycoins at Bitcoin market prices,
> because whether other transactions are replayed or not, *their* coins won't be
> valid on the main chain.
>
> Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/1e3823f1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/1e3823f1/attachment.sig>

2023-06-07 18:02:24

- reply

📅 Original date posted:2017-06-06
📝 Original message:Hey Greg,
It wasn't my intention to insult anyone (a bit defensive?).
Maybe this is yet another example of a recurring criticism of Core: that core doesn't community these issues very well to journalists / reports / media / community outside of this list.
Because outside of this list it's been all about those 148 coins, and almost zero mention of replay attacks.
> BIP149 is arguably something of another matter in particular because
> it has a time-frame that allows dealing with replay and other issues--
> and particularly because it has a time-frame that can allow for the
> avoidance of a meaningful fork at all.
Are there other, more reasonable / feasible ways of addressing replay attacks in Bitcoin / BIP149 scenario?
Cheers,
Greg
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jun 6, 2017, at 4:02 PM, Gregory Maxwell <greg at xiph.org <mailto:greg at xiph.org>> wrote:
>
> On Tue, Jun 6, 2017 at 10:39 PM, Tao Effect via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>> I believe the severity of replay attacks is going unvoiced and is not
>> understood within the bitcoin community because of their lack of experience
>> with them.
>
> Please don't insult our community-- the issues with replay were
> pointed out by us to Ethereum in advance and were cited specifically
> in prior hardfork discussions long before Ethereum started editing
> their ledger for the economic benefit of its centralized
> administrators.
>
> The lack of extensive discussion on these issues you're seeing is
> rather symptomatic of engineers that take stability seriously not
> taking BIP148 seriously; not symptomatic of people not knowing about
> them. The same concerns also applies to all these HF proposals (which
> for some reason you don't mention), arguably even stronger. The same
> basic pattern exists: There are people that just don't care about the
> technical issues who have made up their minds, and so you don't see
> technical discussion. Those people who do see the issues already
> called out the proposals as being ill-advised. Replay isn't even the
> largest of the technical issues (network partitioning, for example, is
> a much larger one).
>
> BIP149 is arguably something of another matter in particular because
> it has a time-frame that allows dealing with replay and other issues--
> and particularly because it has a time-frame that can allow for the
> avoidance of a meaningful fork at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/6748ec9e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/6748ec9e/attachment-0001.sig>

2023-06-07 18:02:24

- reply

📅 Original date posted:2017-06-07
📝 Original message:Nick,
> Please don't spread misinformation. Whatever you think of the DAO hard fork, it's a simple fact that the Ethereum ledger was not edited.
This sort of email is unhelpful to this conversation, and it certainly doesn't help with the perception that Ethereum is nothing but a bunch of hypocritical Bankers 2.0.
Everyone knows you didn't edit Ethereum Classic, but the the hard fork, which was re-branded as Ethereum, was edited.
- Greg
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jun 7, 2017, at 6:25 AM, Nick Johnson <nick at ethereum.org <mailto:nick at ethereum.org>> wrote:
>
> On Wed, Jun 7, 2017 at 12:02 AM Gregory Maxwell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> On Tue, Jun 6, 2017 at 10:39 PM, Tao Effect via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> > I believe the severity of replay attacks is going unvoiced and is not
> > understood within the bitcoin community because of their lack of experience
> > with them.
>
> Please don't insult our community-- the issues with replay were
> pointed out by us to Ethereum in advance and were cited specifically
> in prior hardfork discussions long before Ethereum started editing
> their ledger for the economic benefit of its centralized
> administrators.
>
> Please don't spread misinformation. Whatever you think of the DAO hard fork, it's a simple fact that the Ethereum ledger was not edited.
>
> -Nick Johnson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170607/d0012334/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170607/d0012334/attachment.sig>

2023-06-07 18:02:23

- reply

📅 Original date posted:2017-06-06
📝 Original message:This is just me putting in my formal objection to BIP148 and BIP149 based on my experience with the ETH/ETC hard fork and involvement in that drama.
First, it's important to note that ETC/ETH HF is a very different situation from BIP148 and all other soft-forks. To those on this mailing list, the reasons should be self-evident (one results in two incompatible chains, the other doesn't).
However, replay attacks are common to both possibilities (i.e. when BIP148 has <51% hash power).
I believe the severity of replay attacks is going unvoiced and is not understood within the bitcoin community because of their lack of experience with them.
I further believe that replay attacks are the #1 issue with BIP148, BIP149, etc., superseding wipeout attacks in severity.
These are not baseless beliefs, they're born out of experience and I think anyone will reach the same conclusion upon study.
In a nutshell, replay attacks mean that all talk of there being potentially "two coins" as a result of BIP148 is basically nonsense.
Replay attacks effectively eliminate that possibility.
When users go to "sell their legacy coins", they've just sold their 148 coins, and vice versa.
Both of the coin-splitting techniques given so far by the proponents BIP148 are also untenable:
- Double-spending to self with nLockTime txns is insanely complicated, risky, not guaranteed to work, extremely time consuming, and would likely result in a massive increase in backlogged transactions and increased fees.
- Mixing with 148 coinbase txns destroys fungibility.
Without a coin, there is no real threat from BIP148. Without that threat, there is no point to BIP148, and the miners know this.
These and other concerns are outlined and explained in more detail in this conversation I had yesterday with John Light:
https://www.youtube.com/watch?v=33rL3-p8cPw <https://www.youtube.com/watch?v=33rL3-p8cPw>
Cheers,
Greg Slepak
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/7b754c78/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/7b754c78/attachment.sig>

2023-06-07 18:02:23

- reply

📅 Original date posted:2017-06-06
📝 Original message:This is just me putting in my formal objection to BIP148 and BIP149 based on my experience with the ETH/ETC hard fork and involvement in that drama.
First, it's important to note that ETC/ETH HF is a very different situation from BIP148 and all other soft-forks. To those on this mailing list, the reasons should be self-evident (one results in two incompatible chains, the other doesn't).
However, replay attacks are common to both possibilities (i.e. when BIP148 has <51% hash power).
I believe the severity of replay attacks is going unvoiced and is not understood within the bitcoin community because of their lack of experience with them.
I further believe that replay attacks are the #1 issue with BIP148, BIP149, etc., superseding wipeout attacks in severity.
These are not baseless beliefs, they're born out of experience and I think anyone will reach the same conclusion upon study.
In a nutshell, replay attacks mean that all talk of there being potentially "two coins" as a result of BIP148 is basically nonsense.
Replay attacks effectively eliminate that possibility.
When users go to "sell their legacy coins", they've just sold their 148 coins, and vice versa.
Both of the coin-splitting techniques given so far by the proponents BIP148 are also untenable:
- Double-spending to self with nLockTime txns is insanely complicated, risky, not guaranteed to work, extremely time consuming, and would likely result in a massive increase in backlogged transactions and increased fees.
- Mixing with 148 coinbase txns destroys fungibility.
Without a coin, there is no real threat from BIP148. Without that threat, there is no point to BIP148, and the miners know this.
These and other concerns are outlined and explained in more detail in this conversation I had yesterday with John Light:
https://www.youtube.com/watch?v=33rL3-p8cPw <https://www.youtube.com/watch?v=33rL3-p8cPw>
Cheers,
Greg Slepak
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/862fdff6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/862fdff6/attachment.sig>

2023-06-07 17:48:58

- reply

📅 Original date posted:2016-02-09
📝 Original message:Look, if we’re going to declare something an emergency, we cannot on the one hand say things like: "I strongly believe bitcoin has no place in the world if the fee raise much higher than a few cents per typically-sized transaction”, and on the other declare that there is an emergency worth redefining what *Bitcoin is* because the average txn fee is on the order of 7 cents [1] and has remained reasonable for some time [2].
If you’d like to understand what a qualifying emergency looks like, read the links:
> http://bitledger.info/why-a-hard-fork-should-be-fought-and-its-not-evil-to-discuss/
>
> And here:
>
> http://bitledger.info/hard-fork-risks-and-why-95-should-be-the-standard/
In terms of scaling, we are nowhere close to an emergency.
Scaling is priority #4, maybe, and it’s being taken care of.
Meanwhile, we should be directing our attention one the more pressing and serious concerns like mining centralization & privacy.
Mining centralization is a serious issue. It is *not cool* that 4 dudes (and 1 government) have the power to redefine what Bitcoin is *right now*.
Relevant post with suggestions for fixing that:
https://www.reddit.com/r/Bitcoin/comments/44kwf0/the_hardfork_that_bitcoin_really_needs_not/czrh3na
As far as I can tell, P2Pool & GBT are not the same thing, but I’ve been told that P2Pool might use GBT in some way, even though it’s listed on the wiki as not using it. [3]
A hard fork would ideally enforce decentralized mining pools somehow so that transaction selection is done at the edges instead of the center.
Cheers,
Greg
[1] http://www.cointape.com/
[2] https://blockchain.info/charts/transaction-fees
[3] https://en.bitcoin.it/wiki/Comparison_of_mining_pools
> On Feb 8, 2016, at 4:54 PM, Chris Priest <cp368202 at ohiou.edu> wrote:
>
>> Also, if you’re going to do a hard fork, you’d better make the most of it as hard forks must be a *rare* world-is-ending-if-we-don’t-do-it thing
>
> In my opinion, the network publishing more than 1MB worth of
> transactions while the limit is still 1MB *is* an emergency worthy of
> a hard fork.
>
> If that's not an emergency, then what is?
>
> I strongly believe bitcoin has no place in the world if the fee raise
> much higher than a few cents per typically-sized transaction.
>
> On 2/8/16, Tao Effect via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Hard forks should always come in response to some major crisis that all
>> participants can agree is an actual crisis, as per the excellent rational
>> here:
>>
>> http://bitledger.info/why-a-hard-fork-should-be-fought-and-its-not-evil-to-discuss/
>>
>> And here:
>>
>> http://bitledger.info/hard-fork-risks-and-why-95-should-be-the-standard/
>>
>> Also, if you’re going to do a hard fork, you’d better make the most of it as
>> hard forks must be a *rare* world-is-ending-if-we-don’t-do-it thing
>> (otherwise Bitcoin cannot be considered decentralized in any sense of the
>> word).
>>
>> So for any sort of hard fork, be sure to address the real threats and
>> challenges that are facing Bitcoin today:
>>
>> 1. Mining centralization.
>> 2. Privacy.
>>
>> Best regards,
>> Greg Slepak
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160208/bb73279d/attachment.sig>

2023-06-07 17:48:55

- reply

📅 Original date posted:2016-02-08
📝 Original message:Hard forks should always come in response to some major crisis that all participants can agree is an actual crisis, as per the excellent rational here:
http://bitledger.info/why-a-hard-fork-should-be-fought-and-its-not-evil-to-discuss/
And here:
http://bitledger.info/hard-fork-risks-and-why-95-should-be-the-standard/
Also, if you’re going to do a hard fork, you’d better make the most of it as hard forks must be a *rare* world-is-ending-if-we-don’t-do-it thing (otherwise Bitcoin cannot be considered decentralized in any sense of the word).
So for any sort of hard fork, be sure to address the real threats and challenges that are facing Bitcoin today:
1. Mining centralization.
2. Privacy.
Best regards,
Greg Slepak
> On Feb 8, 2016, at 12:37 PM, jl2012--- via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Thanks for this proposal. Just some quick response:
>
> 1. The segwit hardfork (BIP HF) could be deployed with BIP141 (segwit
> softfork). BIP141 doesn't need grace period. BIP HF will have around 1 year
> of grace period.
>
> 2. Threshold is 95%. Using 4 versoin bits: a) BIP 141; b) BIP HF; c) BIP 141
> if BIP HF has already got 95%; d) BIP HF if BIP141 has already got 95%.
> Voting a and c (or b and d) at the same time is invalid. BIP 141 is
> activated if a>95% or (a+c>95% and b+d>95%). BIP HF is activated if b>95% or
> (a+c>95% and b+d>95%).
>
> 3. Fix time warp attack: this may break some SPV implementation
>
> 4. Limiting non-segwit inputs may make some existing signed tx invalid. My
> proposal is: a) count the number of non-segwit sigop in a tx, including
> those in unexecuted branch (sigop); b) measure the tx size without scripgSig
> (size); c) a new rule is SUM(sigop*size) < some_value . This allows
> calculation without actually running the script.
>
>
> -----Original Message-----
> From: bitcoin-dev-bounces at lists.linuxfoundation.org
> [mailto:bitcoin-dev-bounces at lists.linuxfoundation.org] On Behalf Of Matt
> Corallo via bitcoin-dev
> Sent: Tuesday, 9 February, 2016 03:27
> To: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
> Subject: [bitcoin-dev] On Hardforks in the Context of SegWit
>
> Hi all,
>
> I believe we, today, have a unique opportunity to begin to close the book on
> the short-term scaling debate.
>
> First a little background. The scaling debate that has been gripping the
> Bitcoin community for the past half year has taken an interesting turn in
> 2016. Until recently, there have been two distinct camps - one proposing a
> significant change to the consensus-enforced block size limit to allow for
> more on-blockchain transactions and the other opposing such a change,
> suggesting instead that scaling be obtained by adding more flexible systems
> on top of the blockchain. At this point, however, the entire Bitcoin
> community seems to have unified around a single vision - roughly 2MB of
> transactions per block, whether via Segregated Witness or via a hard fork,
> is something that can be both technically supported and which adds more
> headroom before second-layer technologies must be in place. Additionally, it
> seems that the vast majority of the community agrees that segregated witness
> should be implemented in the near future and that hard forks will be a
> necessity at some point, and I don't believe it should be controversial
> that, as we have never done a hard fork before, gaining experience by
> working towards a hard fork now is a good idea.
>
> With the apparent agreement in the community, it is incredibly disheartening
> that there is still so much strife, creating a toxic environment in which
> developers are not able to work, companies are worried about their future
> ability to easily move Bitcoins, and investors are losing confidence. The
> way I see it, this broad unification of visions across all parts of the
> community places the burden of selecting the most technically-sound way to
> achieve that vision squarely on the development community.
>
> Sadly, the strife is furthered by the huge risks involved in a hard fork in
> the presence of strife, creating a toxic cycle which prevents a safe hard
> fork. While there has been talk of doing an "emergency hardfork" as an
> option, and while I do believe this is possible, it is not something that
> will be easy, especially for something as controversial as rising fees.
> Given that we have never done a hard fork before, being very careful and
> deliberate in doing so is critical, and the technical community working
> together to plan for all of the things that might go wrong is key to not
> destroying significant value.
>
> As such, I'd like to ask everyone involved to take this opportunity to
> "reset", forgive past aggressions, and return the technical debates to
> technical forums (ie here, IRC, etc).
>
> As what a hard fork should look like in the context of segwit has never
> (!) been discussed in any serious sense, I'd like to kick off such a
> discussion with a (somewhat) specific proposal.
>
> First some design notes:
> * I think a key design feature should be taking this opportunity to add
> small increases in decentralization pressure, where possible.
> * Due to the several non-linear validation time issues in transaction
> validation which are fixed by SegWit's signature-hashing changes, I strongly
> believe any hard fork proposal which changes the block size should rely on
> SegWit's existence.
> * As with any hard fork proposal, its easy to end up pulling in hundreds of
> small fixes for any number of protocol annoyances. In order to avoid doing
> this, we should try hard to stick with a few simple changes.
>
> Here is a proposed outline (to activate only after SegWit and with the
> currently-proposed version of SegWit):
>
> 1) The segregated witness discount is changed from 75% to 50%. The block
> size limit (ie transactions + witness/2) is set to 1.5MB. This gives a
> maximum block size of 3MB and a "network-upgraded" block size of roughly
> 2.1MB. This still significantly discounts script data which is kept out of
> the UTXO set, while keeping the maximum-sized block limited.
>
> 2) In order to prevent significant blowups in the cost to validate
> pessimistic blocks, we must place additional limits on the size of many
> non-segwit transactions. scriptPubKeys are now limited to 100 bytes in size
> and may not contain OP_CODESEPARATOR, scriptSigs must be push-only (ie no
> non-push opcodes), and transactions are only allowed to contain up to 20
> non-segwit inputs. Together these limits limit total-bytes-hashed in block
> validation to under 200MB without any possibility of making existing outputs
> unspendable and without adding additional per-block limits which make
> transaction-selection-for-mining difficult in the face of attacks or
> non-standard transactions. Though 200MB of hashing (roughly 2 seconds of
> hash-time on my high-end
> workstation) is pretty strongly centralizing, limiting transactions to fewer
> than 20 inputs seems arbitrarily low.
>
> Along similar lines, we may wish to switch MAX_BLOCK_SIGOPS from
> 1-per-50-bytes across the entire block to a per-transaction limit which is
> slightly looser (though not too much looser - even with libsecp256k1
> 1-per-50-bytes represents 2 seconds of single-threaded validation in just
> sigops on my high-end workstation).
>
> 3) Move SegWit's generic commitments from an OP_RETURN output to a second
> branch in the merkle tree. Depending on the timeline this may be something
> to skip - once there is tooling for dealing with the extra OP_RETURN output
> as a generic commitment, the small efficiency gain for applications checking
> the witness of only one transaction or checking a non-segwit commitment may
> not be worth it.
>
> 4) Instead of requiring the first four bytes of the previous block hash
> field be 0s, we allow them to contain any value. This allows Bitcoin mining
> hardware to reduce the required logic, making it easier to produce
> competitive hardware [1].
>
> I'll deliberately leave discussion of activation method out of this
> proposal. Both jl2012 and Luke-Jr recently begun some discussions about
> methods for activation on this list, and I'd love to see those continue.
> If folks think a hard fork should go ahead without SPV clients having a say,
> we could table #4, or activate #4 a year or two after 1-3 activate.
>
>
> [1] Simpler here may not be entirely true. There is potential for
> optimization if you brute force the SHA256 midstate, but if nothing else,
> this will prevent there being a strong incentive to use the version field as
> nonce space. This may need more investigation, as we may wish to just set
> the minimum difficulty higher so that we can add more than 4 nonce-bytes.
>
>
>
>
> Obviously we cannot reasonably move forward with a hard fork as long as the
> contention in the community continues. Still, I'm confident continuing to
> work towards SegWit as a 2MB-ish soft-fork in the short term with some plans
> on what a hard fork should look like if we can form broad consensus can go a
> long way to resolving much of the contention we've seen.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160208/3e8cf754/attachment.sig>

2023-06-07 17:42:10

- reply

📅 Original date posted:2015-10-01
📝 Original message:Dear list,
Mike has made a variety of false and damaging statements about Bitcoin, of which this is but one:
> On Sep 30, 2015, at 2:01 PM, Mike Hearn via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> I coined the term SPV so I know exactly what it means, and bitcoinj implements it, as does BreadWallet (the other big SPV implementation).
On his website Vinumeris.com <http://vinumeris.com/> he writes:
> Vinumeris was founded in 2014 by Mike Hearn, one of the developers of the Bitcoin digital currency system.
On plan99.net <http://plan99.net/> there are several embedded videos that refer to him a “core developer” of Bitcoin. And now it seems he is claiming to be Satoshi.
It seems to me that Mike’s emails, false statements (like the one above about coining SPV), arguments, and his attempts to steal control of Bitcoin via the contentious Bitcoin XT fork, represent actions that have been harming and dividing this community for several years now.
In many communities/tribes, there exists a line that, once crossed, results in the expulsion of a member from the community.
So, two questions:
1. Does the Bitcoin-devs mailing list have such a line?
2. If so, does the community feel that Mike Hearn has crossed it? (I personally feel he has. Multiple times.)
Thanks for your thoughts,
Greg Slepak
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150930/9fabbbf7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150930/9fabbbf7/attachment-0001.sig>