public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: yanmaani@cock.li
To: Christopher Gilliard <christopher.gilliard@gmail.com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF
Date: Tue, 20 Apr 2021 01:22:51 +0000	[thread overview]
Message-ID: <bfea86cbe0d63df5219b77ca2409cea1@cock.li> (raw)
In-Reply-To: <CAK=nyAxOa8fsVfxucH7WTTMn25BCzgQ28h_sNsunedpCoRXjjQ@mail.gmail.com>

This has already been discussed and proposed in various papers and 
articles, typically to replace SHA-256d with something else. It 
basically works, but there's a some tiny issues:

1) Who goes first?

If you first calculate the expensive PoW and then do a cheap SHA-256d 
around it, anyone can malleate it by changing the outer PoW.

If you first calculate the cheap SHA-256d and then do an expensive PoW 
around it, it would work, but then you would have to retool the P2P 
protocol.

2) What's the incentive for miners?

In a "normal" soft-fork, miners have the incentive to upgrade because 
their blocks will be orphaned if they don't, and even the old clients 
won't accept them.

Here, miners will be able to produce an alternate chain that will appear 
valid to old clients, and that the new miners won't be able to orphan 
(since their hash power is much weaker).


      parent reply	other threads:[~2021-04-20  1:22 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-16  7:45 [bitcoin-dev] BIP - limiting OP_RETURN / HF Christopher Gilliard
2021-04-16 13:56 ` Russell O'Connor
2021-04-16 15:34   ` Christopher Gilliard
2021-04-16 15:55     ` Andrew Poelstra
2021-04-16 23:52     ` ZmnSCPxj
2021-04-17  3:57       ` Christopher Gilliard
2021-04-17 15:50         ` Peter Todd
2021-04-17 16:57           ` Christopher Gilliard
2021-04-16 13:59 ` Clark Moody
2021-04-16 15:33   ` Christopher Gilliard
2021-04-16 16:32 ` Jeremy
2021-04-16 17:05   ` Christopher Gilliard
2021-04-16 18:00     ` Jeremy
2021-04-16 19:15 ` Kostas Karasavvas
2021-04-16 20:12   ` Christopher Gilliard
2021-04-17  7:41     ` Kostas Karasavvas
2021-04-16 20:30   ` Ruben Somsen
2021-04-16 21:09     ` Christopher Gilliard
2021-04-20  1:23     ` yanmaani
2021-04-20  8:45       ` Zach Greenwood
2021-04-20 17:12         ` Christopher Gilliard
2021-04-20 19:07       ` Ruben Somsen
2021-05-03  5:17         ` ZmnSCPxj
2021-05-04 12:51           ` Ruben Somsen
2021-04-20  1:22 ` yanmaani [this message]

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=bfea86cbe0d63df5219b77ca2409cea1@cock.li \
    --to=yanmaani@cock.li \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=christopher.gilliard@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