* [bitcoin-dev] Sending OP_RETURN via Bitcoin Lightning
@ 2021-12-06 9:54 Héctor José Cárdenas Pacheco
2021-12-06 10:20 ` Karl
0 siblings, 1 reply; 10+ messages in thread
From: Héctor José Cárdenas Pacheco @ 2021-12-06 9:54 UTC (permalink / raw)
To: bitcoin-dev; +Cc: lightning-dev
[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]
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 make transactions with this opcode via Lightning.
More specific questions could be:
Can opcodes like OP_RETURN be inside a channel’s opening or closing transaction?
If so, could that OP_RETURN change hands within that channel or network of channels?
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?
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
[-- Attachment #2: Type: text/html, Size: 1929 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Sending OP_RETURN via Bitcoin Lightning
2021-12-06 9:54 [bitcoin-dev] Sending OP_RETURN via Bitcoin Lightning Héctor José Cárdenas Pacheco
@ 2021-12-06 10:20 ` Karl
2021-12-06 11:31 ` [bitcoin-dev] [Lightning-dev] " Martin Habovštiak
2021-12-06 12:38 ` [bitcoin-dev] " Christian Moss
0 siblings, 2 replies; 10+ messages in thread
From: Karl @ 2021-12-06 10:20 UTC (permalink / raw)
To: Héctor José Cárdenas Pacheco, Bitcoin Protocol Discussion
Cc: lightning-dev
[-- Attachment #1: Type: text/plain, Size: 1948 bytes --]
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@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@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 4496 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Sending OP_RETURN via Bitcoin Lightning
2021-12-06 10:20 ` Karl
@ 2021-12-06 11:31 ` Martin Habovštiak
2021-12-06 16:35 ` Christian Moss
2021-12-06 12:38 ` [bitcoin-dev] " Christian Moss
1 sibling, 1 reply; 10+ messages in thread
From: Martin Habovštiak @ 2021-12-06 11:31 UTC (permalink / raw)
To: Karl
Cc: Bitcoin Protocol Discussion, lightning-dev,
Héctor José Cárdenas Pacheco
[-- Attachment #1: Type: text/plain, Size: 2331 bytes --]
I recommend you researching RGB: https://rgb-org.github.io/
On Mon, Dec 6, 2021, 11:21 Karl <gmkarl@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@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@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
[-- Attachment #2: Type: text/html, Size: 5388 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Sending OP_RETURN via Bitcoin Lightning
2021-12-06 10:20 ` Karl
2021-12-06 11:31 ` [bitcoin-dev] [Lightning-dev] " Martin Habovštiak
@ 2021-12-06 12:38 ` Christian Moss
1 sibling, 0 replies; 10+ messages in thread
From: Christian Moss @ 2021-12-06 12:38 UTC (permalink / raw)
To: Karl, Bitcoin Protocol Discussion
Cc: lightning-dev, Héctor José Cárdenas Pacheco
[-- Attachment #1: Type: text/plain, Size: 2779 bytes --]
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@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@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@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 5469 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Sending OP_RETURN via Bitcoin Lightning
2021-12-06 11:31 ` [bitcoin-dev] [Lightning-dev] " Martin Habovštiak
@ 2021-12-06 16:35 ` Christian Moss
2021-12-09 9:12 ` Peter Todd
0 siblings, 1 reply; 10+ messages in thread
From: Christian Moss @ 2021-12-06 16:35 UTC (permalink / raw)
To: Martin Habovštiak, Bitcoin Protocol Discussion
Cc: Héctor José Cárdenas Pacheco, lightning-dev
[-- Attachment #1: Type: text/plain, Size: 2845 bytes --]
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@lists•linuxfoundation.org> wrote:
> I recommend you researching RGB: https://rgb-org.github.io/
>
> On Mon, Dec 6, 2021, 11:21 Karl <gmkarl@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@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@lists•linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 6084 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Sending OP_RETURN via Bitcoin Lightning
2021-12-06 16:35 ` Christian Moss
@ 2021-12-09 9:12 ` Peter Todd
2021-12-09 9:49 ` Christian Moss
0 siblings, 1 reply; 10+ messages in thread
From: Peter Todd @ 2021-12-09 9:12 UTC (permalink / raw)
To: Christian Moss, Bitcoin Protocol Discussion
Cc: lightning-dev, Héctor José Cárdenas Pacheco
[-- Attachment #1: Type: text/plain, Size: 447 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Sending OP_RETURN via Bitcoin Lightning
2021-12-09 9:12 ` Peter Todd
@ 2021-12-09 9:49 ` Christian Moss
2021-12-09 10:07 ` Peter Todd
0 siblings, 1 reply; 10+ messages in thread
From: Christian Moss @ 2021-12-09 9:49 UTC (permalink / raw)
To: Peter Todd
Cc: Bitcoin Protocol Discussion,
Héctor José Cárdenas Pacheco, lightning-dev
[-- Attachment #1: Type: text/plain, Size: 887 bytes --]
pete@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@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
>
[-- Attachment #2: Type: text/html, Size: 1504 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Sending OP_RETURN via Bitcoin Lightning
2021-12-09 9:49 ` Christian Moss
@ 2021-12-09 10:07 ` Peter Todd
2021-12-09 12:12 ` Alex Schoof
0 siblings, 1 reply; 10+ messages in thread
From: Peter Todd @ 2021-12-09 10:07 UTC (permalink / raw)
To: Christian Moss
Cc: Bitcoin Protocol Discussion,
Héctor José Cárdenas Pacheco, lightning-dev
[-- Attachment #1: Type: text/plain, Size: 733 bytes --]
On Thu, Dec 09, 2021 at 09:49:11AM +0000, Christian Moss wrote:
> pete@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?
Exactly. And since the aggregation is trustless with respect to validity, users
can choose what kind of censorship risk they're willing to take (as well as
mitigate it with "multisig" schemes that use multiple aggregators in parallel).
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Sending OP_RETURN via Bitcoin Lightning
2021-12-09 10:07 ` Peter Todd
@ 2021-12-09 12:12 ` Alex Schoof
2021-12-09 12:56 ` Peter Todd
0 siblings, 1 reply; 10+ messages in thread
From: Alex Schoof @ 2021-12-09 12:12 UTC (permalink / raw)
To: pete
Cc: Bitcoin Protocol Discussion, lightning-dev,
Héctor José Cárdenas Pacheco
[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]
The multisig scheme is interesting. From my understanding of Single Use
Seals, since seal n commits to seal n+1, for the on-chain aggregation seals
you would want to pick some common aggregation service provider ahead of
time and if that provider disappears, you’re stuck and cant close the next
seal. If instead you say “this seal commits to three of the five of these
next seals” then you mitigate both availability and censorship risk. Am I
getting that right?
Alex
On Thu, Dec 9, 2021 at 5:23 AM Peter Todd <pete@petertodd•org> wrote:
> On Thu, Dec 09, 2021 at 09:49:11AM +0000, Christian Moss wrote:
> > pete@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?
>
> Exactly. And since the aggregation is trustless with respect to validity,
> users
> can choose what kind of censorship risk they're willing to take (as well as
> mitigate it with "multisig" schemes that use multiple aggregators in
> parallel).
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
--
Alex Schoof
[-- Attachment #2: Type: text/html, Size: 2436 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] Sending OP_RETURN via Bitcoin Lightning
2021-12-09 12:12 ` Alex Schoof
@ 2021-12-09 12:56 ` Peter Todd
0 siblings, 0 replies; 10+ messages in thread
From: Peter Todd @ 2021-12-09 12:56 UTC (permalink / raw)
To: Alex Schoof
Cc: Bitcoin Protocol Discussion, lightning-dev,
Héctor José Cárdenas Pacheco
[-- Attachment #1: Type: text/plain, Size: 1666 bytes --]
On Thu, Dec 09, 2021 at 07:12:45AM -0500, Alex Schoof wrote:
> The multisig scheme is interesting. From my understanding of Single Use
> Seals, since seal n commits to seal n+1, for the on-chain aggregation seals
> you would want to pick some common aggregation service provider ahead of
> time and if that provider disappears, you’re stuck and cant close the next
> seal. If instead you say “this seal commits to three of the five of these
> next seals” then you mitigate both availability and censorship risk. Am I
> getting that right?
Re: "some common aggregation service provider", you might be misunderstanding
the protocol: since seals are trustless with regard to validity, I can validate
your seal, regardless of which aggregation service you use.
But other than that, I think we're on the same page!
A concrete example would be an exchange: they do a lot of transactions, so they
could choose to be their own aggregator, and wouldn't need any multisig at all
because they can trust themselves not to censor themselves. :) Meanwhile, one
of their customers might use 3-of-5 as you suggest, as they only do a few
transactions a month.
Interestingly, in some scenarios it might be worthwhile to both run your own
aggregator, and use multisig. Eg Alice could use a 2-of-3 with two third-party
aggregators, and her own aggregation chain. If both third-parties are up, she
does no on-chain transactions at all; if one third-party is down, she can use
her own, and the remaining third-party. Thus she would only do an on-chain
transaction to defeat censorship/failure.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-12-09 12:56 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-06 9:54 [bitcoin-dev] Sending OP_RETURN via Bitcoin Lightning Héctor José Cárdenas Pacheco
2021-12-06 10:20 ` Karl
2021-12-06 11:31 ` [bitcoin-dev] [Lightning-dev] " Martin Habovštiak
2021-12-06 16:35 ` Christian Moss
2021-12-09 9:12 ` Peter Todd
2021-12-09 9:49 ` Christian Moss
2021-12-09 10:07 ` Peter Todd
2021-12-09 12:12 ` Alex Schoof
2021-12-09 12:56 ` Peter Todd
2021-12-06 12:38 ` [bitcoin-dev] " Christian Moss
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox