waxwing @waxwing@x0f.org

I'm curious how many people around here remember the story of Ladar Levison and Lavabit:

"Lavabit was ordered to provide the SSL key in machine readable format by noon, August 5 or face a fine of $5000 per day.[28] Levison closed down Lavabit 3 days later. "

https://en.wikipedia.org/wiki/Lavabit

It still stands out as an almost unique defiance against government surveillance.

@pete in your recent mailing lost post you wrote, in response to this:

"> In the CHECKTEMPLATEVERIFY approach, ... Based on a
> destructuring argument, it is only possible to create templates which expand
> in a finite number of steps. ....

(snipped), :

"The "finite" number of steps could be millions of transactions - "infinitely
long" for any practical purpose."

I don't understand why this is an issue. If there's a chain of ctv outputs, why does the network as a whole care?

This is interesting: stacker news is experimenting with a WoT model:

https://stacker.news/items/8349

#bitcoin #lightning

I fed the sheep :)

https://www.twitch.tv/tanglesheep

#lightning

Interestingly the guy coded it to display the payment hash in the twitch chat when it's received: "tanglesheep
Thx for feeding via BITCOIN LN your payment hash is ..."

The sheep all ran to the trough straight away. Surreal.

Here's a fun artificial case to demonstrate the point (from the first post in thread): you make an app that rewards people who own a set of addresses (that you've chosen in advance because .. they're cool people) A_i with pubkeys P_i . They can claim 1 coin by signing a message with key P_i. To make it fun you allow them to enter the text (m) they sign in some web app, then your app verifies the signature of P_i against that text m, and sends the coin if so (once per P_i).

https://github.com/indutny/elliptic/blob/e71b2d9359c5fe9437fbf46f1f05096de447de57/lib/elliptic/ec/index.js#L102 do not read that great if taken at face value 😂

Also am I taking crazy pills or is it really dubious to be using any form of truncation in these algorithms?!

ECDSA has, as part of its definition in the sign() and verify() operations, a hashing step on the message. There are very good reasons why this is necessary. Apparently according to Matt Green's recent blog post, this is the code that does sign/verify in metamask (and may well be, many other JS projects):

https://github.com/indutny/elliptic/blob/e71b2d9359c5fe9437fbf46f1f05096de447de57/lib/elliptic/ec/index.js#L91-L194

I notice it does not include that hash step. It won't matter in all but an extremely artificial case, but ...

Also comments like this: (1/2)

#cryptography

For trading of many things (good example: FX), margin is logical and it improves liquidity/market functioning. I might want to put 30% of my investments into a position, but if I can do it while only risking 10% of my investments with a central counterparty, it's far superior. When leverage becomes very large, it does indeed become a reckless gamble (except for specialized professional situations), but even when conservative, it's still hugely valuable to reduce counterparty risk.

I still think real-time updating of collateral/margin in trading could be the surprising 'killer-app' of #lightning (or maybe just bidi channels).

I mean I could well be wrong, but it's a surprising idea in the sense that everyone has assumed that 'streaming payments' is useful pretty much only for micro-payments.

The 'posting of margin' (the old name for it) is often misunderstood, people think margin trading is degenerate but it's actually about reducing counterparty risk.

#bitcoin

Pepperidge farm remembers when your computing device was your servant, not your master.

https://stackoverflow.com/a/68761052

... I still can't imagine a concocted scenario where I would screw up in this kind of way. Perhaps that's more an argument for actually *understanding* things like signature algorithms, even if you're not a world-class expert, and less a commentary on personal motivation.

I wonder if the rather high complexity of the code he *removed* might have been a factor, too.

OK I'll stop :)

5/5

.. wanted to achieve a big performance boost and wasn't paying attention to any of the underlying mathematics too carefully.

*Perhaps* choosing '8' in the nonce generation actually made it faster (hmm, ok, maybe not, that is wild guess)? If that were true, it would explain it. But if not, we still have the case of someone ignoring security issues because they're 100% focused on improving user experience/achieving a goal.

As someone who's made bad errors in coding such stuff myself, (4/n)

.. from Charles; this is the most important part of a PR thread as it tells you the outline of what the *intention* is (usually). It is all about performance. He's switching up the underlying crypto code in the hope of making the library a lot faster.
4. In the final comment, on merging, again from Charles, and again the *only* comment that talks about PR content, we have a concret-ised claim of the speed improvement.

The conclusion is conjecture but I think fairly obvious: Charles badly (3/n)

The PR conversation: https://github.com/bitpay/bitcore/pull/409 has 20 entries. There are a few things I notice:

1. This is all Ryan's work, there is no ACK going on, he wrote the code and merged it.
2. There is, however, a fair bit of feedback from several well known community members. All of it is just 'cool!' or variants thereof. (I am loth to judge though, been there, got the T-shirt. We don't always check everything and sometimes take stuff at face value).
3. Look at the main introductory comment .. (2/n)

In that recent citadel dispatch podcast I mentioned the funny anecdote of being on IRC with gmax when the "Biased Nonce-sense" paper (Breitner, Heninger) came out, and how he in a matter of minutes found the commit that caused the 64 bit nonces. I was pleased to see the latest version of the paper credits him (p. 10 https://eprint.iacr.org/2019/023.pdf ) but also it inspired me to re-look at the offending Ryan X Charles commit: https://github.com/bitpay/bitcore/pull/409/commits/ac4d3186bfbb4df2aee4389d1a51e488df08b52a#diff-43ddc84d45d5af8aad777ce038e2df3c39324481da540437b96a9879c19561d4R114
Why 8 bytes? Look at the PR.
(1/2)
#cryptography #bitcoin