waxwing @waxwing@x0f.org

@rubensomsen i am. perhaps you didn't hear, but my blog got wiped and i reconstructed it slowly. There's probably only 3 articles left that I haven't reconstructed with pandoc and re-uploaded, I actually had Gleb ask me the same question about another article yesterday :)
I'll make a point to put that S6 one back up in a day or two.

... very small amounts, has a paradoxical effect: it makes it surprisingly more likely to get multiple "non-derived mappings", i.e. you can end up with multiple interpretations of input-change output linkages.

This effect obviously drastically increases with participant count, but it is kind of interesting. Obviously the idea coinjoins would be whole blocks where people are paying each other and kind of "payjoining" in that sense.

(2/2)

Reading the 2017 paper on knapsack mixing

https://www.comsys.rwth-aachen.de/fileadmin/papers/2017/2017-maurer-trustcom-coinjoin.pdf

... reminds me of something that became particularly obvious in the gridchain analysis. Subset sum (identifying "non-derived mapping" in the paper's terminology) is only computationally difficult in the case of a bunch of payments simply merged together, where all the amounts involved are different. They try to quantify this in the paper.

But specifically having participants pay each other, even ..(1/n)

#coinjoin #bitcoin

New release of joinmarket:

https://github.com/JoinMarket-Org/joinmarket-clientserver/releases/tag/v0.7.2

mostly bugfixes

#bitcoin #joinmarket

When you read this in an academic paper, it kind of makes you chuckle:

"As can be seen in Figure 3, the runtime of our evaluation program does indeed grow exponentially, which supports our assumption."

http://www.erisian.com.au/wordpress/2020/10/26/activating-soft-forks-in-bitcoin

Survey of thoughts of .. some people on activation.

#bitcoin #taproot

@FreePietje yes, that amongst some other UI refinement would make that less confusing, I agree. There are even bigger issues with the whole UX of that though .. one that really bothers me is how unobvious it is to the receiver what is going on with mixdepth of coin spent vs coin received.

About mixdepth vs account, this is baggage from the early days of the project. we're well aware of it.

@FreePietje
> mixdepth was 2 but when pasting URI, it shows 1? I might understand it, but it's confusing as it seems a parsed value.

The mixdepth is a property of your own wallet; you wouldn't want or need to communicate that to the counterparty in the URI (or otherwise). The mixdepth fields for the two wallets are chosen by that person, they're choosing where they're sourcing coins from.

This new paper from a few days ago, on some kind of new payment channel construction ("Payment trees"?) looks like it could be worth a read:

https://eprint.iacr.org/2020/1313.pdf

@FreePietje about the v2 onion thing: we create whatever your tor instance supports as the latest; my ubuntu1804 instance here, irritatingly has a tor from a version just before the one where it creates v3 onions. But it works either way. I agree it would be better if this vid had v3, but we've had plenty of tests with that. The video was just a quick knock-together thing to show how it is done.

I thought I should start giving people a bit more about my thoughts on Joinmarket, from time to time. I guess it's mostly of interest to users of the system, but still:

https://joinmarket.me/blog/blog/oct-2020-update/

#joinmarket #bitcoin

The presence of 'bitcoin' in this table is definitely not going to cause controversy :)

https://tools.ietf.org/html/rfc8905#section-10

discussion thread (seems like an interesting topic, but one has to wonder if the welter of complications is going to stymie any such attempt at standardization):

https://news.ycombinator.com/item?id=24885193