did you know? you can mute a whole instance on your personal tl, and it doesn't require a defederation action
I moved http://mempool.emzy.de over to a server with two 500GB SSDs in a raid0 configuration. Searches for addresses with a big history (address reuse) are now much faster.
@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.
Every notice how if you look at fediverse.space all the Pleroma servers are in the center? Because they actually federate?
Some thoughts about estimating anon set sizes in CoinJoins, I would welcome any inputs, especially critical ones =)
New #JoininBox version: v0.1.13
After updating from the menu the latest v0.7.2 #JoinMarket release can be installed.
It is not only for the #RaspiBlitz, can try it on any Debian based ARM (@armbian and other @Raspberry_Pi) build or a Linux Desktop too: https://github.com/openoms/joininbox/tree/v0.1.13#set-up-joininbox
New release of joinmarket:
... 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.
Reading the 2017 paper on knapsack mixing
... 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)
New release of joinmarket:
Survey of thoughts of .. some people on activation.
@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.
> 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:
@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.
The presence of 'bitcoin' in this table is definitely not going to cause controversy :)
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):