Tier Nolan [ARCHIVE] on Nostr: š Original date posted:2017-05-23 š Original message:On Mon, May 22, 2017 at ...
š
Original date posted:2017-05-23
š Original message:On Mon, May 22, 2017 at 9:00 PM, Paul Sztorc <truthcoin at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170523/69551868/attachment.html>;
š Original message:On Mon, May 22, 2017 at 9:00 PM, Paul Sztorc <truthcoin at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170523/69551868/attachment.html>;