--- Log opened Tue Apr 09 00:00:18 2013
--- Log opened Tue Apr 09 03:13:39 2013
08:28 < HM> Just gone through a paper gmaxwell posted on bitcointalk
08:29 < HM> double blinded ECC signatures - 2010 paper by some folks at Tunghai University
08:29 < HM> i'm glad to say I followed all the algebra
08:30 < HM> it's very cool
08:33 < HM> one of the few papers i read where too much algebraic detail made it harder to follow. kept expanding terms instead of grouping them :S
09:12 < HM> hmm
09:12 < HM> this scheme doesn't prevent colusion between requester and signer
09:20 < HM> also if the signer ever sees a copy of the message it can use its database to discover who requested the signature
09:30 < HM> unless I'm mistaken Chaum's "BLIND SIGNATURES FOR UNTRACEABLE PAYMENTS" proposal doesn't protect you against colusion between payer and signer either
09:31 < HM> "Wei Dai" has a proposal that prevents colusion, but a third party can't verify tokens
09:31 < HM> I haven't seem a scheme that prevents both colusion and allows 3rd party verification
10:26 < gmaxwell> HM: for some protocols you can just have ALL of the participants blind sign.
10:26 < gmaxwell> e.g. for a vote.
10:29 < HM> i'm obviously thinking about digital cash
10:30 < HM> the simplest scheme i've seen has the issuer multiply a random point on a curve by their private key, for a fee. That's easy to blind but a payee can't verify the 'signature' (not really a signature) is legit
10:32 < HM> the 2010 paper you linked to on bitcointalk from Tunghai uni allows that but the signer can never be allowed to see the message again or they can figure out who asked for it to be signed.. and of course to verify the signature you need the message (or a hash of it)
10:33 < HM> so the question, how do you create a signature a 3rd party can verify but you can be sure hasn't been watermarked?
22:03 < warren> jgarzik: gmaxwell: Litecoin-0.8 might easily cut down its UXTO set from the week of spam in November 2011 because the attacker used the same addresses repeatedly.  Just declare all those addresses unspendable.
22:04 < warren> (yes, there is no similar simple solution for bitcoin)
22:09 < gmaxwell> warren: uh didn't the litecoin attacker send 1e-8 litecoin to like every litecoin address?
22:13 < warren> gmaxwell: perhaps in a different part of the attack, I will find out.  I will scan it thoroughly to make sure declared unspendable UXTO are the right ones.  there appear to be a great many that are concentrated in a small number of addresses now.
22:15 < gmaxwell> warren: if you're going to do that in litecoin, why not add utxo aging?
22:15 < warren> gmaxwell: is that written anywhere?
22:15 < amiller> add a utxo rental price
22:15 < amiller> when the parking meter runs out of time, kick out the utxo
22:16 < warren> amiller: more like a purchase price, which I've been suggesting for weeks now.
22:16 < warren> oh ... time limit, I like it.
22:16 < gmaxwell> warren: meh, it's not a purchase price if you can't redeem it.
22:16 < amiller> rental vs purchase
22:16 < warren> I see, rental.
22:16 < amiller> also like a parking meter, you (anyone) can put more coins in
22:16 < amiller> to keep it around longer
22:16 < warren> by spending it
22:16 < amiller> you can have a bitcoin parking meter fairy
22:16 < amiller> that fixes other peoples coins that are about to expire
22:16 < warren> uh
22:17 < gmaxwell> amiller is on the moon right now, leave a message after the beep
22:17 < amiller> just follow your nose starting at 'rental price' and you'll get mostly good ideas.
22:18 < warren> Everyone has to reindex with 0.8.x anyway.  a tiny proportion of those users will have 1e-8 disappear
22:19 < gmaxwell> warren: and then one of those gets spent and the network forks forever.
22:19 < warren> gmaxwell: the network is hardforking anyway
22:19 < gmaxwell> For what?
22:19 < gmaxwell> warren: in any case, it's stupid to solve it one time,
22:19 < warren> (mainly because they don't understand that an immediate fork isn't needed)
22:19 < amiller> people hate the idea of their bitcoins getting forgotten, or getting 'inflated' by demurrage but they'll come around to the idea of safety deposit boxes - those are reasonable
22:20 < gmaxwell> And the, as I illuded to in #bitcoin— people involved in the project will have a weaker position when some authority _orders_ them to edit the utxo set in the future.
22:20 < gmaxwell> alluded*
22:21 < warren> It's an agnostic UXTO change.  If txo < tiny number, just declare it gone.
22:22 < gmaxwell> warren: so generalize that and say a UTXO lives for 51840*ceil(log10(value)) blocks or something like that.
22:22 < warren> rather: If txo < tiny number prior to block X, just declare it gone.  When <mumble>coin is worth $10 million dollars each in the future it will be usable again.
22:23 < gmaxwell> uh. then all nodes still have to retain the data forever
22:23 < warren> at least it won't be in the UXTO set?
22:25 < amiller> how about when the 'value' changes, then previous utxos are credited proportionally for their time
22:26 < warren> gmaxwell: This might not be needed anyway, literally all of the litecoin spam is in a week during November 2011.  I suspect the simplest and least risky plan is just to figure out which addresses concentrate the most spam UXTO and just eject that.
22:26 < warren> (scanning to be damn sure it effects nobody else)
22:27 < gmaxwell> warren: so you do that and then shortly there after someone just floods you again.
22:28 < warren> gmaxwell: they're welcome to pay the ridiculously high fees
22:28 < gmaxwell> Hell, it would be worth doing that just to make you feel stupid. :P
22:28 < warren> litecoin has two fees, a regular high fee, and an added fee for dust values
22:30  * warren still doesn't have <any>coins.  This is just interesting to think about.
23:03 < gmaxwell> So P2SH^2 am I awesome or what? Best idea I've had all month.
23:14 < BlueMatt> is it really worth implementing though?
23:17 < gmaxwell> I .. think! so.
--- Log closed Wed Apr 10 00:00:06 2013