Good morning t-bast, > > Thanks for your response. > > > * Once the pre-funding is sufficiently confirmed as per Bob security > > parameter > > This is the part I'm trying to avoid. If we're ok with waiting for > confirmation, then it's easy to do indeed (and let's just wait for the > funding tx to confirm, I believe we don't even need that pre-funding step). > But if we have to wait for confirmations we're hodling the incoming HTLC for > a few blocks, which I'd like to avoid. > > Do you have a smart construction that would allow us to build safely on that > unconfirmed transaction? > Is there maybe a smart trick that would allow us the pay-to-open server to > provably lock some UTXO in advance to prevent > itself from double-spending them?
Unconfirmed transactions are only safe / trustless if they cannot be replaced. https://zmnscpxj.github.io/offchain/safety.html In offchain techniques, we ensure that pre-agreed offchain transactions cannot be replaced by requiring that all participants agree (n-of-n). With an n-of-n, replacement transactions are only possible if you cooperate in the attempt to steal from you, and thus no different from you voluntarily donating your funds to them anyway. So you need to pre-prepare some already-confirmed UTXOs that are 2-of-2 between you and the client. Of course, such 2-of-2 would *already* be channels themselves. Conversely, if you *do* find a solution to this problem, then that can be made an anchor / funding transaction output for a channel, and we would implement it directly into Lightning to remove the channel-opening confirmation delay. Given that there has been a lot of thinking regarding channel mechanisms, from the original broken Satoshi `nSequence` to Spilman to modern mechanisms like Decker-Wattenhofer, Poon-Dryja, and Decker-Russell-Osuntokun, all of which are still vulnerable to double-spending if you do not confirm the funding transaction deeply, it seems to me unlikely that such a technology could be derived. With current known cryptographic mechanisms, even if you consider that maybe you could pre-confirm some UTXOs that you can then subsequently allocate to clients immediately while ensuring that those UTXOs can only be spent in cooperation with the client, you need to somehow learn some public key before a client generates a private key for it, without knowing the private key yourself (or somehow be able to demonstrate that you can no longer access the private key). And if the client already gives you a pubkey, that is basically just you opening channels to them as soon as they arrive, and requires confirmation anyway. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
