Good morning Tyler,
> I like the efficiency your method brings and I'm also not that enthused about
> bloating the blockchain with "non-financial data", however I do think there's
> value in having the data live in the base chain, both from accessibility and
> censorship resistance of the data to less additional "networks".
Gossiped data is almost impossible to censor (ask Streisand how well that works
to censor her Malibu home). However, mere gossip is often unverifiable.
What we do here is twofold:
1. We use the blockchain layer for verification. Commands
"google.com=127.0.0.1" are backed by actual Bitcoin satoshi being locked,
sacrificing opportunity costs, making them costly and verifiably costly, unlike
gossip which is unverifiable.
2. We use the gossip overlay for censorship resistance. Once a command has
been confirmed on the Bitcoin blockchain, we can share that command to our
peers on the gossip overlay, and unless all our peers are colluding, it is
likely that a command gets out somehow.
This design also uses P2WSH, so 51% miners, at least, cannot censor Numerifides
commands: all they see is a hash of something which could be a LN fundchannel
or a M-of-N SegWit or etc etc. We wait for the transaction to confirm (which
starts the CSV relative-locktime countdown anyway), after which the miner
cannot "take back" its confirmation of your Numerifide command without losing
costly work, and only THEN reveal the P2WSH preimage on the Numerifides gossip
overlay network.
The gossip overlay then provides censorship resistance on top of that,
revealing the preimage of the P2WSH (AFTER it has been confirmed onchain) and
revealing your Numerifide command. It is unlikely that anyone can stop the
gossip overlay unless they control your entire Internet connection, in which
case you have more serious problems and might not even be able to have a
current view of the Bitcoin blockchain anyway.
> Already today any user that includes a commensurate miner's fee can use the
> pushdata opcodes and add whatever data they want to the blockchain.
Granted. It still makes bitcoin-dev cry when this is done. And in any case,
reducing the blockchain footprint has real benefits of reducing the amount that
gets given to miners and increasing what can be put into command bids anyway.
> One thing that the design requires is a separate method of communicating
> bindings and not being censored - if it were onchain, a DNS lookup could
> simply be no more than a light client requesting the relevant block.
Possibly. Note however that the "publish everything onchain" design requires
cooperation of a Bitcoin miner, since it seems you are using scriptpubkey
rather than P2WSH. In particular the IsStandard() check will mean your
transaction will not get transmitted on the normal Bitcoin peer network and you
will need direct connection and cooperation of a Bitcoin miner, to get your
non-standard script in a scriptpubkey.
If you intend to use P2SH or P2WSH, then you will need a gossip layer to reveal
the script preimage anyway, so you might as well use the more efficient
P2WSH-based construction I showed.
> I think anything that gets seriously far along will need to have some data
> crunched and if only 100 users per day would fill up blocks then of course
> constraints would necessitate other avenues.
Yes. Knowing that, we might as well start efficient.
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
