Le 08/05/2023 à 23:43, Christopher Allen via bitcoin-dev a écrit :
> There was a recent thread discussing raising the limit on
> OP_RETURN https://github.com/bitcoin/bitcoin/issues/27043
Indeed we already discussed all of this, and the conclusion was: there
are no reasons to impose limits, becaus
> They could have just as easily used OP_RETURN
outputs or any number of other data encoding techniques.
But doesn't OP_RETURN render the UTXO unspendable, thereby making it impossible
to "trade" the minted BTC-20 tokens?
Moth
Sent from Proton Mail for iOS
On Mon, May 8, 2023 at 7:55 PM, Peter
> Is there a reason such a validation check is a bad idea? We already have
> OP_RETURN to store arbitrary data that is limited to 80kb.
A reason to not ban storing arbitrary/non-functional data is that people will
still want to store things, so will start (ab)using useful data to do so, which
On May 8, 2023 at 1:16:41 PM, Moth via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> From what I understand, things like inscriptions can only be inserted
> between two specific flags - OP_FALSE and OP_IF. Having a validation check
> to reject witness scripts that have arbitrary da
On Mon, May 08, 2023 at 08:16:41PM +, Moth via bitcoin-dev wrote:
> From what I understand, things like inscriptions can only be inserted between
> two specific flags - OP_FALSE and OP_IF.
That's just an artifical limitation of the current inscription protocol. There
are endless ways to embed
From what I understand, things like inscriptions can only be inserted between
two specific flags - OP_FALSE and OP_IF. Having a validation check to reject
witness scripts that have arbitrary data between these two flags could be used
to reject inscriptions while still allowing all the benefits o
