I see it through JM lens where you can't reliably renegotiate the CJ due to ephemeral coordination so I've always just ignored RBF there, (and nor can you stop someone retrospectively cancelling the coinjoin contract by double spending their input). Of course CPFP exists but since there's no penalty mechanism I don't think the whole pinning thing is so relevant?
Maybe with adversarial makers in a taker maker model? It seems unrealistic.
But with redesigned cj protocol maybe other issues arise.
To be clear I really don't know.
First, my knowledge of this area is very sparse. Second, my response would depend on what you're asking: do you need to know about the issue this is trying to address? I could suggest bitcoin optech on pinning: https://bitcoinops.org/en/topics/transaction-pinning/ (optech is good as a library/reference on these technical concepts in bitcoin, generally; you can also follow links from there). Are you asking how exactly the rules in BIP431 will work? I don't know, but the basic concept is: we have this complicated bunch of rules to decide whether a transaction can be received into our mempool. These rules try to make sure a node can't get DOSed with infinite replacements; try to make it so that what gets into the mempool is "incentive compatible" with mining, i.e. that a rational miner would actually choose these transactions, and try to make it so that pinning as described above is either impossible .. or really hard? (not sure). This TRUC thing will be a new tx type which, if you opt into it, you can't have a chain of unconfirmed txs .. like tx1 is unconfirmed, then you add tx2 which spends from tx1, then tx3 spends from tx2 etc. etc.; TRUC would only allow tx2, not the ones after. That will make some versions of pinning not work, if I understand it correctly. Perhaps someone can expand on that last bit.
My original comment was along the lines of 'trying to understand and reason about whether a transaction can confirm is just getting more and more complex the more we understand it, which just illustrates that relying on penalty mechanisms like in current LN is really painful because of the game theory stuff'. not a criticism of this proposal, as I said, it does at least *try* to *restrict* how complex things can be, but it's arguable whether it achieves that goal, I think (because it's adding another way for txs to work .. but .. if everyone takes up this new ruleset for LN stuff then perhaps not? I don't know).
Just discovered BIP431.
My reaction is to be reminded of Shakespeare's "oh what a tangled web we weave, when first we practise to ... use game theory instead of cryptographic verification."
At least *restricting* scope (TRUC) makes the scope of the problem.. less intractable? Even that seems debatable.
Oh interesting setup!
I think this can be done using aut-ct: https://0xparc.org/blog/zk-group-sigs
Cc: nostr:npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7
Sorry only just noticed this ping.
Well, I think so, yes.
ZkSNARKs approach will be better for small, defined groups (more efficient).
For cases of very large spontaneously defined anon set from blockchain that isn't possible hence aut-ct is worth looking at.
This book is excellent. Understanding Cryptography by Christof Paar and Jan Petzel. This is where I learned the math from first principles
https://link.springer.com/book/10.1007/978-3-662-69007-9
If you’re looking for something more hands on, Jimmy Song’s Programming Bitcoin is a great Python resource
Christof Paar does indeed seem like a good recommendation... i remember skimming that book but not getting it for some reason, but his lecture course on YouTube is really good and quite popular.
For EC stuff I'd recommend Washington ("Elliptic Curves Number Theory and Cryptography 2nd ed " easily accessible online). Stuff by Silverman and Galbraith is more thorough and i guess suitable for graduate mathematician researchers, but Washington is already pretty heavy in mathematics. To be clear, it's often better to treat EC as a black box (discrete log hard group is mostly all we care about, except some details like serialization).
nostr:npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7 once gave me a few recs before, escaping my mind atm
Not sure on history. Simon Singh's 'the Code Book' was decent on that, but it's popsci, so fairly light.
For learning fundamentals of modern crypto in practice I'd recommend Serious Cryptography by J P Aumasson.
Boneh and Shoup give you a lot of solid grounding for serious study (e.g. security arguments) in toc.cryptobook.us
Work through the cryptopals challenges if you like hands on learning.
Oh, i had no idea about tge routing distinction, that's interesting.
Thanks.
Not sure it's easy to improve, but esplora lookups aren't as good as monitoring with home node, right? Kinda intrinsic to not having a home node. Just a first thought. Also this model used by phoenix and alby of single channel connection to LN obv has huge advantages but has a privacy tradeoff right.
Just installed #alby hub alongside my home node.
Interesting experience; I did not opt for the purist route of own LN and BTC node (not sure how purist that actually is, in the end) but the more 'default' option of LDK talking to esplora (as I understood). Very interesting how different the modern onboarding experience is.
Of course even this is a bit too much responsibility for most users most of the time (an always on PC!). Cloud hosting makes sense, but I think the fee will put people off, a bit (no judgment).
All of this is super lax privacy wise to be clear. Even more so than my every day expenses LN wallet, Phoenix.
As a result I've finally reenabled zaps for myself after more than a year's hiatus 😄
Bitcoin Core.
Most of Electrum is command line usable as I recall. A little less detailed documentation.
Core CLI is the closest you'll get to the 'swiss army knife' experience, though it can be very arcane.
New blog post
https://reyify.com/blog/adaptors-generalised/
... been thinking a lot about this topic, on and off. Not sure about potential applications to onchain verification of ZKPs, but *any* ability to lock bitcoin state transitions/payments to proofs of statements that are not restricted to a single generator G, feels like it could lead to some important new protocols. But this being interactive is clearly not as good.
I've rewritten the second half of this substantially, since it had several non-trivial errors; sorry for anyone who got that far 😄. I think it makes considerably more sense now ...
Part of that price we pay for true permissionlessness. There is no foundation, org, or person to stand up for them.
Decent people have always recognised that what you say is correct, but not all people are decent.
Unfortunately had to migrate recently, so most are currently not online, but i will bring them back (sadly cannot migrate purely automatically).
New blog post
https://reyify.com/blog/adaptors-generalised/
... been thinking a lot about this topic, on and off. Not sure about potential applications to onchain verification of ZKPs, but *any* ability to lock bitcoin state transitions/payments to proofs of statements that are not restricted to a single generator G, feels like it could lead to some important new protocols. But this being interactive is clearly not as good.
Pretty bad/sloppy takes mixed in with decent analysis there. 'Joinmarket is an old version of ZL' .. no, not even a little bit true. 'Joinmarket is not usable except by devs' that one's more just a matter of opinion, but it's pretty bad to not even mention JAM plus the other client(s) joininbox of nostr:npub14tq8m9ggnnn2muytj9tdg0q6f26ef3snpd7ukyhvrxgq33vpnghs8shy62.
Hmm could be Ukrainian though .. that would make that combination slightly less surprising.