Christian Moss [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2021-12-06 to 2021-12-09
💬 Posted a total of 6 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 13:04:35

- reply

📅 Original date posted:2021-12-06
📝 Original message:
Hi, it is not really possible in the way you think, mainly because
lightning relies on liquidity to work, i.,e. lots of bitcoin locked up in
channels to allow liquidity, NFTs are not liquid, so if you have 1 NFT then
it would be impossible to send on the network
I think the best off chain solution to NFTs on bitcoin is using Ruben
Somsens state chain protocol, which allows you to swap utxos off chain, and
those off chain utxos could harbour an op return/nft
On Mon, Dec 6, 2021 at 10:36 AM Karl via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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
>>
> _______________________________________________
> 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/7533655c/attachment-0001.html>

2023-06-09 13:04:34

- reply

📅 Original date posted:2021-12-06
📝 Original message:
As far as I understand it, RGB doesn't scale NFTs as each
transaction to transfer ownership of an NFT would require an onchain
transaction
On Mon, Dec 6, 2021 at 3:44 PM Martin Habovštiak via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I recommend you researching RGB: https://rgb-org.github.io/
>
> On Mon, Dec 6, 2021, 11:21 Karl <gmkarl at gmail.com> wrote:
>
>> 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
>>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> 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/c62a093a/attachment-0001.html>

2023-06-09 13:04:34

- reply

📅 Original date posted:2021-12-09
📝 Original message:
pete at petertodd.org, so single use seals require an onchain transaction to
post the proof of publication to the ledger (assuming bitcoin is used as
the ledger) when an asset is transferred, but it can scale because you can
batch many proofs (transfer of ownerships) into a merkle tree and just add
the merkle root into the single tx going into the ledger?
On Thu, Dec 9, 2021 at 9:13 AM Peter Todd <pete at petertodd.org> wrote:
> On Mon, Dec 06, 2021 at 04:35:19PM +0000, Christian Moss via bitcoin-dev
> wrote:
> > As far as I understand it, RGB doesn't scale NFTs as each
> > transaction to transfer ownership of an NFT would require an onchain
> > transaction
>
> RGB intends to scale NFTs and similar things in the future via scalable
> single-use-seals:
> https://petertodd.org/2017/scalable-single-use-seal-asset-transfer
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211209/9c5f1126/attachment.html>

2023-06-07 23:00:52

- reply

📅 Original date posted:2021-12-09
📝 Original message:pete at petertodd.org, so single use seals require an onchain transaction to
post the proof of publication to the ledger (assuming bitcoin is used as
the ledger) when an asset is transferred, but it can scale because you can
batch many proofs (transfer of ownerships) into a merkle tree and just add
the merkle root into the single tx going into the ledger?
On Thu, Dec 9, 2021 at 9:13 AM Peter Todd <pete at petertodd.org> wrote:
> On Mon, Dec 06, 2021 at 04:35:19PM +0000, Christian Moss via bitcoin-dev
> wrote:
> > As far as I understand it, RGB doesn't scale NFTs as each
> > transaction to transfer ownership of an NFT would require an onchain
> > transaction
>
> RGB intends to scale NFTs and similar things in the future via scalable
> single-use-seals:
> https://petertodd.org/2017/scalable-single-use-seal-asset-transfer
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211209/9c5f1126/attachment.html>

2023-06-07 23:00:51

- reply

📅 Original date posted:2021-12-06
📝 Original message:As far as I understand it, RGB doesn't scale NFTs as each
transaction to transfer ownership of an NFT would require an onchain
transaction
On Mon, Dec 6, 2021 at 3:44 PM Martin Habovštiak via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I recommend you researching RGB: https://rgb-org.github.io/
>
> On Mon, Dec 6, 2021, 11:21 Karl <gmkarl at gmail.com> wrote:
>
>> 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
>>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> 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/bitcoin-dev/attachments/20211206/c62a093a/attachment-0001.html>

2023-06-07 23:00:50

- reply

📅 Original date posted:2021-12-06
📝 Original message:Hi, it is not really possible in the way you think, mainly because
lightning relies on liquidity to work, i.,e. lots of bitcoin locked up in
channels to allow liquidity, NFTs are not liquid, so if you have 1 NFT then
it would be impossible to send on the network
I think the best off chain solution to NFTs on bitcoin is using Ruben
Somsens state chain protocol, which allows you to swap utxos off chain, and
those off chain utxos could harbour an op return/nft
On Mon, Dec 6, 2021 at 10:36 AM Karl via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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
>>
> _______________________________________________
> 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/bitcoin-dev/attachments/20211206/7533655c/attachment-0001.html>