Published on: 2019-12-19T10:00:09+00:00
The conversation discussed various proposals and solutions for optimizing Bitcoin's opcode behavior. One suggestion was the use of single-show signatures, where the private key is revealed only when combined with another signature from the same key. However, this approach can add fragility to the system and limit useful features. An alternative solution proposed was the use of a signing federation, which would require multiple signatures from respected companies in different legal jurisdictions to spend funds, addressing concerns about double-spending. Other possibilities mentioned include enforcing single-show signatures using OP_CHECKSIGFROMSTACK or SIGHASH_NOINPUT/SIGHASH_ANYPREVOUT.The Lightning network's onboarding process could be made smoother by using pay-to-open, as discussed by Bastien. This method provides a great user experience but requires temporary trust between the user and the node until the funding transaction confirms. The issue of revealing the preimage once the channel is funded can be fixed once Bitcoin supports Schnorr. By using PTLCs and MuSig for channel funding transactions, a tweaked channel opening flow can be initiated. However, in the current version, there is a security concern as Alice knows the nonce tweak beforehand.Addressing the issue of double-spending by the funder while the funding transaction is unconfirmed is a major concern. Suggestions include leveraging HTLC-like constructions similar to those used in BOLT 3 to ensure atomicity. One proposal involves creating a transaction from on-chain funds that pays out to an HTLC-like construction. However, this solution makes Alice vulnerable to Bob aborting after the pre-funding is confirmed. It is suggested that Bob be forced to provide funds to the pre-funding and a pre-signed backout can be created to return the funds back to both Alice and Bob.In conclusion, while pay-to-open offers a smoother onboarding process for Lightning network users, there are trust-related concerns that need to be addressed. The first scenario can be resolved with Schnorr support, but finding a solution for preventing double-spending by the funder during unconfirmed transactions remains a challenge. The mailing list community is actively brainstorming and leveraging their collective expertise to find potential solutions that incentivize funders against double-spending.
Updated on: 2023-07-31T22:29:19.804866+00:00