Show more
waxwing boosted

About a year ago I remember wondering when Boneh-Shoup would ever get updated from 0.4 ... well this month it has! 0.5 is out:

toc.cryptobook.us/book.pdf

I see a section on pairings for example. Hopefully a bunch more chapters filled out 👍

waxwing boosted

RT @_k3tan@twitter.com

13/ Come party with the big boys and their heavy, heavy bags. Try using JoinMarket, where you can coinjoin and earn. I take you through the JoinMarket basics, but be sure to read the docs before you try anything for yourself! youtube.com/watch?v=zTCC86IUzW

waxwing boosted

is anyone still using the binaries for 32-bit x86 linux?
if you do, please let us know—the current idea is to phase them out in the not-so-distant future

github.com/bitcoin/bitcoin/iss
lists.linuxfoundation.org/pipe

waxwing boosted

bitcoin.stackexchange.com/ques

A very old post from @lukedashjr, with a clever way to create an auction using #bitcoin payments.

Seems even more relevant now, PSBTs would make this a lot simpler to implement.

waxwing boosted
In 1998, a programmer who had been working on Y2K fixes started to get anxious because he couldn't believe how pervasive the problem was. He switched from company to company trying to get away from it, but everywhere he went he became regarded as the Y2K expert and immediately became the team lead for that company's Y2K contingencies. He finally had a nervous breakdown, quit his job, and decided he wanted to be knocked unconscious when the Y2K actually came about.

A month before Y2K he was put into an artificial coma and cooled down to a near cryogenic easily sustained long term life support.

Unfortunately the life support notification system had a Y2K bug, and no one revived him for 8000 years.

Finally he was found and revived. He woke up, and saw himself surrounded by lots of glass, light, stainless steel, and tall beautiful people in white robes. He asked if he was in Heaven.

They replied, "No, this is Chicago. Actually but it's a lot like Heaven to someone like you."

"Someone like me?"

"You are from the 20th century. Many of the problems that existed in your lifetime have been solved for thousands of years. There is no hunger and no disease. There is no scarcity, or strife between races and creeds."

"What year is it now?"

"Yeah, about that - it's the year 9,998. You see, the year 10,000 is coming up, and we understand you know something called COBOL?"
waxwing boosted

Some detailed analysis on knapsack mixing from nopara. Busy adding maker to JM gui, so i won't be reading right now but looks interesting.

medium.com/@nopara73/knapsack-

waxwing boosted

We have computed the very first chosen-prefix collision for SHA-1. To put it in another way: all attacks that are practical on MD5 are now also practical on SHA-1.

We have reduced the cost of a collision attack from 2^64.7 to 2^61.2, and the cost of a chosen-prefix collision attack from 2^67.1 to 2^63.4.

Demo: The legacy branch of GnuPG (version 1.4) is vulnerable. We have created two PGP keys with different UserIDs and colliding certificates.

sha-mbles.github.io/

Just to note, this can be done today, using -P to pick parties for the second round (the actual payment). Although it will be a bit flaky in that you can't guarantee that those entities will use the desired utxo (hence 10 might work and 2 might not).

Will have a think about whether you can make it work "for sure".

(5/5 i guess)

This gives rise to a natural thought - since this effect is *from the specific viewpoint of gaining privacy from your payee* so powerful, why not focus on creating it?

One approach: in joinmarket you do a normal coinjoin with say 10 parties, then take the equal sized output of that as your input for your actual payment, and re-join with the same 10 parties - either likely or definitely(? needs work), you will have multiple equal sized inputs, thus the paid coins are not identifiable. (4/n)

Now there's an exception to that identifiability: if you coinjoin with 1 other maker, and one of the maker's inputs happens to be the same size exactly as one of your inputs, then it isn't possible to distinguish between the two input subsets.

This has been noted in the past as one of the main reason disentangling joinmarket joins is hard.

Also note, that idea of equal inputs was termed 'reverse coinjoin' by nopara in some recent writing (pastebin.com/ADu7kQFk).

(3/n)

Caveat: lightning and coinswap (and swaps in and out of lightning) are all natural solutions to this problem; but limited in size and require interactivity. Focusing here on coinjoin which addresses a different scenario.

So joinmarket already by default solves the first half of this problem: it allows you to pay an arbitrary (including large) amount, with a coinjoin. That's the main idea of it.

But with fees on inputs, the taker inputs are identifiable (generally).

(2/n)

Another joinmarket showerthought; it needs a little background:

Consider that one aspect of on-chain privacy is specifically hiding your own coins from the payee. This one is a seriously difficult problem; no existing coinjoin does it except in certain special cases (more on that in a moment). Even Payjoin, difficult to coordinate but powerful technique - but doesn't address this problem at all.
(1/n)

For myself I suspect this hasn't got as much attention as you might expect, not because of a lack of cool crypto tech, but because of a lack of well conceived use cases.

We don't generally pay for computation of things directly. It happens, but rarely.

I found myself idly wondering whether paying for proof of work might ever be a viable idea (aside from the indirect: just using bitcoin itself, often can get same effect).

waxwing boosted

@6102
I'd imagine they would apply some relative ordering of in/out ownership within a transaction... which is idiotic, but fits perfectly well with the rest of the paper.

A little bit of discussion on this paper, from ~ a year ago: bitcoinhackers.org/@htimsxela/

Currently scanning:

eprint.iacr.org/2019/1296

The "swap a coin for a secret" idea slowly developed over time, and Maxwell took a nice step forward in summarizing the more sophisticated idea with "ZKCP" or zero knowledge contingent payments (anyone remember darkleaks? lower tech version of same idea). There's a whole story here but it's one that continues to fascinate me as likely very important in future. This paper is ditching the ZKP heavy machinery but is still an interesting take.

Show more
unidentified instance

(instance image by мøтħer ¢røω)