BIP: Voluntary deposit bonds
12 messages, 29 Dec 2014 to 3 Jan 2015. Started by Sergio Lerner.
Sergio Lerner (2), Justus Ranvier (2), Luke Dashjr (2), Greg Maxwell (2), Mike Hearn, Jorge Timón, Stephen Morse, Peter Todd
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.
Could you explain a bit further Sergio? I'm not sure I fully understand the proposal.
How does adding inputs to a coinbase differ from just having pay-to-fee transactions in the block?
On 12/29/2014 09:10 PM, Mike Hearn wrote:
Quoted text (2 lines)
> How does adding inputs to a coinbase differ from just having > pay-to-fee transactions in the block?
If a miner includes pay-to-fee transactions in a block, those fees could be claimed by another miner in the case the first miner's block is orphaned.
Inputs to a generation transaction can not be similarly poached.
That difference makes some services possible that would can not be safely achieved with pay-to-fee transactions.
- -- Justus Ranvier | Monetas <http://monetas.net/> <mailto:justus@monetas.net> | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
On Monday, December 29, 2014 7:21:02 PM Sergio Lerner wrote:
Quoted text (4 lines)
> 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 something I've wanted since 2011, but hasn't been a priority.
Quoted text (9 lines)
> 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.
I'm not sure this increases the priority of it.
If someone feels it's worth the time, I'd suggest coding up a branch that hardforks it in at some far-off block height. Even if it doesn't get merged right away, at least the code will be available for testing and ready to go when/if that time comes.
Luke
On Monday, December 29, 2014 9:10:20 PM Mike Hearn wrote:
Quoted text (2 lines)
> How does adding inputs to a coinbase differ from just having pay-to-fee > transactions in the block?
Pay-to-fee transactions can be "stolen" by another block at the same or greater height. Additional inputs to the generation transaction are tied to that block alone.
Luke
On Mon, Dec 29, 2014 at 7:21 PM, Sergio Lerner <sergiolerner@certimix•com> wrote:
Quoted text (9 lines)
> 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.
If the motivation is purely enabling different rules in a soft-fork than I think nothing needs to be done.
Instead of providing inputs to a coinbase: you provide an unusual anyone can spend transaction in the block which pays to fees; and simultaneously add a soft-forking rule that makes that anyone can spend rule no longer anyone can spend.
To make that more concrete. E.g. You make your anyone can spend output "PUSH<hash of coinbase output script_pubkeys> OP_NOP3". Now this anyone can pay transaction is really just a coinbase input.
The construction is reasonably efficient, and also more flexible-- in that it could control the data under the hash in more flexible ways than available in the existing sighash flags.
As an aside, I'm not sure that I agree with the claim that making coinbases have inputs is a simple modification... as we use one of the inputs already as the special coinbase field and at least that must be special cased.
On Mon, Dec 29, 2014 at 10:34 PM, Justus Ranvier <justus.ranvier@monetas•net> wrote:
Quoted text (15 lines)
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 12/29/2014 09:10 PM, Mike Hearn wrote: >> How does adding inputs to a coinbase differ from just having >> pay-to-fee transactions in the block? > > If a miner includes pay-to-fee transactions in a block, those fees > could be claimed by another miner in the case the first miner's block > is orphaned. > > Inputs to a generation transaction can not be similarly poached. > > That difference makes some services possible that would can not be > safely achieved with pay-to-fee transactions.
What services? I must be missing something obvious about the motivation. I understand the difference between "paying to myself only when I mine the next block" and "offering fees to whoever mines this tx". But how does allowing miners to pay to themselves in this way help with security and future lower subsidies at all?
On 12/30/2014 10:47 AM, Jorge Timón wrote:
Quoted text (5 lines)
> What services? I must be missing something obvious about the > motivation. I understand the difference between "paying to myself > only when I mine the next block" and "offering fees to whoever > mines this tx". But how does allowing miners to pay to themselves > in this way help with security and future lower subsidies at all?
I don't know what Sergio Lernet meant about miners paying themselves and future network security.
If miners wanted to offer value-added services, especially if those services involved adding specific scripts to the outputs of the generation transaction, the most natural way for their customers to pay them is to allow inputs to the generation transaction.
It could also be done with pay-to-fee transactions, but that would make the services more expensive due to risk premium.
- -- Justus Ranvier | Monetas <http://monetas.net/> <mailto:justus@monetas.net> | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
On 30/12/2014 01:51 a.m., Gregory Maxwell wrote:
Quoted text (11 lines)
> On Mon, Dec 29, 2014 at 7:21 PM, Sergio Lerner > <sergiolerner@certimix•com> 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). >> > > To make that more concrete. E.g. You make your anyone can spend > output "PUSH<hash of coinbase output script_pubkeys> OP_NOP3". Now > this anyone can pay transaction is really just a coinbase input.
Slight off-topic: That looks like an abuse of the VM. Even P2SH is an abuse of the VM. Gavin's OP_EVAL (hard-fork) should had been chosen. I'm taking about a simple change that goes along the lines of Satoshi's original design. Bitcoin was a beautiful design, and extra complexity is making it ugly. We need Bitcoin to be simple to understand for new programmers so they can keep the project going. It doesn't help the project that one needs to be a guru to code for Bitcoin.
On Tue, Dec 30, 2014 at 4:25 PM, Sergio Lerner <sergiolerner@certimix•com> wrote:
Quoted text (8 lines)
> Slight off-topic: > That looks like an abuse of the VM. Even P2SH is an abuse of the VM. > Gavin's OP_EVAL (hard-fork) should had been chosen. I'm taking about a > simple change that goes along the lines of Satoshi's original design. > Bitcoin was a beautiful design, and extra complexity is making it ugly. > We need Bitcoin to be simple to understand for new programmers so they > can keep the project going. It doesn't help the project that one needs > to be a guru to code for Bitcoin.
Sergio there is no "abuse" there, OP_NOP3 in that case would be redefined to OP_COINBASE_FOO_CONSISTENCY.
(I say FOO because it's not clear what rule you actually hope to apply there.)
What you suggested has no purpose by itself: it would need an additional change which overlays functionality in order to actually do something. Such a change would likely be "ugly"-- it's easy to be elegant when you do nothing.
I agree with Gregory Maxwell, I don't think it would be as easy as just changing IsCoinBase(), since there are places where the code assumes that the coinbase's vin doesn't spend any prevouts and/or has size 1. For example, here <https://github.com/bitcoin/bitcoin/blob/v0.9.3/src/main.cpp#L617-620> and here <https://github.com/bitcoin/bitcoin/blob/v0.9.3/src/main.cpp#L785-L808> .
I think the motivation behind the original suggestion is to have a way to pay specific miners upon solving a block without risking possibly paying other miners through pay-to-fee. What I'm not sure about, though, is why not just send them a transaction once you see that the miner has solved a block? Not a pay-to-fee transaction, a pay to pubkeyhash or whatever type of transaction you need to make to send the miner some coins.
Although I don't completely understand the motivation for making such transactions, maybe this would this work. Have outputs in the coinbase transaction which have nValue == 0, then only apply the COINBASE_MATURITY rule to spending coinbase outputs which have non-zero value. That way you could make a transactions which is only valid after the miner specified solves a block with the coinbase having the same TxID referenced by the new transaction's input. It's still a hard fork, but might be easier than allowing the coinbase to spend prevouts. I guess, at that point though, why not just hard fork to allow the coinbase to spend prevouts...
Best, Stephen
On Tue, Dec 30, 2014 at 1:28 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
Quoted text (35 lines)
> On Tue, Dec 30, 2014 at 4:25 PM, Sergio Lerner > <sergiolerner@certimix•com> wrote: > > Slight off-topic: > > That looks like an abuse of the VM. Even P2SH is an abuse of the VM. > > Gavin's OP_EVAL (hard-fork) should had been chosen. I'm taking about a > > simple change that goes along the lines of Satoshi's original design. > > Bitcoin was a beautiful design, and extra complexity is making it ugly. > > We need Bitcoin to be simple to understand for new programmers so they > > can keep the project going. It doesn't help the project that one needs > > to be a guru to code for Bitcoin. > > Sergio there is no "abuse" there, OP_NOP3 in that case would be > redefined to OP_COINBASE_FOO_CONSISTENCY. > > (I say FOO because it's not clear what rule you actually hope to apply > there.) > > What you suggested has no purpose by itself: it would need an > additional change which overlays functionality in order to actually do > something. Such a change would likely be "ugly"-- it's easy to be > elegant when you do nothing. > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >
On Mon, Dec 29, 2014 at 04:21:02PM -0300, Sergio Lerner wrote:
Quoted text (25 lines)
> 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