The first one, https://youtu.be/XVwPEsgV1Gg at first I thought this was kind of a funny question, but I actually got a lot of interest on the Stack Exchange, which is, "How can I manually, on paper, calculate a Bitcoin public key from a private key? PTLC fixes that by making sure that instead of using the preimage of a SHA256 hash and its hash, we’re going to use elliptic curve points and their private keys. So, we’re going to be able with that to make good progress and hopefully, at some point, have a good enough solution to fix all those jamming issues. So, I’m not sure this has made a lot of progress, but this can still make progress in the past months, but I haven’t been tracking that closely. If I’m understanding the reason behind that, it’s that the reason that sipa points out here, that there are known algorithms that are more effective than just brute-forcing 256-bit keys, so that it’s technically then 128-bit security; am I getting that right? This is the main issue here, in my opinion, where you’re basically holding on extra key material. And also another issue with redundant overpayment is that you are actually, for the duration of your payment, using more liquidity of the network than what is requi
So yeah, I do think route boost is more of an interesting historical thing that was tried, but it didn’t really yield any meaningful result in practice, I believe. Mark Erhardt: I think that there might also be a couple of issues here with if you, for example, have one peer that you closely work with and you want to funnel more fees to, you could always route boost them and then make sure that they collect the fees rather than other peers you have, which may be sort of a downside of prioritizing boosted peers. I thought this was sort of a comprehensive treatise of the topic, so glad that we have it on our site. Mark Erhardt: So, while nobody is taking a turn, both have yielded and then anybody can start again, or… So, just a bit of context there. So, this is quite hard to do correctly, and there are proposals. There is a basic, classic, and advanced interface. For example, at least in Eclair and in Core Lightning (CLN), whenever you read an invoice and see some route hints in there between a pair of nodes, you use those channels in priority regardless of whether you have other channels to reach that destination between the - to reach that - well, no, I don’t r
ber.
You would just include them in your blinded path, people don’t even have to know what channel this is, but you kind of force them to go to a direction where you know that there is liquidity. Even if you want to do hundreds of keys. But it’s really the recipient’s decision to whether they want to use it or not. Mark Erhardt: It also is really nice about - one thing that I really want to point out. It’s hard to figure out if hybrid deployments would actually really work in practice. That’s something that we will eventually do because simplifying the protocol is always a good idea, but it’s hard to tell when is going to be the right time. Right now, whenever you send a payment, this payment is going to go through multiple nodes on the network. Mike Schmidt: Does it feel like this is moving towards experimenting and figuring out one solution, and that all implementations and node-runners and going to use that solution, even if it’s a combination of techniques; or is this more something that different implementations may have different combinations of keys and different algorithms for reputation, and maybe even users would be able to configure that; which direction do you
that going?
T-bast, can you talk about the issues with either peer being allowed to propose a commitment transaction and why turn-taking may be a good idea? So if that were the last element on the stack, it would actually indicate that the transaction validation has failed. In this monthly feature, we highlight some of the top-voted questions and answers posted since our last update. After a recent update to Rust Bitcoin introduced stricter parsing of signature fields, a discussion ensued whether a signature field in a PSBT may hold a placeholder, or only valid signatures were permissible. The updated library doesn’t make the features available on sidechains by itself, but it does provide the code upon which both signature generation and verification can be performed-allowing developers to build the tools necessary to put Schnorr-based systems into production. 656 adds a feature bits specification to BOLT11, allowing payments to indicate which features they support or require.