• 목록
• 답변
• 글쓰기
• 게시판 리스트 옵션
  • 수정
  • 삭제

Delays processing payments by the blockchain of about ten minutes make bitcoin use very tough in a retail setting. And right now, it’s going to make use of the same payment hash with all these nodes, which implies that if someone owns two of the nodes in the path, they are studying information, and that is unhealthy for privacy. This all gets confusing, because Bitcoin can also be the title of the cost community on which the Bitcoin digital tokens are saved and moved. That’s why we’re not doing that right now, and that’s why most people will just keep asserting the output that actually corresponds to the channel in order that when it will get spent, folks truly discover it and might take away it from that graph and know that they can't route via that channel anymore. And however, how do you guantee that the identical UTXO is just not reused for the announcement; and what happens if that UTXO will get spent?

So, will we have to be protecting observe of the UTXO really not being moved while it is the stand-in to have introduced the channel? There are two research papers that have proposals on how to do this by modifying the scripts that we use in the corresponding output within the dedication transaction. Bastien Teinturier: Sure. So proper now, once we introduced the channel on the network, we explicitly introduced node IDs and the Bitcoin keys which are inside the multisig 2-of-2, and folks verified that the output that we are referencing is definitely locked with the script hash of multisig 2-of-2 of those two keys, so you may solely use it with scripts that really observe the format of Lightning channels without taproot. Mike Schmidt: The taproot and MuSig2 channel dialogue considerably leads into the updated channel announcement discussion and the way gossip protocol would should be upgraded with a purpose to support shifting to P2TR outputs. All right. The second phase of the LN Summit notes that we highlighted was Taproot and MuSig2 channels. But with this, this kind of narrowly allows taproot channels as effectively, but it also opens the door for experimental channels.

So proper now, the best way channels are introduced, it needs to be particular 2-of-2 multisig, appears precisely like ln-penalty channels. So, just moving the funding transactions to make use of MuSig2 already has a really nice benefit for all users, and it’s a good way to start out experimenting with taproot with MuSig2 before transferring on to PTLC. A technique to consider bitcoin and cryptocurrencies more broadly is that they're rising as a brand new asset class. No one but your channel associate has to grasp how the channel works, basically. It contains "new CLI-stage notifications, better channel state reporting, and stable plugin-hook name ordering" along with different new features and bug fixes. PTLC fixes that by making sure that as an alternative of utilizing the preimage of a SHA256 hash and its hash, we’re going to use elliptic curve factors and their website non-public keys. ● HWI 2.0.2 is a minor launch that provides assist for message signing with the BitBox02, always makes use of h instead of ' to indicated BIP32 paths with hardened derivation, and includes a number of bug fixes. 1088 adds the buildings needed for compact blocks as specified in BIP152, in addition to a method for creating a compact block from a daily block.

So, that is a really nice improvement and it also opens the door to creating more issues on top of regular payments like redundant overpayments. Mike Schmidt: Next section from the Summit mentioned PTLCs and redundant overpayments. The main query that we had through the Summit is that there’s work when the current proposal spends the MuSig2 output for both dedication transactions and splices and mutual closes, which implies that we need to handle nonce-state, MuSig2 nonce-state in lots of places, and it’s potentially dangerous because managing these nonces appropriately is absolutely vital for safety. And this way, you don’t must alternate nonces for the MuSig2 output and only the mutual closing and possibly the splices, in all probability the splices as nicely, would use the MuSig2 spend path. Use of those model names and trademarks doesn't suggest endorsement. So, we need to change that, because we want to permit taproot, which suggests permitting also input, particularly if we use MuSig2; we don’t need to reveal the internal keys. We don’t know exactly how we would do that, those proofs, and the way we would ensure that these proofs cannot be reused, how we would track channel closing in a different way than simply watching onchain.