Rusty Russell on Nostr: Don't do this to me, man: I'm on holidays! Ok, off the top of my head. Let's do a ...
Don't do this to me, man: I'm on holidays!
Ok, off the top of my head. Let's do a single UTXO, which you can spend. We represent all of the pubkey+balance pairs as a hash (separate output? In the script? I don't know).
Three ways to spend it:
1. New funds. Appends pubkey and the new input amount (maybe allow change output?). You have to provide all the previous pubkey+amount pairs, so this gets more expensive as size increases.
2. Early withdraw. You provide all the pubkeys and amounts, and a signature from your pubkey, and an offset of your pubkey. Your amount gets divided by 10, then divided by number of remaining participants (last one can't exit, too bad!) rounded up. Adding that to each participants amount is *hard*, because there is no iteration in Script. This means open iteration, so an upper limit on how many participants.
3. Final withdrawal. This is easier, simply spend with a single tx with outputs to each pubkey/amount.
So, you need introspection, ideally fully (OP_TX or multiple opcodes) to deal with amounts. You want Script restoration to sanely divide and handle whale amounts.
To do this *well* you want stack iteration, for which I am unaware of any proposal. varops could be amended to allow this in future, but it deliberately doesn't charge for some opcodes because we know there's a weight limit, and that will need to change if we have iteration.
But it's a cute idea!
Ok, off the top of my head. Let's do a single UTXO, which you can spend. We represent all of the pubkey+balance pairs as a hash (separate output? In the script? I don't know).
Three ways to spend it:
1. New funds. Appends pubkey and the new input amount (maybe allow change output?). You have to provide all the previous pubkey+amount pairs, so this gets more expensive as size increases.
2. Early withdraw. You provide all the pubkeys and amounts, and a signature from your pubkey, and an offset of your pubkey. Your amount gets divided by 10, then divided by number of remaining participants (last one can't exit, too bad!) rounded up. Adding that to each participants amount is *hard*, because there is no iteration in Script. This means open iteration, so an upper limit on how many participants.
3. Final withdrawal. This is easier, simply spend with a single tx with outputs to each pubkey/amount.
So, you need introspection, ideally fully (OP_TX or multiple opcodes) to deal with amounts. You want Script restoration to sanely divide and handle whale amounts.
To do this *well* you want stack iteration, for which I am unaware of any proposal. varops could be amended to allow this in future, but it deliberately doesn't charge for some opcodes because we know there's a weight limit, and that will need to change if we have iteration.
But it's a cute idea!