Bastien Teinturier: Sure. So right now, when we announced the channel on the network, we explicitly announced node IDs and the Bitcoin keys that are inside the multisig 2-of-2, and people verified that the output that we are referencing is actually locked with the script hash of multisig 2-of-2 of those two keys, so you can only use it with scripts that really follow the format of Lightning channels without taproot. 25943 adds a parameter to the sendrawtransaction RPC to limit the amount of funds burned per output. 17595 adds support for reproducibly building the Windows versions of Bitcoin Core using GNU Guix. \u25cf Help test Bitcoin Core 0.18.0 release candidates: Bitcoin Core\u2019s third RC for its next major version is available and a fourth is being prepared. 13987: when Bitcoin Core receives a transaction whose fee per vbyte is below its minimum feerate, it ignores that transaction. So in the end, you have two transactions that are negotiated with just one request and response, one where the initiator is paying the fee, one where the non-initiator is paying the fee, and each of them chose the fee they are ready to pay. Mark Erhardt: I really like that the person that wants to close the channel now has to pay for it, because it always baffled me that the person that started the channel also had to pay the closing fee.<\/p>\n

Bastien Teinturier: Yeah, I think also one of the reasons we don\u2019t see pinning is that really, it\u2019s harder to pin right now and make it work your while, because right now, commitment transactions do pay some fees. And we\u2019ve always gone back and forth between those, because we don\u2019t know if we should do a simpler version first and wait for later to do a much more complex version, or if we should just jump to the more complex version right now. We don\u2019t know exactly how we would do that, those proofs, and how we would make sure that those proofs cannot be reused, how we would track channel closing differently than just watching onchain. The standardization of these preimage fields was found to be necessary for miniscript-aware finalizers, though they can be used by any PSBT finalizer needing to satisfy hash preimage challenges (e.g. for https:\/\/www.youtube.com\/<\/a> onchain LN commitment transactions). Each workshop will be tailored to the member companies attending and the specific scaling challenges that they are facing.<\/p>\n

Alternatively, a BIP8 flag-day soft fork fulfills the fifth criteria but encounters challenges fulfilling the other four criteria. Basically, I think there\u2019s some basic agreement on this line that we\u2019re shooting for with package relay, v3, and ephemeral anchors, where the commitment transaction can get a very nice cleanup and improvement and kind of confirmation requirements, while the rest, there\u2019s still some pinning vectors beyond that with HTLC transactions. So, since our goal is rather to go in the direction of removing update fee entirely and using zero-fee commitment transactions, we\u2019re just not going to bother changing how the fee is paid before we get to that point. So, that\u2019s like another level. It sounds like that was a several-day meeting. It\u2019s sort of like how Bitcoin nodes all do their individual check of the blockchain and enforce all of the rules locally, because they have absolutely no reason to trust another peer that that peer did the work and is truthfully reporting the data to them, instead of just doing it themselves locally. \u25cf Breez wallet enables spontaneous payments: Version 0.9 of Breez wallet adds the ability to send spontaneous payments to Lightning nodes that support keysend.<\/p>\n

\u25cf UTXO ownership proofs or other alternatives: although not necessary for Riard\u2019s initial proposal, some forwarding nodes may experiment with giving credentials to everyone who proves they own a Bitcoin UTXO, perhaps with modifiers that give older or higher-value UTXOs more credential tokens than newer or lower-value UTXOs. So, making sure that you are actually pinning it and getting more value out of the attack than what you paid to actually make the pinning work is probably quite hard today, especially with the state of the mempool. So, this is basically a channel that cannot be used any more, there\u2019s nothing urgent to do on it apart from closing, so having even a few more round trips is just not at all an issue. The structured representation of Bitcoin scripts provided by miniscript allows wallets to be much more dynamic about the scripts they use. Miniscript allows software to automatically analyze a script, including determining what witness data must be generated in order to spend bitcoins protected by that script. This week\u2019s newsletter includes our regular sections summarizing popular questions and answers from Bitcoin Stack Exchange, announcing new software releases and release candidates, and describing recent changes to Bitcoin infrastructure software.<\/p>\n","protected":false},"excerpt":{"rendered":"

Bastien Teinturier: Sure. So right now, when we announced the channel on the network, we explicitly announced node IDs and the Bitcoin keys that are inside the multisig 2-of-2, and people verified that the output that we are referencing is actually locked with the script hash of multisig 2-of-2 of those two keys, so you […]<\/p>\n","protected":false},"author":3486,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[135],"tags":[],"yoast_head":"\n