Bitcoin Optech newsletter #164 is here:
- describes a new web-based tool for decoding and modifying PSBTs
- links to a blog post and proof-of-concept implementation of an eltoo-based LN payment channel
- continues the 'how to prepare for taproot' series: LN with taproot
I quite accidentally managed to nab #1000 with this :)
Got #joinmarket bots doing transactions on regtest in this branch:
where there's a simple c-lightning plugin (see jmcl.py) that allows the bots to use LN as a "message channel".
It's still early but it was fun to observe that even with all on localhost, doing it this way was faster than a miniircd instance (which is as simple as IRC gets).
It'll be slightly slower over Tor of course. But speed is only a very minor consideration here.
Did a via ferrata today. The scariest part was a traverse across the side of a cliff. I'm good with heights. But with 600m (!) of nothing under me, I was frankly kinda scared and shaking a bit.
But objectively, that was very safe. Climbing gear works. The _actual_ most dangerous part was these innocent looking steps. Why? Because they're held in place by rebar stakes that could impale you if you tripped.
Your monkey brain is shit at assessing risk in a modern society. Think logically.
oh another addendum :) What I said above is really just all about the Schnorr *identity* protocol, i.e. the interactive version. In the *signature* scheme there is an additional non-tightness term from the application of a hash function; that's dealt with a bit in the above blog post, but I believe the paper treats this as well and it isn't particularly different.
By the way if you're not familiar with this stuff and you're curious you might find this old blog post of mine useful:
Maybe, maybe not. The reason key sizes are what they are is a function of these "non-tight reductions". We use 256 bit keys to get ~ 128 bit security. These things may at least notionally be changed if we have tighter reductions (or improvements in security proofs on other dimensions I guess).
Video presentation on talk:
.. making this non-tight proof less non-tight.
The idea as I understand it is to not just "rewind, try again":
(Prover sends R, extractor forks Prover into two, sends two different challenges, then extracts *if both runs/transcripts output success*)
... which results in the squared term, but to repeatedly do the rewind action until success (I gloss over a lot I'm sure!), resulting in a ^3/2 term instead of a ^2 term.
Purely academic? (4/n)
running the attacker *twice*. "Special" soundness afaik means specifically this "extracting the witness from two transcripts" but it's kinda weird since there are very simple extensions to multiple transcripts for other protocols. Whatever.).
So the x^2 term comes specifically from the running twice. The attacker has to get lucky twice in a row meaning p * p rather than just p.
Now on to the point of me posting about this :)
A recent paper: https://eprint.iacr.org/2021/971 talks about (3/n)
.. "knowing the Schnorr sig is a% secure" (hence "non-tight reduction").
So why is the relationship p to p^2? Basically it comes from what's technically known as "special soundness" (ugh I hate that deliberately obtuse term. Soundness proofs are basically showing that you can extract the witness (in this case the private key) by isolating the hypothetical succcessful attacker and showing his attack "contains" the private key. In the Schnorr case that means rewinding and (2/n)
This is a bit heady, but let me try to distill it:
We know that the reduction from #Schnorr sigs to (EC)DLP is "non-tight", what that means is basically if you have an attacker than can forge the signature, you can also break the DLP, the problem being this statement is *probabilistic* - if the attacker forges the sig with probability p, it only breaks DLP with probability p^2 (remember x^2 < x if x < 1).
That means "knowing the DLP is a% secure" is not the same as (1/n)
Is it me or is the WSL Ubuntu a bit kind of useless, since it uses Windows filesystem and sockets? Was testing some code using both those things yesterday and finally realized it was kind of a waste of time, since it behaved differently from the Ubuntu I usually use.
(Perhaps it depends on details. Both the CRLF thing was biting me on git, trivial admittedly, but also starting servers with reactor.listenTCP (twisted, python) behaved in a fundamentally different way.)
Apparently there is a huge labour shortage in the UK:
Call me crazy but how about just massively increasing wages? Yes prices to consumers would go up, but better that it's available for sale at X rather than at infinity.
I found this old blog post by Will Clark interesting: it's investigating how you could route mesh network messages over a Lightning protocol, and it required big hacks, e.g.: they don't gossip, they don't ping, they don't use onions and don't use source routing but rather best-effort routing like IP; to make the LN software work they basically hacked in a fake onion at the software layer as I understood it. And still the latency was high, like 30 seconds.
Today I realised there's nothing stopping someone making a slight alteration to the taker code (literally only taker.py, no other files) in Joinmarket, to create transactions with different structures.
Proof of concept here: https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/994
As per the BIG WARNINGS, do NOT on any account do that on mainnet as I never even checked it myself. It's the idea that matters.
2B6F C204 D9BF 332D 062B 461A 1410 01A1 AF77 F20B (use email to contact)
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!