public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Chris Stewart <chris@suredbits.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Sidechains: Mainstake
Date: Tue, 26 Sep 2017 12:51:50 -0500	[thread overview]
Message-ID: <CAGL6+mEXEzrWK0w58tXEzHWvMQLdUJVEcJ5wBiFO0ye0yrKaig@mail.gmail.com> (raw)
In-Reply-To: <rRLvSIAs4ZyW4YTai9d_ON_xV2HH6NlhRIsU2C9mzTKiGuXmtJjafTtmK9lJIgBYVNVRGcfKAWON_l2ZE9bKuqON11NXGoKKn1SOGXi8Dbs=@protonmail.com>

[-- Attachment #1: Type: text/plain, Size: 3066 bytes --]

>For each sidechain ID, for each mainchain block, at most one sidechain
block header may be published. In addition, the sidechain block header
published on the mainchain blocks may only be published by the stake
lottery winner from the end of the previous block.

What happens if the stake winner disappears? It seems, in your scheme, that
this would cause progress to come to a screeching halt.

Our weak mitigation against a mainchain miner >50% attack is weakened
> further; now the mainchain miner with 51% hashpower need only block the
> creation of sidechain mainstake UTXOs except its own, and eventually the
> other mainstake UTXOs will time out and the miner can outright steal
> costlessly


Can we not nest mainstake outputs in p2wsh/p2sh scripts to mitigate this?
This means that they cannot block the creation of mainstake utxos -- but I
guess they would still be able to block the spends of this utxo.

Another thing that is problematic with using a p2sh output is 'relocking'
the stake. Unfortunately if the p2sh script hash's aren't identical I don't
think we can guarantee they didn't spend the stake to a non stake output.
If the script hash's *are* identical then the miner can censor the
transaction that re-locks the output.

Perhaps there is a hybrid that would work, however it depends on what you
mean by 'creation'. If it is just the *initial* creation of the utxo -- and
not subsequent OP_STAKEVERIFY change outputs -- I think this strategy might
work. You just won't be able to participate in the lottery while the utxo
is nested inside the p2sh output initially.

This also brings back the problem above -- what if a stake winner
disappears -- or a miners creates the illusion they disappeared via
censorship? I guess a miner would be losing out on transaction fees.

-Chris



On Fri, Sep 22, 2017 at 8:49 PM, ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning bitcoin-dev,
>
> I have yet another sidechain proposal: https://zmnscpxj.github.io/
> sidechain/mainstake/index.html
>
> I make the below outlandish claims in the above link:
>
> 1. While a 51% mainchain miner theft is still possible, it will take even
> longer than in drivechains (either months of broadcasting intent to steal
> before the theft, or locking funds that are likely to remain locked after a
> week-long theft).
> 2. A 26% anti-sidechain miner cannot completely block all sidechain
> withdrawals as they could in drivechains.
> 3. Outside of attacks and censorship, the economic majority controls
> sidechains, without going through miners as "representatives of the
> economic majority".
> 4. With sufficient cleverness (stupidity?), proof-of-stake can be made to
> work.
>
> I hope for your consideration.  I suspect that I have not thought things
> out completely, and probably missed some significant flaw.
>
> Regards,
> ZmnSCPxj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 4239 bytes --]

  reply	other threads:[~2017-09-26 17:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-23  1:49 [bitcoin-dev] Sidechains: Mainstake ZmnSCPxj
2017-09-26 17:51 ` Chris Stewart [this message]
2017-09-26 22:38   ` ZmnSCPxj

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=CAGL6+mEXEzrWK0w58tXEzHWvMQLdUJVEcJ5wBiFO0ye0yrKaig@mail.gmail.com \
    --to=chris@suredbits.com \
    --cc=ZmnSCPxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /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