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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
