wumpus changed the topic of #bitcoin-wizards to: This channel is is for discussing theoretical ideas with regard to cryptocurrencies, not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
rusty has quit [Ping timeout: 255 seconds]
<bramc>
Now I'm wondering when/how triggering of a reorg based on a block being too small should be done
archbserver has joined #bitcoin-wizards
archbserver has quit [Remote host closed the connection]
archobserver has joined #bitcoin-wizards
<Eliel>
So, I'm inclined to make some effort towards writing a privacy focused input selector for a wallet software. Would you happen to have pointers on how to go about it? Is that even possible assuming the user does nothing to help the wallet do it?
PaulCapestany has quit [Quit: .]
<kanzure>
perhaps start by assuming user is maximally helpful, then back off from there once you have a good implementation for an expert user
<Eliel>
now if I only had an expert user somewhere :)
<adlai>
it lacks any information on how closely "tainted" to eachother the possible inputs are. this information could lead to better choices, since your wallet could already have some correlated inputs which you might as well merge
PaulCapestany has joined #bitcoin-wizards
<gmaxwell>
Eliel: well the coinselecter in bitcoin core is arguably 'privacy focused' so long as the user _never_ reuses addresses. :P
<gmaxwell>
(bad assumption ...)
<Eliel>
:)
<gmaxwell>
in any case bitcoin core has code that identifies common spending (and makes address gruops). making the coinselector select address groups and not coins, then try to spend all the coins in the group at once (danger: sane handling of dust floods), would probably be much better than what it does today.
AnoAnon has joined #bitcoin-wizards
<gmaxwell>
related, if there is a lot of change, it could be useful to randomly decide to either split the change in half, or (if the change is more than the output) set one change output to be equal to the payment amount.
<gmaxwell>
which would keep which txout was the payment more private.
AnoAnon has quit [Read error: Connection reset by peer]
<Eliel>
I already have some code that creates more change outputs sometimes. It could probably use some randomization though.
<adlai>
if it looks like a coinjoin, and quacks like a coinjoin, it must've been a coinjoin!
rusty has joined #bitcoin-wizards
<gmaxwell>
adlai: funny that.
* adlai
has a whole collection of false positives
<adlai>
by volume, they're a rounding error; but if you just count transactions, joinmarket becomes the rounding error
chris13243 has quit [Read error: Connection reset by peer]
<gmaxwell>
adlai: how do you know they're false positives?
<gmaxwell>
one of the neatest way of using a CJ is a CJpayment, Where I you want me to pay you, so you have me coinjoin with you where you walk away $amount richer.
<adlai>
no subset sum matches between inputs and outputs, or at least, not in a pattern which is produced by joinmarket... it could be one of the other "coinjoin" implementations
bendavenport has quit [Quit: bendavenport]
<adlai>
right, but that requires that the recipient have enough coins to begin with
<gmaxwell>
have any coins.
<adlai>
if you're rich enough, you can make a fake ten-party coinjoin where the real recipient (who has no coins initially) is just one of the "change" outputs
<gmaxwell>
e.g. you want me to pay you 4. you have one, you give me the 1 txin, I provide a 6 txin, and the tx has 5 out to you and 2 out to me.
<Eliel>
adlai: I suspect that set might contain quite a few transactions that I could find in wallet on one of the servers I admin. No coinjoin's there, but they might seem like coinjoins sometimes.
<belcher>
a problem with fake coinjoins is you must never combine the inputs again
<gmaxwell>
so then some privacy invader who thinks they can identify coinjoins now incorrectly thinks that you and I are the same party.
<belcher>
err, outputs
<adlai>
is there any writeup/PoC of CJpayment? it sounds like what the Payment Protocol should be doing, instead of checking CA certs...
<gmaxwell>
belcher: I can imaine that CJs sometimes rejoin, but... even if you don't avoid doing that, having it sometimes work is better than not trying (particularly if the users aren't even aware of this going on)
<belcher>
yes agreed, in the context of this utxo-selecting-for-core
<gmaxwell>
adlai: I suggested it at some point for payment protocol, but there was zero interest from anyone doing payment protocol stuff, so I didn't spec it out... PP seems kind of DOA.
<gmaxwell>
I wish there were a way to measure usage of it, though informally it doesn't seem to get that much.
<belcher>
its a pity, PP is nice
<belcher>
you can actually use PP?!
<bramc>
My conclusion about trying to improve privacy with coin selection algorithms is that everything sucks.
<gmaxwell>
In core we get no bug reports or feature requests related to it, and I've not heard of small wallets that don't support it being asked to support it.
<gmaxwell>
nor has anyone asked us for cli/rpc support for it in core.
<gmaxwell>
AFAIK.
<Eliel>
bramc: well, there's always the difference between crappy and downright awful :P
<gmaxwell>
There is something to be said for best effort being better than no effort, even if its not that great.
mdavid613 has quit [Quit: Leaving.]
<adlai>
belcher: most/all coinbase (and bitpay?) payment requests are compatible with PP, but the sending wallet needs to support it. schildbach's wallet does, and i've used it... once
<belcher>
i thought it was only an idea so far
<belcher>
could it be extended to use multisig for consumer protection ?
<belcher>
pubkeys and refund address and so on
<adlai>
iirc it already supports the recipient specifying a distribution rather than a single (address,amount)
<jcorgan>
o.O?
<bramc>
Here's a list of possible strategies: Use oldest coins first. Use newest coins first. Use largest coins first. Use smallest coins first.
<Luke-Jr>
belcher: there is a refund address, but you can't do escrow with it
<bramc>
I can't even tell which of those is better than the others for privacy.
<Luke-Jr>
(the recipient can use multisig, but it's not useful for escrow)
<Luke-Jr>
bramc: I like "use newest coins with sufficient priority"
<belcher>
could the parties agree on pubkeys to derive a multisig address
<adlai>
bramc: using larger coins lets you delay merges, but as you've written in your fee post, you'll pay for / merge the dust eventually one way or another
<bramc>
Luke-Jr, Define 'priority' and 'better'
<jcorgan>
i'd love to see senders and recipients be able to negotiate a transfer of X amount of BTC through multiple TXes so facilitate "never merge up" poliies
<jcorgan>
policies
<bramc>
adlai, Yes my conclusion working on that post was that it matters much less than you'd expect.
<Luke-Jr>
bramc: "priority" is typically defined as "value of each input multiplied by how many blocks confirmed it is, all combined"
<jcorgan>
like paying $10.52 with 2 fives, 2 quarters, and a dime which you happen to have
<Luke-Jr>
(I didn't use the word "better")
* adlai
and belcher have been discussing prioritizing coinjoin counterparties by BDD or "contribution to resulting tx priority", so it matters more than you'd expect :P
<bramc>
Luke-Jr, You answered my question about which is 'best'
<adlai>
the idea being that if you prioritize by priority, an incentive emerges to actually enlarge the anonymity set, rather than just dancing around in more fungible patterns
<Luke-Jr>
bramc: just saying I like it ;)
<Luke-Jr>
"best" is likely to be subjective
<gmaxwell>
PP has something of a design flaw where the refund address thing is not very useful because there is no strong promise that the payee will get the PP message IF they get the transaction.
<adlai>
enter CT :)
<jgarzik>
I like the idea of common denominations - makes it much easier to do some privacy stuff like mixing, and assists in making the wallet less fragmentation-prone
<Luke-Jr>
gmaxwell: you mean a non-compliant wallet might broadcast the payment transaction directly, rather than only send it to the merchant over PP?
<jcorgan>
jgarzik: exactly
<gmaxwell>
adlai: for joinmarket I think you have a problem that many of the joins are likely graph identifyable because the makers are fixed points.. and keep recycling coins join after join.
<gmaxwell>
Luke-Jr: you're not prohibited from broadcasting directly. :(
<Luke-Jr>
hrm, was that removed? or am I imagining things?
Ylbam has quit [Quit: Connection closed for inactivity]
PaulCapestany has quit [Quit: .]
PaulCapestany has joined #bitcoin-wizards
<adlai>
gmaxwell: yes. belcher's "patientsendpayment" is supposed to alleviate that, by making all market participants act as makers, with some sporadically initiating transactions... i'd also like to see more makers offering "negative fees", which would make the patient algorithm more sensible
<jcorgan>
A: send me X BTC. B: ok, i need 3 addresses. A: ok, here are 3 new addresses. B: here are three TXes that total X BTC for you. A: got them all, confirmed, thanks!
<Luke-Jr>
jcorgan: too many round-trips. remember this may be over QR codes and/or email :/
<gmaxwell>
adlai: I think it could be improved by makers also offering a coinswap market using the same coins.
<adlai>
doesn't the payment protocol already support providing multiple addresses?
<gmaxwell>
adlai: it does, dunno if any clients do anything with it.
<jcorgan>
Luke-Jr: true, but i was thinking more of an online negotiation
<jcorgan>
adlai: the sender needs to determine how many addresses it needs from the receiver based on what UTXOs it has to spend
<jcorgan>
i think PP just lets receiver blindly spec one or more addresses
<jcorgan>
the overall idea is that there would be a "meta" transaction whose state is tracked by the participants, but it would consist of one or more low-level TXes getting confirmed
<jcorgan>
again the goal would be to allow the sender to choose multiple UTXOs and use multiple TXes to avoid merging any UTXOs in a single TX
<Luke-Jr>
jcorgan: better to coinjoin to a single destination
<adlai>
better = cheaper, both for the counterparties and for the commons; but the counterparties sacrifice privacy.
<Luke-Jr>
not using coinjoins..
<jcorgan>
Luke-Jr: i'm not following you
<adlai>
coinjoin to a single destination suggests a specific amount transacted, although confidential values help. but even then it creates links in the transaction graph, which coinswap avoids
<adlai>
(and jcorgan's suggestion maps directly to using multiple coinswaps)