[bitcoin-dev] Drivechain RfD -- Follow Up

[Paul Sztorc via bitcoin-dev]

Hi everyone,

It has been 3 weeks -- responses so far have been really helpful. People
jumped right in, and identified unfinished or missing parts much faster
than I thought they would (ie, ~two days). Very impressive.

Currently, we are working on the sidechain side of blind merged mining.
As you know, most of the Bitcoin cryptosystem is about finding the
longest chain, and displaying information about this chain. CryptAxe is
editing the sidechain code to handle reorganizations in a new way (an
even bigger departure than Namecoin's, imho).

I believe that I have responded to all the on-list objections that were
raised. I will 1st summarize the on-list objections, and 2nd summarize
the off-list discussion (focusing on three key themes).


On-List Objection Summary
---

In general, they were:

* Peter complained about the resources required for the BMM 'crisis
audit', I pointed out that it is actually optional (and, therefore,
free), and that it doesn't affect miners relative to each other, and
that it can be done in an ultra-cheap semi-trusted way with high
reliability.
* Peter also asked about miner incentives, I replied that it is profit
maximizing to BMM sidechains, because the equation (Tx Fees - Zero Cost)
is always positive.
* ZmnSCPxj asked a long series of clarifying questions, and I responded.
* Tier Nolan complained about my equivocation of the "Bitcoin: no block
subsidy" case and the "sidechain" case. He cites the asymmetry I point
out below (in #2). I replied, and I give an answer below.
* ZmnSCPxj pointed out an error in our OP Code (that we will fix).
* ZmnSCPxj also asked a number of new questions, I responded. Then he
responded again, in general he seemed to raise many of the points
addressed in #1 (below).
* ZmnSCPxj wanted reorg proofs, to punish reorgers, but I pointed out
that if 51% can reorg, they can also filter out the reorg proof. We are
at their mercy in all cases (for better or worse).
* ZmnSCPxj also brought up the fact that a block size limit is necessary
for a fee market, I pointed out that this limit does not need to be
imposed on miners by nodes...miners would be willing-and-able to
self-impose such a limit, as it maximizes their revenues.
* ZmnSCPxj also protested the need to soft fork in each individual
sidechain, I pointed out my strong disagreement ("Unrestrained smart
contract execution will be the death of most of the interesting
applications...[could] destabilize Bitcoin itself") and introduced my
prion metaphor.
* ZmnSCPxj and Tier Nolan both identified the problem solved by our
'ratchet' concept. I explained it to ZmnSCPxj in my reply. We had not
coded it at the time, but there is code for it now [1]. Tier proposed a
rachet design, but I think ours is better (Tier did not find ours at
all, because it is buried in obscure notes, because I didn't think
anyone would make it this far so quickly).
* Tier also advised us on how to fix the problem that ZmnSCPxj had
identified with our NOP earlier.
* Tier also had a number of suggestions about the real-time negotiation
of the OP Bribe amount between nodes and miners. I'm afraid I mostly
ignored these for now, as we aren't there yet.
* Peter complained that ACKing the sidechain could be exploited for
political reasons, and I responded that in such a case, miners are free
to simply avoid ACKing, or to acquiesce to political pressure. Neither
affect the mainchain.
* Peter complained that sidechains might provide some miners with the
opportunity to create a pretext to kick other miners off the network. I
replied that it would not, and I also brought up the fact that my
Bitcoin security model was indifferent to which people happened to be
mining at any given time. I continue to believe that "mining
centralization" does not have a useful definition.
* Peter questioned whether or not sidechains would be useful. I stated
my belief that they would be useful, and linked to my site
(drivechain.info/projects) which contains a number of sidechain
use-cases, and cited my personal anecdotal experiences.
* Peter wanted to involve miners "as little as possible", I pointed out
that I felt that I had indeed done this minimization. My view is that
Peter felt erroneously that it was possible to involve miners less,
because he neglected [1] that a 51% miner group is already involved
maximally, as they can create most messages and filter any message, and
[2] that there are cases where we need miners to filter out harmful
interactions among multiple chains (just as they filter out harmful
interactions among multiple txns [ie, "double spends"]). Peter has not
yet responded to this rebuttal.
* Peter also suggested client-side validation as "safer", and I pointed
out that sidechains+BMM _is_ client-side validation. I asked Peter for
CS-V code, so that we can compare the safety and other features.
* Sergio reminded us of his version of drivechain. Sergio and I disagree
over the emphasis on frequency/speed of withdrawals. Also S

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] Drivechain RfD -- Follow Up

[Paul Sztorc via bitcoin-dev]

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.

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.

We might draw a comparison between:

1. Classic Theft   -- A majority hashrate reorganizes the main Bitcoin
chain to double-spend funds (or coordinate with someone who is
double-spending). This is prevented/discouraged by waiting for many
confirmations.
2. Channel Theft -- A majority hashrate assists a Lightning-Network
thief, by censoring the punitive audit txn (possibly by exploiting some
excuse regarding fullness of blocks, or possibly induced to do so by the
thief provably splitting the proceeds with miners). This is
prevented/discouraged by using lengthy custodial periods, paying high
fees with your attacker's money, and using fungibility/non-communication
to interact with miners as little as possible (so as to frame LN-theft
as undermining the entire LN system, and not merely a single tragedy).
3. Drivechain Theft -- A majority hashrate initiates an unrepresentative
withdrawal from some sidechain. This is prevented/discouraged by only
using 'popular' sidechains (those that [a] increase the usefulness
("market price") of bitcoin, and [b] generate tx fees for miners). It is
also discouraged by the fact that egregious theft would probably end the
sidechain experiment, meaning that all present and future sidechains
would be forever unavailable (and unable to buoy the price or the tx
revenues).

I do not think that any of the three stands out as being categorically
worse than the others, especially when we consider the heterogeneity of
use-cases and preferences. As Luke-Jr has been pointing out on social
media recently, the very group which is more associated with miners (and
explicitly more willing to trust them, ie Bitcoin Unlimited et al),
happens to be the same group that would be expected to make use of a
LargeBlock drivechain. Some can argue that one type of security is more
"cryptographic" than others, but I think this is misguided (how many
'bits' of security does each have?) -- imho, all three security models
are 'game theoretic' (neither computer scientific, nor cryptographic).

More importantly, before a miner has any "control" over the sidechain
coins, users must voluntarily agree to subject themselves to these new
rules. This is similar to how an arbitrary piece of (open source)
software can have "total" control over your computer...if you choose to
install it.

> Thus the effect of Drivechain appears to be the creation of a new kind
> of digital border imposed onto the network ...

I'm not sure it would "create a border", given that sidechains are
currently not accessible at all. If anything drivechain cuts a door into
an existing impassible border.

>  ... where everyone hands over ownership of their Bitcoins to a
> /single/ mining cartel when they wish to interact with /any/ sidechain.

The qualifier "/any/ sidechain" would seem to imply that there is a way
to do sidechains that does not involve handing over some control to 51%
hashrate...I think this is false (even in the fabled case of ZK-SNARKS).
The first thing I do in the drivechain spec (
truthcoin.info/blog/drivechain ) is explain why.

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

Yes, but money could also be confiscated from _any_ Bitcoin users
(Chinese or otherwise) using any of the three methods I mentioned above.
And confiscation could strike Chinese Bitcoin users if they decided to
sell their Bitcoin for Chinese Yuan, which they then deposited in a
Chinese bank. Or if they sold their Bitcoin for an Altcoin controlled by
the Chinese govt in some other way.

It is not up to the members of this list to decide, USSR style, what
other people are allowed to do with their own money.

The exceptions to this rule would be (ie, "bitcoin-dev should care about
what users are doing when..."):

1. [Unreasonable use of Reviewer Time]  The user's use-case is either
nonexistent (ie "no one wants that"), or totally unachievable ("we can't
do that") thus rendering the conversation a complete waste of time /
reviewer attention.
2. [Harmful Interference] The user's use-case would impose harm on some
existing use-case(s).

No reasonable person will claim the first, given today's scaling debate
(not to mention

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

[Paul Sztorc via bitcoin-dev]

Hi Erik,

As you know:

1. If a sidechain is merged mined it basically grows out of the existing
Bitcoin mining network. If it has a different PoW algorithm it is a new
mining network.
2. The security (ie, hashrate) of any mining network would be determined
by the total economic value of the block. In Bitcoin this is
(subsidy+tx_fees)*price, but since a sidechain cannot issue new tokens
it would only be (tx_fees)*price.

Unfortunately the two have a nasty correlation which can lead to a
disastrous self-fulfilling prophecy: users will avoid a network that is
too insecure; and if users avoid using a network, they will stop paying
txn fees and so the quantity (tx_fees)*price falls toward zero, erasing
the network's security. So it is quite problematic and I recommend just
biting the bullet and going with merged mining instead.

And, the point may be moot. Bitcoin miners may decide that, given their
expertise in seeking out cheap sources of power/cooling, they might as
well mine both/all chains. So your suggestion may not achieve your
desired result (and would, meanwhile, consume more of the economy's
resources -- some of these would not contribute even to a higher hashrate).

Paul



On 6/19/2017 1:11 PM, Erik Aronesty wrote:
> It would be nice to be able to enforce that a drivechain *not* have
> the same POW as bitcoin.
>
> I suspect this is the only way to be sure that a drivechain doesn't
> destabilize the main chain and push more power to miners that already
> have too much power.
>
>
> On Mon, Jun 19, 2017 at 12:04 PM, Paul Sztorc via bitcoin-dev
>  > 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.
>
> 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.
>
> We might draw a comparison between:
>
> 1. Classic Theft   -- A majority hashrate reorganizes the main Bitcoin
> chain to double-spend funds (or coordinate with someone who is
> double-spending). This is prevented/discouraged by waiting for many
> confirmations.
> 2. Channel Theft -- A majority hashrate assists a Lightning-Network
> thief, by censoring the punitive audit txn (possibly by exploiting
> some
> excuse regarding fullness of blocks, or possibly induced to do so
> by the
> thief provably splitting the proceeds with miners). This is
> prevented/discouraged by using lengthy custodial periods, paying high
> fees with your attacker's money, and using
> fungibility/non-communication
> to interact with miners as little as possible (so as to frame LN-theft
> as undermining the entire LN system, and not merely a single tragedy).
> 3. Drivechain Theft -- A majority hashrate initiates an
> unrepresentative
> withdrawal from some sidechain. This is prevented/discouraged by only
> using 'popular' sidechains (those that [a] increase the usefulness
> ("market price") of bitcoin, and [b] generate tx fees for miners).
> It is
> also discouraged by the fact that egregious theft would probably
> end the
> sidechain experiment, meaning that all present and future sidechains
> would be forever unavailable (and unable to buoy the price or the tx
> revenues).
>
> I do not think that any of the three stands out as being categorically
> worse than the others, especially when we consider the
> heterogeneity of
> use-cases and preferences. As Luke-Jr has been pointing out on social
> media recently, the very group which is more associated with
> miners (and
> explicitly more willing to trust them, ie Bitcoin Unlimited et al),
> happens to be the same group that would be expected to make use of a
> LargeBlock drivechain. Some can argue that one type of security is
> more
> "cryptographic" than others, but I think this is misguided (how many
> 'bits' of security does each have?) -- imho, all three security models
> are 'game theoretic' (neither computer scientific, nor cryptographic).
>
> More importantly, before a miner has any "control" over the sidechain
> coins, users must voluntarily agree to subject themselves to these new
> rules. This is similar to how an arbitrary piece of (open source)
> software can have "total" control over your computer...if you
> choose to
> install it.
>
> > Thus the effect of Drivechain appears to be the creation of a
> new kind
> > of digital border imposed o

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

[Erik Aronesty via bitcoin-dev]

- a proof-of-burn sidechain is the ultimate two-way peg.   you have to burn
bitcoin *or* side-chain tokens to mine the side chain.   the size of the
burn is the degree of security.i actually wrote code to do randomized
blind burns where you have a poisson distribution (non-deterministic
selected burn).there is no way to game it... it's very similar to
algorand - but it uses burns instead of staking

- you can then have a secure sidechain that issues a mining reward in
sidechain tokens, which can be aggrregated and redeemed for bitcoins.   the
result of this is that any bitcoins held in the sidechain depreciate in
value at a rate of X% per year.   this deflation rate pays for increased
security

- logically this functions like an alt coin, with high inflation and cheap
transactions.   but the altcoin is pegged to bitcoin's price because of the
pool of unredeemed bitcoins held within the side chain.



On Tue, Jun 20, 2017 at 7:54 AM, Paul Sztorc  wrote:

> Hi Erik,
>
> As you know:
>
> 1. If a sidechain is merged mined it basically grows out of the existing
> Bitcoin mining network. If it has a different PoW algorithm it is a new
> mining network.
> 2. The security (ie, hashrate) of any mining network would be determined
> by the total economic value of the block. In Bitcoin this is
> (subsidy+tx_fees)*price, but since a sidechain cannot issue new tokens it
> would only be (tx_fees)*price.
>
> Unfortunately the two have a nasty correlation which can lead to a
> disastrous self-fulfilling prophecy: users will avoid a network that is too
> insecure; and if users avoid using a network, they will stop paying txn
> fees and so the quantity (tx_fees)*price falls toward zero, erasing the
> network's security. So it is quite problematic and I recommend just biting
> the bullet and going with merged mining instead.
>
> And, the point may be moot. Bitcoin miners may decide that, given their
> expertise in seeking out cheap sources of power/cooling, they might as well
> mine both/all chains. So your suggestion may not achieve your desired
> result (and would, meanwhile, consume more of the economy's resources --
> some of these would not contribute even to a higher hashrate).
>
> Paul
>
>
>
>
> On 6/19/2017 1:11 PM, Erik Aronesty wrote:
>
> It would be nice to be able to enforce that a drivechain *not* have the
> same POW as bitcoin.
>
> I suspect this is the only way to be sure that a drivechain doesn't
> destabilize the main chain and push more power to miners that already have
> too much power.
>
>
> On Mon, Jun 19, 2017 at 12:04 PM, Paul Sztorc via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> 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.
>>
>> 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.
>>
>> We might draw a comparison between:
>>
>> 1. Classic Theft   -- A majority hashrate reorganizes the main Bitcoin
>> chain to double-spend funds (or coordinate with someone who is
>> double-spending). This is prevented/discouraged by waiting for many
>> confirmations.
>> 2. Channel Theft -- A majority hashrate assists a Lightning-Network
>> thief, by censoring the punitive audit txn (possibly by exploiting some
>> excuse regarding fullness of blocks, or possibly induced to do so by the
>> thief provably splitting the proceeds with miners). This is
>> prevented/discouraged by using lengthy custodial periods, paying high
>> fees with your attacker's money, and using fungibility/non-communication
>> to interact with miners as little as possible (so as to frame LN-theft
>> as undermining the entire LN system, and not merely a single tragedy).
>> 3. Drivechain Theft -- A majority hashrate initiates an unrepresentative
>> withdrawal from some sidechain. This is prevented/discouraged by only
>> using 'popular' sidechains (those that [a] increase the usefulness
>> ("market price") of bitcoin, and [b] generate tx fees for miners). It is
>> also discouraged by the fact that egregious theft would probably end the
>> sidechain experiment, meaning that all present and future sidechains
>> would be forever unavailable (and unable to buoy the price or the tx
>> revenues).
>>
>> I do not think that any of the three stands out as being categorically
>> worse than the others, especially when we consider the heterogeneity of
>> use-cases and preferences. As Luke-Jr has been pointing out on social
>> media recently, the very group which is more associated with miners (and
>> explicitly more willing to trust them, ie Bitco

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

[Paul Sztorc via bitcoin-dev]

Hi Erik,

I don't think that your design is competitive. Why would users tolerate
a depreciation of X% per year, when there are alternatives which do not
require such depreciation? It seems to me that none would.

Paul

On 6/20/2017 9:38 AM, Erik Aronesty wrote:
> - a proof-of-burn sidechain is the ultimate two-way peg.   you have to
> burn bitcoin *or* side-chain tokens to mine the side chain.   the size
> of the burn is the degree of security.i actually wrote code to do
> randomized blind burns where you have a poisson distribution
> (non-deterministic selected burn).there is no way to game it...
> it's very similar to algorand - but it uses burns instead of staking
>
> - you can then have a secure sidechain that issues a mining reward in
> sidechain tokens, which can be aggrregated and redeemed for bitcoins.
>   the result of this is that any bitcoins held in the sidechain
> depreciate in value at a rate of X% per year.   this deflation rate
> pays for increased security
>
> - logically this functions like an alt coin, with high inflation and
> cheap transactions.   but the altcoin is pegged to bitcoin's price
> because of the pool of unredeemed bitcoins held within the side chain.
>
>
>
> On Tue, Jun 20, 2017 at 7:54 AM, Paul Sztorc  > wrote:
>
> Hi Erik,
>
> As you know:
>
> 1. If a sidechain is merged mined it basically grows out of the
> existing Bitcoin mining network. If it has a different PoW
> algorithm it is a new mining network.
> 2. The security (ie, hashrate) of any mining network would be
> determined by the total economic value of the block. In Bitcoin
> this is (subsidy+tx_fees)*price, but since a sidechain cannot
> issue new tokens it would only be (tx_fees)*price.
>
> Unfortunately the two have a nasty correlation which can lead to a
> disastrous self-fulfilling prophecy: users will avoid a network
> that is too insecure; and if users avoid using a network, they
> will stop paying txn fees and so the quantity (tx_fees)*price
> falls toward zero, erasing the network's security. So it is quite
> problematic and I recommend just biting the bullet and going with
> merged mining instead.
>
> And, the point may be moot. Bitcoin miners may decide that, given
> their expertise in seeking out cheap sources of power/cooling,
> they might as well mine both/all chains. So your suggestion may
> not achieve your desired result (and would, meanwhile, consume
> more of the economy's resources -- some of these would not
> contribute even to a higher hashrate).
>
> Paul
>
>
>
>
> On 6/19/2017 1:11 PM, Erik Aronesty wrote:
>> It would be nice to be able to enforce that a drivechain *not*
>> have the same POW as bitcoin.
>>
>> I suspect this is the only way to be sure that a drivechain
>> doesn't destabilize the main chain and push more power to miners
>> that already have too much power.
>>
>>
>
>

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

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

[Erik Aronesty via bitcoin-dev]

Users would tolerate depreciation because the intention is to have a cheap
way of transacting using a two-way pegged chain that isn't controlled by
miners.   Who cares about some minor depreciation when the purpose of the
chain is to do cheap secure transactions forever?

Add in UTXO commitments and you've got a system that is cheap and
secure-enough for transfer. storage and accumulation of a ledger... before
moving in to the main chain.

Seems better to me than messing with the main chain's incentive structure
via merged mining.


On Thu, Jun 22, 2017 at 9:27 AM, Paul Sztorc  wrote:

> Hi Erik,
>
> I don't think that your design is competitive. Why would users tolerate a
> depreciation of X% per year, when there are alternatives which do not
> require such depreciation? It seems to me that none would.
>
> Paul
>
> On 6/20/2017 9:38 AM, Erik Aronesty wrote:
>
> - a proof-of-burn sidechain is the ultimate two-way peg.   you have to
> burn bitcoin *or* side-chain tokens to mine the side chain.   the size of
> the burn is the degree of security.i actually wrote code to do
> randomized blind burns where you have a poisson distribution
> (non-deterministic selected burn).there is no way to game it... it's
> very similar to algorand - but it uses burns instead of staking
>
> - you can then have a secure sidechain that issues a mining reward in
> sidechain tokens, which can be aggrregated and redeemed for bitcoins.   the
> result of this is that any bitcoins held in the sidechain depreciate in
> value at a rate of X% per year.   this deflation rate pays for increased
> security
>
> - logically this functions like an alt coin, with high inflation and cheap
> transactions.   but the altcoin is pegged to bitcoin's price because of the
> pool of unredeemed bitcoins held within the side chain.
>
>
>
> On Tue, Jun 20, 2017 at 7:54 AM, Paul Sztorc  wrote:
>
>> Hi Erik,
>>
>> As you know:
>>
>> 1. If a sidechain is merged mined it basically grows out of the existing
>> Bitcoin mining network. If it has a different PoW algorithm it is a new
>> mining network.
>> 2. The security (ie, hashrate) of any mining network would be determined
>> by the total economic value of the block. In Bitcoin this is
>> (subsidy+tx_fees)*price, but since a sidechain cannot issue new tokens it
>> would only be (tx_fees)*price.
>>
>> Unfortunately the two have a nasty correlation which can lead to a
>> disastrous self-fulfilling prophecy: users will avoid a network that is too
>> insecure; and if users avoid using a network, they will stop paying txn
>> fees and so the quantity (tx_fees)*price falls toward zero, erasing the
>> network's security. So it is quite problematic and I recommend just biting
>> the bullet and going with merged mining instead.
>>
>> And, the point may be moot. Bitcoin miners may decide that, given their
>> expertise in seeking out cheap sources of power/cooling, they might as well
>> mine both/all chains. So your suggestion may not achieve your desired
>> result (and would, meanwhile, consume more of the economy's resources --
>> some of these would not contribute even to a higher hashrate).
>>
>> Paul
>>
>>
>>
>>
>> On 6/19/2017 1:11 PM, Erik Aronesty wrote:
>>
>> It would be nice to be able to enforce that a drivechain *not* have the
>> same POW as bitcoin.
>>
>> I suspect this is the only way to be sure that a drivechain doesn't
>> destabilize the main chain and push more power to miners that already have
>> too much power.
>>
>>
>>
>>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Paul Sztorc via bitcoin-dev]

Responses inline.

On 6/22/2017 9:45 AM, Erik Aronesty wrote:
> Users would tolerate depreciation because the intention is to have a
> cheap way of transacting using a two-way pegged chain that isn't
> controlled by miners.  Who cares about some minor depreciation when
> the purpose of the chain is to do cheap secure transactions forever?

Thus far you've claimed that these transactions would be "cheap", "[not]
controlled by miners", and "secure".

They would certainly not be cheap, because they are relatively more
expensive due to the extra depreciation cost.

I also doubt that they would be free of control by miners. 51% hashrate
can always filter out any message they want from anywhere.

For the same reason, I don't understand why they would be any more or
less secure.

So I think your way is just a more expensive way of accomplishing
basically the same result.

>
> Add in UTXO commitments and you've got a system that is cheap and
> secure-enough for transfer. storage and accumulation of a ledger...
> before moving in to the main chain.

As I posted to bitcoin-discuss last week, I support UTXO commitments for
sidechains.

> Seems better to me than messing with the main chain's incentive
> structure via merged mining.

I don't think that blind merged mining messes with the main chain's
incentive structure. Miners are free to ignore the sidechain (and yet
still get paid the same as other miners), as are all mainchain users.

Paul
>
> On Thu, Jun 22, 2017 at 9:27 AM, Paul Sztorc  > wrote:
>
> Hi Erik,
>
> I don't think that your design is competitive. Why would users
> tolerate a depreciation of X% per year, when there are
> alternatives which do not require such depreciation? It seems to
> me that none would.
>
> Paul
>
> On 6/20/2017 9:38 AM, Erik Aronesty wrote:
>> - a proof-of-burn sidechain is the ultimate two-way peg.   you
>> have to burn bitcoin *or* side-chain tokens to mine the side
>> chain.   the size of the burn is the degree of security.i
>> actually wrote code to do randomized blind burns where you have a
>> poisson distribution (non-deterministic selected burn).there
>> is no way to game it... it's very similar to algorand - but it
>> uses burns instead of staking
>>
>> - you can then have a secure sidechain that issues a mining
>> reward in sidechain tokens, which can be aggrregated and redeemed
>> for bitcoins.   the result of this is that any bitcoins held in
>> the sidechain depreciate in value at a rate of X% per year.  
>> this deflation rate pays for increased security
>>
>> - logically this functions like an alt coin, with high inflation
>> and cheap transactions.   but the altcoin is pegged to bitcoin's
>> price because of the pool of unredeemed bitcoins held within the
>> side chain.
>>
>>
>>
>> On Tue, Jun 20, 2017 at 7:54 AM, Paul Sztorc > > wrote:
>>
>> Hi Erik,
>>
>> As you know:
>>
>> 1. If a sidechain is merged mined it basically grows out of
>> the existing Bitcoin mining network. If it has a different
>> PoW algorithm it is a new mining network.
>> 2. The security (ie, hashrate) of any mining network would be
>> determined by the total economic value of the block. In
>> Bitcoin this is (subsidy+tx_fees)*price, but since a
>> sidechain cannot issue new tokens it would only be
>> (tx_fees)*price.
>>
>> Unfortunately the two have a nasty correlation which can lead
>> to a disastrous self-fulfilling prophecy: users will avoid a
>> network that is too insecure; and if users avoid using a
>> network, they will stop paying txn fees and so the quantity
>> (tx_fees)*price falls toward zero, erasing the network's
>> security. So it is quite problematic and I recommend just
>> biting the bullet and going with merged mining instead.
>>
>> And, the point may be moot. Bitcoin miners may decide that,
>> given their expertise in seeking out cheap sources of
>> power/cooling, they might as well mine both/all chains. So
>> your suggestion may not achieve your desired result (and
>> would, meanwhile, consume more of the economy's resources --
>> some of these would not contribute even to a higher hashrate).
>>
>> Paul
>>
>>
>>
>>
>> On 6/19/2017 1:11 PM, Erik Aronesty wrote:
>>> It would be nice to be able to enforce that a drivechain
>>> *not* have the same POW as bitcoin.
>>>
>>> I suspect this is the only way to be sure that a drivechain
>>> doesn't destabilize the main chain and push more power to
>>> miners that already have too much power.
>>>
>>>
>>
>>
>
>

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

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

[Erik Aronesty via bitcoin-dev]

> They would certainly not be cheap, because they are relatively more
expensive due to the extra depreciation cost.

This depends on how long you expect to keep money on a side chain and how
many transactions you plan on doing.   Inflation is a great way of paying
PoS / PoB  miners - that cannot introduce issues with consolidation.   If
you design the inflation schedule correctly, it should be balance
transaction costs *precisely*.   Indeed, you can calculate the exact amount
of inflation needed to guarantee that a side chain is always exactly 10
times cheaper than bitcoin.

>As I posted to bitcoin-discuss last week, I support UTXO commitments for
sidechains.

Indeed, I think side chain nodes should always be fast-synced from 6 month
old commitments and thus be ephemeral, cheap, and *never *appropriate for
long term storage.  This would provide the best possible incentive
structure to keep the main chain secure, paid for with high clearing fees,
etc.

> I don't think that blind merged mining messes with the main chain's
incentive structure

The critical issue is that we cannot introduce protocol changes that
*further *incentivize geographical and institutional consolidation.  Miners
who are able to deal with the bandwidth caused by drivechain coffee
transactions will profit from these transactions, whereas smaller and more
geographically distributed miners will not.   Those miners will, in turn,
build faster ASICs and buy more electricity and drive out smaller players.
  I think this is *abundantly *clear, and is the primary motivation behind
preserving block size limits.

If this premise is false (which it may be), or is skewed so as to damage
bitcoin as a whole (could be as well), then that needs to be demonstrated
*first*.

The lightning model does the opposite of this.   Miners watch fees increase
and coming from an *orthoganal* protocol that cannot cause further
centralization.

One problem is that the main chain also *must* grow in response to
bandwidth, or the disadvantages of using the main chain will weaken
financial support and hashrate securing it.   I believe this is also true,
and that a "balancing act" will be Bitcoin's norm until we adopt something
like BIP103 - which provides a steady and appropriate growth.





On Thu, Jun 22, 2017 at 4:30 PM, Paul Sztorc  wrote:

> Responses inline.
>
> On 6/22/2017 9:45 AM, Erik Aronesty wrote:
>
> Users would tolerate depreciation because the intention is to have a cheap
> way of transacting using a two-way pegged chain that isn't controlled by
> miners.  Who cares about some minor depreciation when the purpose of the
> chain is to do cheap secure transactions forever?
>
>
> Thus far you've claimed that these transactions would be "cheap", "[not]
> controlled by miners", and "secure".
>
> They would certainly not be cheap, because they are relatively more
> expensive due to the extra depreciation cost.
>
> I also doubt that they would be free of control by miners. 51% hashrate
> can always filter out any message they want from anywhere.
>
> For the same reason, I don't understand why they would be any more or less
> secure.
>
> So I think your way is just a more expensive way of accomplishing
> basically the same result.
>
>
> Add in UTXO commitments and you've got a system that is cheap and
> secure-enough for transfer. storage and accumulation of a ledger... before
> moving in to the main chain.
>
>
> As I posted to bitcoin-discuss last week, I support UTXO commitments for
> sidechains.
>
> Seems better to me than messing with the main chain's incentive structure
> via merged mining.
>
>
> I don't think that blind merged mining messes with the main chain's
> incentive structure. Miners are free to ignore the sidechain (and yet still
> get paid the same as other miners), as are all mainchain users.
>
> Paul
>
>
> On Thu, Jun 22, 2017 at 9:27 AM, Paul Sztorc  wrote:
>
>> Hi Erik,
>>
>> I don't think that your design is competitive. Why would users tolerate a
>> depreciation of X% per year, when there are alternatives which do not
>> require such depreciation? It seems to me that none would.
>>
>> Paul
>>
>> On 6/20/2017 9:38 AM, Erik Aronesty wrote:
>>
>> - a proof-of-burn sidechain is the ultimate two-way peg.   you have to
>> burn bitcoin *or* side-chain tokens to mine the side chain.   the size of
>> the burn is the degree of security.i actually wrote code to do
>> randomized blind burns where you have a poisson distribution
>> (non-deterministic selected burn).there is no way to game it... it's
>> very similar to algorand - but it uses burns instead of staking
>>
>> - you can then have a secure sidechain that issues a mining reward in
>> sidechain tokens, which can be aggrregated and redeemed for bitcoins.   the
>> result of this is that any bitcoins held in the sidechain depreciate in
>> value at a rate of X% per year.   this deflation rate pays for increased
>> security
>>
>> - logically this functions like an alt coin, with high inflatio

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

[Moral Agent via bitcoin-dev]

>Miners who are able to deal with the bandwidth caused by drivechain coffee
transactions will profit from these transactions, whereas smaller and more
geographically distributed miners will not.   Those miners will, in turn,
build faster ASICs and buy more electricity and drive out smaller players.

I think you are conflating 3 different (though overlapping) groups:

1. Block header generators. These need 'good internet' meaning very low
latency, reasonable bandwidth, good place in network (e.g. FIBRE or mining
backbone). They need reliable computers with enough RAM and CPU to validate
prior blocks promptly and immediately assemble new blocks.

2. Hashers. These need cheap electricity, access to economical uses of
waste heat, cheap mining hardware. e.g. IOT electric water heater.

3. ASIC manufacturers. These need lots of capital, etc.

It might be helpful to keep these three groups distinct in your mind and
conversation, and to use the protocol as a crowbar to pry them into
separate people, or at a minimum make it economically possible to
participate in one role without needing to participate in the other two. If
different, geographically and politically dispersed groups are helping
perform these functions, it aids decentralization.

On Fri, Jun 23, 2017 at 10:19 AM, Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > They would certainly not be cheap, because they are relatively more
> expensive due to the extra depreciation cost.
>
> This depends on how long you expect to keep money on a side chain and how
> many transactions you plan on doing.   Inflation is a great way of paying
> PoS / PoB  miners - that cannot introduce issues with consolidation.   If
> you design the inflation schedule correctly, it should be balance
> transaction costs *precisely*.   Indeed, you can calculate the exact amount
> of inflation needed to guarantee that a side chain is always exactly 10
> times cheaper than bitcoin.
>
> >As I posted to bitcoin-discuss last week, I support UTXO commitments for
> sidechains.
>
> Indeed, I think side chain nodes should always be fast-synced from 6 month
> old commitments and thus be ephemeral, cheap, and *never *appropriate for
> long term storage.  This would provide the best possible incentive
> structure to keep the main chain secure, paid for with high clearing fees,
> etc.
>
> > I don't think that blind merged mining messes with the main chain's
> incentive structure
>
> The critical issue is that we cannot introduce protocol changes that
> *further *incentivize geographical and institutional consolidation.
> Miners who are able to deal with the bandwidth caused by drivechain coffee
> transactions will profit from these transactions, whereas smaller and more
> geographically distributed miners will not.   Those miners will, in turn,
> build faster ASICs and buy more electricity and drive out smaller players.
>   I think this is *abundantly *clear, and is the primary motivation
> behind preserving block size limits.
>
> If this premise is false (which it may be), or is skewed so as to damage
> bitcoin as a whole (could be as well), then that needs to be demonstrated
> *first*.
>
> The lightning model does the opposite of this.   Miners watch fees
> increase and coming from an *orthoganal* protocol that cannot cause further
> centralization.
>
> One problem is that the main chain also *must* grow in response to
> bandwidth, or the disadvantages of using the main chain will weaken
> financial support and hashrate securing it.   I believe this is also true,
> and that a "balancing act" will be Bitcoin's norm until we adopt something
> like BIP103 - which provides a steady and appropriate growth.
>
>
>
>
>
> On Thu, Jun 22, 2017 at 4:30 PM, Paul Sztorc  wrote:
>
>> Responses inline.
>>
>> On 6/22/2017 9:45 AM, Erik Aronesty wrote:
>>
>> Users would tolerate depreciation because the intention is to have a
>> cheap way of transacting using a two-way pegged chain that isn't controlled
>> by miners.  Who cares about some minor depreciation when the purpose of the
>> chain is to do cheap secure transactions forever?
>>
>>
>> Thus far you've claimed that these transactions would be "cheap", "[not]
>> controlled by miners", and "secure".
>>
>> They would certainly not be cheap, because they are relatively more
>> expensive due to the extra depreciation cost.
>>
>> I also doubt that they would be free of control by miners. 51% hashrate
>> can always filter out any message they want from anywhere.
>>
>> For the same reason, I don't understand why they would be any more or
>> less secure.
>>
>> So I think your way is just a more expensive way of accomplishing
>> basically the same result.
>>
>>
>> Add in UTXO commitments and you've got a system that is cheap and
>> secure-enough for transfer. storage and accumulation of a ledger... before
>> moving in to the main chain.
>>
>>
>> As I posted to bitcoin-discuss last week, I support UTXO commitments for
>> sidechains.
>>

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

[Paul Sztorc via bitcoin-dev]

On 6/23/2017 10:19 AM, Erik Aronesty wrote:
> > They would certainly not be cheap, because they are relatively more 
> > expensive due to the
> extra depreciation cost.
>
> If you design the inflation schedule correctly, it should be balance
> transaction costs *precisely*.

You have not explained how your scheme would cause a relative decrease
in transaction costs. The way I see it, tx costs would be exactly the
same, so it would in fact be impossible to design an inflation schedule
to "balance" these costs (other than inflation of zero as I suggest).

>
> > I don't think that blind merged mining messes with the main chain's
> incentive structure 
>
> Miners who are able to deal with the bandwidth caused by drivechain
> coffee transactions
There is no additional bandwidth requirement. That is the point of BMM.
They do not even need to run a sidechain node (to be paid just as much
as if they had).

--Paul



>
> On Thu, Jun 22, 2017 at 4:30 PM, Paul Sztorc  > wrote:
>
> Responses inline.
>
> On 6/22/2017 9:45 AM, Erik Aronesty wrote:
>> Users would tolerate depreciation because the intention is to
>> have a cheap way of transacting using a two-way pegged chain that
>> isn't controlled by miners.  Who cares about some minor
>> depreciation when the purpose of the chain is to do cheap secure
>> transactions forever?
>
> Thus far you've claimed that these transactions would be "cheap",
> "[not] controlled by miners", and "secure".
>
> They would certainly not be cheap, because they are relatively
> more expensive due to the extra depreciation cost.
>
> I also doubt that they would be free of control by miners. 51%
> hashrate can always filter out any message they want from anywhere.
>
> For the same reason, I don't understand why they would be any more
> or less secure.
>
> So I think your way is just a more expensive way of accomplishing
> basically the same result.
>
>>
>> Add in UTXO commitments and you've got a system that is cheap and
>> secure-enough for transfer. storage and accumulation of a
>> ledger... before moving in to the main chain.
>
> As I posted to bitcoin-discuss last week, I support UTXO
> commitments for sidechains.
>
>> Seems better to me than messing with the main chain's incentive
>> structure via merged mining.
>
> I don't think that blind merged mining messes with the main
> chain's incentive structure. Miners are free to ignore the
> sidechain (and yet still get paid the same as other miners), as
> are all mainchain users.
>
> Paul
>>
>> On Thu, Jun 22, 2017 at 9:27 AM, Paul Sztorc > > wrote:
>>
>> Hi Erik,
>>
>> I don't think that your design is competitive. Why would
>> users tolerate a depreciation of X% per year, when there are
>> alternatives which do not require such depreciation? It seems
>> to me that none would.
>>
>> Paul
>>
>> On 6/20/2017 9:38 AM, Erik Aronesty wrote:
>>> - a proof-of-burn sidechain is the ultimate two-way peg.  
>>> you have to burn bitcoin *or* side-chain tokens to mine the
>>> side chain.   the size of the burn is the degree of
>>> security.i actually wrote code to do randomized blind
>>> burns where you have a poisson distribution
>>> (non-deterministic selected burn).there is no way to
>>> game it... it's very similar to algorand - but it uses burns
>>> instead of staking
>>>
>>> - you can then have a secure sidechain that issues a mining
>>> reward in sidechain tokens, which can be aggrregated and
>>> redeemed for bitcoins.   the result of this is that any
>>> bitcoins held in the sidechain depreciate in value at a rate
>>> of X% per year.   this deflation rate pays for increased
>>> security
>>>
>>> - logically this functions like an alt coin, with high
>>> inflation and cheap transactions.   but the altcoin is
>>> pegged to bitcoin's price because of the pool of unredeemed
>>> bitcoins held within the side chain.
>>>
>>>
>>>
>>> On Tue, Jun 20, 2017 at 7:54 AM, Paul Sztorc
>>> mailto:truthc...@gmail.com>> wrote:
>>>
>>> Hi Erik,
>>>
>>> As you know:
>>>
>>> 1. If a sidechain is merged mined it basically grows out
>>> of the existing Bitcoin mining network. If it has a
>>> different PoW algorithm it is a new mining network.
>>> 2. The security (ie, hashrate) of any mining network
>>> would be determined by the total economic value of the
>>> block. In Bitcoin this is (subsidy+tx_fees)*price, but
>>> since a sidechain cannot issue new tokens it would only
>>> be (tx_fees)*price.
>>>
>>> Unfortunately the two have a nasty c

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] Drivechain RfD -- Follow Up

[Paul Sztorc via bitcoin-dev]

The confusion below stems from his conflation of several different ideas.

I will try to explicitly clarify a distinction between several types of
user (or, "modes" of use if you prefer):

[DC#0] -- Someone who does not upgrade their Bitcoin software (and is
running, say, 0.13). However, they experience the effects of the new
rules which miners add (as per the soft fork[s] to add drivechain
functionality and individual drivechains).
[DC#1] -- Someone who always upgrades to the latest version of the
Bitcoin software, but otherwise has no interest in running/using sidechains.
[DC#2] -- Someone who upgrades to the latest Bitcoin version, and
decides to also become a full node of one or more sidechains, but who
ever actually uses the sidechains.
[DC#3] -- Someone who upgrades their software, runs sidechain full
nodes, and actively moves money to and from these.


On 7/12/2017 6:43 PM, Tao Effect wrote:
>
> I am now looking closer again at step number 4 in the Drivechain
> specification [2]:
>
> 4. Everyone waits for a period of, say, 3 days. This gives
> everyone an opportunity to make sure the same WT^ is in both the
> Bitcoin coinbase and the Sidechain header. If they’re different,
> everyone has plenty of time to contact each other, figure out what
> is going on, and restart the process until its right.
>
> It seems to me that where our disagreement lies is in this point.
> The Drivechain spec seems to claim that its use of anyone-can-pay is
> the same as P2SH (and in later emails you reference SegWit as well).
> Is this really true?
FYI that document is nearly two years old, and although it is still
overwhelmingly accurate, new optimizations allow us (I think) to push
the waiting period to several weeks and the total ACK counting period up
to several months.

[DC#0] Yes
[DC#1] Yes
[DC#2] Yes
[DC#3] Yes

Because if a node doesn't have the sidechain's information, it will just
assume every withdrawal is valid. This is comparable to someone who
still hasn't upgraded to support P2SH, in cases [DC#0] and [#1].

(And this is the main advantage of DC over extension blocks).


> 2. Per the question in [1], it's my understanding that P2SH
> transactions contain all of the information within themselves for full
> nodes to act as a check on miners mishandling the anyone-can-spend
> nature of P2SH transactions. However, that does not seem to be the
> case with WT^ transactions.
[DC#0] They do.
[DC#1] They do.
[DC#2] They do.
[DC#3] They do.

Again, from the perspective of a mainchain user, every withdrawal is valid.


> In P2SH txns, there is no need for anyone to, as the Drivechain spec
> says, "to contact each other, figure out what is going on". Everything
> just automatically works.
There is no *need* to this in Drivechain, either, for [DC#0] or [DC#1].

[DC#2] and [DC#3] would certainly have an interest in understanding what
is going on, but that has absolutely nothing whatsoever to do with
Bitcoin Core and so is off-topic for this mailing list.


> If the security of WT^ transactions could be brought up to actually be
> in line with the security of P2SH and SegWit transactions, then I
> would have far less to object to.
Somehow I doubt it.


Paul
___
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]

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

[Paul Sztorc via bitcoin-dev]

I will repeat that Drivechain can sometimes be confusing because it is
different things to different people.

Here is my attempt to break it down into different modes:

[DC#0] -- Someone who does not upgrade their Bitcoin software (and is
running, say, 0.13). However, they experience the effects of the new
rules which miners add (as per the soft fork[s] to add drivechain
functionality and individual drivechains).
[DC#1] -- Someone who always upgrades to the latest version of the
Bitcoin software, but otherwise has no interest in running/using sidechains.
[DC#2] -- Someone who upgrades to the latest Bitcoin version, and
decides to also become a full node of one or more sidechains, but who
ever actually uses the sidechains.
[DC#3] -- Someone who upgrades their software, runs sidechain full
nodes, and actively moves money to and from these.

Greg is still conflating modes [DC#1] and [DC#3]. Specifically, he
equivocates on the team "steal", using it to mean two different things:
[a] spending an invalid transaction, and [b] a withdrawal that would not
match the report given by a sidechain node.

The two are quite different, see my comments below:


On 7/12/2017 9:15 PM, Tao Effect wrote:
>> FYI that document is nearly two years old, and although it is still
>> overwhelmingly accurate, new optimizations allow us (I think) to push
>> the waiting period to several weeks and the total ACK counting period
>> up to several months.
> What does that have to do with my question? The counting period, if I
> understood correctly, is something miners do, not full nodes.

Greg quoted a passage that contained an older parameter estimate of "a
few days", and I thought it would be helpful and informative if I
clarified that the parameter estimate had been updated to a new (more
secure) value.

In point of fact, he is wrong, because nodes do the counting. When
miners find a block, they can choose to move the counter up, down, or
not at all. But nodes do the counting.


> Also, if the document is old and/or outdated, do you happen to have a
> link to a more update-to-date version of the spec? It would be helpful
> for review.

As I stated above, the document is mostly accurate. There is no other
more up to date version.


>> Because if a node doesn't have the sidechain's information, it will
>> just assume every withdrawal is valid. This is comparable to someone
>> who still hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
>
> Right, for [DC#0] and [DC#1], but for [DC#2] an [DC#3] you marked it
> as "Yes" without substantiating why you did so.


Above, Greg omitted his original question. For reference, it was:

>  The Drivechain spec seems to claim that its use of anyone-can-pay is the 
> same as P2SH

The answer is that both DC and P2SH use transactions which are 'always
valid' to some group of people (un-upgraded users) but which are
sometimes invalid to new users. So the only difference would be for
[DC#0] vs other versions, but this difference is trivial as miners will
censor invalid txns.

It is your classic soft fork situation.


>> Again, from the perspective of a mainchain user, every withdrawal is
>> valid.
> And that is not how P2SH works.

Again, keep in mind that Greg continually conflates two different things:
1. Whether the soft fork rules have been followed, and
2. Whether the WT^ submitted by a majority hashrate matches the one
calculated by sidechain nodes.

The first case is exactly equal to P2SH. Just as old nodes accept every
P2SH transaction, so too will [DC#0] users accept every WT^ transaction.

In the second case, it so happens that [DC#1], [DC#2], and [DC#3] would
also accept any WT^ *that followed the Drivechain rules*, even if they
did not like the outcome (because the outcome in question was
arbitrarily designated as a "theft" of funds -- again, see the second
case in the list above). In this way, it is exactly similar to P2SH
because nodes will accept *any* p2sh txn **that follows the p2sh
rules**, even if they don't "like" the specific script contained within
(for example, because it is a theft of "their" BitFinex funds, or a
donation to a political candidate they dislike, etc).


>> [DC#2] and [DC#3] would certainly have an interest in understanding
>> what is going on, but that has absolutely nothing whatsoever to do
>> with Bitcoin Core and so is off-topic for this mailing list.
> How is that an answer to my question?

Greg is, of course, not entitled to an answer to irrelevant questions --
just as he would not be entitled to an answer if he asked for my
favorite color or my home address. And such answers would needlessly
consume the mailing list's scarce time.


> What does "[DC#2] and [DC#3] would certainly have an interest in
> understanding what is going on" mean?

It is clear to me that, if we are not clear on the basics first, we
cannot hope to tackle anything intermediate. We will come back to this
after clearing up soft fork part.


> In P2SH, all upgraded nodes will reject inva

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

[Hampus Sjöberg via bitcoin-dev]

In softforks, I would argue that 100% of all nodes and miners need to
upgrade to the new rules.
This makes sure that trying to incorrectly spend an "AnyOneCanSpend" will
result in a hardfork, instead of a temporary (or permanent) chainsplit.

With drivechains, it seems like the current plan is to only let the nodes
that are interested in the drivechain validate the other chain, and not
necessarily 100% of the network.
I guess this could be any percentage of the network, which could lead to a
temporary/permanent chainsplit depending on how many percentage of the
miners are also validating the other chain (am I missing something here?).

I have no way to evaluate if this is an okay trade-off.
It seems like major disruption could very likely happen if say only 5% of
all fullnodes validate the drivechain.

To be fully secure, it seems like 100% of all nodes should also have a
fullnode for the drivechain as well...
This is one of the reasons I don't advocate sidechains/drivechains as a
scaling solution, it looks like it would have to the same outcome as a
blocksize increase on the mainchain, but with more complexity.
I think sidechains/drivechains could be useful for other things though.


Thanks for all your work so far Paul.
Hampus

2017-07-13 4:58 GMT+02:00 Paul Sztorc via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> I will repeat that Drivechain can sometimes be confusing because it is
> different things to different people.
>
> Here is my attempt to break it down into different modes:
>
> [DC#0] -- Someone who does not upgrade their Bitcoin software (and is
> running, say, 0.13). However, they experience the effects of the new rules
> which miners add (as per the soft fork[s] to add drivechain functionality
> and individual drivechains).
> [DC#1] -- Someone who always upgrades to the latest version of the Bitcoin
> software, but otherwise has no interest in running/using sidechains.
> [DC#2] -- Someone who upgrades to the latest Bitcoin version, and decides
> to also become a full node of one or more sidechains, but who ever actually
> uses the sidechains.
> [DC#3] -- Someone who upgrades their software, runs sidechain full nodes,
> and actively moves money to and from these.
>
> Greg is still conflating modes [DC#1] and [DC#3]. Specifically, he
> equivocates on the team "steal", using it to mean two different things: [a]
> spending an invalid transaction, and [b] a withdrawal that would not match
> the report given by a sidechain node.
>
> The two are quite different, see my comments below:
>
>
> On 7/12/2017 9:15 PM, Tao Effect wrote:
>
> FYI that document is nearly two years old, and although it is still
> overwhelmingly accurate, new optimizations allow us (I think) to push the
> waiting period to several weeks and the total ACK counting period up to
> several months.
>
> What does that have to do with my question? The counting period, if I
> understood correctly, is something miners do, not full nodes.
>
>
> Greg quoted a passage that contained an older parameter estimate of "a few
> days", and I thought it would be helpful and informative if I clarified
> that the parameter estimate had been updated to a new (more secure) value.
>
> In point of fact, he is wrong, because nodes do the counting. When miners
> find a block, they can choose to move the counter up, down, or not at all.
> But nodes do the counting.
>
>
> Also, if the document is old and/or outdated, do you happen to have a link
> to a more update-to-date version of the spec? It would be helpful for
> review.
>
>
> As I stated above, the document is mostly accurate. There is no other more
> up to date version.
>
>
> Because if a node doesn't have the sidechain's information, it will just
> assume every withdrawal is valid. This is comparable to someone who still
> hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
>
>
> Right, for [DC#0] and [DC#1], but for [DC#2] an [DC#3] you marked it as
> "Yes" without substantiating why you did so.
>
>
>
> Above, Greg omitted his original question. For reference, it was:
>
>  The Drivechain spec seems to claim that its use of anyone-can-pay is the 
> same as P2SH
>
>
> The answer is that both DC and P2SH use transactions which are 'always
> valid' to some group of people (un-upgraded users) but which are sometimes
> invalid to new users. So the only difference would be for [DC#0] vs other
> versions, but this difference is trivial as miners will censor invalid txns.
>
> It is your classic soft fork situation.
>
>
> Again, from the perspective of a mainchain user, every withdrawal is valid.
>
> And that is not how P2SH works.
>
>
> Again, keep in mind that Greg continually conflates two different things:
> 1. Whether the soft fork rules have been followed, and
> 2. Whether the WT^ submitted by a majority hashrate matches the one
> calculated by sidechain nodes.
>
> The first case is exactly equal to P2SH. Just as old nodes accept every
> P2SH transaction, so too will [DC#0] users acc

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

[Paul Sztorc via bitcoin-dev]

Greg is still conflating two different usages of the word "theft":
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.

In his message he claims to uniquely adopt definition #2, saying
(emphasis added):

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

...however, he revokes that commitment below when it suits his purposes.

Since Greg's message is probably too confusing to be helpful, I will
first clarify both cases:

Case 1 -- soft fork rules -- all "invalid_1" txns are regarded as
"theft_1" and are rejected.
Case 2 -- sidechain's unique consensus rules -- all WT^ are accepted (if
these WT^ are valid_1 under the Case 1 rules), whether they match the
sidechain's reported WT^ or not (in other words, whether they are
valid_2 or not).

In Case 2, the mainchain accepts all WT^ transactions as "valid", in
that they can be included in a block, whether or not they are
"valid_2".  By design, sidechains make no effort to validate the rules
specific to each sidechain, just as they make no effort to validate the
rules of Altcoins. In this way, a WT^ transaction is comparable to
someone who is selling an Altcoin to purchase some Bitcoin -- Bitcoin
doesn't care how they got the Altcoin.


On 7/12/2017 11:24 PM, Tao Effect wrote:
> 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

To be clear: yes, Greg did get it confused.

And it is very important, because a neglect of the node-enforced rules
is a neglect of **both** theft_1 and theft_2 simultaneously, making it
easier to conflate the both of them as Greg is still doing.


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


This is the instance I mentioned above -- despite committing to only
discussing theft_2, Greg has secretly switched back to theft_1, when he
talks about a "P2SH script...used for the purpose of facilitating theft".

Under theft_2, there is no way to infer the theft-ness of the
transaction from the script itself. For example, if someone made a
2-of-3 multisig with a third party escrow , and these funds were
"stolen", this would be an example of funds "stolen" from a P2SH under
"theft_2".

At which point Greg would angrily say that whoever wrote P2SH was
reckless and...allowed Bitcoins to be "stolen". Or perhaps he would
switch definitions yet again, and say that "that doesn't count as
theft". blah blah blah yada yada yada

It is true that moving from pre-P2SH to post-P2SH has not --yet--
enabled any theft_2 as a result. But P2SH has also failed to enable
sidechains. Sidechains logically must open the door to theft_2, else
they will regress to the undesirable cases of hard/evil fork (as I
explain in the spec). Empirically, we do not know how much theft_2 will
be enabled by drivechain. Theoretically, it is possible that there will
never be a theft_2 on drivechain.


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

I do not affirm the latter. The SPV proofs in DC are very important, as
they are what allow nodes to enforce the delayed withdrawal upon miners.
In fact, this is exactly what Greg admits to being confused about above.
He is correct that he is confused.

Experts including Adam Back (co-author of original sidechains paper, CEO
of Blockstream which started the sidechains conversation) have publicly
stated that they share my belief that this delayed withdrawal technique
is likely to mitigate the threat of theft_2. Greg S is free to hold a
different op

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

[Paul Sztorc via bitcoin-dev]

Hello,


On 7/13/2017 9:17 AM, Hampus Sjöberg wrote:
> In softforks, I would argue that 100% of all nodes and miners need to
> upgrade to the new rules.
> This makes sure that trying to incorrectly spend an "AnyOneCanSpend"
> will result in a hardfork, instead of a temporary (or permanent)
> chainsplit.
>
> With drivechains, it seems like the current plan is to only let the
> nodes that are interested in the drivechain validate the other chain,
> and not necessarily 100% of the network.

Correct.


> I guess this could be any percentage of the network, which could lead
> to a temporary/permanent chainsplit depending on how many percentage
> of the miners are also validating the other chain (am I missing
> something here?).
> I have no way to evaluate if this is an okay trade-off.
> It seems like major disruption could very likely happen if say only 5%
> of all fullnodes validate the drivechain.


You are correct that some % of the network would be validating both
chains. However, if miners improperly withdraw from a sidechain, it --by
design-- does not lead to any chainsplit of any kind. Instead, the
sidechain in question just dies a painful death (notice that, if any
withdrawals are improper, it is quite as bad as if all of the sidechain
funds were withdrawn improperly -- this is because the sidechain would
instantly have a bunch of problems, including that it would be
something-like 'fractional reserve' which would lead to an immediate
bank run of withdrawals [none of which could have any real expectation
of success, in my view]).

In practice, a concern of mine is that people *would* try to turn a
sidechain-theft even into some kind of grand UASF-style campaign. I
would prefer for people not to do this. Then again, I do not hold this
preference unconditionally -- I see it as comparable to Bitcoin's
commitment to "the code is the spec". Which is to say that this
commitment is overwhelmingly held, but not dogmatically as in
exceptional cases such as theValue overflow incident [1].

I think that in such ambiguous cases, we must rely on [a] the miner's
desire to maximize the purchasing power of each Bitcoin, and [b] the
technical wisdom of Bitcoin's future leaders in helping miners to
achieve this goal.

[1] https://en.bitcoin.it/wiki/Value_overflow_incident


> To be fully secure, it seems like 100% of all nodes should also have a
> fullnode for the drivechain as well...

Perhaps, but this is exactly what I am trying to avoid. The design goal,
in some sense, is to have "half security", ie <100%. This is because the
only way to achieve "full" 100% security is with full enforcement of all
rules. Full enforcement of the rules, in turn, means either that we are
exactly where we are right now (where we only add compatible rules, aka
the traditional "soft fork") or we are [also] exactly where we are right
now (in that if we add an incompatible rule, it results in a "hard
fork"). I would like to build something new, which trades off on the
qualities of each, and therefore lies (intentionally) somewhere in between.


> This is one of the reasons I don't advocate sidechains/drivechains as
> a scaling solution, it looks like it would have to the same outcome as
> a blocksize increase on the mainchain, but with more complexity.

Keep in mind that, if some people leave the small chain (what you might
call the "Core" chain, although some disagree with summarizing it this
way) for some other chain, it does free up more space on this chain.

I'm not really sure the extent to which that "counts" as increasing
capacity.

Also, I agree that sc/dc do not help with "scalability", if that problem
is defined as "better technology" or as "how to do more with less".

Actually my full view is a little nuanced and it is here:
http://www.drivechain.info/faq/index.html#can-sidechains-really-help-with-scaling


> Thanks for all your work so far Paul.

You're welcome!

Paul



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