ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-20 📝 Original message: Good morning Tyler, > ...
📅 Original date posted:2018-04-20
📝 Original message:
Good morning Tyler,
> Great points. IsStandard() is something I hadn't considered yet, but I think miners are incentivized to want Numerifides transactions as a registration will need a solid miners fee, and "revoked" names will cause escalating fee wars that the miners can just soak up. I think a standard that uses mappings in a sane way (and maybe pushdata2/4 won't be allowed if 255 bytes are enough) would be allowable given the benefit it brings of truly decentralized, human-readable trust.
Granted, but using scriptpubkey will require changes to miner software, and would require large number of mining pools to support it. And large numbers of mining pools will not support it significantly unless you have already demonstrated its usefulness, so you may find bootstrapping less easy.
One thing that can be done would be to publish the command in the witness vector and use an intermediate transaction. This at least lets you use the cheaper witness space.
1. First pay to a P2WSH OP_HASH160 <h(blocks || nextpubkey || command)> OP_EQUALVERIFY <pubkey> OP_CHECKSIG
2. Spend the above P2WSH, which requires you to provide the witness data <signature> <blocks || nextpubkey || command>
3. The spend should pay out a value to the P2WSH <blocks> OP_CHECKSEQUENCEVERIFY OP_DROP <nextpubkey> OP_CHECKSIG
This puts the extra data into the witness area, which is cheaper, and also utilizes P2WSH so that you do not have to convince miners to use Numerifides. bitcoin-dev will still cry because it puts non-financial data onchain, but at least fewer tears will be shed since it is the witness area.
> I also wonder what the economic incentive might be for every node to store and gossip the Numerifides mappings - sure they want everyone to find them, but who cares about other people? It could be a situation like the current Bitcoin mempool where it's saved on a best-effort basis and is semi-transient, but that makes troubleshooting lookups problematic.
You have an economic incentive to *store* all the Numerifides mappings -- if you do not, somebody could fool you with a revoked mapping, or you might not be able to locate a mapping you need to use.
Incentive to then *share* mappings could be that peers would try a "tit for tat" strategy: they will give you one (or a few) mappings "for free", but if you do not give any back, they will stop sharing with you. So you are incentivized to contact multiple peers and try to trade information from one with information from another. But that requires a durable identity from you, which may be undesirable.
One could also wonder what economic incentive might be to *seed* torrents as opposed to leech them only, other than a "high-level" consideration that if nobody seeds, nobody can leech.
> Also, I know this is only tangentially related to Lightning so if this is a discussion best left off the mailing list, just let me know.
bitcoin-dev will probably have more ideas and might be able to point you at some prior art for similar systems.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180420/c079d13f/attachment.html>;
📝 Original message:
Good morning Tyler,
> Great points. IsStandard() is something I hadn't considered yet, but I think miners are incentivized to want Numerifides transactions as a registration will need a solid miners fee, and "revoked" names will cause escalating fee wars that the miners can just soak up. I think a standard that uses mappings in a sane way (and maybe pushdata2/4 won't be allowed if 255 bytes are enough) would be allowable given the benefit it brings of truly decentralized, human-readable trust.
Granted, but using scriptpubkey will require changes to miner software, and would require large number of mining pools to support it. And large numbers of mining pools will not support it significantly unless you have already demonstrated its usefulness, so you may find bootstrapping less easy.
One thing that can be done would be to publish the command in the witness vector and use an intermediate transaction. This at least lets you use the cheaper witness space.
1. First pay to a P2WSH OP_HASH160 <h(blocks || nextpubkey || command)> OP_EQUALVERIFY <pubkey> OP_CHECKSIG
2. Spend the above P2WSH, which requires you to provide the witness data <signature> <blocks || nextpubkey || command>
3. The spend should pay out a value to the P2WSH <blocks> OP_CHECKSEQUENCEVERIFY OP_DROP <nextpubkey> OP_CHECKSIG
This puts the extra data into the witness area, which is cheaper, and also utilizes P2WSH so that you do not have to convince miners to use Numerifides. bitcoin-dev will still cry because it puts non-financial data onchain, but at least fewer tears will be shed since it is the witness area.
> I also wonder what the economic incentive might be for every node to store and gossip the Numerifides mappings - sure they want everyone to find them, but who cares about other people? It could be a situation like the current Bitcoin mempool where it's saved on a best-effort basis and is semi-transient, but that makes troubleshooting lookups problematic.
You have an economic incentive to *store* all the Numerifides mappings -- if you do not, somebody could fool you with a revoked mapping, or you might not be able to locate a mapping you need to use.
Incentive to then *share* mappings could be that peers would try a "tit for tat" strategy: they will give you one (or a few) mappings "for free", but if you do not give any back, they will stop sharing with you. So you are incentivized to contact multiple peers and try to trade information from one with information from another. But that requires a durable identity from you, which may be undesirable.
One could also wonder what economic incentive might be to *seed* torrents as opposed to leech them only, other than a "high-level" consideration that if nobody seeds, nobody can leech.
> Also, I know this is only tangentially related to Lightning so if this is a discussion best left off the mailing list, just let me know.
bitcoin-dev will probably have more ideas and might be able to point you at some prior art for similar systems.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180420/c079d13f/attachment.html>;