Re: [bitcoin-dev] Future of the bitcoin-dev mailing list

[Tao Effect via bitcoin-dev]

Hi, I also have faced this same problem, and here’s my solution to it:

Use the latest version of https://www.simplemachines.org/ .

This is the same forum software that powered Bitcointalk, Silk Road, etc.

It has many advantages over every other platform out there:

1. It has great anti-spam prevention tools.
2. It gives you the tools you’ve requested with respect to moderation 
(individual moderation accounts with customizable permissions).
3. It is simple to use.
4. It is pretty and well designed, and allows you to organize threads and 
forums really well (unlike Discourse).
5. It doesn’t make unnecessary use of JavaScript (unlike Discourse), and 
therefore works well with all search engines (present and future).
6. You can self-host it, and migrate it to another server if needed, allowing 
the community to maintain full control over the data (unlike Microsoft/Github).
7. It supports great search functionality.
8. It is open source, and has many community plugins.
9. It runs anywhere PHP runs.
10. It is fast.
11. It has a well established history of powering Bitcoin communities. It has 
been with us from Day 1.

After using phpBB for years, researching other forums software, I switched to 
SMF, and stuck with it. I’m happy I did so. I recommend it.

Kind regards,
Greg Slepak

> On Nov 7, 2023, at 7:37 AM, Bryan Bishop via bitcoin-dev 
>  wrote:
> 
> [moving]

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

[Tao Effect via bitcoin-dev]

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 
>  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.
>  [..]
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Boost Bitcoin circulation, Million Transactions Per Second with stronger privacy

[Tao Effect via bitcoin-dev]

Hi ZmnSCPxj & Raymo,

> On Jun 28, 2021, at 8:28 AM, ZmnSCPxj via bitcoin-dev 
>  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___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Some thoughts on removing timestamps in PoW

[Tao Effect via bitcoin-dev]

> 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  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


signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Some thoughts on removing timestamps in PoW

[Tao Effect via bitcoin-dev]

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  > 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
> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Some thoughts on removing timestamps in PoW

[Tao Effect via bitcoin-dev]

Copied from: 
https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/pull/13 



# Blockchain Timestamps Unnecessary In Proof-of-Work?

*Author: Greg Slepak ([@taoeffect@mastodon.social 
](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.



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] The DCS Theorem - theory for understanding blockchain scalability

[Tao Effect via bitcoin-dev]

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 

Cheers,
Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A DNS-like decentralized mapping for wallet addresses?

[Tao Effect via bitcoin-dev]

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 
>  > 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@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@lists.linuxfoundation.org 
> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Introducing a POW through a soft-fork

[Tao Effect via bitcoin-dev]

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 
>  > 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 
>  )
> 
> # 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
>

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

[Tao Effect via bitcoin-dev]

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  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 
>>  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  wrote:
>>> 
>>> Your method would change the number of Bitcoins in existence. Why? 
>>> 
>>> On Oct 10, 2017 12:47 PM, "Tao Effect via bitcoin-dev" 
>>>  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 
>>>>  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  wrote:
>>>>>> 
>>>>>> Haha, no. Because you "burned" the coins.
>>>>>> 
>>>>>> On Oct 10, 2017 1:20 AM, "Tao Effect"  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  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" 
>>>>>&g

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

[Tao Effect via bitcoin-dev]

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  wrote:
> 
> Your method would change the number of Bitcoins in existence. Why? 
> 
>> On Oct 10, 2017 12:47 PM, "Tao Effect via bitcoin-dev" 
>>  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 
>>>  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  wrote:
>>>>> 
>>>>> Haha, no. Because you "burned" the coins.
>>>>> 
>>>>>> On Oct 10, 2017 1:20 AM, "Tao Effect"  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  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" 
>>>>>>>  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: &q

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

[Tao Effect via bitcoin-dev]

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 
>  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  wrote:
>>> 
>>> Haha, no. Because you "burned" the coins.
>>> 
>>>> On Oct 10, 2017 1:20 AM, "Tao Effect"  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  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" 
>>>>>  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@lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>> 
>>>>> 
>>>> 
>> 
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

[Tao Effect via bitcoin-dev]

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  <mailto:truthc...@gmail.com>> wrote:
> 
> Haha, no. Because you "burned" the coins.
> 
> On Oct 10, 2017 1:20 AM, "Tao Effect"  <mailto:cont...@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 > <mailto:truthc...@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" 
>> > <mailto:bitcoin-dev@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@lists.linuxfoundation.org 
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 
>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>> 
>> 
> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

[Tao Effect via bitcoin-dev]

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.



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

[Tao Effect via bitcoin-dev]

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  <mailto:truthc...@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" 
>  <mailto:bitcoin-dev@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@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

[Tao Effect via bitcoin-dev]

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.



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

[Tao Effect via bitcoin-dev]

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 


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 
>  > 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

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

[Tao Effect via bitcoin-dev]

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  > 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].

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

[Tao Effect via bitcoin-dev]

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 

[2] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014745.html 

[3] http://www.truthcoin.info/blog/drivechain/ 

[4] 
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  > 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.. ]



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Tao Effect via bitcoin-dev]

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 
>  <mailto:bitcoin-dev@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@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Tao Effect via bitcoin-dev]

> 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  > 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  > 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 > > 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 tak

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Tao Effect via bitcoin-dev]

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  > 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
> > 
> >
> 
> 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
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Tao Effect via bitcoin-dev]

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  > 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 
> 
> 
>> 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
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Tao Effect via bitcoin-dev]

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 


--
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 
>  > 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 ther

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

[Tao Effect via bitcoin-dev]

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/
 


[2] 
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 
>  > 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 o

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

[Tao Effect via bitcoin-dev]

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  <mailto:n...@ethereum.org>> wrote:
> 
> On Wed, Jun 7, 2017 at 12:02 AM Gregory Maxwell via bitcoin-dev 
>  <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> On Tue, Jun 6, 2017 at 10:39 PM, Tao Effect via bitcoin-dev
>  <mailto:bitcoin-dev@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



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

[Tao Effect via bitcoin-dev]

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 


Cheers,
Greg Slepak

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

[Tao Effect via bitcoin-dev]

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 


--
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  > 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  > 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
>> > > wrote:
>> 
>> Due to the proposed calendar(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.
>> 
>> 
>> BIP: splitprotection
>> Layer: Consensus (soft fork)
>> Title: User Activated Soft Fork Split Protection
>> Author: James Hilliard > >
>> Comments-Summary: No comments yet.
>> Comments-URI:
>> Status: Draft
>> Type: Standards Track
>> Created: 2017-05-22
>> License: BSD-3-Clause
>>  CC0-1.0
>> 
>> 
>> ==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 ===
>> 
>> 
>> 

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

[Tao Effect via bitcoin-dev]

> Please read my email more carefully; the replay threat would be moot because 
> there would be no alternative chain to replay the TX on,

In order to *get to that point*, you need >51%.

Not only that, but, if you started out with <51%, then you need >>51% in order 
to *catch up* and replace the large number of blocks added to the legacy chain 
in the mean time.

So, since >51% is _required_ for BIP148 to succeed (and likely >>51%)... you 
might as well do as SegWit did originally, or lower the threshold to 80% or 
something (as BIP91 does).

Without replay protection at the outset, BIP148, as far as I can tell, isn't a 
threat to miners.

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

> On Jun 6, 2017, at 5:29 PM, Kekcoin  > wrote:
> 
> Please read my email more carefully; the replay threat would be moot because 
> there would be no alternative chain to replay the TX on, as the non-148 chain 
> would have been reorganized into oblivion.
> 
> 
> Sent with ProtonMail  Secure Email.
> 
>>  Original Message 
>> Subject: Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable
>> Local Time: June 7, 2017 3:26 AM
>> UTC Time: June 7, 2017 12:26 AM
>> From: cont...@taoeffect.com 
>> To: Kekcoin mailto:kekc...@protonmail.com>>
>> Anthony Towns mailto:a...@erisian.com.au>>, 
>> bitcoin-dev@lists.linuxfoundation.org 
>>  
>> > >
>> 
>> I don't know what you mean by "render the replay threat moot."
>> 
>> If you don't have replay protection, replay is always a threat. A very 
>> serious one.
>> 
>> --
>> Please do not email me anything that you are not comfortable also sharing 
>> with the NSA.
>> 
>>> On Jun 6, 2017, at 5:19 PM, Kekcoin >> > wrote:
>>> 
>>> Hmm, that's not the difference I was talking about. I was referring to the 
>>> fact that using "post-chainsplit coinbases from the non-148 chain" to 
>>> unilaterally (ie. can be done without action on the 148-chain) taint coins 
>>> is more secure in extreme-adverserial cases such as secret-mining reorg 
>>> attacks (as unfeasibly expensive they may be); the only large-scale (>100 
>>> block) reorganization the non-148 chain faces should be a resolution of the 
>>> chainsplit and therefore render the replay threat moot.
>>> 
> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

[Tao Effect via bitcoin-dev]

I don't know what you mean by "render the replay threat moot."

If you don't have replay protection, replay is always a threat. A very serious 
one.

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

> On Jun 6, 2017, at 5:19 PM, Kekcoin  > wrote:
> 
> Hmm, that's not the difference I was talking about. I was referring to the 
> fact that using "post-chainsplit coinbases from the non-148 chain" to 
> unilaterally (ie. can be done without action on the 148-chain) taint coins is 
> more secure in extreme-adverserial cases such as secret-mining reorg attacks 
> (as unfeasibly expensive they may be); the only large-scale (>100 block) 
> reorganization the non-148 chain faces should be a resolution of the 
> chainsplit and therefore render the replay threat moot.
> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] User Activated Soft Fork Split Protection

[Tao Effect via bitcoin-dev]

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 
>  > wrote:
> 
> Due to the proposed calendar(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.
> 
> 
>  BIP: splitprotection
>  Layer: Consensus (soft fork)
>  Title: User Activated Soft Fork Split Protection
>  Author: James Hilliard  >
>  Comments-Summary: No comments yet.
>  Comments-URI:
>  Status: Draft
>  Type: Standards Track
>  Created: 2017-05-22
>  License: BSD-3-Clause
>   CC0-1.0
> 
> 
> ==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 ===
> 
> 
> // 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 signallin

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

[Tao Effect via bitcoin-dev]

> You keep referring to 148 coinbase coins, what is the rationale behind this? 
> Why would you prefer using 148 coinbases over legacy coinbases for this 
> purpose?

OK, maybe "post-UASF coinbase coins" is a better term? I just wanted to make it 
clear that this refers to coins that come from blocks generated after the UASF 
is activated.

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

> On Jun 6, 2017, at 4:59 PM, Kekcoin  > wrote:
> 
> You keep referring to 148 coinbase coins, what is the rationale behind this? 
> Why would you prefer using 148 coinbases over legacy coinbases for this 
> purpose?
> 
> 
> Sent with ProtonMail  Secure Email.



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

[Tao Effect via bitcoin-dev]

> 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  > 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
> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

[Tao Effect via bitcoin-dev]

> 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 
>  <mailto:bitcoin-dev@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@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

[Tao Effect via bitcoin-dev]

> 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  <mailto:l...@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



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

[Tao Effect via bitcoin-dev]

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  <mailto:g...@xiph.org>> wrote:
> 
> On Tue, Jun 6, 2017 at 10:39 PM, Tao Effect via bitcoin-dev
>  <mailto:bitcoin-dev@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.



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

[Tao Effect via bitcoin-dev]

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 


Cheers,
Greg Slepak

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On Hardforks in the Context of SegWit

[Tao Effect via bitcoin-dev]

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  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
>  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
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On Hardforks in the Context of SegWit

[Tao Effect via bitcoin-dev]

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 
>  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-boun...@lists.linuxfoundation.org
> [mailto:bitcoin-dev-boun...@lists.linuxfoundation.org] On Behalf Of Matt
> Corallo via bitcoin-dev
> Sent: Tuesday, 9 February, 2016 03:27
> To: Bitcoin Dev 
> 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 de

[bitcoin-dev] Crossing the line? [Was: Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!]

[Tao Effect via bitcoin-dev]

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 
>  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  he writes:

> Vinumeris was founded in 2014 by Mike Hearn, one of the developers of the 
> Bitcoin digital currency system.

On 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.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev