Published on: 2018-04-20T13:42:51+00:00
The email conversation between two individuals discusses the use of Numerifides transactions for decentralized and human-readable trust. They suggest using mappings in a sane way and not allowing pushdata2/4 if 255 bytes are enough. Implementing scriptpubkey would require changes to miner software and support from mining pools. To address this, they propose publishing the command in the witness vector and using an intermediate transaction to put extra data into the cheaper witness area.The economic incentive of storing and sharing Numerifides mappings is also discussed, with incentives for avoiding revoked mappings and locating needed mappings. Sharing could be incentivized through a "tit for tat" strategy. Bitcoin-dev is suggested as a resource for more ideas.Tyler and ZmnSCPxj discuss using blockchain for verification and gossip overlay for censorship resistance. They talk about the benefits of using a standard that uses mappings in a sane way for decentralized, human-readable trust. They also discuss the economic incentive for every node to store and gossip the Numerifides mappings. They mention the design of using the blockchain layer for verification and the gossip overlay for censorship resistance. The design uses P2WSH to prevent miners from censoring Numerifides commands. They also mention reducing the blockchain footprint and the need for cooperation from Bitcoin miners. They conclude that constraints may necessitate other avenues if blocks get filled up.The writer proposes a system for using blockchain for verification and gossip overlay for censorship resistance. The design uses P2WSH to prevent censorship by miners. They discuss reducing the blockchain footprint and the separate method of communicating bindings. They also discuss the need for cooperation from Bitcoin miners. They conclude that constraints may require alternative solutions if blocks fill up.The context discusses a method for efficiently using the blockchain without bloating it with non-financial data. The user acknowledges the value of having data on the base chain for accessibility and censorship resistance but recognizes that constraints may require other options if blocks get filled up. They discuss the design of using the blockchain layer for verification and the gossip overlay for censorship resistance. They mention the use of P2WSH and reducing the amount given to miners. They also mention the need for cooperation from Bitcoin miners and alternative avenues if blocks fill up.The context discusses a scheme called Numerifides that allows for non-financial data to be stored on-chain. The scheme involves generating a secret private key and public key, encoding the command, computing the pay-to-contract public key, and paying to a P2WSH on the Bitcoin network. The writer mentions that the same scheme can be used for any kind of asset. They also discuss the use of CLTV Unix epoch and CSV for time locks. They mention that locked coins can be reclaimed when the command expires. They conclude that the same scheme can be used for practically any kind of asset, not just names.In this context, Tyler discusses the appropriate opcode for a relative time lock in Bitcoin script. ZmnSCPxj questions the validity of Tyler's proposed script and clarifies the purpose of OP_CheckLockTimeVerify. They also suggest that locking funds for a time may be sufficient without involving proof-of-work. They share their own ideas for proof-of-mainstake which uses locking funds in the mainchain as voting rights for the correctness of the sidechain.A proposal called Numerifides is discussed, which commits directly to the Bitcoin blockchain and solves Zooko's triangle. The system can be used for various name->data associations. The writer acknowledges concerns regarding implementation details, censorship resistance, and privacy. They suggest encrypting or hashing the committed data. They also mention the possibility of using a "catchall" unadvertised datatype for committing anything for any purpose. Feedback from the community is requested. Two favorite approaches for securely advertising human-understandable node names are mentioned: Namecoin-style registration and Web of Trust.Tyler is working on finding a secure way to advertise human-understandable node names for Lightning technology. He suggests two approaches: Namecoin-style registration and Web of Trust. He acknowledges the limitations of these approaches and hopes to find a solution soon.Tyler expresses his understanding of the trilemma in implementing something suitable for Lightning technology. He pulls his support for the proposed BOLT and cautions against trusting DNS. ZmnSCPxj mentions the issue of Zooko's Triangle and suggests using a DNS-like system for Lightning that is decentralized and secure while allowing for human-meaningful names.Tyler pulls his support for implementing a proposed BOLT related to opening appropriate channels for Lightning. He raises concerns about trusting DNS and suggests not making guarantees based on DNS records. ZmnSCPxj discusses the idea of private nodes with channels open to public nodes and suggests multiple public nodes for load distribution. They caution against the use of "private" channels and suggest using "published" and "unpublished" channels instead.
Updated on: 2023-07-31T19:58:44.589363+00:00