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
Published at
2023-06-07 15:01:47Event JSON
{
"id": "84a64f28edc74602f0f54cf3fb97baf535b7a3357eecd00f4729e5c4268d9b91",
"pubkey": "ee0fa66772f633411e4432e251cfb15b1c0fe8cd8befd8b0d86eb302402a8b4a",
"created_at": 1686150107,
"kind": 1,
"tags": [
[
"e",
"3d231ffbf2b23d1e927eb23a9615f524e90075cdb16538107339b1567211693b",
"",
"root"
],
[
"e",
"e99e94e031a0e4fd2432165e31191bd3235519482579722b3c0d0c461a076062",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "📅 Original date posted:2013-05-14\n📝 Original message:On Tue, May 14, 2013 at 12:50:27PM -0400, Jeff Garzik wrote:\n\u003e\u003e Well if it is a later transaction, not an integral part of the reward\n\u003e\u003e transaction (that is definitionally mined by being serialized into the\n\u003e\u003e coinbase), the user may elect to withhold the promised transaction\n\u003e\u003e give-to-miner, so thats not so good. [...]\n\u003e[...]\n\u003eJust referring to a standard, fee-bearing, user-created bitcoin\n\u003etransaction, where output_value \u003c input_value. The fee is paid to the\n\u003efirst miner who includes that transaction in a block, as part of the\n\u003eprotocol.\n\nYes but thats inferior in the sense that it is spamming the bitcoin payment\nprotocol slightly, to the small reward of miners, and involves actual money\nand traceability to real-name (where did you get the coin from to spend). \n\nIf alternatively you just proof you direct mined on a block with a coinbase\nthat immediately makes payment to future miners its better because: a) you\ncan do that with no new traffic for the bitcoin network (except when you\nmine a whole block, you'll post it); and b) anyone with a reasonable\nverification on the blockchain head (even if the spender has to give it to\nthem!) can verify it without any other network traffic; and c) if its\nmicro-mined on the spot it can be bound to the service whereas if you give\nit to fees as an on network transaction you are limited to values above the\nmin tx fee. \n\nSo idealy I think you need to be able to simultanously mine and give reward\nto future block miners.\n\nWhat you could do with out that is d) mine for the reward of bitcoin\nfoundation/software author/or service provider. In the last case (service\nprovider) its an extreme form of Rivests peppercoin probabilistic payment\n\nAdam",
"sig": "c20144aead0863588154132b64a03fcbe2fc6ad0a8df59c1c718788dceb663c8c9fed530bc37972d5324dd249d67859866483aacbcc39402935306ec6697234f"
}