public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Sergio Lerner <sergiolerner@certimix.com>
To: bitcoin-development <bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] BIP: Voluntary deposit bonds
Date: Mon, 29 Dec 2014 16:21:02 -0300	[thread overview]
Message-ID: <54A1A99E.1020604@certimix.com> (raw)

I propose to allow miners to voluntarily lock funds by letting miners
add additional inputs to the coinbase transaction. Currently the
coinbase transaction does not allow any real input  to be added (only a
pseudo-input).
This is a hard-fork, and we could include it the next time a hardfork is
made.
The modifications to the code are minimal (no more than 12 lines
modified where IsCoinBase() is called), and they generally involve
removing code, not adding.

Why ?

Because sometime in the future (maybe 5-10 years) we may have to deal
with problems of securing the blockchain, as the subsidy is lowered. We
don't want the number of confirmation blocks to be increased in
compensation because Bitcoin won't be able to compete with other payment
networks.
Then by having this hardfork now, we will be able to soft-fork later to
any rule we may came come up with involving deposit bonds,
proof-of-stake, and the penalization of double-mining (mining two blocks
at the same height) to prevent short-range attacks.

Can it hurt?

No. I doesn't not change the incentives or the security in any way, as
adding additional inputs to the coinbase transaction would be voluntary
until the time for a soft-fork comes.
We shouldn't hard-fork for this change only, but maybe we could do this
change when the next hard-fork is scheduled (when we increase the block
size?).

Regards, S.











             reply	other threads:[~2014-12-29 19:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-29 19:21 Sergio Lerner [this message]
2014-12-29 21:10 ` [Bitcoin-development] BIP: Voluntary deposit bonds Mike Hearn
2014-12-29 21:34   ` Justus Ranvier
2014-12-30 10:47     ` Jorge Timón
2014-12-30 13:16       ` Justus Ranvier
2014-12-29 22:36   ` Luke Dashjr
2014-12-29 22:35 ` Luke Dashjr
2014-12-30  4:51 ` Gregory Maxwell
2014-12-30 16:25   ` Sergio Lerner
2014-12-30 18:28     ` Gregory Maxwell
2014-12-31 18:25       ` Stephen Morse
2015-01-03  3:48 ` Peter Todd

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=54A1A99E.1020604@certimix.com \
    --to=sergiolerner@certimix.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /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