There is some discussion about the use burn addresses. Counterparty, a meta-layer protocol on top of Bitcoin, first used an approach to generate their native token: when an user sent BTC to 1CounterpartyXXXXXXXXXXXXXXXUWLpVr, the protocol automagically generated Counterparty tokens.
Wormhole Cash used a similar approach: they generate their native token WHC by sending BCH to a similar vanity address.
Someone then spread the rumor they may hold the key for that destination and sending coins to a vanity address isn't a good way. He continued by proposing to send coins to a script with OP_FALSE. This op-code ensures the script always fails.
In theory this is a better approach, because this script is guaranteed not spendable, but this doesn't work in practice: only a handful of output scripts are considered "standard", which is the Bitcoin way of saying, they are forwarded and accepted by nodes and miners. This includes scripts sending coins to a pubkey, a pubkey-hash, a script-hash, a bare-multisig script, or OP_RETURN scripts. The related templates are defined here.
When trying to create a transaction with different scripts, they are not accepted, forwarded or mined by your own, others, or miner's nodes, which haven't changed their standardness-policy (which no one has ever done, except Luke-Jr with Eligius, as far as I know).
This means: burning coins with OP_FALSE does not work in practice.
While there certainly are other approaches than sending coins to a vanity-address, like sending coins to an OP_RETURN script, which also evaluates to false, claiming the use of OP_FALSE is a better approach doesn't factor in what's actually possible in practice.
[link] [comments]
from Bitcoin - The Internet of Money https://ift.tt/2opXHsT
No comments:
Post a Comment
We have received your message and would like to thank you for writing to us, we will reply by email as soon as possible.
Talk to you soon,
[Pakcoin Worker]
[Pakcoin Global]