[Bitcoin-development] BIP: Voluntary deposit bonds

[Bitcoin-development] BIP: Voluntary deposit bonds

[Sergio Lerner]

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.

Re: [Bitcoin-development] BIP: Voluntary deposit bonds

[Mike Hearn]

[-- 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 --]

Re: [Bitcoin-development] BIP: Voluntary deposit bonds

[Justus Ranvier]

[-- 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 --]

Re: [Bitcoin-development] BIP: Voluntary deposit bonds

[Luke Dashjr]

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

Re: [Bitcoin-development] BIP: Voluntary deposit bonds

[Luke Dashjr]

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

Re: [Bitcoin-development] BIP: Voluntary deposit bonds

[Gregory Maxwell]

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.

Re: [Bitcoin-development] BIP: Voluntary deposit bonds

[Jorge Timón]

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?

Re: [Bitcoin-development] BIP: Voluntary deposit bonds

[Justus Ranvier]

[-- 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 --]

Re: [Bitcoin-development] BIP: Voluntary deposit bonds

[Sergio Lerner]

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.

Re: [Bitcoin-development] BIP: Voluntary deposit bonds

[Gregory Maxwell]

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.

Re: [Bitcoin-development] BIP: Voluntary deposit bonds

[Stephen Morse]

[-- 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 --]

Re: [Bitcoin-development] BIP: Voluntary deposit bonds

[Peter Todd]

[-- 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 --]