public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Paul Sztorc <truthcoin@gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Drivechain -- Request for Discussion
Date: Tue, 23 May 2017 10:22:43 -0400	[thread overview]
Message-ID: <141a0cd1-9d4f-c137-a349-17248f9cafd4@gmail.com> (raw)
In-Reply-To: <CAE-z3OVWXN58X-+nAFTm61G1=v_1xrniyrBy8x=VRG4N149aXQ@mail.gmail.com>



On 5/23/2017 5:51 AM, Tier Nolan via bitcoin-dev wrote:
> On Mon, May 22, 2017 at 9:00 PM, Paul Sztorc <truthcoin@gmail.com
> <mailto:truthcoin@gmail.com>> 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
>     <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 http://www.truthcoin.info/blog/drivechain/ , that is
probably the most human-readable description.

Cheers,
Paul


  reply	other threads:[~2017-05-23 14:22 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-22  6:17 [bitcoin-dev] Drivechain -- Request for Discussion Paul Sztorc
2017-05-22 13:33 ` Peter Todd
2017-05-22 15:30   ` Paul Sztorc
2017-05-28 21:07     ` Peter Todd
     [not found]       ` <CAJowKgJjNaoWVc=QXfOqH3OdBPoKm3qkfUNpKV6oKLSRx_fD0g@mail.gmail.com>
     [not found]         ` <CAJowKgKFMXDE-yzEqYkY7c+80Mgn+iL9ZRNJbv9WhUBR32EvRg@mail.gmail.com>
2017-05-29  5:54           ` Erik Aronesty
2017-05-30  5:11       ` Paul Sztorc
2017-06-09 21:54         ` Sergio Demian Lerner
2017-06-10 16:28           ` Paul Sztorc
2017-05-22 14:39 ` ZmnSCPxj
2017-05-22 16:19   ` Paul Sztorc
2017-05-22 19:12     ` Tier Nolan
2017-05-22 20:00       ` Paul Sztorc
2017-05-23  9:51         ` Tier Nolan
2017-05-23 14:22           ` Paul Sztorc [this message]
2017-05-24  8:50             ` Tier Nolan
2017-05-24 10:05               ` Tier Nolan
2017-05-24 17:32                 ` CryptAxe
2017-05-25 22:08                   ` Tier Nolan
2017-06-18 14:36               ` Chris Stewart
2017-06-18 21:27                 ` CryptAxe
     [not found]                   ` <CAGL6+mGZZ=wG8P_DNj3PXVf==mLjJwA_bESh0_UdH2iVBY7GQA@mail.gmail.com>
2017-06-19 15:41                     ` Chris Stewart
2017-05-23  0:13     ` ZmnSCPxj
2017-05-23 14:12       ` Paul Sztorc
2017-05-23 23:26         ` ZmnSCPxj
2017-06-10 17:04 ` [bitcoin-dev] Drivechain RfD -- Follow Up Paul Sztorc
2017-06-18 21:30   ` Tao Effect
2017-06-19 16:04     ` Paul Sztorc
     [not found]       ` <CAJowKgLJW=kJhcN4B7TbWXLb7U51tzYU3PFOy1m8JqKXqFsU4A@mail.gmail.com>
2017-06-20 11:54         ` Paul Sztorc
2017-06-20 13:38           ` Erik Aronesty
2017-06-22 13:27             ` Paul Sztorc
2017-06-22 13:45               ` Erik Aronesty
2017-06-22 20:30                 ` Paul Sztorc
2017-06-23 14:19                   ` Erik Aronesty
2017-06-23 14:51                     ` Moral Agent
2017-06-23 18:11                     ` Paul Sztorc
2017-07-12 22:43       ` Tao Effect
2017-07-13  0:26         ` Paul Sztorc
2017-07-13  1:15           ` Tao Effect
2017-07-13  2:58             ` Paul Sztorc
2017-07-13  3:24               ` Tao Effect
2017-07-13 15:39                 ` Paul Sztorc
2017-07-13 13:17               ` Hampus Sjöberg
2017-07-13 17:04                 ` Paul Sztorc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=141a0cd1-9d4f-c137-a349-17248f9cafd4@gmail.com \
    --to=truthcoin@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=tier.nolan@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox