Thx for explaining the priming @jdogresorg, though there’s more elegant solutions to that…, you could use an input from another address to pay the fee for example so you wouldn’t have to prefill it with BTC.
However in the current state of CP it still would require the hassle to gather the assets into 1 main address etc. to make it easier to spend so I understand the concern completely.
Back on topic of this feature in isolation;
Apart from the exchange problem I think this is a very niche feature, you generally don’t send someone assets without any side-channel communication (about a deal, purchase or gift) and even if you do it’s not very sane to include a message in public writing.
I can think of arguments against letting users stuff public arbitrary notes into transactions,
- some might not realize it’s public (oops my phone number is in the blockchain),
- others might use it to dox or attack people,
- it could be used to advertise,
But you could easily use asset names and descriptions (and broadcasts) already for the last 2,
and the first one … should be more of a UI thing for a wallet than a protocol decision.
So I can’t really object to this feature when considered in isolation.
Now as for keeping
send within opreturn bounds, this is an entirely different subject;
Most users probably won’t care enough about the UTXO pollution to make the choice not to when they’re given this choice, they’d at most consider the increase in fee.
But should we force
send within opreturn because the other 2 encodings hurt the bitcoin network and
send is by far the largest part of CP messages?
If we’d want to force
send to remain within opreturn bounds then;
my #1 desire for adjusting
send (or even #1 desire for CP overall) would be to add a change address and allow spending from multiple addresses in 1 TX just as with bitcoin transactions, so we have the posibility to move away from address reuse.
I’d prefer discussing that in depth before “giving away” space in the opreturn to things like an address or a memo and then not having enough space left to do so (though this new
send could also be
send2 and apply new restrictions to the memo field.
Considering current fee rates dust outputs are way below economically spendable my priority would be change output + multi input > no dust output > memo
I need a bit of time to think about all this myself,
I don’t enjoy the thought of taking part of something that is polluting the bitcoin UTXO set (and thus slowly - though only mildly - hurting the bitcoin network),
and being able to completely fix this (by removing pubkeyhash and multisig encoding at some point) would be my dream come true.
Doing a “best effort” thing of at least forcing
send to remain within bounds of opreturn is somewhat comforting…
Down the line when segwit has activated and P2SH encoding has been released we could remove pubkeyhash encoding and bare multisig encoding in favor of P2SH encoding, P2SH encoding doesn’t hurt the bitcoin network in any way.
This change would then enable
send beyond opreturn bounds and it would just be a choice of the user if he’s willing to pay the extra fee for his memo to be included, the memo could be of arbitrary length then.
PS. 100% sure 2 CIPs, could be implemented 2gether though.