Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Chris Stewart via bitcoin-dev]

>
> Since the sidechain has the sidechain BMM headers that they want the LD
> (bribe) data for, I think that they could specifically request LD data
> relevant only to that sidechain by providing a list of hashes to the
> mainchain, and the mainchain can return a list of boolean values telling
> the sidechain if the LD data exists. That way the data never even has to
> go over the network, just a verification that it exists on the mainchain
> and
>

Since you seem to be talking about the initial block download process for
the drivechain. It seems that we might as well request the set of *valid*
blocks from a bitcoin peer first, since at the end of the day they are in
control of the mining process on the sidechain. Here is what I envision:

   1. Request all hashes for sidechain from a bitcoin peer
   2. Request all sidechain block header's for the hashes the bitcoin peer
   gave us
   3. Order the set of sidechain block headers by looking at hashPrevBlock.
   4. Request full sidechain blocks and start validating against the
   consensus rule set of the sidechain


we can drop the sidechain_id from the script.

I agree the 'sidechain_id' is unneeded in the coinbase tx output. We should
just fix these based on index. This should be reflected in my latest commit
if we are talking about the same thing:
https://github.com/Christewart/bitcoin/blob/c355e39fbe2ea48856ea86b25cb8a97710feb032/src/script/script.cpp#L254


and have the sidechain handle filtering out invalid LD data /
> only requesting the verification of LD data that they know to be valid
> as far as chain order goes.
>

 I agree, the whole point of BMM is to have bitcoin miners indifferent to
what happens in the sidechain (although Paul argues in a wonky way they do
care sort of). If there is an invalid (in the sense the block it represents
does *not* follow the sidechain's consensus rule set) OP_BRIBEVERIFY that
pays *more* money than a valid OP_BRIBEVERIFY output, we need to assume
that a 'blind' bitcoin miner will choose the one that pays them the most
money.

>I might be wrong but I thought that OP_RETURN outputs do not go into the
UTXO set. Anyone else want to chime in?

I'm fairly certain you are right. It just feels like we should be able to
exploit the fact that *only* miners can claim these OP_BRIBEVERIFY outputs.
I'll have to think about this more, maybe some one else can come up with
something clever that exploits that fact.

On Mon, Jun 19, 2017 at 10:24 AM, Chris Stewart  wrote:

> Since the sidechain has the sidechain BMM headers that they want the LD
>> (bribe) data for, I think that they could specifically request LD data
>> relevant only to that sidechain by providing a list of hashes to the
>> mainchain, and the mainchain can return a list of boolean values telling
>> the sidechain if the LD data exists. That way the data never even has to
>> go over the network, just a verification that it exists on the mainchain
>> and
>>
>
> Since you seem to be talking about the initial block download process for
> the drivechain. It seems that we might as well request the set of *valid*
> blocks from a bitcoin peer first, since at the end of the day they are in
> control of the mining process on the sidechain. Here is what I envision:
>
>1. Request all hashes for sidechain from a bitcoin peer
>2. Request all sidechain block header's for the hashes the bitcoin
>peer gave us
>3. Order the set of sidechain block headers by looking at
>hashPrevBlock.
>4. Request full sidechain blocks and start validating against the
>consensus rule set of the sidechain
>
>
> we can drop the sidechain_id from the script.
>
> I agree the 'sidechain_id' is unneeded in the coinbase tx output. We
> should just fix these based on index. This should be reflected in my latest
> commit if we are talking about the same thing: https://github.com/
> Christewart/bitcoin/blob/c355e39fbe2ea48856ea86b25cb8a9
> 7710feb032/src/script/script.cpp#L254
>
>
> and have the sidechain handle filtering out invalid LD data /
>> only requesting the verification of LD data that they know to be valid
>> as far as chain order goes.
>>
>
>  I agree, the whole point of BMM is to have bitcoin miners indifferent to
> what happens in the sidechain (although Paul argues in a wonky way they do
> care sort of). If there is an invalid (in the sense the block it represents
> does *not* follow the sidechain's consensus rule set) OP_BRIBEVERIFY that
> pays *more* money than a valid OP_BRIBEVERIFY output, we need to assume
> that a 'blind' bitcoin miner will choose the one that pays them the most
> money.
>
> >I might be wrong but I thought that OP_RETURN outputs do not go into the
> UTXO set. Anyone else want to chime in?
>
> I'm fairly certain you are right. It just feels like we should be able to
> exploit the fact that *only* miners can claim these OP_BRIBEVERIFY outputs.
> I'll have to think about this more, maybe some one else can come up with
> 

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[CryptAxe via bitcoin-dev]

> >OP_RETURN  
>
> I think it is redundant here to have the , we can
> implicitly assume what the sidechain_id is since we have a fixed set
> of drivechains. I.e. mining reward is index 0, mimblewimble sidechain
> is index 1, etc. CryptAxe has specific indexes defined already in his
> implementation: 
> https://github.com/drivechain-project/bitcoin/blob/mainchainBMM/src/sidechain.h#L26-L30.
>

Since the sidechain has the sidechain BMM headers that they want the LD
(bribe) data for, I think that they could specifically request LD data
relevant only to that sidechain by providing a list of hashes to the
mainchain, and the mainchain can return a list of boolean values telling
the sidechain if the LD data exists. That way the data never even has to
go over the network, just a verification that it exists on the mainchain
and we can drop the sidechain_id from the script.


> I think it would be wise to include a version byte to allow us to
> upgrade this commitment structure in the future. Similar to how
> witness program's are now versioned.

Agreed, we need that.


>
> >   OP_BRIBE_VERIFY
>
> If  is an argument that OP_BRIBE_VERIFY takes, doesn't
> that mean the mainchain miner has to validate this *is* the actual
> block height on the sidechain? Does that take the 'blindness' away
> from BMM?

No, OP_BRIBE (the old version) didn't care about the block height. Where
the blockheight was relevant is when bribe data is added to LD. In order
to be added to LD, the bribe needed to either be a fork (block height
less than the sidechain tip height) or extending the current side-chain
(block height = sidechain tip height + 1). The goal of this was to allow
for reorgs, and also make it so that people cannot skip forward (which
would never be valid so it's a waste of time and space) so that the
sidechain makes progress. With the new design that we have been talking
about, I think that we will need to drop this requirement from the
mainchain, and have the sidechain handle filtering out invalid LD data /
only requesting the verification of LD data that they know to be valid
as far as chain order goes.


>
> Overall, I think we need to work on the commitment structure to the
> coinbase tx.

Agreed. It might be helpful if you outlined the idea you had on IRC to
the mailing list.


> If I understand the current implementation correctly we can have up to
> 256 OP_RETURNs embedded in the coinbase tx signifying new blocks mined
> on drivechains.. this seems less than ideal. It might be prudent to
> make these outputs ANYONECANSPEND, and then have miners spending these
> outputs to themselves for every block mined.. maybe this doesn't have
> a benefit over using OP_RETURNs though?
>
> The structure could be something like:
>  
>
> and then in a subsequent block the miner spends that output to
> themselves. I will admit I'm not super familiar with how OP_RETURNs
> work with the UTXO set -- maybe this scheme doesn't have any benefit.
>
> -Chris

I might be wrong but I thought that OP_RETURN outputs do not go into the
UTXO set. Anyone else want to chime in?





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

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Chris Stewart via bitcoin-dev]

>OP_RETURN  

I think it is redundant here to have the , we can implicitly
assume what the sidechain_id is since we have a fixed set of drivechains.
I.e. mining reward is index 0, mimblewimble sidechain is index 1, etc.
CryptAxe has specific indexes defined already in his implementation:
https://github.com/drivechain-project/bitcoin/blob/mainchainBMM/src/sidechain.h#L26-L30
.

I think it would be wise to include a version byte to allow us to upgrade
this commitment structure in the future. Similar to how witness program's
are now versioned.

>   OP_BRIBE_VERIFY

If  is an argument that OP_BRIBE_VERIFY takes, doesn't that
mean the mainchain miner has to validate this *is* the actual block height
on the sidechain? Does that take the 'blindness' away from BMM?

Overall, I think we need to work on the commitment structure to the
coinbase tx. If I understand the current implementation correctly we can
have up to 256 OP_RETURNs embedded in the coinbase tx signifying new blocks
mined on drivechains.. this seems less than ideal. It might be prudent to
make these outputs ANYONECANSPEND, and then have miners spending these
outputs to themselves for every block mined.. maybe this doesn't have a
benefit over using OP_RETURNs though?

The structure could be something like:
 

and then in a subsequent block the miner spends that output to themselves.
I will admit I'm not super familiar with how OP_RETURNs work with the UTXO
set -- maybe this scheme doesn't have any benefit.

-Chris

On Wed, May 24, 2017 at 3:50 AM, Tier Nolan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tue, May 23, 2017 at 3:22 PM, Paul Sztorc  wrote:
>
>>
>> If you haven't seen http://www.truthcoin.info/blog/drivechain/ , that is
>> probably the most human-readable description.
>>
>
> I guess I was looking for the detail you get in the code, but without
> having to read the code.
>
> My quick reading gives that the sidechain codes (critical hashes) are
> added when a coinbase is processed.
>
> Any coinbase output that has the form "OP_RETURN <32 byte push>" counts as
> a potential critical hash.
>
> When the block is processed, the key value pair (hash, block_height) is
> added to a hash map.
>
> The OP_BRIBE opcode checks that the given hash is in the hash map and
> replaces the top element on the stack with the pass/fail result.
>
> It doesn't even check that the height matches the current block, though
> there is a comment that that is a TODO.
>
> I agree with ZmnSCPxj, when updating a nop, you can't change the stack.
> It has to fail the script or do nothing.
>
> OP_BRIBE_VERIFY would cause the script to fail if the hash wasn't in the
> coinbase, or cause a script failure otherwise.
>
> Another concern is that you could have multiple bribes for the same chain
> in a single coinbase.  That isn't fair and arguably what the sidechain
> miner is paying for is to get his hash exclusively into the block.
>
> I would suggest that the output is
>
> OP_RETURN  
>
> Then add the rule that only the first hash with a particular sidechain id
> actually counts.
>
> This forces the miner to only accept the bribe from 1 miner for each
> sidechain for each block.  If he tries to accept 2, then only the first one
> counts.
>
> OP_BRIBE_VERIFY could then operate as follows
>
>OP_BRIBE_VERIFY
>
> This causes the script to fail if
>does not match the block height, or
>is not the hash for the sidechain with , or
>   there is no hash for that sidechain in the block's coinbase
>
> If you want reduce the number of drops, you could serialize the info into
> a single push.
>
> This has the advantage that a sidechain miner only has to pay if his block
> is accepted in the next bitcoin block.  Since he is the only miner for that
> sidechain that gets into the main bitcoin block, he is pretty much
> guaranteed to form the longest chain.
>
> Without that rule, sidechain miners could end up having to pay even though
> it doesn't make their chain the longest.
>
> How are these transactions propagated over the network?  For relaying, you
> could have the rule that the opcode passes as long as  is
> near the current block height.  Maybe require that they are in the future.
> They should be removed from the memory pool once the block height has
> arrived, so losing miners can re-spend those outputs.
>
> This opcode can be validated without needing to look at other blocks,
> which is good for validating historical blocks.
>
> I am still looking at the deposit/withdrawal code.
>
> ___
> 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] Drivechain -- Request for Discussion

[Paul Sztorc via bitcoin-dev]

Hi Sergio / everyone,

As some of you may know, Sergio and I each did an implementation of
drivechain. I started working on mine, and he started working on his,
and then I didn't hear from him for awhile about what he was doing.

Anyways, with two versions, we each have an opportunity to double-check
our work. For example, this already happened wrt the "ACK size". Let me
share from his linked BIP:

"By allowing miners to refer to transaction candidates by
transaction id prefixes, the space consumption for a single ack can be
as low as 2 bytes."

Sergio shared this with me last October at Scaling Milan. After
listening to him, we saw an opportunity to improve our design: now, our
miners can conjecture that miners will grant ACKs in a few simple ways
[always honest, honest+ignore some, ignore all], and it will precompute
these possibilities (guessing what rival miners will do, even before
they find and broadcast a new block). Therefore, in all honest cases,
our ACK-counting now requires zero (0) bytes to be sent over the
network. In dishonest cases it requires only a few bits per sidechain,
because we also maintain a deterministically ordered list, both of
sidechains and withdrawal attempts -- therefore it can just be a string
of binary information. This is not part of consensus, and so can be
further improved over time.

I'm sure there are still a few opportunities for mutual improvements
going forward.

In general, Sergio and I disagree over the withdrawal-frequency. a major
difference of opinion is over the withdrawal-frequency. I view
infrequent withdrawal as essential to the security model, but Sergio
does not. In both our designs, the withdrawal-time is configurable, but
Sergio's design seems to be optimized for cases with frequent withdrawal
attempts, whereas mine is optimized for cases with very infrequent
withdrawal attempts.

Another difference is that, as a direct result of earlier peer review, I
have been integrating 'blind merged mining' into my version. It may be
easy for Sergio to add BMM to his version, or it may not.

It is true that I am not interested in the hybrid model. I would not
make use of the multisig / centralized part, and so for me it
complicates the security properties for no benefit. I see why some
people are interested in it, though.

Paul



On 6/9/2017 5:54 PM, Sergio Demian Lerner wrote:
> I'm a bit late to this party. I just want to add that there exists an
> hybrid model where both a federation and the miners provide acknowledges
> (sometimes known as "votes" in drivechain terms and "multi-signatures"
> in a federation) of the sidechain state.
> 
> My Drivechain proposal (Feb 2016) was tailored to enable this particular
> use-case, which I'm not sure Paul's proposal enable.
> 
> 
> The proposal is on this list under the following subject: Drivechain
> proposal using OP_COUNT_ACKS
> 
> BIP (draft):
> https://github.com/rootstock/bips/blob/master/BIP-R10.md
> 
> 
> Code & Test cases:
> https://github.com/rootstock/bitcoin/tree/op-count-acks_devel
> 
> 
> In this proposal, the "poll" time is sidechain-configurable, and I
> proposed a few days delay was enough. 
> Some have said that a longer times are needed, such as 2 months.  
> So if you want to have a 2 month dalay for sidechain->mainchain
> transfers in this code, you still can. However a better dynamic cache of
> acks/nacks would be needed. However, for the hybrid use-case, one day is
> more than enough.
> 
> Regards
> 
> 
> 
> 
> On Tue, May 30, 2017 at 2:11 AM, Paul Sztorc via bitcoin-dev
>  > wrote:
> 
> Hi Peter,
> 
> Responses below.
> 
> On 5/28/2017 5:07 PM, Peter Todd wrote:
> > On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wrote:
> >> Surprisingly, this requirement (or, more precisely, this incentive) 
> does
> >> not effect miners relative to each other. The incentive to upgrade is 
> only
> >> for the purpose of preventing a "theft" -- defined as: an improper
> >> withdrawal from a sidechain. It is not about miner revenues or the 
> ability
> >> to mine generally (or conduct BMM specifically). The costs of such a 
> theft
> >> (decrease in market price, decrease in future transaction fee levels) 
> would
> >> be shared collectively by all future miners. Therefore, it would have 
> no
> >> effect on miners relative to each other.
> >
> > That's not at all true. If I'm a miner with a better capability than 
> another
> > miner to prevent that theft, I have reasons to induce it to happen to 
> give me
> > political cover to pushing that other miner off the network.
> 
> Miners can abstain from 'voting', which is politically neutral. Or, if
> they wish, smaller miners could acquiesce to the coercion and just copy
> the 

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Sergio Demian Lerner via bitcoin-dev]

I'm a bit late to this party. I just want to add that there exists an
hybrid model where both a federation and the miners provide acknowledges
(sometimes known as "votes" in drivechain terms and "multi-signatures" in a
federation) of the sidechain state.

My Drivechain proposal (Feb 2016) was tailored to enable this particular
use-case, which I'm not sure Paul's proposal enable.


The proposal is on this list under the following subject: Drivechain
proposal using OP_COUNT_ACKS

BIP (draft):
https://github.com/rootstock/bips/blob/master/BIP-R10.md

Code & Test cases:
https://github.com/rootstock/bitcoin/tree/op-count-acks_devel

In this proposal, the "poll" time is sidechain-configurable, and I proposed
a few days delay was enough.
Some have said that a longer times are needed, such as 2 months.
So if you want to have a 2 month dalay for sidechain->mainchain transfers
in this code, you still can. However a better dynamic cache of acks/nacks
would be needed. However, for the hybrid use-case, one day is more than
enough.

Regards




On Tue, May 30, 2017 at 2:11 AM, Paul Sztorc via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Peter,
>
> Responses below.
>
> On 5/28/2017 5:07 PM, Peter Todd wrote:
> > On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wrote:
> >> Surprisingly, this requirement (or, more precisely, this incentive) does
> >> not effect miners relative to each other. The incentive to upgrade is
> only
> >> for the purpose of preventing a "theft" -- defined as: an improper
> >> withdrawal from a sidechain. It is not about miner revenues or the
> ability
> >> to mine generally (or conduct BMM specifically). The costs of such a
> theft
> >> (decrease in market price, decrease in future transaction fee levels)
> would
> >> be shared collectively by all future miners. Therefore, it would have no
> >> effect on miners relative to each other.
> >
> > That's not at all true. If I'm a miner with a better capability than
> another
> > miner to prevent that theft, I have reasons to induce it to happen to
> give me
> > political cover to pushing that other miner off the network.
>
> Miners can abstain from 'voting', which is politically neutral. Or, if
> they wish, smaller miners could acquiesce to the coercion and just copy
> the votes of the attacking 51% group. For users who are only running
> Bitcoin Core, there is nothing bad about that.
>
> As you say, a 51% group can arbitrarily start orphaning the blocks that
> are mined by non-member rivals. This _may_ be a problem, or it may not,
> but it is not exacerbated by drivechain.
>
> So, what exactly is "not at all true"?
>
>
> >
> > This is a very similar problem to what we had with zeroconf
> double-spending,
> > where entities such as Coinbase tried to pay off miners to guarantee
> something
> > that wasn't possible in a geninely decrentralized system: safe zeroconf
> > transactions.
>
> I don't see what you mean here. You can't stop Coinbase from donating
> BTC to a subset of miners. That will always be possible, and it has
> nothing to do with drivechain (as I see it).
>
>
> >
> >> Moreover, miners have other recourse if they are unable to run the node.
> >> They can adopt a policy of simply rejecting ("downvoting") any
> withdrawals
> >> that they don't understand. This would pause the withdraw process until
> >> enough miners understand enough of what is going on to proceed with it.
> >
> > Why are you forcing miners to run this code at all?
>
> Could we not say the same thing about the code behind CLTV?
>
> The nature of a contract, is that people are happier to be bound by some
> rules that they themselves construct (for example, a nuclear
> non-proliferation treaty).
>
> In this case, miners prefer sidechains to exist (as existence makes the
> BTC they mine more valuable, and provides additional tx fee revenues),
> and so they would like to run code which makes them possible.
>
>
> >
> > Equally, you're opening up miners to huge political risks, as rejecting
> all
> > withdrawals is preventing users' from getting their money, which gives
> other
> > miners a rational for kicking those miners off of Bitcoin entirely.
>
> As I explained above, miners can abstain from voting, which is
> politically neutral, or else they can delegate their vote to an
> aggressive miner. The "51% can orphan" concern could be raised, even in
> a world without drivechain. All that is required, is for the miners to
> be anonymous, or in private 'dark' pools (and to thereby escape censure).
>
> But there is a much bigger issue here, which is that our threat models
> are different.
>
> As you may know, my threat model [1] does not include miners "pushing
> each other off". It only cares about the miner-experience, to the extent
> that it impacts the user-experience.
>
> Moreover, I reject [2] the premise that we can even measure "miner
> centralization", or even that such a concept exists. If someone has a
> definition of this concept, which is 

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Paul Sztorc via bitcoin-dev]

Hi Peter,

Responses below.

On 5/28/2017 5:07 PM, Peter Todd wrote:
> On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wrote:
>> Surprisingly, this requirement (or, more precisely, this incentive) does
>> not effect miners relative to each other. The incentive to upgrade is only
>> for the purpose of preventing a "theft" -- defined as: an improper
>> withdrawal from a sidechain. It is not about miner revenues or the ability
>> to mine generally (or conduct BMM specifically). The costs of such a theft
>> (decrease in market price, decrease in future transaction fee levels) would
>> be shared collectively by all future miners. Therefore, it would have no
>> effect on miners relative to each other.
> 
> That's not at all true. If I'm a miner with a better capability than another
> miner to prevent that theft, I have reasons to induce it to happen to give me
> political cover to pushing that other miner off the network.

Miners can abstain from 'voting', which is politically neutral. Or, if
they wish, smaller miners could acquiesce to the coercion and just copy
the votes of the attacking 51% group. For users who are only running
Bitcoin Core, there is nothing bad about that.

As you say, a 51% group can arbitrarily start orphaning the blocks that
are mined by non-member rivals. This _may_ be a problem, or it may not,
but it is not exacerbated by drivechain.

So, what exactly is "not at all true"?


> 
> This is a very similar problem to what we had with zeroconf double-spending,
> where entities such as Coinbase tried to pay off miners to guarantee something
> that wasn't possible in a geninely decrentralized system: safe zeroconf
> transactions.

I don't see what you mean here. You can't stop Coinbase from donating
BTC to a subset of miners. That will always be possible, and it has
nothing to do with drivechain (as I see it).


> 
>> Moreover, miners have other recourse if they are unable to run the node.
>> They can adopt a policy of simply rejecting ("downvoting") any withdrawals
>> that they don't understand. This would pause the withdraw process until
>> enough miners understand enough of what is going on to proceed with it.
> 
> Why are you forcing miners to run this code at all?

Could we not say the same thing about the code behind CLTV?

The nature of a contract, is that people are happier to be bound by some
rules that they themselves construct (for example, a nuclear
non-proliferation treaty).

In this case, miners prefer sidechains to exist (as existence makes the
BTC they mine more valuable, and provides additional tx fee revenues),
and so they would like to run code which makes them possible.


> 
> Equally, you're opening up miners to huge political risks, as rejecting all
> withdrawals is preventing users' from getting their money, which gives other
> miners a rational for kicking those miners off of Bitcoin entirely.

As I explained above, miners can abstain from voting, which is
politically neutral, or else they can delegate their vote to an
aggressive miner. The "51% can orphan" concern could be raised, even in
a world without drivechain. All that is required, is for the miners to
be anonymous, or in private 'dark' pools (and to thereby escape censure).

But there is a much bigger issue here, which is that our threat models
are different.

As you may know, my threat model [1] does not include miners "pushing
each other off". It only cares about the miner-experience, to the extent
that it impacts the user-experience.

Moreover, I reject [2] the premise that we can even measure "miner
centralization", or even that such a concept exists. If someone has a
definition of this concept, which is both measurable and useful, I would
be interested to read it.

( For what it's worth, Satoshi did not care about this, either. For
example: "If a greedy attacker is able to assemble more CPU power than
all the honest nodes, he...ought to find it more profitable to play by
the rules." which implies robustness to 51% owned by one entity. )

[1] http://www.truthcoin.info/blog/mining-threat-equilibrium/
[2] http://www.truthcoin.info/blog/mirage-miner-centralization/


> 
>> Finally, the point in dispute is a single, infrequent, true/false question.
>> So miners may resort to semi-trusted methods to supplement their decision.
>> In other words, they can just ask people they trust, if the withdrawal is
>> correct or not. It is up to users to decide if they are comfortable with
>> these risks, if/when they decide to deposit to a sidechain.
> 
> Why do you think this will be infrequent? Miners with a better ability to
> validate the drivechain have every reason to make these events more frequent.

It is part of the spec. These timing parameters must be agreed upon when
the sidechain is added, ie _before_ users deposit to the sidechain. Once
the sidechain is created, the timing is enforced by nodes, the same as
with any other protocol rules. Miner-validation-ability has no effect on
the frequency.


> 
>> It 

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Peter Todd via bitcoin-dev]

On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wrote:
> Surprisingly, this requirement (or, more precisely, this incentive) does
> not effect miners relative to each other. The incentive to upgrade is only
> for the purpose of preventing a "theft" -- defined as: an improper
> withdrawal from a sidechain. It is not about miner revenues or the ability
> to mine generally (or conduct BMM specifically). The costs of such a theft
> (decrease in market price, decrease in future transaction fee levels) would
> be shared collectively by all future miners. Therefore, it would have no
> effect on miners relative to each other.

That's not at all true. If I'm a miner with a better capability than another
miner to prevent that theft, I have reasons to induce it to happen to give me
political cover to pushing that other miner off the network.

This is a very similar problem to what we had with zeroconf double-spending,
where entities such as Coinbase tried to pay off miners to guarantee something
that wasn't possible in a geninely decrentralized system: safe zeroconf
transactions.

> Moreover, miners have other recourse if they are unable to run the node.
> They can adopt a policy of simply rejecting ("downvoting") any withdrawals
> that they don't understand. This would pause the withdraw process until
> enough miners understand enough of what is going on to proceed with it.

Why are you forcing miners to run this code at all?

Equally, you're opening up miners to huge political risks, as rejecting all
withdrawals is preventing users' from getting their money, which gives other
miners a rational for kicking those miners off of Bitcoin entirely.

> Finally, the point in dispute is a single, infrequent, true/false question.
> So miners may resort to semi-trusted methods to supplement their decision.
> In other words, they can just ask people they trust, if the withdrawal is
> correct or not. It is up to users to decide if they are comfortable with
> these risks, if/when they decide to deposit to a sidechain.

Why do you think this will be infrequent? Miners with a better ability to
validate the drivechain have every reason to make these events more frequent.

> It is a matter of comparing the costs and benefits. Ignoring theft, the
> costs are near-zero, and the benefits are >0. Specifically, they are: a
> higher BTC price and greater transaction fees. Theft is discouraged by
> attempting to tie a theft to a loss of confidence in the miners, as
> described in the spec/website.
> In general the incentives are very similar to those of Bitcoin itself.

This is also a very dubious security model - I would argue that Bitcoin is much
*more* valuable if miners do everything they can to ensure that drivechains
fail, given the huge risks involved. I would also argue that users should do
user-activated-soft-forks to ensure they fail.

By comparison, note Adam Back and my own efforts to ensure miners have a
smaller part in the ecosystem, with things like committed (encrypted)
transactions and my closed-seal-set/truth-list approach(1). We want to involve
miners as little as possible in the consensus, not more.

I have to ask: What use-cases do you actually see for drivechains? Why can't
those use-cases be done in the much safer client-side validation fashion?

1) https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


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

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Tier Nolan via bitcoin-dev]

On Wed, May 24, 2017 at 6:32 PM, CryptAxe via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Also the block number can only change by +1 or -1, so when a new h* is
> added to the
> queue it must be compared to the most recent h* in the queue.
> std::abs(queue.back().nHeight - ToAdd.nHeight) must equal 1.
>

I think it is better to have it locked to a particular bitcoin height and
if it doesn't get included in that block, the sidechain miner can re-claim
it.

This could be taken to the extreme where the sidechain miner specifies a
particular parent of the claiming block.

The output should have a standard template, so miners can easily find bids.

The template on my previous post was:

IF
  OP_BRIBE_VERIFY
ELSE
   OP_CHECKSIG
ENDIF


If the output is spent by the miner for block , then the
sidechain miner has spent the funds.

Otherwise, the sidechain miner can use the else branch to reclaim his money.

The sidechain miner could also reclaim his money if the transaction was
included in an earlier block.  That would defeat the purpose of the bribe.
Bitcoin miners would have a (justified) incentive to not allow Bribe
outputs to be spent "early".

The bribe transactions could be created with no fees.  This would mean that
it is pointless for bitcoin miners to include them in blocks unless they
are claiming the outputs.

The relay rules would need to be modified to handle that.  Pools could
allow bids to be made directly, but that is less decentralized.

Here's what I'm testing right now as I'm working on BMM:
>
> script << OP_RETURN << CScriptNum::serialize(nSidechain) <<
> CScriptNum(nSidechainHeight) << ToByteVector(sidechain blinded block hash
> h*)
>

I don't think OP_BRIBE should care about info for the side chain.  The only
thing that is necessary is to indicate which sidechain.

You could just define the critical hash as

Hash( SideChainHeight | blinded h* )

For bribe payout release, it needs to give that particular miner an
advantage over all competitors, so their block forms the longest chain on
the sidechain (assuming their block is actually valid).

> One other thing I want to make sure is clear enough is that the block
> number in the critical hash script is
> a sidechain block number, not a mainchain block number.
>
The sidechain miner is saying that they will pay the bribe but only if
their block is included in the main chain.  The means that main chain
height is important.

They are paying for their block to be placed ahead of all competing blocks
for their chain.

It does mean that the side-chain can have at most the same number of blocks
as bitcoin.

>
> We were thinking about making bribe outputs have a maturity period like
> generated coins. You
> think that they should be locked for >100 blocks by having OP_BRIBE also
> check the lock time?
>

Well, it depends on the exact rules for OP_BRIBE.

The process I see is:

- sidechain miner submits a bribe transaction which pays to op bribe
- bitcoin miner includes that transaction in his block (or it could be
included in a previous block)
- bitcoin miner includes a claim transaction in his block

The claim transaction spends the outputs from the bribe transaction.  If
the claim transaction is block height locked, then it violates the rules
that previous soft-forks have followed.

For previous opcode changes there was a requirement that if a transaction
was accepted into block N, then it must also be acceptable in block (N+1).

The only (unavoidable) exceptions were double spends and coinbases outputs.

This means that the same protection should be added to your claim
transaction.

You could do it by requiring all outputs of the claim transaction to start
with

<100> CHECK_SEQUENCE_VERIFY DROP ...

This is only a few bytes extra at the start of the output script.

This means you can't use witness or P2SH output types for any of the
outputs, but that isn't that important.  The point of the transaction is to
make a payment.

An alternative would be to just add the rule as part of soft-fork
definition.  You could define a claim transaction as one that spends at
least one OP_BRIBE output and therefore, all its outputs have a 100 block
delay.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[CryptAxe via bitcoin-dev]

Your assumptions of the bribe process are indeed correct you seem to
have a pretty good handle on all of that.

Hopefully I can clear up a few things. BMM among other things is still a
work in progress so you'll have to wait a
bit longer before any reorg code is on github. The "ratchet" system on
github right now just has the block hash
part of the critical hash script. The completed version needs to check
the sidechain number (ID) and the sidechain
block number in the script. Also the block number can only change by +1
or -1, so when a new h* is added to the
queue it must be compared to the most recent h* in the queue.
std::abs(queue.back().nHeight - ToAdd.nHeight) must equal 1.

Here's what the script looks like on github:
Note that the h* is just a block hash.

script << OP_RETURN << ToByteVector(h*);

Here's what I'm testing right now as I'm working on BMM:

script << OP_RETURN << CScriptNum::serialize(nSidechain) <<
CScriptNum(nSidechainHeight) << ToByteVector(sidechain blinded block
hash h*)

One other thing I want to make sure is clear enough is that the block
number in the critical hash script is
a sidechain block number, not a mainchain block number. That might mess
up the new format you have
suggested for bribes. And the reason a sidechain miner would want to
refund their bribe is if the h* doesn't
end up in a coinbase after a number of blocks, making their blinded
block on the sidechain invalid as tx's
will be spent in other blocks that do get their h* in a coinbase.

We were thinking about making bribe outputs have a maturity period like
generated coins. You
think that they should be locked for >100 blocks by having OP_BRIBE also
check the lock time?

I like all of your suggestions so far, thank you for taking a look!


On 05/24/2017 03:05 AM, Tier Nolan via bitcoin-dev wrote:
> On Wed, May 24, 2017 at 9:50 AM, Tier Nolan  > wrote:
>
> OP_BRIBE_VERIFY could then operate as follows
>
>OP_BRIBE_VERIFY
>
> This causes the script to fail if
>does not match the block height, or
>is not the hash for the sidechain with
> , or
>   there is no hash for that sidechain in the block's coinbase
>
>
> I was thinking more on the process for these transactions.
>
> I assume that the process is
>
> - sidechain miner broadcasts transaction with OP_BRIBE output
> - this transaction ends up in the memory pool of miners
> - Miners add the transaction to their next block
> - Miners add a transaction which spends the output to one of their own
> addresses
>
> I think you need an additional rule that OP_BRIBE checks fails unless
> the output is locked 100 or more blocks.
>
> The output script would end up something like
>
> IF
>   OP_BRIBE_VERIFY
> ELSE
>OP_CHECKSIG
> ENDIF
>
> This output acts like "anyone can spend" for the one block height. 
> Otherwise, only the sidechain miner can spend the output.
>
> This allows the sidechain miner to reclaim their coins if the
> transaction ends up in a different block.
>
> OP_BRIBE_VERIFY would have an additional rule
>
> The script to fails if
>   one or more of the transaction outputs start with something other
> than the template
>does not match the block height, or
>is not the hash for the sidechain with
> , or
>   there is no hash for that sidechain in the block's coinbase
>
> The template is
>   <100> OP_CHECKSEQUENCE_VERIFY
>
>
> ___
> 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] Drivechain -- Request for Discussion

[Tier Nolan via bitcoin-dev]

On Tue, May 23, 2017 at 3:22 PM, Paul Sztorc  wrote:

>
> If you haven't seen http://www.truthcoin.info/blog/drivechain/ , that is
> probably the most human-readable description.
>

I guess I was looking for the detail you get in the code, but without
having to read the code.

My quick reading gives that the sidechain codes (critical hashes) are added
when a coinbase is processed.

Any coinbase output that has the form "OP_RETURN <32 byte push>" counts as
a potential critical hash.

When the block is processed, the key value pair (hash, block_height) is
added to a hash map.

The OP_BRIBE opcode checks that the given hash is in the hash map and
replaces the top element on the stack with the pass/fail result.

It doesn't even check that the height matches the current block, though
there is a comment that that is a TODO.

I agree with ZmnSCPxj, when updating a nop, you can't change the stack.  It
has to fail the script or do nothing.

OP_BRIBE_VERIFY would cause the script to fail if the hash wasn't in the
coinbase, or cause a script failure otherwise.

Another concern is that you could have multiple bribes for the same chain
in a single coinbase.  That isn't fair and arguably what the sidechain
miner is paying for is to get his hash exclusively into the block.

I would suggest that the output is

OP_RETURN  

Then add the rule that only the first hash with a particular sidechain id
actually counts.

This forces the miner to only accept the bribe from 1 miner for each
sidechain for each block.  If he tries to accept 2, then only the first one
counts.

OP_BRIBE_VERIFY could then operate as follows

   OP_BRIBE_VERIFY

This causes the script to fail if
   does not match the block height, or
   is not the hash for the sidechain with , or
  there is no hash for that sidechain in the block's coinbase

If you want reduce the number of drops, you could serialize the info into a
single push.

This has the advantage that a sidechain miner only has to pay if his block
is accepted in the next bitcoin block.  Since he is the only miner for that
sidechain that gets into the main bitcoin block, he is pretty much
guaranteed to form the longest chain.

Without that rule, sidechain miners could end up having to pay even though
it doesn't make their chain the longest.

How are these transactions propagated over the network?  For relaying, you
could have the rule that the opcode passes as long as  is
near the current block height.  Maybe require that they are in the future.
They should be removed from the memory pool once the block height has
arrived, so losing miners can re-spend those outputs.

This opcode can be validated without needing to look at other blocks, which
is good for validating historical blocks.

I am still looking at the deposit/withdrawal code.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[ZmnSCPxj via bitcoin-dev]

Good morning,

>> (What happens if the h* to be put in the coinbase, by chance - even very
>> unlikely chance - is 0? Then  OP_NOP4 is not the same as 
>> OP_BRIBE scripts in result - the former will be rejected by old nodes,
>> the latter will be accepted by new nodes)
>
>That would indeed be a bug, if it happened as you described. I will
>check when I get the chance, thanks.

Indeed, this is the reason why CLTV and CSV do not pop off their parameters 
when executed, and require a subsequent OP_DROP. I suggest, that OP_BRIBE 
should not manipulate stack (pop, then push 0/1); my understanding is that this 
requirement is necessary for compatibility with old nodes, which will not 
manipulate stack on OP_NOP4. Instead, OP_BRIBE should imitate CLTV and CSV 
code, and raise an error in script execution if the check fails.

>>
>> How is OP_BRIBE superior to just using a  OP_RETURN script? Cannot
>> a sidechain scan the block for OP_RETURN attesting that the block hash
>> is present in the block?
>
>The sidechain software can indeed, but the mainchain software cannot
>(without making validation of both chains part of the mainchain, which
>defeats the original purpose of sidechains).
>
>The purpose of OP_BRIBE is to allow "Sam" (on the sidechain) and "Mary"
>(a mainchain miner) to work together. Sam would pay X BTC to Mary, if
>Mary could provide Sam with some guarantee that Sam's sidechain block
>[defined by h*] would make it into the largest chain.

Regarding "largest chain", do you mean mainchain or sidechain?

An OP_RETURN is still some guarantee that it will make it into the longest 
mainchain. If OP_RETURN tx is in a shorter mainchain but not on the longer 
mainchain, then on the longer mainchain, the utxo's funding the OP_RETURN tx is 
still unspent and the OP_RETURN tx will still be mineable by any miner 
following the longer mainchain. The X BTC would be the OP_RETURN transaction's 
fee, which Mary would still want to mine into the longest mainchain, as it is 
still money on the table if it is not mined on the longest mainchain.

Or, does OP_BRIBE somehow assure that Sam's block goes onto the longer 
sidechain? But then, do not side blocks refer to their previous side block to 
define the sidechain?

>1. main:A sends 100 to side:A, then transfers 100 to side:B in exchange
>for B's good or service (provided on the sidechain)
>2. side:B attempts to move side-to-main with the 100 BTC, using the
>lightning network. He swaps 100 side:BTC for 100 of C's main:BTC.
>3. C attempts to move side-to-main, using the slow, settlement method.
>4. C's side-to-main sidechain tx (wt) is bundled with others and becomes
>a withdrawal attempt (WT^)
>5. The WT^ attempt is initiated on the mainchain.
>6. After a waiting period, the WT^ begins to accumulate ACKs or NACKs
>(upvotes / downvotes), on the mainchain.
>7. The transaction either succeeds or fails.
>
>I'm not sure, but your question seems to concern B, who exploits a reorg
>that happens just after step 2. After the reorg, the sidechain chain
>history will have a different side-to-main withdrawal in part 3. The
>time between each of these step is very long, on the order of weeks
>(summing to a length of time totaling months), for exactly this reason
>(as well as to encourage people to avoid using this 'formal' method, in
>favor of the cooperative LN and Atomic Swaps).
>
>I think that this principle of scale (ie, very VERY slow withdrawals) is
>important and actually makes the security categorically different.

I see.

Is there some predictable schedule for side->main withdrawals? If a withdrawal 
is imminent, or if some actor can get "insider information" about whether a 
withdrawal is imminent, cannot some actor induce the above, with potentially 
shorter time to reach step 3?

From my reading, Blockstream's sidechains proposal supports a reorg proof after 
a side->main withdrawal on the mainchain side, with a reorg proof burn window 
after the main:side->main withdrawal, preventing its utxo from being used. If 
the reorg proof is published and shows that a sidechain reorg invalidates a 
particular side->main withdrawal, then the main:side->main withdrawal's utxo is 
burned.

>For extraordinary DAO-like situations, disinterested mainchain miners
>merely need a single bit of information (per sidechain), which is
>"distress=true", and indicates to them to temporarily stop ACKing
>withdrawals from the sidechain. This alone is enough to give the reorg
>an unlimited amount of time to work itself out.

Do you have some document containing these details? I cannot find this in the 
blog posts I've read so far.

>>>I feel that my proposal is more secure, as it can operate healthily and
>> quickly while using spv proofs which are much slower and much much
>> easier to audit.
>>
>> I don't quite understand how Drivechain handles sidechain reorgs, while
>> keeping Bitcoin miners blinded. It seems sidechains need to be known
>> ("seen") by the miner, so I don't see 

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Paul Sztorc via bitcoin-dev]

On 5/23/2017 5:51 AM, Tier Nolan via bitcoin-dev wrote:
> On Mon, May 22, 2017 at 9:00 PM, Paul Sztorc  > wrote:
> 
> I would replace "Bitcoins you manage to steal" with "Bitcoins you
> manage to double-spend". Then, it still seems the same to me.
> 
> 
> With double spending, you can only get ownership of coins that you owned
> at some point in the past.  Coins that are owned by someone else from
> coinbase to their current owners cannot be stolen by a re-org (though
> they can be moved around).

I'm not sure it makes much of a difference. First of all, in point of
fact, the miners themselves own the coins from the coinbase. But more
importantly, even if miners did not explicitly own the coins, they might
profit by being bribed -- these bribes would come from people who did
own the coins.

The principle is that value "v' has been taken from A and given to B.
This is effectively coercive activity, and therefore itself has value
proportional to 'v'.

> 
> With BMM, you can take the entire reserve.  Creating a group of double
> spenders can help increase the reward.
>  
> 
> 
> It may destroy great value if it shakes confidence in the sidechain
> infrastructure. Thus, the value of the stolen BTC may decrease, in
> addition to the lost future tx fee revenues of the attacked chain.
> 
> http://www.truthcoin.info/blog/drivechain/#drivechains-security
> 
> 
> 
> That is a fair point.  If sidechains are how Bitcoin is scaled, then
> shaking confidence in a side-chain would shake confidence in Bitcoin's
> future.

Yes. The more value _on_ the sidechain, the more abhorrent the malfeasance.

> 
> I wasn't thinking of a direct miner 51% attack.  It is enough to assume
> that a majority of the miners go with the highest bidder each time.

What do you think of my argument, that we already labor under such an
assumption? An attacker could pay fees today equal to greater than
sum(blockreward_(last N block)). According to you this would force a
reorg, even on mainchain (pre-sidechain) Bitcoin. Yet this has never
happened.

It seems that this argument fully reduces to the "what will happen when
the block subsidy falls to zero" question.

> 
> If (average fees) * (timeout) is less than the total reserves, then it
> is worth it for a 3rd party to just bid for his theft fork.  Miners
> don't have to be assumed to be coordinating, they just have to be
> assumed to take the highest bid.
> 
> Again, I don't really think it is that different. One could
> interchange "recent txns" (those which could be double-spent within
> 2-3 weeks) with "sidechain deposit tnxs".
> 
> 
> It is not "recent txns", it is recent txns that you (or your group) have
> the key for.  No coordination is required to steal the entire reserve
> from the sidechain.

See above (?) for why I still feel they are comparable, if not identical.

> 
> Recent txns and money on the sidechain have the property that they are
> riskier than money deep on the main chain.  This is the inherent point
> about sidechains, so maybe not that big a deal. 

Yes. Sidechains have newer, more interesting features, and
simultaneously more risk.


> 
> My concern is that you could have a situation where an attack is
> possible and only need to assume that the miners are indifferent.

Again, I think that we _already_ need to eliminate any assumption of
"charitable miners".

> 
> If the first attacker who tries it fails (say after creating a fork that
> is 90% of the length required, so losing a lot of money), then it would
> discourage others.   If he succeeds, then it weakens sidechains as a
> concept and that creates the incentive for miners to see that he fails.
> 
> I wonder how the incentives work out.  If a group had 25% of the money
> on the sidechain, they could try to outbid the attacker.

Yes, we may see interesting behavior where people buy up these
liabilities using the LN. In my original post, I mention that miners
themselves may purchase these liabilities (at competitive rates, even if
these arent the idealized 1:1). At this point, miners would be paying
themselves and there would be no agency problem.

> 
> In fact, since the attacker, by definition, creates an illegal fork, the
> effect is that he reduces the block rate for the side chain (possibly to
> zero, if he wins every auction).  This means that there are more
> transactions per block, if there is space, or more fees per transaction,
> if the blocks are full. 
> 
> In both cases, this pushes up the total fees per block, so he has to pay
> more per block, weakening his attack.  This is similar to where
> transaction spam on Bitcoin is self-correcting by increasing the fees
> required to keep the spam going.
> 
> Is there a description of the actual implementation you decided to go
> with, other than the code?

If you haven't seen 

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Paul Sztorc via bitcoin-dev]

On 5/22/2017 8:13 PM, ZmnSCPxj wrote:
> Good morning,
> 
> 
> 
>>What you read is only an introduction of BMM. You may also consult the
> notes (at the bottom of the BMM post) or the code, although this is time
> consuming of course.
> 
> Looking over the code, I have a question: Is OP_BRIBE supposed to be
> softforked in, or hardforked?

Softforked, of course.

  From my understanding, the code as
> published in your linked github cannot be softforked in, since it is not
> a softfork-compatible replacement for OP_NOP: it replaces the stack top
> value with a 0/1 value.  Both CLTV and CSV do not touch the stack, only
> flag an error if they fail.

Your understanding may exceed my own. I don't understand the principle
of your distinction, as it seems to me that one could add a new protocol
rule which says that the block is invalid unless the OP Code does
results in arbitrary-item-x. The intent is to mimic CLTV or CSV
behavior, by causing something that would otherwise succeed, to fail, if
arbitrary new conditions are met.

> 
> (What happens if the h* to be put in the coinbase, by chance - even very
> unlikely chance - is 0?  Then  OP_NOP4 is not the same as 
> OP_BRIBE scripts in result - the former will be rejected by old nodes,
> the latter will be accepted by new nodes)

That would indeed be a bug, if it happened as you described. I will
check when I get the chance, thanks.

> 
> Is OP_BRIBE the same as the OP_h_is_in_coinbase operation you described?

Yes. Sorry if that was confusing.

> 
> How is OP_BRIBE superior to just using a  OP_RETURN script? Cannot
> a sidechain scan the block for OP_RETURN attesting that the block hash
> is present in the block?

The sidechain software can indeed, but the mainchain software cannot
(without making validation of both chains part of the mainchain, which
defeats the original purpose of sidechains).

The purpose of OP_BRIBE is to allow "Sam" (on the sidechain) and "Mary"
(a mainchain miner) to work together. Sam would pay X BTC to Mary, if
Mary could provide Sam with some guarantee that Sam's sidechain block
[defined by h*] would make it into the largest chain.

So, as I see it, this needs to be a mainchain consensus rule, but one
which enforces the bare minimum criteria.


> 
>>The literal answer to your question is that mainchain Bitcoin will
> notice that, for the second withdrawal, the sum of the inputs is less
> than the sum of the outputs and they the transaction is therefore invalid.
> 
> You misunderstand.  The first withdrawal was done by double-spending,
> and exchanging your sidechain funds for mainchain funds using some
> off-chain method.  The second withdrawal is done on-chain.

If A, B, and C are transacting, and each has an account on both chains.
Then your example would be something like:

1. main:A sends 100 to side:A, then transfers 100 to side:B in exchange
for B's good or service (provided on the sidechain)
2. side:B attempts to move side-to-main with the 100 BTC, using the
lightning network. He swaps 100 side:BTC for 100 of C's main:BTC.
3. C attempts to move side-to-main, using the slow, settlement method.
4. C's side-to-main sidechain tx (wt) is bundled with others and becomes
a withdrawal attempt (WT^)
5. The WT^ attempt is initiated on the mainchain.
6. After a waiting period, the WT^ begins to accumulate ACKs or NACKs
(upvotes / downvotes), on the mainchain.
7. The transaction either succeeds or fails.

I'm not sure, but your question seems to concern B, who exploits a reorg
that happens just after step 2. After the reorg, the sidechain chain
history will have a different side-to-main withdrawal in part 3. The
time between each of these step is very long, on the order of weeks
(summing to a length of time totaling months), for exactly this reason
(as well as to encourage people to avoid using this 'formal' method, in
favor of the cooperative LN and Atomic Swaps).

I think that this principle of scale (ie, very VERY slow withdrawals) is
important and actually makes the security categorically different.

For extraordinary DAO-like situations, disinterested mainchain miners
merely need a single bit of information (per sidechain), which is
"distress=true", and indicates to them to temporarily stop ACKing
withdrawals from the sidechain. This alone is enough to give the reorg
an unlimited amount of time to work itself out.


> 
> That said, I confused OP_h_is_in_coinbase as your method of getting out
> of the sidechain into the mainchain.  It seems, OP_h_is_in_coinbase is
> only for blind mining?

Correct

> 
> 
> 
>>I feel that my proposal is more secure, as it can operate healthily and
> quickly while using spv proofs which are much slower and much much
> easier to audit.
> 
> I don't quite understand how Drivechain handles sidechain reorgs, while
> keeping Bitcoin miners blinded.  It seems sidechains need to be known
> ("seen") by the miner, so I don't see what is being blinded by blinded
> merge mining.

Mainchain miners do 

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Tier Nolan via bitcoin-dev]

On Mon, May 22, 2017 at 9:00 PM, Paul Sztorc  wrote:

> I would replace "Bitcoins you manage to steal" with "Bitcoins you manage
> to double-spend". Then, it still seems the same to me.
>
>
With double spending, you can only get ownership of coins that you owned at
some point in the past.  Coins that are owned by someone else from coinbase
to their current owners cannot be stolen by a re-org (though they can be
moved around).

With BMM, you can take the entire reserve.  Creating a group of double
spenders can help increase the reward.


>
> It may destroy great value if it shakes confidence in the sidechain
> infrastructure. Thus, the value of the stolen BTC may decrease, in addition
> to the lost future tx fee revenues of the attacked chain.
>
> http://www.truthcoin.info/blog/drivechain/#drivechains-security
>
>
That is a fair point.  If sidechains are how Bitcoin is scaled, then
shaking confidence in a side-chain would shake confidence in Bitcoin's
future.

I wasn't thinking of a direct miner 51% attack.  It is enough to assume
that a majority of the miners go with the highest bidder each time.

If (average fees) * (timeout) is less than the total reserves, then it is
worth it for a 3rd party to just bid for his theft fork.  Miners don't have
to be assumed to be coordinating, they just have to be assumed to take the
highest bid.

Again, I don't really think it is that different. One could interchange
> "recent txns" (those which could be double-spent within 2-3 weeks) with
> "sidechain deposit tnxs".
>

It is not "recent txns", it is recent txns that you (or your group) have
the key for.  No coordination is required to steal the entire reserve from
the sidechain.

Recent txns and money on the sidechain have the property that they are
riskier than money deep on the main chain.  This is the inherent point
about sidechains, so maybe not that big a deal.

My concern is that you could have a situation where an attack is possible
and only need to assume that the miners are indifferent.

If the first attacker who tries it fails (say after creating a fork that is
90% of the length required, so losing a lot of money), then it would
discourage others.   If he succeeds, then it weakens sidechains as a
concept and that creates the incentive for miners to see that he fails.

I wonder how the incentives work out.  If a group had 25% of the money on
the sidechain, they could try to outbid the attacker.

In fact, since the attacker, by definition, creates an illegal fork, the
effect is that he reduces the block rate for the side chain (possibly to
zero, if he wins every auction).  This means that there are more
transactions per block, if there is space, or more fees per transaction, if
the blocks are full.

In both cases, this pushes up the total fees per block, so he has to pay
more per block, weakening his attack.  This is similar to where transaction
spam on Bitcoin is self-correcting by increasing the fees required to keep
the spam going.

Is there a description of the actual implementation you decided to go with,
other than the code?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[ZmnSCPxj via bitcoin-dev]

Good morning,

>What you read is only an introduction of BMM. You may also consult the notes 
>(at the bottom of the BMM post) or the code, although this is time consuming 
>of course.

Looking over the code, I have a question: Is OP_BRIBE supposed to be softforked 
in, or hardforked? From my understanding, the code as published in your linked 
github cannot be softforked in, since it is not a softfork-compatible 
replacement for OP_NOP: it replaces the stack top value with a 0/1 value. Both 
CLTV and CSV do not touch the stack, only flag an error if they fail.

(What happens if the h* to be put in the coinbase, by chance - even very 
unlikely chance - is 0? Then  OP_NOP4 is not the same as  OP_BRIBE 
scripts in result - the former will be rejected by old nodes, the latter will 
be accepted by new nodes)

Does Drivechain require a hardfork? My understanding is that you want to use 
some kind of softforked anyone-can-spend transaction to use Drivechain. So I 
don't quite understand why OP_BRIBE is written the way it is.

Is OP_BRIBE the same as the OP_h_is_in_coinbase operation you described?

How is OP_BRIBE superior to just using a  OP_RETURN script? Cannot a 
sidechain scan the block for OP_RETURN attesting that the block hash is present 
in the block? OP_BRIBE encodes  twice (once in the transaction, once in the 
coinbase), OP_RETURN encodes it once (once in the transaction)

>The literal answer to your question is that mainchain Bitcoin will notice 
>that, for the second withdrawal, the sum of the inputs is less than the sum of 
>the outputs and they the transaction is therefore invalid.

You misunderstand. The first withdrawal was done by double-spending, and 
exchanging your sidechain funds for mainchain funds using some off-chain 
method. The second withdrawal is done on-chain.

That said, I confused OP_h_is_in_coinbase as your method of getting out of the 
sidechain into the mainchain. It seems, OP_h_is_in_coinbase is only for blind 
mining?

>I feel that my proposal is more secure, as it can operate healthily and 
>quickly while using spv proofs which are much slower and much much easier to 
>audit.

I don't quite understand how Drivechain handles sidechain reorgs, while keeping 
Bitcoin miners blinded. It seems sidechains need to be known ("seen") by the 
miner, so I don't see what is being blinded by blinded merge mining.

>>seems to me that your OP_is_h_in_coinbase should scan a series of sidechain 
>>block headers backed by mainchain (meaning at the minimum that sidechains 
>>should have some common header format prefix), rather than just mainchain 
>>depth as your article seems to imply.
>
>How would security be improved as a result? In either case, 51% of hashrate 
>can cause a reorg. The sidechain software itself does scan block headers, of 
>course.

I misunderstand the purpose of your OP_is_h_in_coinbase, sorry.

>>Blind merged mining seems strictly inferior ... a rich attacker can simply 
>>reorg the sidechain outright without playing such games.
>
>In the future, when there is no block subsidy, a rich attacker can also do 
>that in mainchain Bitcoin.

I see. However, block subsidies will drop far in the future, do you mean to 
say, that sidechains will be used only in the far future?

>>How does your proposal handle multiple side block creators on the same 
>>sidechain, with the possibility that chain splits occur?
>
>The side block is only "mined" if it is committed to in a mainchain Bitcoin 
>blog, and each mainchain block can only contain one block per sidechain. In 
>this way, drivechain sidechains are different from classical Namecoin merged 
>mining (where one _could_ run the entire system, mining included, without 
>interfacing with Bitcoin at all).

I assume you mean "mainchain Bitcoin block" here.

What mechanism ensures only one mainchain block can contain only one sidechain 
block? It seems, this isn't implemented by OP_BRIBE yet. Can you elaborate on 
this mechanism?

>>Regarding your dig about people who dislike data centers, the main issue with 
>>miners blindly accepting sidechain commitments is that it violates "Don't 
>>trust, verify", not that allows datacenters to be slightly smaller by not 
>>including side:nodes.
>
>As I explain early on, in earlier rounds of peer review, the focus was on 
>harms the sidechain technology might do to mainchain Bitcoin, and the 
>"datacenter point" was specifically the chief objection raised. So I am afraid 
>you are entirely incorrect.

I see. It seems, the main problem, is that sidechains can be used to sneak in 
block size increases. Of course, the advantage of sidechains, is that when it 
increases block size irresponsibly, only those who participated in the 
sidechain will suffer.

>In point of fact, the transactions *are* validated...by sidechain full nodes, 
>same as Bitcoin proper.

But from blind merge mining by itself, how would the blinded merge miner know 
that there exists an actual sidechain full node 

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Paul Sztorc via bitcoin-dev]

On May 22, 2017 3:13 PM, "Tier Nolan via bitcoin-dev"  wrote:

On Mon, May 22, 2017 at 5:19 PM, Paul Sztorc via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> In the future, when there is no block subsidy, a rich attacker can also do
> that in mainchain Bitcoin.
>

I don't think they are the same.

With Bitcoin, you only get to reverse recent transactions.  If you actually
reversed 2-3 weeks of transactions, then the Bitcoin price would fall,
destroying the value of the additional coins you managed to obtain.  Even
if their was no price fall, you can only get a fraction of the total.


I would replace "Bitcoins you manage to steal" with "Bitcoins you manage to
double-spend". Then, it still seems the same to me.


With BMM, you can "buy" the entire reserve of the sidechain by paying
(timeout) * (average tx fees).  If you destroy a side-chain's value, then
that doesn't affect the value of the bitcoins you manage to steal.


It may destroy great value if it shakes confidence in the sidechain
infrastructure. Thus, the value of the stolen BTC may decrease, in addition
to the lost future tx fee revenues of the attacked chain.

http://www.truthcoin.info/blog/drivechain/#drivechains-security

In my view, sidechains should only exist at all if they positively impact
Bitcoin's value. It is therefore desirable for miners to steal from chains
that provide no value-add.




> In point of fact, the transactions *are* validated...by sidechain full
> nodes, same as Bitcoin proper.
>
>
The big difference is that Bitcoin holds no assets on another chain.  A
side-chain's value is directly linked to the fact that it has 100% reserves
on the Bitcoin main chain.  That can be targeted for theft.


Again, I don't really think it is that different. One could interchange
"recent txns" (those which could be double-spent within 2-3 weeks) with
"sidechain deposit tnxs".
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Tier Nolan via bitcoin-dev]

On Mon, May 22, 2017 at 5:19 PM, Paul Sztorc via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> In the future, when there is no block subsidy, a rich attacker can also do
> that in mainchain Bitcoin.
>

I don't think they are the same.

With Bitcoin, you only get to reverse recent transactions.  If you actually
reversed 2-3 weeks of transactions, then the Bitcoin price would fall,
destroying the value of the additional coins you managed to obtain.  Even
if their was no price fall, you can only get a fraction of the total.

With BMM, you can "buy" the entire reserve of the sidechain by paying
(timeout) * (average tx fees).  If you destroy a side-chain's value, then
that doesn't affect the value of the bitcoins you manage to steal.

The incentive could be eliminated by restricting the amount of coin that
can be transferred from the side chain to the main chain to a fraction of
the transaction fee pay to the bitcoin miners.

If the side chain pays x in fees, then at most x/10 can be transferred from
the side chain to the main chain.  This means that someone who pays for
block creation can only get 10% of that value transferred to the main chain.

Main-chain miners could support fraud proofs.  A pool could easily run an
archive node for the side chain in a different data center.

This wouldn't harm the performance of their main operations, but would
guarantee that the side chain data is available for side chain validators.

The sidechain to main-chain timeout would be more than enough for fraud
proofs to be constructed.

This means that the miners would need to know what the rules are for the
side chain, so that they can process the fraud proofs.  They would also
need to run SPV nodes for the side chain, so they know which sidechain
headers to blacklist.


> In point of fact, the transactions *are* validated...by sidechain full
> nodes, same as Bitcoin proper.
>
>
The big difference is that Bitcoin holds no assets on another chain.  A
side-chain's value is directly linked to the fact that it has 100% reserves
on the Bitcoin main chain.  That can be targeted for theft.


> Paul
>
>
> Regards,
> ZmnSCPxj
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Paul Sztorc via bitcoin-dev]

On May 22, 2017 10:39 AM, "ZmnSCPxj" <zmnsc...@protonmail.com> wrote:

Good morning Paul,

I read only http://www.truthcoin.info/blog/blind-merged-mining/

>From just this document, I can't see a good justification for believing
that a main->side locking transaction can be safely spent into a side->main
unlocking transaction.  Do you have a better explanation?


Yes, a better explanation is in the drivechain spec, at:
http://www.truthcoin.info/blog/drivechain/

What you read is only an introduction of BMM. You may also consult the
notes (at the bottom of the BMM post) or the code, although this is time
consuming of course.


If I attempt to spend a main->side locking transaction on the basis of a
"mistaken" side block #49, what prevents me from this sequence:


The literal answer to your question is that mainchain Bitcoin will notice
that, for the second withdrawal, the sum of the inputs is less than the sum
of the outputs and they the transaction is therefore invalid.


1.  Put a side:side->main transaction into a block together with TheDAO's
hacked money.

So far, the only good side->main transfer I know of is in Blockstream's
original sidechains paper, with the main:side->main transaction ... Is your
proposal at the technical level actually similar, or does it truly seem to
be riskier?


I feel that my proposal is more secure, as it can operate healthily and
quickly while using spv proofs which are much slower and much much easier
to audit.


seems to me that your OP_is_h_in_coinbase should scan a series of sidechain
block headers backed by mainchain (meaning at the minimum that sidechains
should have some common header format prefix), rather than just mainchain
depth as your article seems to imply.


How would security be improved as a result? In either case, 51% of hashrate
can cause a reorg. The sidechain software itself does scan block headers,
of course.


Blind merged mining seems strictly inferior ... a rich attacker can simply
reorg the sidechain outright without playing such games.


In the future, when there is no block subsidy, a rich attacker can also do
that in mainchain Bitcoin.


Or is your proposal strictly for centralized sidechains, where only one
entity creates side blocks?


Not at all.

How does your proposal handle multiple side block creators on the same
sidechain, with the possibility that chain splits occur?


The side block is only "mined" if it is committed to in a mainchain Bitcoin
blog, and each mainchain block can only contain one block per sidechain. In
this way, drivechain sidechains are different from classical Namecoin
merged mining (where one _could_ run the entire system, mining included,
without interfacing with Bitcoin at all).


Regarding your dig about people who dislike data centers, the main issue
with miners blindly accepting sidechain commitments is that it violates
"Don't trust, verify", not that allows datacenters to be slightly smaller
by not including side:nodes.


As I explain early on, in earlier rounds of peer review, the focus was on
harms the sidechain technology might do to mainchain Bitcoin, and the
"datacenter point" was specifically the chief objection raised. So I am
afraid you are entirely incorrect.

In point of fact, the transactions *are* validated...by sidechain full
nodes, same as Bitcoin proper.

Paul


Regards,
ZmnSCPxj


Sent with ProtonMail Secure Email.

---- Original Message 
Subject: [bitcoin-dev] Drivechain -- Request for Discussion
Local Time: May 22, 2017 6:17 AM
UTC Time: May 22, 2017 6:17 AM
From: bitcoin-dev@lists.linuxfoundation.org
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>

Dear list,

I've been working on "drivechain", a sidechain enabling technology, for
some time.

* The technical info site is here: www.drivechain.info
* The changes to Bitcoin are here:
https://github.com/drivechain-project/bitcoin/tree/mainchainBMM
* A Blank sidechain template is here:
https://github.com/drivechain-project/bitcoin/tree/sidechainBMM

As many of you know, I've been seeking feedback in person, at various
conferences and meetups over the past year, most prominently Scaling
Milan. And I intend to continue to seek feedback at Consensus2017 this
week, so if you are in NYC please just walk up and start talking to me!

But I also wanted to ask the list for feedback. Initially, I was
hesitant because I try not to consume reviewers' scarce time until the
author has put in a serious effort. However, I may have waiting too
long, as today it is actually quite close to a working release.


Scaling Implications
-

This upgrade would have significant scaling implications. Since it is
the case that sidechains can be added by soft fork, and since each of
these chains will have its own blockspace, this theoretically removes
the blocksize limit from "the Bitcoin system" (if one includes
sidechains as part of

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[ZmnSCPxj via bitcoin-dev]

Good morning Paul,

I read only http://www.truthcoin.info/blog/blind-merged-mining/

From just this document, I can't see a good justification for believing that a 
main->side locking transaction can be safely spent into a side->main unlocking 
transaction. Do you have a better explanation?

OP_is_h_in_coinbase, as described, does not seem to protect against a sidechain 
reorg in your next section of the document. If I attempt to spend a main->side 
locking transaction on the basis of a "mistaken" side block #49, what prevents 
me from this sequence:

1. Put a side:side->main transaction into a block together with TheDAO's hacked 
money.
2. Wait for a reorg to revert TheDAO.
3. Spend my now-free-in-the-reorg funds on Lightning Network to get mainchain 
funds.
4. Create a main:side->main transaction with the side:side->main transaction in 
the TheDAO-hacked block as witness.
5. Get another set of mainchain funds from the same sidechain funds.

So far, the only good side->main transfer I know of is in Blockstream's 
original sidechains paper, with the main:side->main transaction spending into a 
timelocked transaction that may be burned if a reorg proof is submitted (i.e. 
you try to create a main:side->main transaction with the side:side->main 
transaction in the mistaken #49 and #50 as your proof, but someone else can 
come along and show a corrected #49, #50, #51 without your side:side->main 
transaction and burn your funds). Is your proposal at the technical level 
actually similar, or does it truly seem to be riskier? It seems to me that your 
OP_is_h_in_coinbase should scan a series of sidechain block headers backed by 
mainchain (meaning at the minimum that sidechains should have some common 
header format prefix), rather than just mainchain depth as your article seems 
to imply.

Also, blinded merge mining seems strictly inferior to proof-of-burn: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-December/007012.html

Proof-of-burn integrates a lottery to reduce the ability of a mainchain-rich 
attacker to reorg the sidechain by burning its greater funds. However it still 
seems to me that a rich attacker can simply make more bets in that scheme by 
some trivial modification of the side block. Blind merged mining seems strictly 
inferior as a rich attacker can simply reorg the sidechain outright without 
playing such games.

Or is your proposal strictly for centralized sidechains, where only one entity 
creates side blocks? How does your proposal handle multiple side block creators 
on the same sidechain, with the possibility that chain splits occur?

Regarding your dig about people who dislike data centers, the main issue with 
miners blindly accepting sidechain commitments is that it violates "Don't 
trust, verify", not that allows datacenters to be slightly smaller by not 
including side:nodes.

Regards,
ZmnSCPxj

Sent with ProtonMail Secure Email.

-------- Original Message ----
Subject: [bitcoin-dev] Drivechain -- Request for Discussion
Local Time: May 22, 2017 6:17 AM
UTC Time: May 22, 2017 6:17 AM
From: bitcoin-dev@lists.linuxfoundation.org
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>

Dear list,

I've been working on "drivechain", a sidechain enabling technology, for
some time.

* The technical info site is here: www.drivechain.info
* The changes to Bitcoin are here:
https://github.com/drivechain-project/bitcoin/tree/mainchainBMM
* A Blank sidechain template is here:
https://github.com/drivechain-project/bitcoin/tree/sidechainBMM

As many of you know, I've been seeking feedback in person, at various
conferences and meetups over the past year, most prominently Scaling
Milan. And I intend to continue to seek feedback at Consensus2017 this
week, so if you are in NYC please just walk up and start talking to me!

But I also wanted to ask the list for feedback. Initially, I was
hesitant because I try not to consume reviewers' scarce time until the
author has put in a serious effort. However, I may have waiting too
long, as today it is actually quite close to a working release.

Scaling Implications
-

This upgrade would have significant scaling implications. Since it is
the case that sidechains can be added by soft fork, and since each of
these chains will have its own blockspace, this theoretically removes
the blocksize limit from "the Bitcoin system" (if one includes
sidechains as part of such a system). People who want a LargeBlock
bitcoin can just move their BTC over to such a network [1], and their
txns will have no longer have an impact on "Bitcoin Core". Thus, even
though this upgrade does not actually increase "scalability" per se, it
may in fact put an end to the scalability debate...forever.

This work includes the relatively new concept of "Blind Merged Mining"
[2] which I developed in January to allow SHA256^2 miners to merge-mine
t

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Paul Sztorc via bitcoin-dev]

Charlie, I'll be mostly in the tech track, of course. And I've already
planned to meet RSK guys after their event tomorrow.

Ryan, the more review the better. We aren't in any direct rush, other than
the natural desire to have cool things as early as possible.

Peter, responses below:

On May 22, 2017 9:33 AM, "Peter Todd"  wrote:

On Mon, May 22, 2017 at 02:17:07AM -0400, Paul Sztorc via bitcoin-dev wrote:
> This work includes the relatively new concept of "Blind Merged Mining"
> [2] which I developed in January to allow SHA256^2 miners to merge-mine
> these "drivechains", even if these miners aren't running the actual
> sidechain software. The goal is to prevent sidechains from affecting the
> levelness of the mining "playing field". BMM is conceptually similar to
> ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not
> required for drivechain, but it would address some of the last remaining
> concerns.

Thanks for the credit, although I think the security properties of what
you're
proposing are very different - and much weaker - than what I proposed in
Zookeyv.


As you state in [2] "if miners never validate sidechains at all, whoever
bids
the most for the chain (on a continuous basis), can spam a 3-month long
stream
of invalid headers, and then withdraw all of the coins deposited to the
sidechain." and "Since the mining is blind, and the sidechain-withdrawal
security-level is SPV, miners who remain blind forever have no way of
telling
who “should” really get the funds."

Finally, you suggest that in this event, miners *do* have to upgrade to a
full
node, an expensive and time-consuming operation (and one that may be
impossible
for some miners if necessary data isn't available).


Surprisingly, this requirement (or, more precisely, this incentive) does
not effect miners relative to each other. The incentive to upgrade is only
for the purpose of preventing a "theft" -- defined as: an improper
withdrawal from a sidechain. It is not about miner revenues or the ability
to mine generally (or conduct BMM specifically). The costs of such a theft
(decrease in market price, decrease in future transaction fee levels) would
be shared collectively by all future miners. Therefore, it would have no
effect on miners relative to each other.

Moreover, miners have other recourse if they are unable to run the node.
They can adopt a policy of simply rejecting ("downvoting") any withdrawals
that they don't understand. This would pause the withdraw process until
enough miners understand enough of what is going on to proceed with it.

Finally, the point in dispute is a single, infrequent, true/false question.
So miners may resort to semi-trusted methods to supplement their decision.
In other words, they can just ask people they trust, if the withdrawal is
correct or not. It is up to users to decide if they are comfortable with
these risks, if/when they decide to deposit to a sidechain.


It's unclear to me what the incentive is for miners to do any of this. Could
you explain in more detail what that incentive is?


It is a matter of comparing the costs and benefits. Ignoring theft, the
costs are near-zero, and the benefits are >0. Specifically, they are: a
higher BTC price and greater transaction fees. Theft is discouraged by
attempting to tie a theft to a loss of confidence in the miners, as
described in the spec/website.
In general the incentives are very similar to those of Bitcoin itself.

Paul



> [2] http://www.truthcoin.info/blog/blind-merged-mining/
> [3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log

--
https://petertodd.org 'peter'[:-1]@petertodd.org
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Peter Todd via bitcoin-dev]

On Mon, May 22, 2017 at 02:17:07AM -0400, Paul Sztorc via bitcoin-dev wrote:
> This work includes the relatively new concept of "Blind Merged Mining"
> [2] which I developed in January to allow SHA256^2 miners to merge-mine
> these "drivechains", even if these miners aren't running the actual
> sidechain software. The goal is to prevent sidechains from affecting the
> levelness of the mining "playing field". BMM is conceptually similar to
> ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not
> required for drivechain, but it would address some of the last remaining
> concerns.

Thanks for the credit, although I think the security properties of what you're
proposing are very different - and much weaker - than what I proposed in
Zookeyv.

As you state in [2] "if miners never validate sidechains at all, whoever bids
the most for the chain (on a continuous basis), can spam a 3-month long stream
of invalid headers, and then withdraw all of the coins deposited to the
sidechain." and "Since the mining is blind, and the sidechain-withdrawal
security-level is SPV, miners who remain blind forever have no way of telling
who “should” really get the funds."

Finally, you suggest that in this event, miners *do* have to upgrade to a full
node, an expensive and time-consuming operation (and one that may be impossible
for some miners if necessary data isn't available).

It's unclear to me what the incentive is for miners to do any of this. Could
you explain in more detail what that incentive is?


> [2] http://www.truthcoin.info/blog/blind-merged-mining/
> [3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


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

[bitcoin-dev] Drivechain -- Request for Discussion

[Paul Sztorc via bitcoin-dev]

Dear list,

I've been working on "drivechain", a sidechain enabling technology, for
some time.

* The technical info site is here: www.drivechain.info
* The changes to Bitcoin are here:
https://github.com/drivechain-project/bitcoin/tree/mainchainBMM
* A Blank sidechain template is here:
https://github.com/drivechain-project/bitcoin/tree/sidechainBMM

As many of you know, I've been seeking feedback in person, at various
conferences and meetups over the past year, most prominently Scaling
Milan. And I intend to continue to seek feedback at Consensus2017 this
week, so if you are in NYC please just walk up and start talking to me!

But I also wanted to ask the list for feedback. Initially, I was
hesitant because I try not to consume reviewers' scarce time until the
author has put in a serious effort. However, I may have waiting too
long, as today it is actually quite close to a working release.


Scaling Implications
-

This upgrade would have significant scaling implications. Since it is
the case that sidechains can be added by soft fork, and since each of
these chains will have its own blockspace, this theoretically removes
the blocksize limit from "the Bitcoin system" (if one includes
sidechains as part of such a system). People who want a LargeBlock
bitcoin can just move their BTC over to such a network [1], and their
txns will have no longer have an impact on "Bitcoin Core". Thus, even
though this upgrade does not actually increase "scalability" per se, it
may in fact put an end to the scalability debate...forever.

This work includes the relatively new concept of "Blind Merged Mining"
[2] which I developed in January to allow SHA256^2 miners to merge-mine
these "drivechains", even if these miners aren't running the actual
sidechain software. The goal is to prevent sidechains from affecting the
levelness of the mining "playing field". BMM is conceptually similar to
ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not
required for drivechain, but it would address some of the last remaining
concerns.


Total Transaction Fees in the Far Future
-

Some people feel that a maximum blocksize limit is needed to ensure that
future total equilibrium transaction fees are non-negligible. I
presented [4] on why I don't agree, 8 months ago. The reviewers I spoke
to over the last year have stopped bringing this complaint up, but I am
not sure everyone feels that way.


Juxtaposition with a recent "Scaling Compromise"
-

Recently, a scalability proposal began to circulate on social media. As
far as I could tell, it goes something like "immediately activate
SegWit, and then HF to double the nonwitness blockspace to 2MB within 12
months". But such a proposal is quite meager, compared to a "LargeBlock
Drivechain". The drivechain is better on both fronts, as it would not
require a hardfork, and could *almost immediately* add _any_ amount of
extra blockspace (specifically, I might expect a BIP101-like LargeBlock
chain that has an 8 MB maxblocksize, which doubles every two years).

In other words, I don't know why anyone would support that proposal over
mine. The only reasons would be either ignorance (ie, unfamiliarity with
drivechain) or because there are still nagging unspoken complaints about
drivechain which I apparently need to hear and address.


Other Thoughts
---

Unfortunately, anyone who worked on the "first generation" of sidechain
technology (the skiplist) or the "second generation" (federated /
Liquid), will find that this is very different.

I will admit that I am very pessimistic about any conversation that
involves scalability. It is often said that "talking politics lowers
your IQ by 25 points". Bitcoin scalability conversations seem to drain
50 points. (Instead of conversing, I think people should quietly work on
whatever they are passionate about until their problem either is solved,
or it goes away for some other reason, or until we all agree to just
stop talking about it.)

Cheers,
Paul

[1] http://www.drivechain.info/faq/#can-sidechains-really-help-with-scaling
[2] http://www.truthcoin.info/blog/blind-merged-mining/
[3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log
[4]
https://www.youtube.com/watch?v=YErLEuOi3xU=PLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg=4

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