From: Peter Todd <pete@petertodd•org>
To: Sergio Lerner <sergiolerner@certimix•com>
Cc: bitcoin-development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] BIP: Voluntary deposit bonds
Date: Fri, 2 Jan 2015 22:48:29 -0500 [thread overview]
Message-ID: <20150103034829.GP6538@savin.petertodd.org> (raw)
In-Reply-To: <54A1A99E.1020604@certimix.com>
[-- Attachment #1: Type: text/plain, Size: 2407 bytes --]
On Mon, Dec 29, 2014 at 04:21:02PM -0300, Sergio Lerner wrote:
> 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
It definitely does change the incentives as it makes it easy and secure
to pay miners to mine specific blocks rather than specific transactions.
For instance I could securely pay a miner to mine a re-org in a specific
way, something I can't do right now. From the perspective of "the
blockchain must move forward" this is worrying. I have proposed this
idea before myself for my PowPay(1) micropayments scheme, but on
reflection I don't think it's a good idea anymore.
PowPay in general is an idea I'm now rather dubious about: it works much
better with large mining pools, which would further incentivise pools to
get bigger. In general we want mining to be dumber, not smarter, to keep
the overhead of it as small as possible to getting into it is as easy as
possible.
re: hard-fork vs. soft-fork, Gregory Maxwell's comments elsewhere in the
thread are what I'd say myself.
1) [Bitcoin-development] Coinbase TxOut Hashcash,
Peter Todd, May 10th 2013,
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02159.html
--
'peter'[:-1]@petertodd.org
000000000000000008bb7f424d81b7a0ea568086f4d320c2867705f88c27bb0a
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
prev parent reply other threads:[~2015-01-03 3:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-29 19:21 Sergio Lerner
2014-12-29 21:10 ` 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 [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=20150103034829.GP6538@savin.petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=sergiolerner@certimix$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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