From: 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:51:26 +0100 [thread overview]
Message-ID: <CAE-z3OVWXN58X-+nAFTm61G1=v_1xrniyrBy8x=VRG4N149aXQ@mail.gmail.com> (raw)
In-Reply-To: <CA+XQW1hRhcxJBoOJ57YG0t5y5j1Qm3RO4wr2eXV5V-UzDaiPPw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3102 bytes --]
On Mon, May 22, 2017 at 9:00 PM, Paul Sztorc <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).
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?
[-- Attachment #2: Type: text/html, Size: 4489 bytes --]
next prev parent reply other threads:[~2017-05-23 9:51 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-22 6:17 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 [this message]
2017-05-23 14:22 ` Paul Sztorc
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='CAE-z3OVWXN58X-+nAFTm61G1=v_1xrniyrBy8x=VRG4N149aXQ@mail.gmail.com' \
--to=tier.nolan@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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