public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] An implementation of BIP102 as a softfork.
@ 2015-12-30  5:46 joe2015
  2015-12-30 10:33 ` Marco Falke
  2015-12-30 13:29 ` Jonathan Toomim
  0 siblings, 2 replies; 14+ messages in thread
From: joe2015 @ 2015-12-30  5:46 UTC (permalink / raw)
  To: bitcoin-dev

Below is a proof-of-concept implementation of BIP102 as a softfork:

https://github.com/ZoomT/bitcoin/tree/2015_2mb_blocksize
https://github.com/jgarzik/bitcoin/compare/2015_2mb_blocksize...ZoomT:2015_2mb_blocksize?diff=split&name=2015_2mb_blocksize

BIP102 is normally a hardfork.  The softfork version (unofficial
codename BIP102s) uses the idea described here:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012073.html

The basic idea is that post-fork blocks are constructed in such a way
they can be mapped to valid blocks under the pre-fork rules.  BIP102s
is a softfork in the sense that post-fork miners are still creating a
valid chain under the old rules, albeit indirectly.

 From the POV of non-upgraded clients, BIP102s circumvents the
block-size limit by moving transaction validation data "outside" of
the block.  This is a similar trick used by Segregated Witness and
Extension Blocks (both softfork proposals).

 From the POV of upgraded clients, the block layout is unchanged,
except:
- A larger 2MB block-size limit (=BIP102);
- The header Merkle root has a new (backwards compatible)
   interpretation;
- The coinbase encodes the Merkle root of the remaining txs.
Aside from this, blocks maintain their original format, i.e. a block
header followed by a vector of transactions.  This keeps the
implementation simple, and is distinct from SW and EB.

Since BIP102s is a softfork it means that:
- A miner majority (e.g. 75%, 95%) force miner consensus (100%).  This
   is not true for a hardfork.
- Fraud risk is significantly reduced (6-conf unlikely depending on
   activation threshold).
This should address some of the concerns with deploying a block-size
increase using a hardfork.

Notes:

- The same basic idea could be adapted to any of the other proposals
   (BIP101, 2-4-8, BIP202, etc.).
- I used Jeff Garzik's BIP102 implementation which is incomplete (?).
   The activation logic is left unchanged.
- I am not a Bitcoin dev so hopefully no embarrassing mistakes in my
   code :-(

--joe



^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] An implementation of BIP102 as a softfork.
@ 2015-12-30 11:16 Martijn Meijering
  2015-12-30 14:28 ` Peter Todd
  0 siblings, 1 reply; 14+ messages in thread
From: Martijn Meijering @ 2015-12-30 11:16 UTC (permalink / raw)
  To: bitcoin-dev

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

That looks very interesting. But is effectively blocking old clients from
seeing transactions really safe? After all, such transactions are still
confirmed on the new chain. A person might try to send a similar
transaction several times, perhaps with increasing fees in an attempt to
get it to confirm and end up paying someone several times.

Maybe we could require the tx version number to be increased as well so
transactions sent from old clients would never confirm? Perhaps your code
already includes this idea, I need to look at it more closely.

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2016-01-12  3:59 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-30  5:46 [bitcoin-dev] An implementation of BIP102 as a softfork joe2015
2015-12-30 10:33 ` Marco Falke
2015-12-30 16:27   ` joe2015
     [not found]     ` <CAKJqnrE7W8aRgracL1cy_hBLWpVsTAQL4qg4ViSP9aCHvM1yvA@mail.gmail.com>
2016-01-03  3:51       ` joe2015
2016-01-04 18:04         ` Nick ODell
2016-01-05  1:26           ` joe2015
2016-01-12  3:58             ` joe2015
2015-12-30 13:29 ` Jonathan Toomim
2015-12-30 13:57   ` Marcel Jamin
2015-12-30 14:19   ` Peter Todd
2015-12-30 14:31     ` Peter Todd
2015-12-30 15:00     ` Jonathan Toomim
2015-12-30 11:16 Martijn Meijering
2015-12-30 14:28 ` Peter Todd

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox