Open gamedevalice opened 6 months ago
I would like to second this request on behalf of many in the Ordicord. This has been the number one ask since halving by those wishing to airdrop their premined runes.
Note that according to this post from less than 2 hours ago this feature is already implemented in the protocol: https://github.com/ordinals/ord/assets/124552025/e7fb05f5-ab70-4ced-8455-3c7014f747ad
To use it you set output
to the total number of outputs (including OP_RETURNs). You also have the option to set amount
to zero to split all of the runes in the transaction.
It seems like it may also airdrop to yourself. If that's the case, that's not ideal. You typically wouldn't want the airdrop to include the output where you are sending the remaining change,
Also note, even if this is considered sufficient, there are some remaining things to do: 1 - add it to the documentation so people can know about it 2 - adding a command to the wallet for constructing transactions with edicts and multiple outputs
For reference, the code to the current implementation is here: https://github.com/ordinals/ord/blob/1e6cb641faf3b1eb0aba501a7a2822d7a3dc8643/src/index/updater/rune_updater.rs#L81-L112
@raphjaph the current split all works great already, what is needed rather is a flag for excluding an output # from the split all, so that we can reliably exclude change outputs
following the pattern that's already in place,
output == tx.output.len()
means split to all outputs
so perhaps
output == tx.output.len() + 1
could mean split to all outputs except pointer
this allows the possibility for other kinds of special Edicts with new behaviors in the future, like:
output == tx.output.len() + 2
output == tx.output.len() + 3
etc
This would make it a lot simpler to do large airdrops, and would require much fewer transactions, making it more cost efficient as well.
Based on: https://github.com/ordinals/ord/blob/91a14fd9ed0270d021a0dac99087182c2cedeaae/crates/ordinals/src/edict.rs#L4-L8
I can see that the type of
output
isu32
, i.e can have a maximum value of:4,294,967,295
According to: https://bitcoinops.org/en/tools/calc-size/ You could probably fit
roughly 100,000 outputs
in a transaction that would be large enough to hit the block size limit.So, given that the higher values are actually far from achievable, I suggest when
output
has a value ofu32::MAX
, we treat it as meaning:amount
to every output (except the output to which the remaining change is sent to)This approach requires no changes to the runestone's data structure or size, so it is 'free' as far as the runestone size fitting in a
OP_RETURN
is concerned.