pull down to refresh

Donating sats today for distant future block rewards (year 2140+)
1860 sats \ 17 comments \ @bitcoin_rationalist 28 Oct 2023 bitcoin
What if there was a way today to do this easily for non-techies like me? I can imagine a UX where I pick a block height in the future and then donate a few sats that would be awarded to the miner.
This could incentivize miners in the distant future to want to want to continue mining if there were pockets of donated sats in blocks after year 2140 (when a single sat would be extremely valuable).
I know Michael Dunworth has done this but his approach sounded super technical. I know plebs would part with some of their sats today to incentive future mining.
write
preview
related posts
1095 sats \ 1 reply \ @VzxPLnHqr 29 Oct 2023
A fun idea indeed! This is actually quite doable today (though not necessarily advisable). No fancy UI/UX is necessary though. Rather we can just a generate a big list of addresses. Then you can use the "send to many" feature in a wallet of your choosing you can send sats to future miners!
The locking script is a simple anyone can spend script <blockheight> OP_CHECKLOCKTIMEVERIFY When we wrap this script in a pay2sh or pay2wsh output (so that any transactions sending funds to it are still considered standard), then this means that future miners interested in spending such an output would need to know about it first or how to derive/check similar addresses, but it is not hard for them to do so.
Here is the pay2wsh address for a blockheight that will unlock somewhere near year 2140:
block number 6973063 (approximately end of year 2140): bc1qmqckte0sfhh8xyc6v7zswrs5mpjrrf2f5frwe2yz68lyy253m7qshzrdqn
Here is the code I used to generate it: https://gist.github.com/VzxPLnHqr/acc4fd4ee399196e7723a7d36a90834b#file-pay-to-future-sc
Here are some more addresses:
block number 7025623 (approximately end of year 2141): bc1que50q4j3rkz782y8m8s6xqzra32j8qmf0tsxaltlhayy6jr68phqekpu4r
block number 7078183 (approximately end of year 2142): bc1qxfagwc0v0gytcjy7zmq6wr73fndk7ltevwmak97xyd07q6fru8hs5vufs7
block number 7130743 (approximately end of year 2143): bc1q4ldz0stpet6qf0qzdqqswrhuhhw0hyj6ezxskh3q0785cwypn3kqmd6q42
block number 7183303 (approximately end of year 2144): bc1q7yvzu937xx4j5jvrr08qxu9ut9jmx82nk3qhltjk0tjt6qk7rkgs55s0eg
block number 7235863 (approximately end of year 2145): bc1qdhwu4x34z3yksq4ca4fnf2d7hp2nw3d8ne6va25j36f5p4u7kk0stm74ca
block number 7288423 (approximately end of year 2146): bc1qkwsj47mucut9cvcf66lwn8tzc75lzz2wdagqnzsl0vd0huee5ktqma3cke
block number 7340983 (approximately end of year 2147): bc1qw99zdp6z7xsxdk40lgu56582s8n5vhmga5hw5kzrtmq73v7r5weq4rw3p9
block number 7393543 (approximately end of year 2148): bc1qp7dc8849nkcpz35pmlj5a7tk6tj0r4t5yee8j8cr4fuqehxx5gyq547tzs
block number 7446103 (approximately end of year 2149): bc1qpaqd826nsdm503t3wv6pf0dfgy9f3adrpj865e3euqayp35443zq7es949
block number 7498663 (approximately end of year 2150): bc1qax770e6u4x08nhslue3chy4wtxt5rcll53542smk4qcwsyvzuk5qwcne09
block number 7551223 (approximately end of year 2151): bc1qqk4zw2652k5vg3ujxnndwc2ljphkjdgrl7u4k8p47dvm89wgga8qfsvs2z
block number 7603783 (approximately end of year 2152): bc1qzstkpf9pdqzvtpfr4v6mtkh3j4ssy7cyrmtlak223fga0yf4d94qttfujz
block number 7656343 (approximately end of year 2153): bc1qfkjyaezp03lnn85f42hp8zs0449zn0z7m0wsfxcyz6a6l7tt8wusenqycp
block number 7708903 (approximately end of year 2154): bc1ql2ycs7gudtcjpmajggkq2xzl6y34dheurgnd8ypaj33clhuahgzsz3ewl8
block number 7761463 (approximately end of year 2155): bc1qu9p2ydctxnvvjaektpqx5emfusez7343f68gu0hdfsr6r8ec993qe3k5m0
block number 7814023 (approximately end of year 2156): bc1qaqs0sc7d2a70737kmsv369zefmrr4jp9wn0xt4z6a4spd65c5d6s6d5q90
block number 7866583 (approximately end of year 2157): bc1qv2k3p0dt5kdj5qdeslqhzkk0cl4jf09f7tyd72tuhv50ancqqgrsntcejk
block number 7919143 (approximately end of year 2158): bc1q63s3y5c0d2fw32w9fkp7dzwfk3srz5u25t9dez4uea3uz0wh6lwqe5wumm
block number 7971703 (approximately end of year 2159): bc1qulvu323repmtena46snlem2md35qj2gn7t7etnjr3lqmsw0l7a0sdlqum3
Note: I did not have a chance to double check these. You should probably not send money to these addresses. Rather I just wanted to demonstrate that it would not be hard to create such a list, either statically or on-the-fly. There are also other types of addresses which would likely be cheaper from a fee standpoint.
reply
0 sats \ 0 replies \ @bitcoin_rationalist OP 29 Oct 2023
Badass!
reply
39 sats \ 3 replies \ @k00b 28 Oct 2023
I'm not sure how this would even work. You'd need to pay some kind of alias address for the unknowable miner of a block in the future.
Maybe if you publicized that a utxo had a spend condition that would allow anyone to spend it at X block height, miners would be sure that a height X they would spend it to themselves.
reply
10 sats \ 2 replies \ @bitcoin_rationalist OP 28 Oct 2023
I have no idea how it would work technically, or even if it’s possible. I just know that people would donate to the cause.
reply
10 sats \ 1 reply \ @anon 29 Oct 2023
It's very easy to do with CheckLockTimeVerify. Just create the address corresponding to the script:
<block height> CheckLockTimeVerify
Since there is no signature required, any miner can collect those funds with a spend-to-fees transaction.
reply
0 sats \ 0 replies \ @bitcoin_rationalist OP 29 Oct 2023
Raddd
reply
60 sats \ 2 replies \ @tolot 29 Oct 2023
That's thw first time I hear an idea like this...sounds interesting
The first idea that came to my mind is the fact that this would eventually change the incentives at the base layer, changing literally the reward scheme. This could be very very disruptive if adopted widely (which I doubt because why donate to miners if you can just can put high fees only when you need the tx to go through?)
Moreover, inventives wpuld change even for future miners. If the block 1'000'000 happens to have a total of 10btc worth of donations (ballpark figure) then miners would be incentivized to try to mine it even when the timechain state passed that blockheight. Imagine miners trying to win that block price and building every one its own fork to invalidate the other's chain ans win the reward of that block.
This is off course an extreme example, nobody really nows what would happen
My guess is that Bitcoin si build on top of protocol rules whereby the future of mining rewards will be one of this two:
  1. Fees increase at the point of replacing the coinbase value. This will lead to a protocol where onchain transactions are only created once in a while by big Layer2 providers (ex. some big LN hubs)
  2. Fees stay relatively low, meaning that the block reward isn't sufficient to sustain the mining industry. This would inevitably lead to a Mining ecosystem where bitcoin-focuses companies allocate some capital for the mining acitiviy, just to sustain the protocol's security and, as a matter of fact, the protocol on top of which their services are build.
The second scenario may be a little dangerous too, because it would mean that the bitcoin protocol is sustained by economical value that 'comes from outside of the protocol', which could undermine the Bitcoin's stabiliy.
reply
20 sats \ 1 reply \ @bitcoin_rationalist OP 29 Oct 2023
Good point regarding the incentives changing, that would not be good
reply
10 sats \ 0 replies \ @tolot 29 Oct 2023
I wouldn't say that is strictly 'not good', I simply observe that a change like that one would possibly flip a lot of incentives...which is something that we don't want to happen into Bitcoin
reply
50 sats \ 0 replies \ @jasonofbitcoin 28 Oct 2023
I believe this is the episode where Michael Dunworth describes what he did:
https://www.whatbitcoindid.com/podcast/solving-the-unsolvable-problems
reply
20 sats \ 0 replies \ @TheWildHustle 29 Oct 2023
It'll be crazy when the UI/UX around timelocks get better.
I'd love to reliably send sats to the future me.
reply
20 sats \ 3 replies \ @Bitman 28 Oct 2023
Love it. That's such a simple idea to that big, looming problem. Tackling it sooner, rather than later, really makes sense.
It could be an idea to start the donation drip feed a lot earlier - maybe when block rewards drops into the thousand or hundred sats range - scaling up as it goes.
We've grown accustomed to expect things to be solved by those 'better' than us - swinging in heroically to save the day.
The idea of plebs could starting early to mitigate this problem seems pretty plausible and in a way quite in the spirit of Bitcoin.
BTW I've not heard of this great idea before - care to share some links?
reply
30 sats \ 1 reply \ @bitcoin_rationalist OP 29 Oct 2023
Not a bad idea starting it early :)
This is where I heard Dunworth talking about it:
reply
20 sats \ 0 replies \ @Bitman 29 Oct 2023
Nice, thanks! It's got a great title too - 'Bitcoin is Time Traveling Energy'
reply
0 sats \ 0 replies \ @sudonaka 29 Oct 2023
It’s not a problem at all
reply
10 sats \ 1 reply \ @sudonaka 29 Oct 2023
This is psy op fud. It’s a misunderstanding of bitcoin and free markets.
We have already passed the point of transaction fees > block reward -Because of some stupid wizard pictures.
And this occurred during the 4th epoch- with more than 6.25 bitcoin transaction fees.
“Helping” miners in the future?
What do you think will happen to fees when nation-states (and their evolutions) are competing to settle global trade on the base chain in a timely manner?
We are the “OGs” who have actually made base chain transactions in an individual capacity.
reply
0 sats \ 0 replies \ @bitcoin_rationalist OP 29 Oct 2023
Love it
reply