Adam Back [ARCHIVE] on Nostr: 📅 Original date posted:2013-05-14 📝 Original message:On Tue, May 14, 2013 at ...
📅 Original date posted:2013-05-14
📝 Original message:On Tue, May 14, 2013 at 12:50:27PM -0400, Jeff Garzik wrote:
>> Well if it is a later transaction, not an integral part of the reward
>> transaction (that is definitionally mined by being serialized into the
>> coinbase), the user may elect to withhold the promised transaction
>> give-to-miner, so thats not so good. [...]
>[...]
>Just referring to a standard, fee-bearing, user-created bitcoin
>transaction, where output_value < input_value. The fee is paid to the
>first miner who includes that transaction in a block, as part of the
>protocol.
Yes but thats inferior in the sense that it is spamming the bitcoin payment
protocol slightly, to the small reward of miners, and involves actual money
and traceability to real-name (where did you get the coin from to spend).
If alternatively you just proof you direct mined on a block with a coinbase
that immediately makes payment to future miners its better because: a) you
can do that with no new traffic for the bitcoin network (except when you
mine a whole block, you'll post it); and b) anyone with a reasonable
verification on the blockchain head (even if the spender has to give it to
them!) can verify it without any other network traffic; and c) if its
micro-mined on the spot it can be bound to the service whereas if you give
it to fees as an on network transaction you are limited to values above the
min tx fee.
So idealy I think you need to be able to simultanously mine and give reward
to future block miners.
What you could do with out that is d) mine for the reward of bitcoin
foundation/software author/or service provider. In the last case (service
provider) its an extreme form of Rivests peppercoin probabilistic payment
Adam
📝 Original message:On Tue, May 14, 2013 at 12:50:27PM -0400, Jeff Garzik wrote:
>> Well if it is a later transaction, not an integral part of the reward
>> transaction (that is definitionally mined by being serialized into the
>> coinbase), the user may elect to withhold the promised transaction
>> give-to-miner, so thats not so good. [...]
>[...]
>Just referring to a standard, fee-bearing, user-created bitcoin
>transaction, where output_value < input_value. The fee is paid to the
>first miner who includes that transaction in a block, as part of the
>protocol.
Yes but thats inferior in the sense that it is spamming the bitcoin payment
protocol slightly, to the small reward of miners, and involves actual money
and traceability to real-name (where did you get the coin from to spend).
If alternatively you just proof you direct mined on a block with a coinbase
that immediately makes payment to future miners its better because: a) you
can do that with no new traffic for the bitcoin network (except when you
mine a whole block, you'll post it); and b) anyone with a reasonable
verification on the blockchain head (even if the spender has to give it to
them!) can verify it without any other network traffic; and c) if its
micro-mined on the spot it can be bound to the service whereas if you give
it to fees as an on network transaction you are limited to values above the
min tx fee.
So idealy I think you need to be able to simultanously mine and give reward
to future block miners.
What you could do with out that is d) mine for the reward of bitcoin
foundation/software author/or service provider. In the last case (service
provider) its an extreme form of Rivests peppercoin probabilistic payment
Adam