One observation about these out-of-band non-atomic accelerators is that the fee is earned/spendable immediately by miners. This is because the fee is not included in the coinbase output and hence not locked for 100 blocks the way that mining rewards are supposed to be.
It may not be something to worry about right now, but in the far future, if somehow most transactions end up paying their fees out of band, then the network security may suffer. Would be curious to get @petertodd 's take on this.
It is experimental, but there is also nixos-airgapped.
I agree that we need to be very very cautious about changing anything with regard to the incentive structure.
That being said, it does feel like current incentives are not as aligned as they could be. I have not yet read the specific post that you linked on bitcoin-dev, but here is one of my favorite (soft-fork) ideas which might better align incentives:
example soft-fork w/ burning: require all transactions over a certain size (including witness) to include an op_return output which burns a certain number of sats/byte
Burning sats is not a very popular idea. If need be, we could probably replace burning with a suitably long timelocked
anyone_can_spend output, something like 10 or 15 years would be my preference. Then it is almost like burning, but the sats still are available to be (re)mined in the future.This mechanism still has some vulnerabilities (for example, people would probably just chop their larger transactions into smaller transactions to get under the limit, so more research is certainly necessary), but the idea of burning sats is at least interesting to me because it fairly (proportionally and instantly) rewards all remaining hodlers -- and the node operators we care most about and want to protect are the hodlers. These are the people who are in bitcoin for the long run.
At least then when your node is verifying all these large transactions, every time you get to the op_return output, you get a little bit richer and, by definition, the creator of that offending transaction gets a little bit poorer.
This seems like a very reasonable and useful solution. Then each LN node simply runs a nostr client. Is anyone working on that?
Right, that is actually why I am trying to focus more on the error-correction aspect of this. Using a secure hash function for checksum calculation (as in the bip39 spec) helps determine that there is an error but it does not identify where the error is nor help correct it.
Reed-Solomon error correcting codes are more what I am seeking, but it is non-trivial to make those work for permutations.
Anyway, there seems to be less interest/activity in this bounty thread than I was anticipating, so I went ahead and awarded the bounty to you!
Thanks for engaging, and good questions. Please help me firm up the definitions.
How do you measure the difference between two orderings? As the number of inversions?
Number of inversions probably makes sense, but I guess it depends. If we come up with some clever way of doing this (e.g. with a non-standard deck of cards) then maybe there is some other measure we could use?
And what are you trying to maximize here? The number of cards you can lose? Can any subset of card indices be lost?
It would be great if some subset of the larger
M-card deck (M = 54 in the example) could be lost and yet still be able to reconstruct the data where the data in the example is a number between 0 and factorial(N) where N = 13. I was representing that number as a permutation of 13 objects, but I suppose that part is not very important.Think about
data as being the entropy+checksum for a bip39 seed. What I want is definitions for encode and decode such that:encode(data) = f decode(g) = data
where
f and g are not equal, but f and g are permutations of {1,2,3,4,...,M}.Does that help clarify?
Thanks. I understand what you mean now. However, it does not quite capture what I am seeking. I want it to be a single message which is comprised of
data (e.g. entropy for a cold wallet, which itself may include some of its own checksums, etc), and I want the whole thing to be represented as a permutation of {1,2,3,4,5...,M}. So what I want is definitions for encode and decode such that:encode(data) = f decode(g) = data
where
f and g are not equal, but f and g are permutations of {1,2,3,4,...,M}.Continuing with the cold storage example: the sender "sends"
f by putting the cards in the order determined by f and then destroying the underlying original entropy (the secret) since it is now represented by f. Maybe Sender then buries this deck of cards in a hole in the ground or something :-).Then, some time later, the Receiver (which could be the Sender itself) digs up the deck of cards and writes down their order. Unfortunately the order the cards are now in, for whatever reason, turns out to be
g which is not equal to f. In other words, there was an error in the transmission. However, all hope should not be lost.So, the question is: can we endow
f with enough error correction capabilities that even if the receiver receives g, the receiver can still find the underlying original secret data from g?Ngl I find it a little difficult to understand what you even want.
Thanks for your answer and for the feedback regarding clarity. I should have given a more explicit example of the type of transmission I am after:
better example / motivation -- cold storage of entropy
Imagine storing the entropy for a cold wallet in the form of a carefully ordered deck of cards. It is not hard to take a number and represent it as a permutation of
N objects. This is what a Lehmer code does, but Lehmer codes alone do not get us all the way there from a redundancy/error-correcting standpoint.Where I get stumped is how to build error correction into the permutation itself so that you can recover the seed entropy even if your permutation (the message) got a little jumbled up. My thought is that there is probably a way to do it by using an even larger collection of
M objects where M > N.a method that's widely used in many protocols in computer science for transmission.
Regarding your specific solution, I am confused. I want the final encoding of the message (e.g. what is actually transmitted) to be in the form of a permutation of objects, nothing else. Does your method do that? I think your merkle tree idea assumes that the receiver somehow already knows/learns the root hash, but that would be outside of the rules.
If you have an idea for how to do this robustly but which needs a non-standard deck of cards, that is fine, please share your idea!
The important thing is that the final encoding is solely in terms of a permutation of
M physical objects (in the example M = 54) and that such an encoding stores information about a permutation of N objects (in the example N = 13) with some robustness against errors.Maybe you have a clever way of doing it with a permutation of polynomials or something crazy like that?
I added a test demonstrating 1 of n oblivious signing. It does not quite solve the problem you point out, but it gets closer (notice how Alice can privately shuffle the messages and yet Bob still receives one and only one valid signature, while Alice still remains oblivious as to which one he receives).
Thanks for engaging on this. I hope it is helpful and we each further our own understanding of these concepts. I see what you are saying, and you very well might be correct.
Still, it feels like there is probably some way to do it with oblivious signing that would satisfy your objection.
Ok, I am shooting from the hip here quickly (so what follows could very well be wrong), but let's try this:
-
do you see how it is easy to extend a 1 of 2 oblivious transfer (oblivious signing in our case) to a 1 of n?
-
if so, then Alice funds the output with amount
Uand can sell sell a ticket to each Bob for an amount slightly more thanU / n(it is slightly more so that, in expectation she can earn a profit). -
if one of the Bob's wins they will, naturally, move/claim the utxo
-
if more than one Bob wins, they will have a fee fight
I think for large enough
n and slow enough ticket sales, these issues are surmountable, no?Yes. There is no need for every e-commerce merchant to know your physical address. There have been a couple explorations, but a lot of work still needs to be done to make it practical. See this SN thread
If done right, it feels like we should be able to take the Amazon Prime model and flip it inside out.
Good idea!
As a step towards making it trustess, you might want to check out "oblivious signing"1 which uses adaptor signatures and something called oblivious transfer to achieve a trustless off-chain coinflip and which can probably be generalized into a lottery.
I also implemented a simple demonstration/test2 of the underlying ecc math that makes oblivious signing work and which you might also find helpful.
Footnotes
Some sort of easy git integration would be very helpful for long-form posts -- something sort of like gist.github.com would be nice. It would also make creating/editing posts offline much easier.
It would be an easy way for people to monetize useful code snippets too. Often I will create a little gist showcasing/demonstrating some code or construct, and it would be great if I could do it on SN so that it at least has a chance to self-monetize.
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): bc1qmqckte0sfhh8xyc6v7zswrs5mpjrrf2f5frwe2yz68lyy253m7qshzrdqnHere 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.
What you are describing is, for the most part, doable on the lightning network as it exists today. In fact there have been some explorations and mailing list posts regarding using hodl invoices for a physical/parcel delivery protocol1.
However, one thing that makes such a protocol difficult to utilize at scale in lightning today is that physical deliveries are often on the order of days or even weeks, whereas lightning invoices usually have shorter expiration times.
If long duration hodl invoices became a popular thing on lightning, intermediate routing nodes may be hesitant to forward payments unless/until they are adequately compensated. This is due to the limited number of unsettled htlcs a channel can have at any given time, so they are foregoing fee revenue in the interim. Maybe there are some ways to address these issues.
Now, to try to briefly answer your questions:
question 1: Is this possible to do this with any current lightning implementation (CLN, LND, Eclair)?
I have only tested hodl invoices with LND, but I think the other implementations now support generating such invoices.
question 2 : Does it require custom made or specific lightning wallets or it can work for people using like say Wallet of Satoshi?
For people paying the hodl invoices, it should work with pretty much any lightning wallet which follows the lightning specs. Some wallets might not have the UI setup to handle long expiration invoices though, so it might be clunky.
question 3: Is there a service today that acts as the described application?
Not that I am aware of, but I think it is a good idea and should be explored further!
<k blocks> OP_CSVthereby emulating (withk = 100) the traditional incentives.kto longer durations.k, this "explicit fee output" would cost the sender more sats (time value of money) to get the transaction confirmed (assuming miners would even be on the lookout for such transactions with these outputs), but if the mempools were to have a lot of otherwise equal value transactions with differentks, then we might be able to get a near-real-time gauge of miner time preference/myopia.