Re: [Lightning-dev] [bitcoin-dev] Sending OP_RETURN via Bitcoin
Omni Layer already does this, on Bitcoin, and recently added NFT support, but I don't know much about that aspect. OmniBOLT also exists as a LN layer for Omni assets. OB is being audited right now. Sending NFTs using Lightning is generally impractical, as it is a liquidity-based routing network, thus requires a whole new network for each new asset. But fungible assets should be doable by any popular token asset. I don't think RGB is practically usable by anyone yet, and still needs severe attention paid to auditing the design, if it is ever completed at all... On Mon, Dec 6, 2021 at 7:00 AM < lightning-dev-requ...@lists.linuxfoundation.org> wrote: > Send Lightning-dev mailing list submissions to > lightning-dev@lists.linuxfoundation.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > or, via email, send a message with subject or body 'help' to > lightning-dev-requ...@lists.linuxfoundation.org > > You can reach the person managing the list at > lightning-dev-ow...@lists.linuxfoundation.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Lightning-dev digest..." > > > Today's Topics: > >1. Re: [bitcoin-dev] Sending OP_RETURN via Bitcoin Lightning (Karl) >2. Re: [bitcoin-dev] Sending OP_RETURN via Bitcoin Lightning > (Martin Habov?tiak) > > > -- > > Message: 1 > Date: Mon, 6 Dec 2021 05:20:55 -0500 > From: Karl > To: H?ctor Jos? C?rdenas Pacheco , Bitcoin > Protocol Discussion > Cc: lightning-dev@lists.linuxfoundation.org > Subject: Re: [Lightning-dev] [bitcoin-dev] Sending OP_RETURN via > Bitcoin Lightning > Message-ID: > cf-bawbw4dq2pgjc9w_nqaqehsb829z...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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-...@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-...@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-0001.html > > > > -- > > Message: 2 > Date: Mon, 6 Dec 2021 12:31:29 +0100 > From: Martin Habov?tiak > To: Karl > Cc: Bitcoin Protocol Discussion > , lightning-dev > , H?ctor Jos? C?rdenas > Pacheco > Subject: Re: [Lightning-dev] [bitcoin-dev] Sending OP_RETURN via > Bitcoin Lightning > Message-ID: > < > calkkcjas_pf7un45cjyfg8j9cbk8ptkn4iyal81ttlsrnnk...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > I recommend you researching RGB: https://rgb-org.github.io/ > > On Mon, Dec 6, 2021, 11:21 Karl 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-...@lists.linuxfoundation.org> wrote: > > > >> Hello all, > >> > >> I?ve been thinking about how OP_RETURN is being used to create and trade > >> NFTs on
Re: [Lightning-dev] Lightning-dev Digest, Vol 72, Issue 18
The dust limit is required to prevent massive UTXO expansion. The details around miner incentives to process dust are irrelevant to this because there simply needs to be a buffer of friction to prevent spamming the UTXO set to be much, much larger, as an *attack* and long-term overhead on both storage size and resources in purposing UTXO data within applications/servers. Even if I were wrong, it is still silly to propose changing a thing no one actually needs or wants changed for any practical application. It ain't broke, don't fix it. On Fri, Aug 20, 2021 at 7:00 AM < lightning-dev-requ...@lists.linuxfoundation.org> wrote: > Send Lightning-dev mailing list submissions to > lightning-dev@lists.linuxfoundation.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > or, via email, send a message with subject or body 'help' to > lightning-dev-requ...@lists.linuxfoundation.org > > You can reach the person managing the list at > lightning-dev-ow...@lists.linuxfoundation.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Lightning-dev digest..." > > > Today's Topics: > >1. Re: [bitcoin-dev] Removing the Dust Limit (Jeremy) > > > -- > > Message: 1 > Date: Thu, 19 Aug 2021 23:51:31 -0500 > From: Jeremy > To: Bitcoin Protocol Discussion > > Cc: lightning-dev > Subject: Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit > Message-ID: > < > cad5xwhieda2kjf265idz1ism4afzh3s3d4cjsesvvknwv9l...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > one interesting point that came up at the bitdevs in austin today that > favors remove that i believe is new to this discussion (it was new to me): > > the argument can be reduced to: > > - dust limit is a per-node relay policy. > - it is rational for miners to mine dust outputs given their cost of > maintenance (storing the output potentially forever) is lower than their > immediate reward in fees. > - if txn relaying nodes censor something that a miner would mine, users > will seek a private/direct relay to the miner and vice versa. > - if direct relay to miner becomes popular, it is both bad for privacy and > decentralization. > - therefore the dust limit, should there be demand to create dust at > prevailing mempool feerates, causes an incentive to increase network > centralization (immediately) > > the tradeoff is if a short term immediate incentive to promote network > centralization is better or worse than a long term node operator overhead. > > > /// > > my take is that: > > 1) having a dust limit is worse since we'd rather not have an incentive to > produce or roll out centralizing software, whereas not having a dust limit > creates an mild incentive for node operators to improve utreexo > decentralizing software. > 2) it's hard to quantify the magnitude of the incentives, which does > matter. > -- next part -- > An HTML attachment was scrubbed... > URL: < > http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210819/831b9608/attachment-0001.html > > > > -- > > Subject: Digest Footer > > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > -- > > End of Lightning-dev Digest, Vol 72, Issue 18 > * > -- ~ John Carvalho Schedule: https://calendly.com/bitcoinerrorlog Chat: https://t.me/bitcoinerrorlog Social: https://twitter.com/bitcoinerrorlog ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proposal for an invoice pattern with an embedded Bitcoin onchain address
You can already embed a bitcoin address into an LN invoice. See example by clicking “contribute” at https://thebiz.pro Looks like this: bitcoin:bc1qfzaj2jaqhq7yn9hy3c00ndat4lq9me7sdvgc4q?lightning=lnbc50u1pswjc7ppp5qddlvfgk6j8aj3p9c3r7ql5j40yntv30ydcw77a6r8vvxmpf9uzsdrq235x2gzzd9azcgznv4shxmmwyqcjcgz9wp5hxmmyv5srxzjtwf5hxare94xx26t8dqsy66twv45xzms2yq34g3jnxqc52vpncqzpgfppqfzaj2jaqhq7yn9hy3c00ndat4lq9me7ssp5ftd8uqjrdrycugwmq0v868vk0zyu9gntrlla3chr74d83hkdz78s9qyyssqahk0vjzc0yfd3faevtsg0rx6guyyw6mnjmsyw858xtsqp3l4k763jhct4k7q5ndpc4mkznuskzj00vqql8vxlfp6n54kskkc8qheseqqf38kwg -- ~ John Carvalho Schedule: https://calendly.com/bitcoinerrorlog Chat: https://t.me/bitcoinerrorlog Social: https://twitter.com/bitcoinerrorlog ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Turbo channels spec?
Thanks for instigating this, Rusty! 0conf/turbo channels have been hackable for a long time, and we would love to unlock new user experiences for our platforms with it, formally if possible. 0conf is desired by every wallet, every LN exchange, and truly shows off something only LN can uniquely offer as a UX. We are happy to support how we can, and answer any questions from the trenches. On Tue, Jun 29, 2021 at 8:34 AM Rusty Russell wrote: > Hi all! > > John Carvalo recently pointed out that not every implementation > accepts zero-conf channels, but they are useful. Roasbeef also recently > noted that they're not spec'd. > > How do you all do it? Here's a strawman proposal: > > 1. Assign a new feature bit "I accept zeroconf channels". > 2. If both negotiate this, you can send update_add_htlc (etc) *before* >funding_locked without the peer getting upset. > 3. Nodes are advised *not* to forward HTLCs from an unconfirmed channel >unless they have explicit reason to trust that node (they can still >send *out* that channel, because that's not their problem!). > > It's a pretty simple change, TBH (this zeroconf feature would also > create a new set of channel_types, altering that PR). > > I can draft something this week? > > Thanks! > Rusty. > -- ~ John Carvalho Schedule: https://calendly.com/bitcoinerrorlog Chat: https://t.me/bitcoinerrorlog Social: https://twitter.com/bitcoinerrorlog ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Lightning-dev Digest, Vol 62, Issue 14
Regarding putting trust on the table as a design solution to possible attacks that aren't happening, wouldn't it be wise to start with whatever trust solutions common networks already use and mutate that to this situation? Example: KYC, black/whitelisting, reputation scoring, permissioned/private subnets, scoring/tiers Of course, none of us actually want to design formal KYC into LN, but it really is the same premise: "identifying" your counterparty and assessing the amount of risk you would like to allocate. Permissioned access, reduced public listening, out-of-band credentialing, etc, etc. Networking issues like these might not even be appropriate to be handled at the LN level. Possibly better to use a multipurpose context layer (gets into ID systems, namespaces, WoTs). Sorry if I'm oversimplifying the topic, but it is frustrating to watch devs argue about the edge of an edge of a knife no one is using, and then bikeshed every imperfection... Cryptographic punishment schemes aren't swiss army knives. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
