Karl [ARCHIVE] on Nostr: đź“… Original date posted:2021-12-06 đź“ť Original message: Hi, I'm not a bitcoin ...
đź“… Original date posted:2021-12-06
đź“ť Original message:
Hi,
I'm not a bitcoin developer.
On Mon, Dec 6, 2021, 5:05 AM Héctor José Cárdenas Pacheco via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello all,
>
> I’ve been thinking about how OP_RETURN is being used to create and trade
> NFTs on Bitcoin (think RarePepes, SoG and other new ones) and was wondering
> if it’s possible to
>
Do you have a link to any of these protocols?
make transactions with this opcode via Lightning.
>
> More specific questions could be:
>
> 1. Can opcodes like OP_RETURN be inside a channel’s opening or closing
> transaction?
> 2. If so, could that OP_RETURN change hands within that channel or
> network of channels?
>
> OP_RETURNs do not have ownership according to the bitcoin network. It is
not hard to define a protocol that associates an OP_RETURN with ownership,
and ownership could then be transferred via lightning by sending associated
currency via lightning. Robustness improvements seem possible.
> 1. If possible, could the OP_RETURN be divisible? Could one person
> send a piece of a OP_RETURN just like one can do right now on the primary
> ledger or would it need to maintain the OP_RETURN code intact?
>
> OP_RETURNs themselves do not have ownership, but you can define a protocol
that gives them divisible ownership, including via lightning.
I’m assuming that, if possible, this would need a protocol layer parallel
> to Bitcoin/Lightning that stores and reads all Bitcoin transactions and the
> ones which involve the node's channels as well as the ones with the
> OP_RETURN, just like CounterParty does right now with the primary ledger.
>
> Thank in advance.
> ——
>
> *Héctor Cárdenas*@hcarpach
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211206/f3253ec4/attachment.html>
đź“ť Original message:
Hi,
I'm not a bitcoin developer.
On Mon, Dec 6, 2021, 5:05 AM Héctor José Cárdenas Pacheco via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello all,
>
> I’ve been thinking about how OP_RETURN is being used to create and trade
> NFTs on Bitcoin (think RarePepes, SoG and other new ones) and was wondering
> if it’s possible to
>
Do you have a link to any of these protocols?
make transactions with this opcode via Lightning.
>
> More specific questions could be:
>
> 1. Can opcodes like OP_RETURN be inside a channel’s opening or closing
> transaction?
> 2. If so, could that OP_RETURN change hands within that channel or
> network of channels?
>
> OP_RETURNs do not have ownership according to the bitcoin network. It is
not hard to define a protocol that associates an OP_RETURN with ownership,
and ownership could then be transferred via lightning by sending associated
currency via lightning. Robustness improvements seem possible.
> 1. If possible, could the OP_RETURN be divisible? Could one person
> send a piece of a OP_RETURN just like one can do right now on the primary
> ledger or would it need to maintain the OP_RETURN code intact?
>
> OP_RETURNs themselves do not have ownership, but you can define a protocol
that gives them divisible ownership, including via lightning.
I’m assuming that, if possible, this would need a protocol layer parallel
> to Bitcoin/Lightning that stores and reads all Bitcoin transactions and the
> ones which involve the node's channels as well as the ones with the
> OP_RETURN, just like CounterParty does right now with the primary ledger.
>
> Thank in advance.
> ——
>
> *Héctor Cárdenas*@hcarpach
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211206/f3253ec4/attachment.html>