* [Bitcoin-development] BIP: Voluntary deposit bonds
@ 2014-12-29 19:21 Sergio Lerner
2014-12-29 21:10 ` Mike Hearn
` (3 more replies)
0 siblings, 4 replies; 12+ messages in thread
From: Sergio Lerner @ 2014-12-29 19:21 UTC (permalink / raw)
To: bitcoin-development
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.
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [Bitcoin-development] BIP: Voluntary deposit bonds 2014-12-29 19:21 [Bitcoin-development] BIP: Voluntary deposit bonds Sergio Lerner @ 2014-12-29 21:10 ` Mike Hearn 2014-12-29 21:34 ` Justus Ranvier 2014-12-29 22:36 ` Luke Dashjr 2014-12-29 22:35 ` Luke Dashjr ` (2 subsequent siblings) 3 siblings, 2 replies; 12+ messages in thread From: Mike Hearn @ 2014-12-29 21:10 UTC (permalink / raw) To: Sergio Lerner; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 186 bytes --] 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? [-- Attachment #2: Type: text/html, Size: 307 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] BIP: Voluntary deposit bonds 2014-12-29 21:10 ` Mike Hearn @ 2014-12-29 21:34 ` Justus Ranvier 2014-12-30 10:47 ` Jorge Timón 2014-12-29 22:36 ` Luke Dashjr 1 sibling, 1 reply; 12+ messages in thread From: Justus Ranvier @ 2014-12-29 21:34 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1193 bytes --] -----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. - -- Justus Ranvier | Monetas <http://monetas.net/> <mailto:justus@monetas•net> | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJUocjPAAoJEMP3uyY4RQ21zrMH/1f3vjac9XqOZbDItjiD6XXU EkpRUROjyQAs6/tO6dwWAIcXgulYREAJsU/udQNkTYteIDFlDzwkYL+NLXpYtwHs BiZJEEwmAEHFgOD3QmmqhTx867zIbEYIB/dpHlMOppE6fhTKFr9z6JdqAKlNcHHW tkW5sq8q9uq7StiUs3/mmZ0XXeEb84N+bPiJ9S7kuTm9QWnrF1oMLhAk4M6yX8hn 7MUowmfc9RZ4uIFkqxk6gkWJSRx7dlnCRP2TRhyABpZwAcZANuPhqBOZ6eJ6T9Fs DOJ14c5JYachXW5z8GqR+abeq0JPE76kEQt145B4degJ4DTQLLhlfdvjbuJvzy4= =Kfe2 -----END PGP SIGNATURE----- [-- Attachment #2: 0x38450DB5.asc --] [-- Type: application/pgp-keys, Size: 14542 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] BIP: Voluntary deposit bonds 2014-12-29 21:34 ` Justus Ranvier @ 2014-12-30 10:47 ` Jorge Timón 2014-12-30 13:16 ` Justus Ranvier 0 siblings, 1 reply; 12+ messages in thread From: Jorge Timón @ 2014-12-30 10:47 UTC (permalink / raw) To: Justus Ranvier; +Cc: Bitcoin Dev On Mon, Dec 29, 2014 at 10:34 PM, Justus Ranvier <justus.ranvier@monetas•net> wrote: > -----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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] BIP: Voluntary deposit bonds 2014-12-30 10:47 ` Jorge Timón @ 2014-12-30 13:16 ` Justus Ranvier 0 siblings, 0 replies; 12+ messages in thread From: Justus Ranvier @ 2014-12-30 13:16 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1574 bytes --] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/30/2014 10:47 AM, Jorge Timón wrote: > 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 -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJUoqXIAAoJEMP3uyY4RQ21OZUH/iI9N9bQ3TLPnmCVW6bkIitD WT6uBUhBREls2NMjyDQ//UN9F9nt+aU7jN/I0AMrdB8ngFb4r1gfxSpld9KVp6Yw k3jW8Lo3WhTnCCE0a1MbBqomsAfIwDdksZoH73QW+sGYD+cShgFC55QWfE6gy3OF pge1dsWNPlMSHmWn9+g7g3+FjkhKeZFNSb0MKzIvEBE7iJOf85etJpMs9a/425sx UcJX33bVdhG51Au3PSs+0jUljoFby28EM717otq8Tkjei2hw1yNNmtws4/NcQlh3 W6TGBZLb188hUrOOH52p2Cckm8gGgw9hTc9nSLSjQS2pPjVRpTRR4smxMTKND9E= =QBYE -----END PGP SIGNATURE----- [-- Attachment #2: 0x38450DB5.asc --] [-- Type: application/pgp-keys, Size: 14542 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] BIP: Voluntary deposit bonds 2014-12-29 21:10 ` Mike Hearn 2014-12-29 21:34 ` Justus Ranvier @ 2014-12-29 22:36 ` Luke Dashjr 1 sibling, 0 replies; 12+ messages in thread From: Luke Dashjr @ 2014-12-29 22:36 UTC (permalink / raw) To: bitcoin-development On Monday, December 29, 2014 9:10:20 PM Mike Hearn wrote: > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] BIP: Voluntary deposit bonds 2014-12-29 19:21 [Bitcoin-development] BIP: Voluntary deposit bonds Sergio Lerner 2014-12-29 21:10 ` Mike Hearn @ 2014-12-29 22:35 ` Luke Dashjr 2014-12-30 4:51 ` Gregory Maxwell 2015-01-03 3:48 ` Peter Todd 3 siblings, 0 replies; 12+ messages in thread From: Luke Dashjr @ 2014-12-29 22:35 UTC (permalink / raw) To: Sergio Lerner; +Cc: bitcoin-development On Monday, December 29, 2014 7:21:02 PM 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 something I've wanted since 2011, but hasn't been a priority. > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] BIP: Voluntary deposit bonds 2014-12-29 19:21 [Bitcoin-development] BIP: Voluntary deposit bonds Sergio Lerner 2014-12-29 21:10 ` Mike Hearn 2014-12-29 22:35 ` Luke Dashjr @ 2014-12-30 4:51 ` Gregory Maxwell 2014-12-30 16:25 ` Sergio Lerner 2015-01-03 3:48 ` Peter Todd 3 siblings, 1 reply; 12+ messages in thread From: Gregory Maxwell @ 2014-12-30 4:51 UTC (permalink / raw) To: Sergio Lerner; +Cc: bitcoin-development 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). > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] BIP: Voluntary deposit bonds 2014-12-30 4:51 ` Gregory Maxwell @ 2014-12-30 16:25 ` Sergio Lerner 2014-12-30 18:28 ` Gregory Maxwell 0 siblings, 1 reply; 12+ messages in thread From: Sergio Lerner @ 2014-12-30 16:25 UTC (permalink / raw) Cc: bitcoin-development On 30/12/2014 01:51 a.m., Gregory Maxwell wrote: > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] BIP: Voluntary deposit bonds 2014-12-30 16:25 ` Sergio Lerner @ 2014-12-30 18:28 ` Gregory Maxwell 2014-12-31 18:25 ` Stephen Morse 0 siblings, 1 reply; 12+ messages in thread From: Gregory Maxwell @ 2014-12-30 18:28 UTC (permalink / raw) To: Sergio Lerner; +Cc: bitcoin-development 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] BIP: Voluntary deposit bonds 2014-12-30 18:28 ` Gregory Maxwell @ 2014-12-31 18:25 ` Stephen Morse 0 siblings, 0 replies; 12+ messages in thread From: Stephen Morse @ 2014-12-31 18:25 UTC (permalink / raw) To: Gregory Maxwell; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 3241 bytes --] 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: > 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 > [-- Attachment #2: Type: text/html, Size: 4184 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bitcoin-development] BIP: Voluntary deposit bonds 2014-12-29 19:21 [Bitcoin-development] BIP: Voluntary deposit bonds Sergio Lerner ` (2 preceding siblings ...) 2014-12-30 4:51 ` Gregory Maxwell @ 2015-01-03 3:48 ` Peter Todd 3 siblings, 0 replies; 12+ messages in thread From: Peter Todd @ 2015-01-03 3:48 UTC (permalink / raw) To: Sergio Lerner; +Cc: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2015-01-03 3:48 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-12-29 19:21 [Bitcoin-development] BIP: Voluntary deposit bonds 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 is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox