--- Log opened Tue Nov 12 00:00:14 2013
04:00 < adam3us> amiller_: lsb no, < n/2 mod n, yes? or is < also on small ints
04:51 < adam3us> i guess size limits would get in the way, but the lack of bigint operations in the script lang, invites people to write a sha256 in the script lang USING small ints (if there are enough small int ops ot turing completeness to even do that)
06:46 < adam3us> btw i hope someone has a real-time archive of bitcointalk - didnt seem to be that reliably maintained and managed from the repeated hacks & downtime - be an actual problem if that archive was lost
06:53 < adam3us> btw about "not as described" yesterday ... the fact that bitcoins fungibility is imperfect (and improvements worked on) can not be logically used as a rationale for building non fungible p2p bearer bond
06:55 < adam3us> the 1995 era digital bearer bond had perfect fungibility because of the simplicity of chaum blinding, but limited durability as the combined issuer/transaction server housing the double spend db could (and often did) disappear, like digicash betabucks server eg
06:57 < adam3us> it seems like chris odom's OT model with receipts and multiple competing redundant but not decentralized servers, and users could collaboratively, p2p, detect servers that issue conflicting transactions (each user audits his own view, posts conflict to other users) -and react by switching to another server
06:59 < adam3us> i dont know if the p2p part is implemented - seems more like a dissatisfaction word of mouth, loss of business for tx server argument afaik.  but at least the receipts provide some durability, however you may need all users in the tx chain to be around, online, to not lose their own records, to reassemble a server state  which sounds fragile
07:26 < jtimon> adam3us maaku wanted to add in-chain chaumian cash to freimarket, but I still don't see much value on it
07:26 < jtimon> chaumian cash is not atomically tradeable by anything else, not even in the same chain/server
07:27 < jtimon> I don't see the problem with non-perfectly-fungible in-chain assets
07:27 < adam3us> jtimon: i think it provides two features: optional privacy, and fungibility arising from the privacy.  just because the payment is fungible (due to anonymity) doesnt have to imply you need to use the anonymity: eg you ca be full identified, kyc certified, or pseudonymous or anonymous as you choose
07:28 < jtimon> you do have optional privacy with traceable pseudonyms
07:28 < adam3us> jtimon: if something is not fungible it adds to risk and transaction cost.  credit cards being the canonical example - many internet businesses cant take credit cards for this reason
07:29 < jtimon> no, the transactions are still irreversible
07:29 < adam3us> jtimon: if you mean bitcoin current, then yes and the implication is  you then get moderate fungibility which many think is a risk that needs fixing
07:30 < adam3us> jtimon: bitcoin transactions? or freimarket transactions?
07:30 < jtimon> both are irreversible
07:30 < adam3us> jtimon: defacto yes, cryptographically no, courts will disabuse people of the difference in due course
07:32 < jtimon> you mean at redemption time, but I don't think that's legally feasible nor how "full p2p fungibility" (whatever that means and if it's possible at all) helps in any way
07:32 < jtimon> let's go back to yesterday's example
07:33 < adam3us> jtimon: say mining was very centrlized, and consensus based (ripple), and claimed defacto irreversibilty, or friemarkets similarly and FBI found DPR coin, they could trace it but not grind the password - they would then apply an NSL or order or pressure on the few central servers to block the transaction, or to forcibly change the owner without signature
07:34 < jtimon> well, that's a problem with ripple consensus, not with bitcoin pow
07:34 < adam3us> jtimon: consider DPR doesnt want to redeem it, he wants to sell his IBM shares for bitcoin to hire a good lawyer
07:34 < adam3us> jtimon: yes and maybe with freimarkets also?
07:34 < sipa> jtimon: it's only not a problem for bitcoin if mining anonymously is possible
07:34 < jtimon> no, freimarkets is supposed to be deployed in a pow chain like bitcoin or freicoin
07:35 < adam3us> sipa, jtimon: its a problem in bitcoin also, as sipa said, because if there are few, central miners, they can block transactions (unless committed tx is implemented and used)
07:36 < adam3us> jtimon: ok.  still bitcoin has the issue and freicoin worse unless merged mined due to lower hashrate
07:37 < adam3us> in my opinion something is not a p2p bearer share unless it has full fungibility; the strength of its claim is how close it gets to ZC/chaum like assurances
07:37 < jtimon> what if I mine outside the judge's jurisdiction?
07:37 < jtimon> unless we're assuming a global state or something...
07:37 < adam3us> jtimon: yes but do you have 51% of poer
07:38 < adam3us> the coerced miners may be forced to orphan your transactions
07:38 < jtimon> I see don't see a judge ordering a mining pool to undue all their mined blocks
07:38 < jtimon> doesn't make any legal sense to me
07:39 < sipa> doesn't need to
07:39 < adam3us> jtimon: see most of the mining power is in the us, which is the closest we have to a global state (they think they can apply their laws abroad, and have the gall to put pressure to try emulate that)
07:39 < jtimon> miners are not responsible for Bob stealing from alice, nor selling to Carol, who's not responsible either
07:40 < jtimon> they can only expropriate from Bob to compensate Alice
07:40 < adam3us> jtimon: true, you may have trouble getting 6-blocks confirmation
07:40 < jtimon> if Bob, sold the stolen share, then they will force him to compensate with other assets he owns
07:40 < jtimon> you == bob ?
07:41 < adam3us> jtimon: yes bob the thief
07:41 < jtimon> so you say miners will be forced not to accept the tx where bob sells to carol, mhumm
07:42 < jtimon> if the sell is already in the chain, I think there's no way back they can ask from miners
07:42 < adam3us> jtimon: yep or worse, eg an exchange has alice's money she sues the exchange for its return, as there is taint list and the exchange did not follow best practices in rejecting bob's attempts to cash it out
07:43 < jtimon> wait wait
07:43 < sipa> i think we want a system that works correctly because of technical reasons, and doesn't need to assume reasonable laws or judges around it
07:43 < adam3us> jtimon: yes that is defacto harder as its a 51% attack.
07:43 < adam3us> sipa: bingo
07:43 < sipa> that's not always possible, but if your argument starts with "judges are reasonable", i don't think you're still arguing about the quality of the system itself
07:43 < sipa> even if for practical purposes, you still make that assumption
07:44 < jtimon> no, I'm not assuming that judges are reasonable but you're assuming that they're completely stupid and crazy
07:44 < sipa> i prefer not making any assumption at all, if possible
07:44 < adam3us> jtimon: its a stronger assurance to rely on cryptogahy
07:45 < sipa> i also prefer not assuming reasonable miners
07:45 < sipa> but for the time being, we have to
07:45 < jtimon> yes, completely agree, but I don't think the law can make a pow chain reversible
07:45 < adam3us> sipa: potentiall committed tx addresses both judge issues and miner issues
07:45 < adam3us> jtimon: no but it can block and freeze funds
07:46 < jtimon> I like the idea of blind commiting, but your p2p deployment doesn't convince me
07:46 < adam3us> jtimon: and they love to do that, if anything semi-technical gets in their path they will become irrationally unreasonable so fast it will make your head spin, cognitive dissonance means nothing to them
07:46 < jtimon> well, not completely
07:46 < jtimon> the judge could order US miners not to validate the transaction where bob sells
07:47 < jtimon> but an iran miner could mine it
07:47 < adam3us> jtimon: yes and there is some argumnt that courts are slow, it'll be a few weeks of confirms by the time they react
07:47 < jtimon> would US miners forced to leave that block orphan risking a fork?
07:48 < adam3us> jtimon: its a reasonableness argument so its slippey
07:48 < jtimon> I think they will just attack the redemption side
07:48 < jtimon> if anything
07:48 < adam3us> jtimon: viz what they tried to pull on the lavabit guy, illegal requests for ssl key to ll users, legal threats, cost harrassment etc
07:49 < jtimon> but again, optional privacy removes responsability from the redeemer
07:49 < adam3us> jtimon: i dont think redemption matters so much... just trade it for something else and cash out another way
07:49 < adam3us> jtimon: so long as you have fungibility, sell share for bitcoin, do a bitcoin-otc (in person)
07:50 < jtimon> gmaxwell's argument is that no one will buy it from you if the issuer marks it as non-redeemable
07:50 < adam3us> jtimon: redemption for a share is a fringe event right.  its  new stock issue, or a share buy back... 99.9% of trades are buy/sell for another currency or stock swap, in this case bitcoin
07:51 < adam3us> jtimon: but thats a suicide pact argument.  a judge cant close down the entire share ownership because dpr has 1000 ibm shares with perfect fungibility
07:51 < jtimon> I'm trying to udnerstand the advantage of "full fungibility"
07:52 < adam3us> jtimon: partial fungibilty invites legal and miner policy attacks
07:52 < jtimon> the redemption argument is that with unperfect fungibility they will force issuers to mark some of their assets as non-redeemable
07:53 < adam3us> jtimon: if legal threats become effective, it ruins your immediately settlement.. now everyone has to verify the sellers reputation to guess risk of undone settlement and we're back to square one - thats the current financial system
07:53 < jtimon> that attack doesn't make much sense to me neither because of optional privacy
07:54 < adam3us> jtimon: but if they cant tell which assets to mark as non-redeemable what is that - a haircut % for everyone?
07:54 < adam3us> jtimon: arent you making my argument? if you use the privacy, (chaum blinding) you have full fungibility?
07:54 < jtimon> "tainting" just doesn't make sense to me, maybe because I assume that judges won't be totally crazy...
07:55 < jtimon> a haricut for everyone on what basis?
07:55 < adam3us> jtimon: the lesson from lavabit if anything is that the judge saw the technical argument, and did his best to override it ignoring sanity and privacy rights of unrelated users
07:56 < jtimon> if an state forces issuers in its jurisdiction to do such a stupid thing, all issuers will move to other jurisdictions very fast, as their clients go away
07:56 < adam3us> jtimon: u said the issuer will be forced to mark some assets non-redeemable, if you dont know which user is which you how do you withhold from the target user?
07:56 < adam3us> jtimon: well... you could make that agument about the us in spades, and yet most of the worlds bitcoin companies are there
07:57 < jtimon> maybe I'm too optimistic
07:57 < adam3us> jtimon: also jurisdiction shopping has limits - it just depends how badly they want to attack something
07:57 < jtimon> I think some jurisdictions will get this right and others won't
07:58 < adam3us> jtimon: i don tthink we're necessarily disagreeing, what you are saying is reasonable, but what i (and i think sipa) said is why tempt fate and push the limits of their reasonableness to find out - just use cryptography
07:58 < jtimon> the ones that get it wrong will suffer the economic consequences and maybe reconsider their reactionary positions
07:59 < jtimon> but I don't like chaumian cash because it lacks a lot of features I want
07:59 < adam3us> jtimon: i think real-politic is far uglier and selective extra-legally enforced - nsa blackmail, local favors, backroom deals between respective TLAs etc
07:59 < adam3us> jtimon: use brands it is very flexible
07:59 < jtimon> what?
07:59 < adam3us> jtimon: brands blind credential = blind schnorr extension
08:00 < adam3us> jtimon: you said chaum lacks features, if your features are achievable with blinding, brands is goig to be the answer as it has more features than anything else
08:00 < jtimon> I don't know that, but I highly doubt there's any non-traceable asset that can be traded atomically with, say, 8 other assets transitively
08:01 < jtimon> please, tell me if the following is possible
08:01 < jtimon> Alice wants to pay David, who only accepts CCC as payment
08:01 < adam3us> jtimon: u might be surprised what you can do with it efficiently, and compactly in zero knowledge it can be all EC discrete log like ECDSA
08:01 < jtimon> Alice owns AAA
08:02 < jtimon> there's open orders selling BBBs for AAAs, CCCs for BBBs
08:02 < jtimon> in a single atomic transaction alice sells her AAAs for BBBs, which sells for CCCs which sends to David
08:03 < adam3us> jtimon: so why do you think thats not possible even with chaum?
08:03 < jtimon> is that atomic transaction possible with brands?
08:03 < adam3us> jtimon: the atomic swap relies on smart contract hashlocks and scripts right
08:04 < jtimon> ok, I forgot to mention that AAA, BBB, CCC are accounted for in different servers/chains
08:04 < adam3us> jtimon: i am not sure what the atomic swap model is but it might be possible already with chaum, its still a normal signature
08:04 < adam3us> just sign a smart contract with a sript input and blind chaum sign no and use the existing atomic swap tx?
08:05 < jtimon> maybe I don't understand chaum well enough, but I don't think it is a signature
08:05 < adam3us> jtimon: not natively but you can make it so
08:05 < TD> if anyone wants to talk to me via Pond (pond.imperialviolet.org) then let me know and I'll give you a shared secret
08:05 < adam3us> jtimon: in my credlib library i did that
08:05 < TD> [ob explanation:   pond is forward secure, tor based messaging that scrambles everything against every attacker except someone who can de-anonymize tor)_
08:06 < adam3us> jtimon: the idea is that the thing you get the issuer to blind sign is the hash of your public key, that you will sign with to prove ownership in contracts
08:06 < jtimon> that's not what I read about chaumian cash
08:06 < adam3us> chaum ecash only doesnt do that because its an online protocol so theres no point
08:07 < adam3us> they just sign a structured random number to act as the coin serial umber for double spend protectio
08:07 < adam3us> anyway check it out, its in the credlib library with a demo program
08:07 < jtimon> this is what I read: http://anoncvs.aldigital.co.uk/lucre/theory2.pdf
08:08 < adam3us> oh thats not even chaum thts david wagners blind mac work aroun as implemented by ben laurie
08:08 < adam3us> but the patent expired on chaum so now blind mac is less important
08:08 < jtimon> ok, then everything I said about chaumian cash doesn't apply
08:09 < jtimon> that's the theory OT links to
08:09 < jtimon> ok, time to read about chaumian cash, I thought I knew what it was
08:09 < adam3us> jtimon: but you were right that chaum cash did not use blind certificates, only blind signatures because they assume the issuer and the transaction server are the same, and in fact the only transaction is redemption
08:10 < adam3us> jtimon: its much simpler than wagner's blind mac.
08:10 < jtimon> do you have a quick link?
08:11 < adam3us> jtimon: vs rsa sig   s=m^d mod n verified s^e=?m
08:11 < adam3us> jtimon: blind sig is: -> b^e*m (user sends to server)
08:11 < adam3us> jtimon: server sends (b^e*m)^d back to user
08:12 < adam3us> jtimon: user unblinds and gets normal rsa sig m^d for m server neve saw
08:12 < adam3us> jtimon: because (b^e*m)^d = b*m^d and user divides by b so (b^e*m)^d/b=m^d qed
08:12 < jtimon> so once it shows it to the server, the tx cannot be rolled back?
08:13 < adam3us> jtimon: the server will not be able to correlate the issue message with the deposit message because b is random and choen by the user
08:13 < adam3us> jtimon: the server prevents double spend by accepting m only once it is the coin serial number
08:13 < jtimon> so the server never sees b, no?
08:14 < adam3us> right doesnt see b ever, doesnt see m during issue, sees m during deposit
08:14 < adam3us> jtimon: the server has no idea what it signed, so it doesnt support attributes - eg value/denomination/currency
08:15 < jtimon> the issuer does
08:15 < adam3us> jtimon: they work around that by having a different issuer key for each currency / denomination
08:15 < adam3us> jtimon: yes
08:15 < jtimon> so there's only issuance and deposits, no transfers
08:16 < jtimon> say Alice issues AAA and sends it to Bob
08:16 < adam3us> jtimon: as stated because thats what they wanted
08:16 < jtimon> How does Bob transfer it to Carol?
08:16 < adam3us> jtimon: but instead of m being a coin serial number, it can be the users hash of public key
08:16 < adam3us> then the blind sig is actually a blind certificate, so you can transferaby assert and prove ownership of it
08:17 < jtimon> in bitcoin I can prove ownership of a coin by signing external messages with my private keys
08:17 < adam3us> u know in the 1995 era we had a coloredcoin like idea to color coins without the central banks approval - as it cant tell what its signing it was called a cut-out protocol
08:18 < adam3us> jtimon: right so if you have a blind certificate from teh issuer, you sign a message transfering ownership to another user
08:18 < jtimon> that cannot be conditional to anything else
08:18 < adam3us> jtimon: or asbitcoin geeralize th concept of  signature into a contact script involving the signture
08:19 < jtimon> I cannot "transfer AAA to Bob if and only if Bob transfers BBBs to me"
08:19 < adam3us> jtimon: why not?
08:19 < jtimon> I'm asking, is that possible when AAAs and BBBs are accounted for in different servers ?
08:19 < adam3us> jtimon: if you take whatever you are doing now and replace the signature by the certified blind chaum address signature, doesnt it still work?
08:20 < adam3us> jtimon: i dont know how your atomic swap tx works with two different freimarket servers
08:21 < jtimon> private servers implement additional OPs that can make scripts conditional to events in external chains
08:21 < jtimon> so they rely on traceability
08:22 < jtimon> but they can just use a simple timestamping server that functionally acts as blind signer for the commit
08:23 < adam3us> jtimon: so it seems to me you can use chaum blind cert to have the issuer create you a issuer blind but transferable proof, and traceable proof
08:23 < jtimon> I was under the impression that you couldn't transfer chaumian cash conditionally, but since I was confusing chaumian cash with blind mac...no I'm notsure
08:25 < jtimon> also fellowtraveller confirmed me jsut that: you cannot atomically trade assets in different servers
08:26 < adam3us> jtimon: the mechanism bitcoin is using to generalize a signature into a script is to augment the verification step in a way that is hashed into the sending address
08:27 < adam3us> jtimon: as the issuer doesnt even see your sending address during the issue process it can be whatever you wish
08:27 < adam3us> jtimon: rather than H(Q) it could be H(y=H(x) and ECDSA(Q))
08:28 < adam3us> jtimon: and i presume your atomic method uses some script referring to cross chain activities that the verifier must monitor
08:29 < jtimon> yes, or just conditional to a centralized timestamper that signs the hash of the tx before expiry
08:29 < adam3us> jtimon: well i think OT does not include an external timestamp maybe it is possible but they did not so far try to explore in that area
08:29 < adam3us> jtimon: so then yes i dont see that a certified blind sig is any differnt other than there is no coinbase issue, just issuer issue
08:30 < adam3us> jtimon: and the issuer issue is verified by checking the bldin certificate signature (and the signature made by the certified key on the transaction)
08:31 < jtimon> and this could be all implemented in a pow chain, no?
08:31 < adam3us> jtimon: after its transfered normal block chain rules apply, unless you aim to refresh the blinding by refresh (redeem and immediately reiussue)
08:31 < adam3us> jtimon: i think so
08:31 < adam3us> jtimon: why schnorr blind sig is interesting is that can even use bitcoin style keys with the same curves
08:32 < adam3us> jtimon: i didnt find an efficient simple ecdsa (there is a moderately efficient but ridiculously complex and experimental grade crypto assuption method involving homomorphic additinon in damgard-jurik extnesion to paillier but i would not touch that)
08:33 < adam3us> jtimon: blind schnorr cetificate is basically brands certificate with 0 attributes
08:35 < adam3us> jtimon: btw p5 and p6 give the chaum and schnorr blind sig
08:35 < adam3us> http://www.di.ens.fr/~pointche/Documents/Slides/1996_asiacrypt.pdf
08:36 < adam3us> jtimon: i think EC schnorr is probably preferable for size, security etc and compatibility with bitcoin while still a simple protocol with no hard to implement crypto
08:36 < adam3us> jtimon: eg you need 3072 bit blind RSA for same security as 256-bit blind EC schnorr
08:38 < adam3us> jtimon: also i propose generally bitcoin should add schnorr as a new signature type, because it has many flexibility, space and performance improvements in addition to supporting simple blinding where ECDSA does none of those things
08:39 < jtimon> so functionally this would allow secure off-chain transfers in adition to in-chain conditional transfers, no?
08:40 < adam3us> jtimon: i think it should allow everything you can do with non-blind sigs, though i am not sure how the security of your off-chain transfer works
08:41 < adam3us> jtimon: btw with brands credentials you can do "secure"  offline transaction even (where the double spender is later detected and loses their anonymity) probably of limited use in a "trust no one" model but interesting property
08:42 < jtimon> in freimarkets off-chain transfers are just transfers in "private chains", you have to trust the accountant
08:42 < adam3us> jtimon:  guess it should work then.  is the issuer also the accountant/transaction server?
08:43 < jtimon> if you trade assets in different private servers, you make the whole transaction conditional to a 3rd party centralized timestamp or to a transaction in a public chain before block Exp
08:43 < adam3us> jtimon: makes sense
08:46 < jtimon> I definetely need to study chaumian cash better
08:46 < jtimon> thank you
08:46 < jtimon> I'm going to eat now
08:47 < adam3us> try out the credlib library
08:47 < adam3us> the api is optimized for simplicity
08:47 < adam3us> there is an example program
08:47 < adam3us> using either chaum or brands
08:48 < adam3us> think of blind schnorr as basically brands with 0 attributes
08:48 < adam3us> http://www.cypherspace.org/credlib/
09:01 < adam3us> btw i lied and it seems i didnt actually get around to implement chaum credential support in credlib, though i was thinking of it, its been a few years since i worked on it so forgot status -- you need to replace the serial in libchaum.c with hash of your public key, or script hash
09:03 < adam3us> there are chaum signatures/cash but not chaum credential (were you can sign with the key certified in the credential) see above change
12:12 < michagogo|cloud> 01:49:09 <gmaxwell> (the closest I could find was ILS but it was fixed to the israel lira, which was fixed to the ukp, which was fixed to the usd (!), which was previously fixed to gold)
12:12 < michagogo|cloud> IIRC, it's slightly more complicated -- you had the Lira, which started as fixed to the GBP, but was unfixed at some point, then that became the Shekel, 10 Liras to 1 Shekel, and then the Shekel became the New Shekel, usually referred to as NIS here in Israel, but the currency code (ISO?) is ILS
12:13 < michagogo|cloud> 04:39:54 <gmaxwell> what a mess.. you hardware fractionalized and sold to people with no control over it.. who then mine at a single enormous pool which is full of these miners that can't vote with their feet.
12:13 < michagogo|cloud> IIRC, they can sort of vote with their feet -- I think I remember reading that if you have a certain number of GH/s credits on cex.io, you can "redeem" them and they'll ship you an equivalent miner
12:13 < michagogo|cloud> 05:21:57 <petertodd> double-spend warnings are going to make this really interesting given that gavin's planning on implementing them by broadcasting the whole tx
12:13 < michagogo|cloud> Hmm, I hadn't heard about that -- where can I find more information?
12:15 < petertodd> michagogo|cloud: IRC logs
12:15 < petertodd> #bitcoin-dev IIRC
12:15 < michagogo|cloud> Got a timestamp?
12:15 < michagogo|cloud> Well, if not -dev, then no accessible-to-me logs
12:16 < sipa> i think it was here
12:17 < petertodd> #bitcoin-wizards actually, 13-11-01
12:17 < michagogo|cloud> In that case, there aren't public logs
12:17 < michagogo|cloud> (or, shouldn't be according to freenode policy, since there's no link in the topic or join message)
12:18 < petertodd> well anyway, it's not rocket surgery: to prove a double-spend you have to relay the whole tx, so gavin wants to add code to relay the first double-spend seen for every tx in the mempool
12:19 < petertodd> ...which makes bandwidth DoS attacks hundreds of times cheaper in the best case
12:20 < michagogo|cloud> Hmm? Hundreds of times?
12:20 < michagogo|cloud> Why not twice?
12:20  * michagogo|cloud is sure he's overlooking something
12:20 < petertodd> yup, basically the double-spend could be a 100K transaction, while the original was just ~200 bytes or something
12:20 < sipa> and you only pay for the one that gets merged
12:20 < michagogo|cloud> Oh, right
12:20 < michagogo|cloud> of course.
12:21 < petertodd> yup. Beats me why gavin doesn't understand that, but whatever.
12:21 < michagogo|cloud> What are his counter-arguments?
12:21 < petertodd> He didn't have any.
12:21 < michagogo|cloud> Also: I assume he'd leave the "mine the first one you saw" rule?
12:21 < petertodd> yup
12:21 < petertodd> anyway, what's nifty about that, is it makes adopting replace-by-fee really easy for miners - no need to find peers that use that rule
12:22 < petertodd> heck, because the double-spend will be checked fully, the singaturs might even be in the sigcache...
12:22 < michagogo|cloud> What's the sigcache?
12:23 < petertodd> just a cache of checked signatures - makes tx validation, and hence block validation, go faster
12:23 < michagogo|cloud> And yeah, sure -- there are plenty of reasons that relaying double-spends would be a good thing
12:24 < petertodd> I'm pretty dubious about the DoS potential - lots of fun things you could do with strategically slowing down propagation.
12:24 < michagogo|cloud> Ah, so if a transaction is relayed, the sig will be cached as valid, so that when it makes it into a block the sig won't need to be verified again?
12:24 < petertodd> Equally though, if you reducethe priority of double-spend notifications, then you can DoS to get away with a double-spend...
12:24 < petertodd> michagogo|cloud: correct
12:25 < michagogo|cloud> Yeah, the DoS is definitely problematic -- what about restricting the size of the double-spend relative to the original?
12:25 < michagogo|cloud> Or the fee, or the fee/kB?
12:25 < petertodd> The only way to do that is to restrict the size of transctions in general.
12:26 < petertodd> If you restrict by fee, then the value of the notification is lost. (unless miners adopt replace-by-fee semantics!)
12:26 < michagogo|cloud> What's wrong with "don't relay a double-spend more than X times the size of the original"?
12:26 < michagogo|cloud> Oh, I see
12:26 < petertodd> heh
12:26 < michagogo|cloud> I was just thinking about it in terms of replace-by-fee
12:26 < petertodd> Reality is, zero-conf is dangerous and we're stupid to try to do anything about that.
12:26 < michagogo|cloud> Right, there's also the "warn the merchant" use case
12:27 < michagogo|cloud> I disagree with the last part
12:27 < petertodd> Now see, *with* replace-by-fee it does make sense to relay double-spends with identical fee-per-kb to warn merchants, but that's it.
12:27 < petertodd> (that lets them use scorched-earth properly)
12:27 < michagogo|cloud> Obviously we will never, ever manage to make then safe
12:27 < michagogo|cloud> Otoh....
12:27 < petertodd> We're not even going to get close frankly.
12:28 < michagogo|cloud> if we implement this warning, people will read more into it than they should
12:28 < petertodd> yup
12:28 < michagogo|cloud> (specifically, absence of said warning)
12:28 < petertodd> the "fix" is worse than the problem.
12:28 < michagogo|cloud> Also: would this also apply for transactions in blocks? Guessing not
12:28 < petertodd> But... I shouldn't discourage anyone, as it *does* help adoption of replace-by-fee.
12:29 < michagogo|cloud> The double-spend relaying thing could certainly be worth adding, if only for replace-by-fee
12:29 < petertodd> yup...
12:30 < michagogo|cloud> Hmm, actually
12:30 < michagogo|cloud> If you do that, you do need to implement some kind of warning
12:30 < petertodd> now if only I could convince gavin to add double-spend relaying that only relayed roughly same-sized txs :P
12:30 < michagogo|cloud> The two things are not separate from each other
12:30 < petertodd> michagogo|cloud: wait, do you know what the scorched earth strategy is?
12:30 < michagogo|cloud> ;;google scorched earth
12:31 < michagogo|cloud> Oh, no gribble
12:32 < michagogo|cloud> "destroy anything that we come across that the enemy might be able to use"?
12:32 < petertodd> https://bitcointalk.org/index.php?topic=251233.msg2669189#msg2669189
12:32 < michagogo|cloud> Or is there something else called that?
12:33 < petertodd> it's brilliant, although jdillon overstates it a little - it heavily depends on a jam-free communications layer, and DoS attacking that can cause it to fail. But overall it's pretty good.
12:34 < michagogo|cloud> Ah, interesting
12:35 < michagogo|cloud> So basically, if someone tries to double-spend a merchant doing this, the merchant will simply throw the amount away
12:35 < petertodd> yup
12:35 < petertodd> aligning the incentives of miners and merchants
12:35 < michagogo|cloud> Well
12:35 < petertodd> main thing I like about it is that it rejects the idea that miners should be "responsible" re: zeroconf
12:35 < michagogo|cloud> You'd still need to wait for confirmations
12:35 < petertodd> nope
12:36 < michagogo|cloud> Because even though an attacker couldn't take the money back
12:36 < michagogo|cloud> (afk for a moment, brb)
12:36 < petertodd> If you can assume that you will "quickly" know about a double-spend, and can "quickly" implement the scorched earth policy with a counter-double-spend, then the attackers gains converge to zero.
12:36 < OrP> Hey Michagogo - I'm from Israel - you guys were correct about NIS
12:37 < michagogo|cloud> petertodd: Even though an attacker couldn't get the money back
12:38 < OrP> Also - I wanted to point our the banks in Israel are investing alot on dollars
12:38 < OrP> A thing I can't figure out
12:38 < petertodd> michagogo|cloud: what do you mean?
12:38 < michagogo|cloud> If you rely on an unconfirmed for anything irreversible, the attacker could still keep the funds from the merchant
12:39 < michagogo|cloud> As a way to damage the merchant, even though you don't get the funds back
12:39 < michagogo|cloud> (though as jdillon says, "The transaction can also be constructed such that the payee pays slightly more in advance, with the merchant refunding the extra amount once the transaction confirms")
12:40 < petertodd> michagogo|cloud: sure, but in a *lot* of real world scenarios the actual damage to the merchant is minimal: for instance if you're selling ringtones you don't actually incur a cost on a double-spend, you just need to make sure it's worth it for the attacker to bother
12:40 < michagogo|cloud> not worth it, you mean?
12:41 < petertodd> michagogo|cloud: I wouldn't want to sell a car with it, but in most low-value circumstances scorched-earth is likely to be enough of a deterrant to keep people honest
12:41 < michagogo|cloud> Right, that's a good point
12:41 < michagogo|cloud> (also, this only helps if you advertise that you do it, right?)
12:41 < petertodd> Same reason coffee shops and bakeries get away with not actually having any sales staff...
12:41 < petertodd> well, if everyone has software that does it automatically...
12:42 < michagogo|cloud> Right, that counts as advertising that you do it :P
12:42 < petertodd> yup
12:42 < michagogo|cloud> Anyway, so it would make unconfirmed transactions somewhat more safe
12:42 < petertodd> even then, an attacker might steal one ringtone, so what?
12:42 < michagogo|cloud> Really, depending on the attacker's motive
12:42 < petertodd> yup, without the nasty politics of trying to regulate miners
12:43 < michagogo|cloud> It makes it much, much safer against an attacker trying to keep their money
12:43 < petertodd> keep in mind, I originally proposed replace-by-fee months ago, not realizing that scorched earth was possible, simply because I though it'd be worth getting miners to do this now before people started trying to take much more dangerous counter-measures to make zeroconf safe
12:44 < petertodd> jdillon came up with scorched earth after that
12:44 < michagogo|cloud> OTOH, since you'd basically be throwing away the money as soon as you detected this attempt, it would make an attack that simply is intended to hurt you much, much easier
12:45 < petertodd> sure, but as I say, in most real-world cases merchant cost is dominated by overhead
12:45 < petertodd> * for low value items
12:46 < michagogo|cloud> (also, worth noting that scorched earth required more than replace-by-fee -- it also requires cpfp)
12:46 < petertodd> yup, and beyond cpfp, it requires the ability to relay multiple-txs in one "packet"
12:47 < michagogo|cloud> Hm?
12:48 < petertodd> the merchant needs to relay both the original tx that paid them, and the pay to fees tx in such a way that even nodes that didn't see the original tx know it's worth replacing the attackers double-spend with the two txs
12:49 < petertodd> also, note how merchants shouldn't let people pay them with txs that are unusually large... which can be a limitation
12:51 < michagogo|cloud> Oh, I see
12:52 < petertodd> yup, really, guaranteed to work is single input, two P2SH outputs
12:52 < michagogo|cloud> Because if you only implement replace-by-fee and not full double-spend relaying, cpfp itself, to work fully, requires a way to relay the parent after or with the child
12:52 < petertodd> yup
12:53 < petertodd> but good cpfp needs that anyway
12:53 < michagogo|cloud> (and of course we don't want to store orphan transactions)
12:53 < michagogo|cloud> Yeah, that's what I just said
12:53 < michagogo|cloud> "cpfp itself, to work fully"
12:53 < petertodd> lol, right
12:53 < michagogo|cloud> :P
12:54 < petertodd> anyway, in the meantime, it's likely that double-spend notification will be implemented, in which case I can encourage miners to adopt replace-by-fee by advertising the fact that I'm making large fee double-spends - join in the fun!
12:58 < michagogo|cloud> lol, nice
12:58 < michagogo|cloud> Though, won't that require a bunch of the network to upgrade first?
12:59 < petertodd> again, no, because of double-spend notifications
12:59 < petertodd> basically you tell miners that you'll broadcast low-fee double-spends, and every time one gets mined, you'll increase the fee
13:00 < michagogo|cloud> Not necessarily replace-by-fee upgraded, but relay-double-spends upgraded
13:01 < michagogo|cloud> "every time one gets mined, you'll increase the fee"?
13:02 < petertodd> See, you want to give people a strong incentive to adopt replace-by-fee, but you also want them to adopt it in such a way that it can be used for any transaction. So by saying "prove to me you've upgraded first" they can't just, say, only do replacement on high-fee txs.
13:02 < michagogo|cloud> Ah, I see
13:02 < michagogo|cloud> (I think?)
13:02 < petertodd> heh
13:02 < michagogo|cloud> eep, power warning
13:03 < petertodd> ?
13:03  * michagogo|cloud goes to find power adaptor
13:03 < petertodd> ah
13:03  * michagogo|cloud is back
13:04 < michagogo|cloud> Well, what's to stop them from just detecting your transactions and mining them?
13:04 < petertodd> Do your double-spends while gambling on satoshidice.
13:05 < maaku> adam3us: atomic swap in freimarkets is in the transaction format, not a hashlock or related
13:06 < maaku> basically we allow hierarchical sub-transactions which themselves don't have to balance, so long as the entire transaction does (outputs < inputs for each asset)
13:07 < maaku> but yeah that's completely unrelated to chaum cash
13:13 < adam3us> maaku: ok, i took it it was still a scriptsig of some form with reference to a merkle root and a timestamp server
13:13 < maaku> for multi-server trade, yes
13:13 < maaku> at least that's one of many options
13:14 < maaku> you can have multiple private servers conditionally accept a transaction based on a timestamp oracle or the state of the public (Freicoin) chain
13:14 < maaku> in a two-phase commit architecture
13:15 < maaku> but within a single server/chain, ripple-like exchange or transitive payments are done by composing pre-signed orders together
13:16 < maaku> if chaumian cash requies a separate online redemption step, then it doesn't work for this
13:16 < maaku> i still need to wrap my head around creditional-chaum to see if it is compatible
13:31 < adam3us> see i think the online aspect is just an artefact of the way they chose to use it, because they did not have a certificate, just a signature, it can be easily stolen once disclosed to anyone, so the model was the recipient immediately deposits it
13:32 < adam3us> maaku: you can as easily have the blind signature be of a signature public key, then you can prove things with it, attach it to a script sig etc.
13:32 < adam3us> maaku: the online validity check is for double spend checking, and if you want privacy then you have to get it refreshed by the issuer (swap a signed certificate for a new one)
13:33 < maaku> the online validity check is the only show stopper for me then, at least in the public chain case
13:34 < maaku> I wonder how much we can reduce the burden of maintaining a double-spend db
13:34 < adam3us> maaku: yes but if its a certificate rather than a signture, you can delay or do that publicly
13:35 < adam3us> maaku:  the chaum thing is like you end up with a signature on a random number which they chose to interpret as "the bearer is the bearer of 1 ecash unit"
13:36 < adam3us> maaku: in bitcoin terms its cashable by anyone! so the recipient has to connect with haste to the issuer and send the coin to it over ssl, because its about as secure as a bitcoin private key that the other user still has
13:36 < maaku> but with credentials it's basically like any other output, minus the traceable history
13:37 < maaku> except that validators have to keep a list of which credentials have already been spent
13:37 < maaku> so you lose the benefits of needing only the utxo for chaum/brands outputs
13:37 < adam3us> maaku: yes so if you replace the random serial number with a publc key hash, then you can define seeing the certificate doesnt confer anything excet that the person wththe ability to sign with this is roving they are the owner of a freshly unlinkable ecash unit
13:39 < adam3us> maaku: i think bitcoins blockchain is a double spend database, its analogous though we think about it differently because of bitcoin mechanics, semantics and terminology - but its a distributed double spend db in functionality
13:39 < maaku> adam3us: yes, but validation must not require access to the entire blockchain history
13:40 < adam3us> maaku: eg its going to be far more scalable for a few validators to keep a list of spent coins, than to broadcast the double spend db
13:40 < maaku> that wouldn't even scale to current levels
13:40 < maaku> that's why we extract out only the information relevant for validation to the unspent transaction output index
13:41 < maaku> but chaum credentials would require keeping a history of all spent blinded outputs, which grows linearlly with total history
13:41 < maaku> that's not scalable
13:41 < maaku> s/keeping/miners maintaining an index of/
13:42 < maaku> of course it's all there in the block chain history, but right now miners or other full validators don't need the entire block chain history to validate new blocks
13:42 < maaku> so it'd be a large step backwards
13:43 < adam3us> maaku: its a bit analogous to zc
13:43 < maaku> but i suppose some sort of system could be designed to pay for this storage, and to retire old series of coins
13:43 < maaku> speaking of which, what's the advantage of zc over this?
13:43 < adam3us> maaku: yes they do have the concept of issues, retire the key
13:44 < maaku> is it that there's no centralized mint?
13:44 < adam3us> maaku: this is a new permuation i think - to have a single issuer, but use blockchain storage of double spend db
13:45 < adam3us> maaku: its a more robust alternative to OT having multiple servers
13:46 < adam3us> yes with zc there is no central issuer, and ll the coins can be in one anonymity set; if an issuer goes down, its keys are lost, then future issues will have a different key - but also this is an issuer - if it goes down maybe they become non-redeemable to the underlying also
13:47 < maaku> adam3us: yes, generally speaking except for the host currency (bitcoin/freicoin) it's okay to have some trust in the availability of the issuer, if the issuer == the redeemer
13:50 < adam3us> maaku: it could be reactive... like start with a separate redundant storage for the dbl spend (peers, validators, redundant servers) but rely on a transaction server.  if thre start to be big problems with transaction servers remaining online, then the redundant stores can populate a blockchain and probalbly receipts and timestamps can prove its the full set
13:50 < maaku> it would be ideal if there were some way that proof-of-uniqueness could be maintained by the holder, not the network, and provided upon redemption
13:51 < maaku> adam3us: no, not if dbl spend status is a concensus property (a double-spend is not a valid transaction, right?)
13:52 < maaku> then every full node would need to have this info, if we want to maintain bitcoin's decentralized properties
13:53 < adam3us> maaku: a few days ago gmaxwell was suggesting you can get most of the benefit just trusting the issuer to be available (or his transacton server... his actual issuing key maybe not online)
13:55 < maaku> i'm not sure how that relates to the issue i'm seeing
13:56 < maaku> i'm a full node, i receive a block with a chaum spend in it. how do I know if it's valid (not double spent)?
13:58 < adam3us> maaku: as it stands the usage pattern people gravitate to is that you check its not double spent
14:00 < maaku> and i see two options for that: (1) check the authoritative block chain history (not scalable because you must always remember spent tokens), or (2) ask a transaction server, which decentralizes bitcoin
14:00 < adam3us> maaku: maybe you could get other tradeoffs; currently by having a double spend db, then any coin spent could be any previously unspent coin from any previous withdrawal (blind issue event) so the anonymity set is maximal
14:03 < maaku> still, all these reservations aside, that only affects the public chain case
14:03 < maaku> there's no reason not to include these blinded credentials on private accounting servers
14:03 < maaku> where the server itself can maintain the dbl spend list
14:03 < maaku> jtimon: ^^
14:04 < adam3us> maaku: lets say you use a brands credential which supports zkp attributes.  you unblind the token, then you prove the block height it was issued at is < 144, and therefore the miners add it, you can later prove you own it, transfer it to the new owner, who cn request the issuer create a new one replacing the old one
14:05 < adam3us> then full nodes only need to keep last 144 blocks of double spend
14:06 < adam3us> maaku: you have anonymity within the last 144 blocks of withdrawals, and the can look for spend transactions to check if its valid
14:07 < adam3us> maaku: (the recipient) presuming the transfer of ownership is itself logged
14:07 < adam3us> maaku: then you have some kind of blind smaller anonymity set utxo like concept
14:14 < adam3us> actually maybe you can make a p2p blind signature for the transfer of ownership.  combined with committed tx that is actually quite interesting, it means you dont know the address of the person you paid (payee anonymity)
14:15 < maaku> committed tx meaning utxo hash tree committment?
14:16 < jtimon> I think commited tx are more like a chai nthat timestamps everything without validating anything
14:16 < adam3us> maaku: no its something else with a badly labelled bitcoin talk subject heading. you can have the blockchain validate double spends
14:16 < jtimon> if I understood it correctly, of course
14:16 < adam3us> maaku, jtimon; right, so the block chain doesnt see who is spending to who, nor how muc
14:16 < maaku> link?
14:17 < jtimon> then validators interpret the transactions by the order they appeared
14:17 < maaku> and yeah that's a horrible name
14:17 < jtimon> so if a double-spend is commited, no problem, it will just be ignored by validators
14:18 < adam3us> https://bitcointalk.org/index.php?topic=206303.0
14:18 < jtimon> but yeah, I should read it, I'm trying to guess how the proposal works really
14:19 < maaku> jtimon: well that's really my point - how do the validators validate without keeping a O(n) history
14:19 < adam3us> maaku: they either pass it with the transaction, or its on the block cin, and being in the transaction path, they get to see its history back to genesis, or to uncommitted form
14:20 < jtimon> the transactions can refer to a previous block
14:20 < adam3us> maaku: you can reveal it back to the network fairly soon, or keep it offchain for ever
14:20 < adam3us> maaku: you can respend a committed tx
14:20 < maaku> "they get to see its history back to genesis" <-- that's what we've got to avoid
14:20 < adam3us> maaku: (in committed form)
14:20 < adam3us> maaku: yes its not had much work on trying to figure out a spv concpt
14:21 < adam3us> but i think the new idea to use a blind signaure for the p2p transfer may nudge some possibillities out of it
14:21 < adam3us> another interesting aspect is had homomorphic encrytped values worked out, then you can disclose those also, without loss of privacy
14:21 < maaku> well it's not really about spv - even full validation would not be possible at current transaction rates if validators needed random access to the entire block chain history
14:23 < adam3us> maaku: it may not be as bad as that, the sender gives you everything you need to validate
14:24 < adam3us> maaku: you can have prevalidated and indexed encrypted utxo (actual forged double spends are ignored so are useless other than spam)
14:25 < gmaxwell> adam3us: "useless other than spam", which there is absolutely no way to defend against in that scheme.
14:25 < adam3us> maaku: combining it with homomorphic value is interesting because you can have normal validation then
14:25 < gmaxwell> so one wizeguy with a while true ends your system.
14:26 < jtimon> maybe transactions can be required to also provide som pow?
14:26 < jtimon> some
14:29 < adam3us> gmaxwell: yes agreed spam needs defending.  there are (cleartext) fees however.  and you can already pay to spam.  however this is messing up a different aspect, which is the utxo size.  i guess you can spam that too currently?
14:30 < gmaxwell> adam3us: only by creating valid transactions.
14:30 < adam3us> gmaxwell: is that a useful distinction? (in the eyes of the spammer)
14:31 < adam3us> gmaxwell: (not saying its not a problem, just that maybe we currently have a close to analogous problem)
14:32 < gmaxwell> adam3us: yes because it results in a natural way to rate limit their activity. They have to spend their coins to do it. Perhaps I've forgotten your proposal, but I though you could create invalid transactions and no one could tell that they weren't valid.
14:32 < adam3us> anyway blind sigs between commited tx spends for payee anonymity - thats neat, i have to think what else can come out of that plus homomorphic vale; also there is another (big) homomorphic value tweak i need to work on
14:32 < adam3us> gmaxwell: yes that is true, however there were clear text fees
14:33 < gmaxwell> adam3us: how can cleartext fees work if the public doesn't know what coin is bein spent?
14:34 < adam3us> the fee has to be from some clean coins.. not ideal but the miner can not see the coins so necessary
14:34 < jtimon> ok, it wasn't what I thought it was, but I think I understand now
14:36 < jtimon> it's like putting hashes of transactions in the chain, and not reveal the actual transaction until it is sufficiently buried
14:37 < jtimon> but what if the dihonest miner doesn't want to include the "revealed transaction"?
14:37 < gmaxwell> adam3us: the other issue with it is that the privacy was very brittle. If you recieve a coin from someone you must be able to decrypt the whole history to know its valid.
14:38 < adam3us> jtimon: in many senses the transaction already happened, revealing it is just to reduce utxo
14:38 < jtimon> but the "revelation" must get into the chain too, no?
14:38 < adam3us> gmaxwell: yes.  its not so much private as non-public
14:39 < adam3us> jtimon: its optional, they can be respent in committed form indefinitely
14:39 < jtimon> adam3us, no as gmaxwell says, you need the whole history public to be sure is valid
14:40 < gmaxwell> not quite.
14:40 < gmaxwell> jtimon: it has to be known by people accepting the coins.
14:40 < adam3us> gmaxwell: when the trail grows long privacy becomes quite weak, so i think its more like ensuring peers can chose policy of who to accept transactions for
14:40 < gmaxwell> but then you get fungibility issues.
14:40 < jtimon> let's say the chain contains hidden(A->B)
14:41 < jtimon> now B wants to pay C, he shows C the reveal of A->B plust B->C and broadcasts hidden(B->C)
14:41 < adam3us> jtimon: yes
14:42 < jtimon> How can C know for sure that hidden(B->C2) and hidden(B->C3) aren't already in the chain?
14:43 < adam3us> jtimon: because a committed spend includes a hash of the address, so you can check that
14:43 < jtimon> if there's no public validation there's no guarantee against double-spend
14:43 < jtimon> of the source address B ?
14:43 < adam3us> yes
14:44 < gmaxwell> jtimon: no, not so. It's basically blinded.
14:44 < adam3us> and if the tansaction is spent in non committed form, it reveals the public key so then anyone can compute the committed form hash, so both committed and non-committed forms can be double-spend protected
14:44 < jtimon> hidden(A->B) contains a hash od address B? I'm confused
14:45 < adam3us> jtimon: no hash of A
14:45 < adam3us> gmaxwell: yes its curious it seems like a symmetric form of blinding approximately
14:46 < jtimon> So, I'm C, you include hidden(B->C), how can I be sure that you haven't spent what you got from hidden(A->B) 5 times already?
14:46 < gmaxwell> jtimon: because when you recieve a hidden coin you must evaluate and unblind its whole history.
14:47 < adam3us> because it has to go to the chain in committed form, which reveals H(B)
14:47 < adam3us> sorry you sid A->B, so rather it reveals H(A)
14:48 < maaku> gmaxwell: but where is the double-spend protection there?
14:48 < gmaxwell> maaku: in the recievers.
14:48 < jtimon> committed form == public form, non-commited form == in-chain but  hiden form, right?
14:48 < maaku> i'm not following
14:48 < adam3us> jtimon: only back to the point of the last uncommitted spend
14:48 < maaku> i have my history, but how there aren't other alternate histories?
14:48 < adam3us> jtimon: uncommitted is normal bitcoin tx form
14:49 < jtimon> ok, uncommited == public
14:49 < gmaxwell> maaku: because you know non-public data that lets you identify any spends of the coins you care about.
14:49 < maaku> gmaxwell: even though all the other histories are encrypted?
14:49 < adam3us> jtimon: basically you can sort of do a (committed/hidden) spend, then later convert that into a normal spend
14:49 < jtimon> can we follow the example please?
14:49 < gmaxwell> maaku: yes, because if you're accepting the coin you have the key.
14:49 < jtimon> I'm getting lost
14:50 < jtimon> A has its funds from a public tx
14:50 < adam3us> jtimon: it generated a long thread until everyone was convinced, its somehow counter-intuitive
14:50 < jtimon> A->B is in the chain in hidden form
14:50 < adam3us> ok
14:50 < gmaxwell> adam3us: he's asking about the case where you are d in a chain of hidden spends.   a->b b->c c->d  And he's confused about how you know that a->q  didn't happend first.
14:51 < adam3us> gmaxwell, jtimon: so if a is spent, in committed or normal form, you see evidence of it on the chain
14:51 < gmaxwell> And, as far as I recall, the reason is if these are all non-public, you will know a's key so that you can see that a->b was the unique first spend of a.
14:51 < maaku> and the reason is that you get the key to a, so you can go back and decrypt all the transactions of the form "a -> ..." and make sure that "a -> b" is the first, right?
14:51 < adam3us> gmaxwell: so you demand sufficient info from the sender to validate that this did not happen
14:52 < adam3us> maaku: yes
14:52 < gmaxwell> maaku: right. You'll demand to know, as adam3us says.
14:52 < maaku> ok
14:52 < maaku> so it's basically encrypted mastercoin :\
14:52 < gmaxwell> maaku: yea, basically.
14:52 < adam3us> gmaxwell: yes, this is a trick that a normal signature include sthe public key and so then anyone can correlate it with any previous committed versions of it
14:52 < adam3us> hey take it easy there.. i am not a mastercoin fan :|
14:53 < gmaxwell> maaku: but it doesn't invoke another currency. :P
14:53 < gmaxwell> though the there is fungibility break, a long chain coin is not as valuable as a public one.
14:53 < adam3us> gmaxwell: are the mastercoin guys on here?
14:54 < maaku> adam3us: no, I don't think so
14:54 < adam3us> i think petertodd is putting archives of this in the clear on amazon, so nothing too biting can be said
14:55 < adam3us> anyway my issues with mastercoin are funding model, not technical ideas
14:55 < maaku> meh, J.R. seems to take genuine technical objections pretty well
14:55 < petertodd> adam3us: only when requested - it's not something I've been doing regularly
14:55 < maaku> doesn't learn from the pointed out mistakes though, but that's a separate issue
14:56 < adam3us> maaku: i havent made any technical comments about msc, i just commenting n the funding model
15:03 < gmaxwell> in any case, adam3us's proposal becomes potentially more interesting if the network can validate a ZKP of a transcript of a validation of his coin scheme.
15:03 < adam3us> so what about this p2p blind sig on the coin transfer idea
15:03 < gmaxwell> as it would allow you to reemerge and make public a coin without making the keys public.
15:04 < adam3us> gmaxwell: SCIP/SNARK fo the encrypted history? wowsers the inefficiency of that :)
15:05 < gmaxwell> adam3us: right. SCIP a validation of the encrypted history to emerge the coin in zero knoweldge  ... and yea, costly, but the validation is fast, so the public part wouldn't be an issue.
15:05 < adam3us> i think the p2p blind sig on transactions could achieve something committed coin similar but on normal transactions, payee anonymity
15:05 < adam3us> gmaxwell: wouldnt it be big?
15:06 < TD> proofs are small
15:06 < adam3us> gmaxwell: i dont know in my head it just seems like its a compiler for what you could do manually with generalized fiat-shamir transform of cut & choose repeated on a program, plus all the systematizable optimizations
15:06 < TD> an OP_SCIP would not be unthinkable
15:06 < adam3us> gmaxwell: and i cant see that being very compact somehow
15:07 < gmaxwell> adam3us: no, the proofs are small (they are not proportional in size to the program). Authoring the proofs is painful.
15:07 < adam3us> gmaxwell, TD: ok that could quote be interesting & powerful as a building block
15:08 < TD> gmaxwell: it got a LOT better, apparently.
15:08 < TD> not sure if i'm allowed to discuss their latest performance results in public, or how that works, etiquette wise
15:09 < adam3us> gmaxwell: eg hal finney made a presentation of what it took to prove a SHA1 hash in zkp it did not look pretty, they must've made some new insight
15:09 < TD> yes they did
15:09 < gmaxwell> adam3us: there has been a _lot_ of avancement here.
15:09 < jtimon> sorry guys, my laptop died
15:09 < adam3us> gmaxwell: ok, its interesting though because whatever they are doing is general - one could use it oneself manually, hand optiize it etc
15:10 < adam3us> gmaxwell: eg can it make a smaller homomorphic valued coin?
15:10 < jtimon> maaku can you paste me the conversation from "A->B is in the chain in hidden form" somewhere else?
15:10 < gmaxwell> adam3us: yea sure the compiler part is obviously never going to be as efficient as hand circuit optiomization.
15:11 < gmaxwell> TD: well, so, they do have multiple backends on this stuff, the really compact things is the knoweldge of expoenet pairing crypto stuff, and adam3us's skin with crawl at that. :P
15:11 < amiller> (this is totally irrelevant, but it irks me that eli ben sasson has gotten everyone to use SCIP as a generic name for this, SNARK is the generic name, SCIP is just the name of his particular project, his paper for scip is even titled SNARKS for C)
15:11 < TD> SNARK sounds dumb
15:11 < maaku> jtimon: http://pastebin.com/vUnrtLME
15:11 < TD> also i doubt any such system would be generic
15:11 < adam3us> gmaxwell: see i optimized the zkp range proof a lot manually in problem specific ways and still came to 1.5kB
15:11 < jtimon> thanks maaku
15:11 < TD> but sure, we can call them SNARKs instead
15:12 < adam3us> gmaxwell, TD: so i must be being dumb if their compiler can outperform me :)..  but yes i stayed well clear of pairing
15:12 < TD> they use a lot of very complicated techniques
15:13 < TD> i only understand some of it
15:13 < amiller> with pinocchio you can create a proof for SHA1 in 15 seconds on a single thread desktop computer
15:13 < amiller> i'm pretty tinyram beats that
15:13 < gmaxwell> and the proof is a couple pairing group elements.
15:13 < adam3us> TD: its very powerful  if that scales, so we can forgive pairing
15:13 < adam3us> gmaxwell: thats amazing
15:14 < TD> i thought it was 8 elements
15:14 < adam3us> and is this non IP-encrusted?
15:14 < warren> My BFL arrives today, far too late to be useful.
15:15 < gmaxwell> Well they have another backend that uses fiat-shamir with locally testable codes... the proofs are bigger but not astronomically large.
15:15 < adam3us> warren: still waiting for mine its been stuck as "fulfilled" but not shipped
15:15 < gmaxwell> (like zerocoin size)
15:15 < amiller> adam3us, there are currently three competing snarks projects, tinyram http://www.scipr-lab.org/tinyram  pantry https://github.com/srinathtv/pantry and pinocchio https://research.microsoft.com/en-us/projects/verifcomp/
15:16 < gmaxwell> adam3us: I did some searches a while back and didn't find anything, but who knows what of their optimizations they may have patented in the last year.
15:16 < adam3us> do yu know if any of them have not covered it with lots of patents
15:16 < warren> adam3us: I missed the "use paypal tos to force BFL refund" thread by 1 day.
15:16 < amiller> adam3us, of these tinyram isn't out yet, pantry is fully open source, pinocchio is mostly open source except for the backend which they're working on reimplemnting open source
15:16 < gmaxwell> If they do, it'll be sad because the history of crypto says that patented crypto is dead on arrival.
15:16 < adam3us> warren: i missed that outright... bought a part upgrade to the 600GH and left order for the smaller 5GH
15:17 < adam3us> gmaxwell, amiller, TD: ok you convinced me I have to learn what they are doing!
15:18 < amiller> adam3us, http://eprint.iacr.org/2012/215.pdf this is the GGPR scheme underlying pinocchio and pantry
15:18 < adam3us> jtimon: i think the committed tx topic did not continue when you lost connection
15:18 < jtimon> I still don't understand commited coins, gmaxwell perfectly explained my worries "he's asking about the case where you are d in a chain of hidden spends.   a->b b->c c->d  And he's confused about how you know that a->q  didn't happend first."
15:19 < gmaxwell> jtimon: when you are d, and get paid by c you demand he provide you the required keys to trade your payment back to entirely public inputs.
15:19 < amiller> adam3us, actually GGPR underlies tinyram as well
15:19 < adam3us> jtimon: yes so the thing is if a->q happened it would be on the block chain, the encrypted/hashed tx and a second H(a), the sender must prvoide info to convince you that isnt the case, ie that that is a forgery/spam
15:19 < gmaxwell> jtimon: and when you do so, because you have a's public key, you can see that a->b is the first a spend in the chain.
15:20 < warren> adam3us: I sold this BFL on ebay.  The first attempt failed with no bids.  The second attempt succeeded with a bid.  BFL forced the first expired listing offline with a "trademark/counterfeit" claim while leaving the high priced successful bids untouched...
15:20 < adam3us> warren: wow thats hostile
15:20 < jtimon> so a->b is in hidden form in the chain
15:20 < warren> I'm pretty sure that's abusing the law to manipulate perception of value.
15:21 < jtimon> b->c must also be in hidden form in the chain, right?
15:21 < adam3us> yes
15:21 < adam3us> it not offchain, its onchain but in encrypted/hashed form
15:21 < adam3us> such that anyone can see which are spends of the same key, they just dont know which key
15:22 < jtimon> and when I receive C->D, C also gives me proof that a->b, b->c and c->d where actually signed properly
15:22 < jtimon> were
15:23 < gmaxwell> well he gives you the keys required for you to be able to check for yourself. (it's not in zero knoweldge)
15:23 < adam3us> jtimon: yes, he just gives you a sym key that allows you to decrypt
15:23 < adam3us> jtimon: you can validate it yourself then as the bit of the block chain you care about is now decryptable and visible to you
15:24 < jtimon> so now I want to pay D -> E in public form
15:24 < gmaxwell> you would make those secrets public at that point, so the whole network could validate what you wanted before.
15:24 < jtimon> couldn't C try to publicly pay C -> C2 first ?
15:24 < adam3us> jtimon: you have to publish all the committed ones or the recipient otherwise needs keys for a-<c
15:25 < adam3us> jtimon: no because of the trick that a public spend correlates with the committed spends
15:25 < adam3us> as a public spend incudes pub key (not just address), and H(pub) can be calculated fro it, and H(pub) is attached cleartext to each committed spend
15:25 < jtimon> but no one is seeing any relation between hiden (commited is confusing sorry) spends
15:26 < jtimon> ok, so every hiden spent refers to the previous one
15:26 < maaku> hidden is a much better term
15:26 < jtimon> explicitly
15:26 < gmaxwell> jtimon: to make d -> e in public you disclose the keys, so the relations then become clear.
15:26 < maaku> yes, these are not blinded
15:27 < jtimon> but not until I publicly pay d -> e ?
15:27 < gmaxwell> right.
15:27 < jtimon> then at any time c -> c2 or b -> b2 could be bradcasted
15:27 < jtimon> no?
15:28 < maaku> yes, but it would be meaningless
15:28 < gmaxwell> No.
15:28 < gmaxwell> (as maaku says)
15:28 < adam3us> not really because people receiving them can see they are spent
15:28 < gmaxwell> Because everyone with the keys can see which comittments were first.
15:28 < maaku> c2 or b2 would have the keys necessary to go check the chain and realize they were double-spent
15:28 < adam3us> as with (c->c2) in clear form, you know public key of C, and that is attached to the original spend as H(c)
15:28 < gmaxwell> and the hidden -> public validation checks this too.
15:28 < adam3us> eeven if they didnt
15:29 < jtimon> ok, so then every hiden spent references the previous hiden spent
15:30 < adam3us> jtimon: the recipient of a hidden spend needs keys back to the first non hidden ancestor
15:30 < adam3us> jtimon: actually with optimiation its just one sym key you disclose at any time
15:30 < jtimon> let's say I have d -> e (public) prepared at home but I chose not to broadcast it until next week
15:30 < adam3us> jtimon: the sym key gives you enough to navigate backwards, decrypt, then validate normally
15:30 < gmaxwell> yea, because you could change the keys in the encrypted data.
15:31 < jtimon> there's 3 possibilities
15:31 < gmaxwell> s/change/chain/
15:31 < gmaxwell> jtimon: I think you've thought yourself into a rut, this isn't that complicated.
15:32 < adam3us> jtimon: i think the thing your maybe missing is that, a public spend is also validated against its inputs, and the inputs are encrypted and so its rejected
15:32 < jtimon> 1) When miners receive public(C -> C2), they realise it is invalid because something in hidden(C->D) indicates it
15:33 < jtimon> hidden(C->D) is already in the chain
15:33 < adam3us> jtimon: think you meant c->d2, yes they can see tht hidden(c->d) was with the same key c as clear c->d2 so its invalid
15:34 < jtimon> ok, I got it
15:34 < adam3us> jtimon: so if clear spend of c->d2 comes after hidden spend c->d then d2 is a double spend and rejected; its interesting because in its hidden form the miner knows almost nothing so he can apply no policy
15:34 < gmaxwell> it would still work if they couldn't however, certantly easier that they can.
15:34 < jtimon> but no, I meant c2 to express that belongs to the same person
15:35 < jtimon> so, c->d publicly states {C, H(C->D)}
15:35 < adam3us> gmaxwell: ? what mean "it would still work if they couldn't however, certantly easier that they can."
15:36 < adam3us> hidden(c->d) = E(tx), H(c) approximatel
15:36 < jtimon> isn't this also traceable?
15:36 < gmaxwell> adam3us: I mean the requirement that miners can reject a double spend isn't a strict requirement. So long as the reciever can identify the first spend thats in the chain thats enough for the scheme to work.
15:36 < adam3us> jtimon: so if you send c->d2 publicly now anyone can compute H(c) and see wait that was alrady spent
15:36 < gmaxwell> jtimon: once the data is made public, sure.
15:36 < adam3us> gmaxwell: ah yes
15:37 < adam3us> jtimon: before its public its utterly hidden except to the people in the path
15:37 < adam3us> jtimon: you cant even tell is a path, the hidden tx are opaque blobs and H(c) is useless if you dont know c
15:38 < adam3us> amiller, gmaxwell, TD: surely SCIP-coin can be a game changer if there is an efficient non-patented version.  or maybe the community can buy them out :)
15:39 < gmaxwell> then the other conversation we had was where I pointed out that using a sufficiently powerful (tm) zero knoweldge proof system you could do the private->public change without making the keys public. (I wrote about this at length in a forum thread of its own)
15:39 < gmaxwell> ( https://bitcointalk.org/index.php?topic=277389.0 )
15:40 < adam3us> gmaxwell: think i missed that forum thread sounds like what you said above about SCIP
15:40 < jtimon> so you have {H(A), H(A->B)}, {H(B), H(B->C)}, {H(C), H(C->D)} in the chain, and until it's all published only the owners can trace it but cannot double-spend, yes, it's not that complicated
15:41 < gmaxwell> adam3us: it is, I described two kinda of scheme it could bind, yours would be another one, sort of in-between the two I described.
15:41 < gmaxwell> (basically replacing the anti-replay-oracle in the first one with a chain)
15:42 < jtimon> I see, what I was missing was the double-spent prevention, but this could definitely work
15:43 < adam3us> jtimon: the motivation was actually miners enforcing policy when they get too powerful
15:44 < jtimon> yeah, I'm subscribed to that thread but I didn't really undesrtand this missing piece until now
15:44 < adam3us> jtimon: as you can see they have no remaining visibility until the coins are long mined, in this system blocking recipients or taint would be hopeless
15:44 < jtimon> this could work with freimarket assets too
15:44 < adam3us> jtimon: so its another taint fix without anonymity
15:44 < amiller> adam3us, there are no patents
15:44 < adam3us> amiller: fantastic
15:44 < amiller> adam3us, there is only one fully open source implementation (pantry) and the others are on their way
15:45 < amiller> i have no idea if scip will be open but pinocchio and pantry definitely will
15:45 < jtimon> so the generic term for them all is spark?
15:45 < amiller> snark
15:45 < adam3us> amiller, gmaxwell, TD: it seems to have immense possibilities.  i think possibly the only downside is its super cutting edge, if they got anything wrong, or someone breaks it n the bicoin scenario it blows up
15:45 < amiller> succinct non-interactive argument of knowledge (it's a generic crypto term, like zero knowledge)
15:46 < gmaxwell> Yea, these are technically arguments of knoweldge not zkp. ... which is a whole source of potential surprises too.
15:47 < gmaxwell> because we assume that there is cryptographic hardness to producing a false argument, but the evidence for the strength of that is somewhat abstract.
15:47 < jtimon> thanks amiller
15:48 < adam3us> jtimon, gmaxwell: while initially motivated by preventing miner policy abuse (even up to 99% centralized power etc) hidden tx (better than commited tx i agree)
15:48 < amiller> gmaxwell, the difference between "argument" and "proof" just means computational not information theoretic
15:48 < adam3us> jtimon, gmaxwell: has interesting privacy aspects also, its temporarily fully anonymous; unfortunatey there seems to be no way, short of scip to privately compact it
15:49 < amiller> most zk proof systems are in fact computionally-sound proofs which is exactly the same as argument
15:49 < jtimon> well, couldn't you present the snark proof in every hidden tx?
15:50 < amiller> snark proof of what?
15:50 < jtimon> amiller of the last hidden tx
15:50 < gmaxwell> amiller: It means the soundness is only computational. A lot of zkp things are sound but zero knoweldge is computational.
15:51 < jtimon> just like with coinwitness, where you present the snark proof on redemption/republishing
15:51 < amiller> it's not clear to me at least what it is you wuld say about the tx in zero knowledge
15:51 < amiller> i think you'd have to refer to a particular blockchain head
15:51 < gmaxwell> amiller:  you would.  "The coin I'm spending was confirmed in this chain"
15:52 < amiller> and how do you prove it hasn't been spent by any subsequent txes in between when it was confirmed and the current head?
15:52 < gmaxwell> amiller: see the coinwitness post.
15:52  * amiller rereads it but has had a hard time grasping it previously
15:53 < jtimon> you would present {H(c), snark(c->b)} ?
15:53 < jtimon> you can't divide the coins with this approach though, no?
15:54 < amiller> i think we should come up with a good notation for ZK.
15:54 < amiller> the crypto community has let us down
15:54 < amiller> there is this weird notation like [f(x) | x] or something that says f(x) is true but x is hidden but it's kind of inflexible
15:54 < adam3us> jtimon i guess you only need scip/snark hop by hop, the miner can validate the scip and see the encrypted inputs validate
15:55 < amiller> gmaxwell, i still don't undersatnd from coinwitness how you avoid replays like that
15:55 < maaku> so without snark, is it possible to use something akin to the hidden txn scheme to replace the chaum blinding double-spend db?
15:55 < amiller> you mention a replay oracle but that seems like just a strawman because it's some trusted other party apparently
15:55 < adam3us> amiller: dont u like the ZkPoK[m]{(a,b),c: a<b ^ SIG(c)} notation ;)
15:55 < gmaxwell> amiller: ...
15:56 < gmaxwell> amiller: A lot of people understood this, I don't think I failed to explain it adequately.
15:56 < jtimon> yes, that's what I'm saying, isn't that part of coinwitness already? or does the snark validation only happen on redemption/republishing?
15:56 < gmaxwell> amiller: First understand that it's not a concrete system on its own.
15:57 < gmaxwell> amiller: What I'm pointing out is that if you have a machine verifyable offchain transaction system {details are up to you}, and SNARK validation in bitcoin,  you can bind the systems that way.
15:57 < jtimon> amiller, what I was missing until know is that miners validate the inputs to prevent double-spending (you have to publish the hash of the input address)
15:57 < jtimon> until now
15:57 < gmaxwell> amiller: I threw out two examples of possible offchain transaction systems, as just examples of how the binding would work.
15:58 < jtimon> amiller what I wasn't able to understand is that " a machine verifyable offchain transaction system" is feasible
15:59 < gmaxwell> amiller: the general idea is you take a coin and pay it to someone who can (in zero knoweldge) provide a transcript showing they own the coin and have decided to emerge it into bitcoin in your selected offchain system.
15:59 < jtimon> even without snark
16:00 < gmaxwell> amiller: then you go off and transact and build up your transacript, and your last payment in that system pays to special terminal address that indicates you're going to reemerge back into bitcoin.
16:00 < gmaxwell> Then you run a SNARK of the transacript validation program over the transacript and get a proof which you present to bitcoin and collect the coin.
16:00 < amiller> gmaxwell, okay i think i understand coinwitness for the purpose you are describing now where you use it to branch out into some other blockchain or oracle-based ledger
16:00 < jtimon> but the transactions aren't really off-chain in this last example, they were just non-public
16:01 < amiller> i guess all that confused me just now is that i was trying to undersatnd it in terms of comitted blind transactions
16:01 < adam3us> maaku: "so without snark, is it possible to use something akin to the hidden txn scheme to replace the chaum blinding double-spend db?
16:01 < adam3us> maaku: without scip or some analogous changes, the utxo cant be compacted
16:02 < gmaxwell> amiller: okay, well, it doesn't have to be some other blockchain or oracle based ledger. It could be a colored coin in bitcoin, for example. Or one of adam3us's blinded things.  It should work for any transaction system which can be reliably verified by a program with maliciously controlled inputs.
16:02 < adam3us> maaku: also its not anonymous as the recipient sees the senders address, but it is encrypted so only people involved see it, which i think is a nice balance
16:02 < maaku> "utxo cant be compacted" <-- what do you mean here?
16:02 < maaku> you mean remove intermediate txns?
16:02 < gmaxwell> making it secure if the {other system} is a chain is a little tricker, you either get 'only' headers security, or you add a public input that locks it to a specific chain.
16:02 < maaku> or the double-spend db?
16:02 < amiller> gmaxwell, okay i think i follow all of that
16:03 < adam3us> maaku: well there isnt really a double spend db anymore as its basically bitcoin tweak
16:03 < gmaxwell> maaku: adam3us's hidden skeem poops commitments all over the place, and you can't clean them up. At least not until they're unhidden.
16:03 < amiller> the only thing i still don't understand is what adam3us's blinded things are
16:03 < amiller> or basically i think i undersatnd them but it has that.... commitment refuse problem
16:03 < maaku> ugh, yeah that's true
16:03 < amiller> commitment garbage*
16:03 < adam3us> maaku: but the utxo is hard because the miners cant tell whats going on
16:04 < gmaxwell> and if you re-emerge them using a SNARK then you can't clean them up even when they're re-emerged. :(
16:04 < adam3us> amiller: thats why it uses mac & encryption so you can prove you have the right key, and the others are garbage
16:04 < maaku> ok what i'm getting at is some way the burden of double-spend prevention can be placed on the recipiant instead of every full node
16:05 < maaku> that's the only thing which keeps me from adding chaum ecash to freimarkets' public chain
16:05 < adam3us> amiller: apart from garbage, you could send just a hash, so it could even be a bandwidth saving (cheaper to drag a payment history than broadcast to everyone)
16:05 < gmaxwell> well if you combine adam3us scheme with petertodd's mmr stuff, then I think you can move the cost onto the reciever.
16:06 < gmaxwell> adam3us: well if you want the emergence to to be small you'll need to have the history encrypted in the transactions themselves as you go.
16:06 < adam3us> gmaxwell: "and if you re-emerge them using a SNARK then you can't clean them up even when they're re-emerged. :(" surely if you reemerge them hop by hop (no hidden form respending) then miners can validate the respend, to the individual but encrypted input tx, and then prune encrypted utxo
16:07 < adam3us> gmaxwell: yes there is no saving unless you never reemerge
16:07 < amiller> i still think it would be a lot easier to argue about whether any of these schemes are sufficient by first describing the ideal function of the ledger using zero knowledge
16:07 < adam3us> (from hashing)..
16:07 < gmaxwell> adam3us: then you'd have to know which utxo is which. (to prune) and the advantage of the snark emergence is that you don't have to ever disclose anything...
16:07 < maaku> hrm.. MMR double-spend db might work very well
16:08 < amiller> in a perfect world you'd learn nothing except that the transaction was valid, and the state could be updated by anyone without having to know anything else
16:08 < adam3us> gmaxwell: but if its an opaque blob, wahts the damage to say yes this was my txin.
16:08 < adam3us> gmaxwell: if the entire chain was in hidden form
16:08 < gmaxwell> adam3us: because it disclosed where it came from and so you can build a transaction graph.
16:09 < amiller> i wonder if accumulators are the right thing because if you know x, you can prove that x is included in acc{...,x,...}, you can also produce acc' = acc - {x} without knowing any of the other committed values
16:09 < adam3us> gmaxwell: yeah but  tx graph of opaque blobs isnt so bad - you dont know who they're to who theyre from or the amount
16:09 < adam3us> gmaxwell: i mean even the addresses arent disclosed, there's nothing
16:10 < amiller> i don't think i believe that adam3us's scheme actually sufficiently protects against blacklisting policies etc
16:10 < gmaxwell> amiller: it doesn't but it makes it softer.
16:10 < gmaxwell> adam3us: ... if you can remove the utxo this emerge consumed, then you could also look to see which utxo it removed and so on.
16:10 < adam3us> gmaxwell: i think it could be about the right model, for privacy you can subpoena a person in the chain, and they can prove the blob they got it from
16:10 < gmaxwell> adam3us: if bitcoin is used correctly the addresses are all single use anyways, hiding the addresses isn't that helpful.
16:11 < adam3us> gmaxwell: yes but coin control fails in real life seemingly
16:11 < amiller> yes and elaborate zk fails to exist in real life seemingly too
16:12 < gmaxwell> adam3us: I mean, the top most wallet promoted on bitcoin.org forces you to constantly reuse an address, as does the most popular wallet software. I don't think you can say there is any fundimental failing, ... and you can't cure people's disinterest by making transactions much more expensive (in size and computation)
16:12 < amiller> isnt coin control an easier thing to get right for this level of improvement
16:12 < maaku> adam3us: these are user interface problems
16:12 < maaku> in short time, with the proper tools, bitcoin addresses will be 1-use-only
16:12 < gmaxwell> What maaku says.
16:13 < gmaxwell> There are things in the pipeline which will help, and eventually we will need to grow some balls and threaten to delist wallet software from bitcoin sites when they force known bad behavior.
16:13 < gmaxwell> But thats mostly orthorgonal from crypto stuff, there is huge information leaks from the transaction graphs even when addresses are not reused.
16:13 < adam3us> gmaxwell, maaku: i dont thnk so quite, hence coinjoin etc
16:14 < gmaxwell> adam3us: coinjoin actually buggers the graph analysis.
16:14 < adam3us> gmaxwell: exactly
16:14 < adam3us> gmaxwell: good,somewhat, still prefer opaque blobs if we could find an efficient way to do it
16:14 < adam3us> unencrypted value is also hideous
16:14 < gmaxwell> But what you're suggesting (snarking at each step) doesn't. It just hides reused public keys, which is kinda boring... I mean, it's better but so long as it has a cost....
16:15 < gmaxwell> right. okay, I don't think we actually disagree. Maybe just on the exact tradeoff points.
16:15 < adam3us> gmaxwell: it hides value as well
16:15 < maaku> mostly it's just a matter of getting payment protocol and hd wallets accepted everywhere and built into every wallet
16:15 < maaku> coinjoin is a separate issue, is it not?
16:15 < adam3us> gmaxwell: you could probably mix some ORs into the snark
16:16 < gmaxwell> In any case, I think it's not good enough to do one thing, we must do all the things.
16:16 < adam3us> maaku: i think coin control is not enough
16:16 < gmaxwell> But I think humans have a lot of inertia so we need to do the more user visible things first.
16:17 < adam3us> maaku: still plenty of transaction graph leaks
16:17 < maaku> adam3us: ? by coin control do you mean coinjoin et al?
16:17 < adam3us> amiller: i think it could block miners
16:17 < gmaxwell> e.g. if we get enormous bitcoin businesses depending on being able to infer refund addresses from chain analysis, any improvement will be hard to deploy.
16:17 < adam3us> maaku:  no i mean not picking coins at random from your wallet
16:17 < adam3us> gmaxwell: yes that has to die
16:18 < adam3us> gmaxwell: btw that is why i proposed a publicly creatable chian code like thing (bip 38?) extension
16:18 < maaku> adam3us: yes, that's not enough. which is why we need payment protocol + hd wallets (don't reuse addresses) and coinjoin (spread the taint around)
16:19 < adam3us> hd wallets are a great invention on multiple grounds (nice job), but it is interactie, and people like static addresses for usabiity and chain is private
16:19 < gmaxwell> adam3us: it's not interactive. 0_o
16:20 < adam3us> gmaxwell: well if the site has a chain code online and hands it out right then to the sender
16:20 < michagogo|cloud> Interactive? What does that even mean?
16:20 < adam3us> michagogo|cloud: spender goes to web site, web site uses chain code to make new address, spender recieves address, sends to block chain
16:20 < gmaxwell> adam3us: the idea is that you can give someone who will pay you multiple times a extended public key for a child chain. Then they can pay you without interacting.
16:21 < gmaxwell> adam3us: thats one possible usecase, another is that you give them their own subchain — the whole extended public key.
16:21 < adam3us> you give htem a subchain key so they can generate more?
16:21 < adam3us> gotcha
16:21 < gmaxwell> adam3us: yes.
16:21 < gmaxwell> You can use it either way, interaction is optional. :P
16:21 < adam3us> yes i got that picture i think from the bip etc
16:21 < adam3us> gmaxwell: my point is you could have a print advertisement in a newspaper, and still have each sender use a different address
16:22 < gmaxwell> adam3us: you could, but they'd need to figure our which addresses were used already first.
16:22 < adam3us> gmaxwell: i wrote it somewhere... i think you replied on the thread, sender does Q'=xG+Q  x=random, and encrypts x for Q
16:22 < adam3us> gmaxwell: no it would be random
16:22 < gmaxwell> I know, bytecoin proposed exactly that a long time ago.
16:23 < adam3us> gmaxwell: tht seems to answer peoples seeming desire to work with static addresses... its probably its just simpler to think about
16:23 < michagogo|cloud> The only thing is, you'd need to generate a sufficiently long series of addresses to watch from that subchain key
16:23 < gmaxwell> but this requires a lot of work from the reciever. e.g. he has to do cryptographic work for every tansaction and can do nothing like bloom filtering.
16:23 < michagogo|cloud> Or, provide some mechanism for people to let you know which address they sent to
16:24 < adam3us> gmaxwell: probably you could put some bloom bait on it
16:26 < maaku> for printed advertisements, payment protocol is often the better solution
16:26 < maaku> which is why we need both
16:27 < maaku> "send coins to myfoundation.org/donate"
16:28 < gmaxwell> adam3us: also, your scheme requires the recieve have an online decryption key to identify their own transactions. (so did bytecoins)
16:28 < jtimon> they could say in the ad how to build the address
16:29 < gmaxwell> Bytecoin's suggestion IIRC was that you include an extra random public key in your transaction. And then the key you payto is ECDH between the recievers private and your public, plus his public.  This also gave you a nice identity for the sender of the transaction (the public key)
16:29 < gmaxwell> by it required doing a free point multiply for every transaction on the network, and also keeping your private key online for doing it.
16:29 < jtimon> in freicoin foundation, for example, is organization_id/months_after_launch but you could have a deterministic mapping between username and an int
16:29 < maaku> jtimon: yes, but equally important is the other end of it. they need to know what addresses to listen for
16:30 < jtimon> all_my_registered_usernames/start_incrementing_from_0
16:31 < maaku> yes, but again: printed ad - you don't know your future donors
16:31 < maaku> hd wallets fit some situations, payment protocols others
16:31 < maaku> typically hd wallets are good for existing relationships, payment protocols for new ones
16:32 < maaku> it would be nice if payment protocol had a mechanism for specifying an hd address (there was some discussion on the list about this, I believe)
16:32 < jtimon> printed add is too much, you can't do it on your own
16:32 < adam3us> gmaxwell: yes bytecoins seems similar and similar side effects.
16:32 < jtimon> but if they register in your web is different
16:32 < jtimon> there was a video "pay to protocol"
16:33 < maaku> ?
16:33 < adam3us> my additional probaby unstated thought on the btc thread is maybe the sender can give you a hint, that allows you to narrow which are for you, or safely delegate searching to a full node
16:33 < jtimon> where the receipt was used to build the payment address from the recipients seed_key
16:33 < maaku> the UI for payment protocol would presumably be the same - you use a url in place of a address and your wallet handles the magic
16:34 < adam3us> gmaxwell: have to think about details coud be interesting as fixed addresses are seemingly what users understand and they are setting a bad direction as is
16:34 < jtimon> sorry, was pay-to-contract http://www.youtube.com/watch?v=qwyALGlG33Q
16:37 < sipa> adam3us: we should start by stopping to call them "addresses" and call them "key identifiers" instead
16:37 < gmaxwell> we're mostly failing to communicate to the public that these address things should be single use.  Joe bitcoin user has no idea of this.
16:37 < sipa> a key identifier can be used as an address if someone wants to receive a payment on it
16:37 < gmaxwell> Even the way bitcoin-qt (in release versions) works basically encourages reuse.
16:38 < maaku> sipa: that's a great idea. i'm going to start doing that
16:38 < sipa> indeed
16:38 < jrmithdobbs> gmaxwell: it's not exactly for a lack of trying, everyone just says "whatever" when it's explained to them and ignore it anyways
16:38 < jtimon> on the previous conversation, what was wrong with snark per hop hidden payments?
16:38 < gmaxwell> (git improves this a fair bit)
16:39 < sipa> most have never been confronted with this idea at all
16:39 < jtimon> what was impeding the prunning if you snark every hop?
16:39 < gmaxwell> jrmithdobbs: it is for lack of trying.
16:39 < sipa> people think bitcoin sends money between addresses
16:39 < gmaxwell> jtimon: pruning is incompatible with privacy.
16:39 < sipa> (and on some level, it does, unfortunately)
16:39 < gmaxwell> At lest git bitcoin-qt is better about not encouraging reuse.
16:40 < gmaxwell> although it does have a checkbox "Reuse an existing recieving address (not recommended)"
16:40 < sipa> i should try qt again
16:40 < gmaxwell> maybe we should change that word existing to something like "stale" :P
16:40 < maaku> gmaxwell: well, it has an address book
16:41 < gmaxwell> maaku: no, not unless you check the reuse thing.
16:41 < jtimon> gmaxwell, I see, H(c) will always be there to prevent double-spend if you snark redemption
16:41 < maaku> well, I mean the very concept of an address book (absent payment protocol or hd wallets) is suspect
16:41 < adam3us> gmaxwell: "pruning is incompatible with privacy." well as above i think its more privacy than current by a large amount
16:41 < gmaxwell> jtimon: unless you make H(c) public while SNARKing but then you are tracable.
16:42 < amiller> can anyone think of a way of estimating the distribution of mining resources among distinct individuals
16:42 < amiller> we really have no idea about that do we?
16:42 < gmaxwell> adam3us: by mining do you mean hashing?
16:42 < jtimon> gmaxwell, yes, undesrtood, you can't have teh cake and eat it too
16:42 < amiller> or how many gpus are out there mining as opposed to asics
16:42 < gmaxwell> amiller: there should be ~0 gpus now.
16:42 < maaku> amiller: politely ask the major mining pools for access to their logs
16:43 < amiller> if i already bought the gpus and i can't sell them, it's unlikely that there's anything to be gained by turning them off
16:43 < amiller> power is relatively cheap
16:43 < gmaxwell> amiller: 0_o
16:43 < adam3us> jtimon: the privacy leak is small compared to current syst
16:43 < amiller> or do you mean you can't even make profit vs the power consumption
16:43 < gmaxwell> amiller: correct.
16:43 < maaku> amiller: they should be very unprofitable by now
16:43 < gmaxwell> amiller: the whole network prior to the introduction of asics was about 20TH/s (and that included a lot of FPGAs), the current network is around 4000 TH/s.
16:44 < adam3us> jtimon: it would be a big net improvement - no value revealed, no addreses linkable.  yes poeple shouldnt link addresses.  but coin control fails.  and even if coin control was optimal there would still be linking
16:44 < jtimon> adma3us yes and it's after republishing, so it makes your example legal attack much harder
16:44 < gmaxwell> so that should give you some kind of upper bound on how many gpus could be in use. ... combined with gpus being power breakeven only if your power costs ....
16:44 < adam3us> jtimon: with scip you never need to republish, the miner just validates it in hidden form wth the scip
16:45 < maaku> amiller: actually you might be able to extra an order of magnitude estimate from the drop in hash following diff adjustment, and corresponding rises in litecoin
16:45 < gmaxwell> $0.028/kwh or lower.
16:45 < gmaxwell> (at $350 exchange rate)
16:46 < jtimon> adam3us: but republishing allows prunning and there's some agents that need transparency (say, nonprofits)
16:47 < adam3us> jtimon: but anyone can validate the scip and see the input is spent, and so the miners can attest to that
16:48 < adam3us> jtimon: its easy to create transparency, publish the hiding sym key
16:49 < jtimon> adam3us if the snark indicates what previous transaction can be pruned, how is this non-traceable?
16:49 < adam3us> gmaxwell: i am starting to feel i will be facing similar break even by the time BFL delivers my april ordered 5GHs never mind my feb 2014 600GH
16:50 < adam3us> jtimon: it does make a graph, but the graph is between opaque blobs
16:50 < gmaxwell> adam3us: You have my condolences for your purchase with BFL. :P
16:51 < phantomcircuit> adam3us, it depends entirely on the rate at which the network continues to grow
16:51 < phantomcircuit> which is to say
16:51 < adam3us> gmaxwell: it was more for amusement and hopefully recoup money than expectation of profit. to lose money might be a bit annoying, never mind, i'll just run it a my contrib to mining decentraliation -
16:51 < phantomcircuit> largely luck
16:51 < amiller> expected income per hash: 3.64e-15  dollars per hash    expected power cost per hash, assuming 6 cents per kwh and the most efficient GPU: 8.33e-15
16:51 < jtimon> adam3us my march ordered jalapeno is on the customs (border) right now, I will pay the taxes but I highly doubt I will break even
16:52 < gavinandresen> mining is a zero-sum game… you should try to play positive-sum games, the rewards are better and are potentially unlimited
16:52 < adam3us> jtimon: whats jalapeno, 5GH? or previous
16:52 < maaku> adam3us: if there's a graph, it's traceable, right?
16:52 < phantomcircuit> gavinandresen, a better way is to describe it as a perfect market
16:52 < maaku> gavinandresen: ain't that the truth
16:52 < adam3us> maaku: not exactly; it acts like a perfect coin control which is impossible otherwise
16:52 < gavinandresen> "perfect" is the enemy of… something....
16:52 < jtimon> adam3us 4.5GH + 2 iirc
16:52 < warren> phantomcircuit: BFL sure is perfect. =)
16:52 < phantomcircuit> although actually i guess that's not true anymore since the barrier to entry isn't insignificant anymore
16:53 < phantomcircuit> gavinandresen, heh
16:53 < gavinandresen> I did make a tidy bitcoin profit flipping my ordered-first-day jalapeno
16:53 < maaku> adam3us: that seems like a total non-sequitur. i'm not sure what you mean
16:53 < gavinandresen> … but my lesson learned was "don't mine"
16:53 < gmaxwell> phantomcircuit: it was never all that perfect when anyone cared. ... even in 2011, all ATI cards everywhere sold out.
16:53 < jtimon> adam3us a graph that comes back to the first public transaction, you can't divide amounts on hiden tx can you?
16:53 < adam3us> maaku: if you do as current and say well there's coin control etc peope should nly use addresses once, that doesn twork in reality
16:54 < sipa> gavinandresen: flipping?
16:54 < gmaxwell> adam3us: there isn't coin control.
16:54 < maaku> adam3us: what i'm saying is you can trace the final output back to the original input(s), even if you don't know what happened inbetween, right?
16:54 < adam3us> jtimon: i think the impilcation is the recipient learns an "argument of knowlege" of the value that he has, and enough to prove it onwards with reference to his own coin
16:54 < gavinandresen> sipa:  selling something soon after you bought it== flipping
16:54 < gavinandresen> (selling for a profit)
16:54 < sipa> thanks
16:55 < amiller> gavinandresen, "zero-sum game" more expected-utility dogmatism :p
16:55 < adam3us> jtimon: without scip yes you can divide and all the normal things; with scip i would think so too
16:57 < adam3us> maaku: with scip you would do per hop validation, and that is transitive so all transactions re visibile in a big fat graph, however you dont know the addresses/identities/amounts
16:57 < jtimon> adam3us with snark and divisions it must be traceable
16:58 < jtimon> hmmh, yeah, I guess you could hide the amounts
16:58 < adam3us> jtimon: yes i think you are right, tough the amounts would be hidden
16:58 < gmaxwell> adam3us: I can't see bitcoin doing a soft forking change (which are inherently risky!) and add costly crypto to achieve something that today people can already do.
17:01 < jtimon> maaku I think this would be better than in-chain chaumian cash
17:02 < maaku> jtimon: it'd be crazy expensive
17:02 < maaku> snark is not cheap to use
17:03 < maaku> hrm I think MMR + Chaum was a red herring, but what about this:
17:04 < maaku> store zerocoin serial number in a composable auth tree, and require a proof-path within the spend
17:04 < jtimon> wait, link to MMR? I still don't know what that is
17:04 < maaku> then validation storage requirements are just 256 bits per mint series, and proofs grow log2
17:05 < adam3us> h he i just had paypal cold call me to ask about butterfly
17:05 < adam3us> reckon they got a mountain of disupte and condiering cutting off bfl as a bad paypal user
17:07 < maaku> jtimon: https://github.com/opentimestamps/opentimestamps-server/blob/master/doc/merkle-mountain-range.md
17:07 < adam3us> gmaxwell: "something that today people can already do" isnt hidden tx + scip per hop hiding something new?
17:09 < gmaxwell> adam3us: people can already use a fresh address and then only have blob linkages.
17:09 < maaku> address != identity
17:10 < jtimon> but they can't hide amounts
17:10 < jtimon> that would ne new
17:10 < adam3us> gavinandresen: "but my lesson learned was "don't mine"" yeah i wasnt expecting to get much more than recoup cost out of it, but i for one missed the GPU mining fun era completely - despite receiving email from satoshi in sep 2008 and feb 2009 saying go check out the client, so this is my variant of that
17:11 < gmaxwell> Mining has done well for me. ::shrugs::
17:12 < gavinandresen> adam3us: if it is any consolation, I did the math in … june?… 2010 and found it was less expensive to buy bitcoins than mine on my CPU.
17:12 < sipa> i think i profited moderately from both gpu and asics
17:13 < sipa> though never large scale
17:13 < sipa> and now i've stopped
17:13 < gmaxwell> wuss. :P
17:14 < adam3us> yes so its just an amusing thing to try, mining, and if i slightly help decentralization so its fine to just leave it on at elec break even
17:15 < gmaxwell> even at break even, it's a nice highly anonymous way to buy coins from the power company, assuming you have the hardware. :P
17:16 < adam3us> gmaxwell: well in fact i was thinking you might earn enough to pay fees on hidden (aka committed) tx which are perfectly unlinkable ;)
17:16 < gmaxwell> though it's still nowhere near break even now..  at current diff and $350 exchange your power would have to cost $1.1578/kwh to make avalons merely break even for power costs.
17:17 < phantomcircuit> gmaxwell, assuming what daily increase in network hash rate?
17:17 < adam3us> gmaxwell: that was partly why i was thinking it'd be interesting to have lower gpu self-mine without pools ie some kind of part-block payout
17:17 < gmaxwell> phantomcircuit: thats _right now_. I mean, I can turn them off in under a minute...
17:17 < phantomcircuit> gmaxwell, right
17:18 < phantomcircuit> you're already made capital costs right?
17:18 < gmaxwell> phantomcircuit: yea, they paid back their initial price in usd on the third day, and the initial price in bitcoin in about 2 weeks.
17:19 < phantomcircuit> gmaxwell, yeah people buying now are going to have a much harder time doing that
17:19 < phantomcircuit> even if you can get delivery tomorrow
17:19 < gmaxwell> indeed, people ask me if they should buy mining hardware and I dunno, the future is hard to predict.
17:19 < gmaxwell> There are optimistic predictions which are nuts, and pessimistic predictions which are slightly less nuts but still nuts. The truth, who knows?
17:20 < MC1984> youd have had to have junked them by now if the price didnt keep skyrocketing
17:20 < adam3us> right - i guess if its cheaper to buy coins just buy coins however
17:20 < phantomcircuit> yeah i mean the knc boxes are entirely sold out i think for months
17:20 < gmaxwell> MC1984: they's still be profitable over power costs at $100/btc, though not very much.
17:21 < adam3us> so i wonder - if the supply problems with asics do finally get resolved
17:21 < adam3us> difficulty will spike, and profitability will sink to electricity cost
17:21 < gmaxwell> adam3us: I dunno miners are different now than in the past, in the gpu days when my (at 6.5cts/kwh power) operation was 2:1 return on power cost hashrate was dropping.
17:21 < MC1984> gmaxwell, i think that just goes to show how ridiculously stinking profitable they were at the beginning
17:22 < adam3us> wonder if that will cause miners to switch off, or bitcoin exchange rate to go up
17:22 < gmaxwell> MC1984: there was a guy who had a chart showing how much money a batch 1 avalon has made, I'm glad he's taken it down.
17:22 < adam3us> (switch off and stop buying more)
17:23 < gmaxwell> adam3us: well, I'm planning on moving my avalons someplace where the power is cheaper.
17:23 < adam3us> see there are two parameters to network hash rate: speed/energy efficiency per unit, and availabiity of units, seems like the asic so far have improved the speed a lot, but the availability is thin
17:24 < gmaxwell> adam3us: availablity has always been ~0 when the profitablity has been high.
17:25 < MC1984> gonna put your boxes into hosting?
17:25 < adam3us> gmaxwell: in theory more availability is good for decentralization (now the litecoin argument) and the counter-argument was sha256 is easy lots of people will make tem
17:26 < adam3us> gmaxwell: not happening that well so far, though i live in hope
17:26 < gmaxwell> it has been happening, but the demand is pretty awesome when the devices are spitting out a ton of coin...
17:26 < MC1984> havent heard a peep out of asicminer for ages though
17:26 < MC1984> i bet they are hiding thier power level
17:30 < gmaxwell> if they're not crazy they've sold their first gen hardware to other suckers^wpeople by now... but who knows.
17:30 < gmaxwell> That whole model was really crappy. I mean, good for them at suckering people to finance them but .. ::shrugs::
17:30 < MC1984> the pie charts says 1%
17:30 < MC1984> and a nice chunk of unknown too
17:31 < MC1984> im actually more pleased that p2pool is holding at 1%
17:31 < MC1984> its not quite oblivion
17:32 < gmaxwell> p2pool is pretty much where its always been. it sagged a bit when the avalons didn't initially work on it..
17:32 < maaku> MC1984: as long as its not decreasing
17:33 < MC1984> i wonder if that more or less represents a percentage of people who give a shit about mining consolidation
17:33 < MC1984> whats the ratio for altruists to stop a system turning to poop?
17:33 < gmaxwell> MC1984: or more like some mixture of that and paranoid about pool op theft,  and who are willing to go through the trouble.
17:34 < MC1984> hm yeah
17:34 < MC1984> its not too much trouble though. i set up a p2pool node once
17:34 < MC1984> i just didnt have anything to mine against it
17:35 < adam3us> why doesnt everyone p2pool?
17:36 < gmaxwell> Some number of people are convinced that all the pool operators are theives... e.g. cypherdoc on the forums.  He claims to solo-mine, though based on his comments I would be a little surprised if it were true.
17:36 < gmaxwell> so you don't have to care about decenteralization to prefer to not use the centeralized pools.
17:36 < MC1984> they could be thieves
17:36 < gmaxwell> they could be, in fact I'm sure some have been.
17:36 < gmaxwell> but you can't tell.
17:37 < MC1984> why so much trust around still
17:37 < maaku> adam3us: it's a hog, you can lose more than the average pool fee on a high-latency connection, variance is super-high, etc.
17:37 < adam3us> help centralization, spread rumors about miners
17:37 < MC1984> some pool ops have been straight guys though
17:37 < adam3us> decentralization i meant
17:37 < midnightmagic> maaku: Mm..  that's not quite true.
17:38 < gmaxwell> For some definition of high, though you also lose pool income on high latency connections too.
17:38 < gmaxwell> though p2pool somewhat more.
17:38 < midnightmagic> adam3us: The statistics as shown make it easier to infer that p2pool is *wasting* mining effort up to 16% or so.
17:38 < gmaxwell> Which isn't the case, but that doesn't stop people from claiming it.
17:38 < maaku> midnightmagic: it's my experience running a p2pool node.. although I haven't synced with forestv's sources in some months
17:39 < gmaxwell> maaku: the time between shares was upped to 30 seconds, which greatly reduced the latency dependance. its still higher, but this isn't entirely bad.
17:39 < maaku> it was much worse under 10s shares (it's now 30s right?)
17:39 < maaku> yeah
17:39 < midnightmagic> adam3us: It requires local knowledge and setup and maintenance of a bitcoind, and a p2pool instance running on either the same machine or another one. I suspect it's mostly just misunderstandings that people don't want to clear up, and the fact that it's got a 15-hour block turnaround time.
17:40 < midnightmagic> there was a spike a few times where the orphan rate just shot right up like crazy with a huge influx of hashrate. I don't know what was going on there. It looked as though someone was trying to mine with smoething big and gave up on it.
17:40 < amiller> i've been thinking about mining and asics and for the moment, equipment costs totally dominate power costs
17:40 < adam3us> as i recall i tried it once and it was like really nothing just just p2pool instead of eligius
17:40 < gmaxwell> P2Pool has roughly 1/10th the orphaning rate of eligius, for example. ... why? beyond the relaying advantages, ... it makes miners fix their latency (or drives away slow miners)
17:41 < adam3us> and my reactin was woah why doesnt everyone do that!
17:41 < amiller> but we alos aren't at the full curve of the chip development cycle, the 65nm chips are coming out now, but once we get to like 20 or whatever intel does, it totally levels off and then there's going to be hardly anymore improvement in hashes per second per dollar-spent-on-chips
17:42 < gmaxwell> adam3us: if you're already running bitcoin-qt / bitcoind  and have a reasonable host.. it's easy.  Otherwise, its actually a lot of work.  People show up in #p2pool  "halp on my atom with drum memory I get 60% effiency!"
17:42 < maaku> lol drum memory
17:42 < gmaxwell> amiller: well, KNC is 28nm but its using structured asic.
17:42 < MC1984> structured?
17:42 < sipa> aka glorified fpga
17:43 < amiller> structured cell arrays are sort of gateway asic, much cheaper than fpga, but still sort of general purpose and less efficient than standard cell array
17:43 < gmaxwell> yea, it's in between a hardcopy fpga and a real asic.
17:43 < MC1984> whats the point of that
17:43 < gmaxwell> lower upfront costs, potentially faster time to market.
17:43 < gmaxwell> The downside is higher marginal costs (per hashrate ... but this is actually really low in any case) and higher power consumption.
17:44 < MC1984> isuppose right now the time to mrket thing makes it worth it
17:45 < MC1984> whats that nifty state about how long it would take current hashrate to recreate the whole chain
17:45 < MC1984> i bet its down to like a week now
17:45 < gmaxwell> Though the power consumption of their stuff is better than the 65nm asics today.  Well, the 55nm bitfurry stuff, which was a careful hand layout is more power efficient than knc.
17:45 < MC1984> its like where there is a huge breakthrough in hashrate security actually decreases for a while
17:46 < gmaxwell> MC1984: you've noticed sipa pointing out that we're down to ~1 month work to replace the chain.
17:46  * jgarzik returns
17:46 < MC1984> yeah a while ago
17:47 < MC1984> do you still keep very close tabs on the asic manufacturers gmaxwell
17:49 < gmaxwell> There is a new chinese company claiming to have parts that are 1.47GH/j on 55nm, parts in hand near release, pretty close to what hashfast and cointerra are claiming to have targeted at 28nm.
17:49 < gmaxwell> ( https://bitcointalk.org/index.php?topic=330665.0 )
17:49 < gmaxwell> MC1984: somewhat.
17:49 < midnightmagic> adam3us: Based on my experience with p2pool, if I pretend everyone is smart, I ask myself the same thing. Why the heck doesn't everyone p2pool. I'd bet if it were included with mainline and "just worked" if people pointed their miners at their bitcoind(-qt) it would probably dominate.
17:50 < MC1984> midnightmagic, true
17:50 < MC1984> i called for that ahwile ago
17:51 < MC1984> the power of default seems to override even rational economic interest a lot of the time
17:51 < midnightmagic> gavin has mentioned (don't know if it's still true these days) that if p2pool were c++'ized he would want to include it in mainline
17:51 < adam3us> do it!
17:51 < MC1984> whats it written in
17:51 < gmaxwell> midnightmagic: there are two things that increased p2pool rate a lot in my expirence: google ads (no kidding), and people paying random bonuses to p2pool users.  And there was two things that decreased its usage, it not working right with the lastest miner of the month, and people posting FUD about it.
17:52 < MC1984> the FUD really pisses me off
17:52 < MC1984> like people are content to post total shit as long as it makes them look like they know something everyone else dont
17:52 < midnightmagic> most of it was corrected with the most-recent versions of p2pool which now operate with the major miners just fine, along with the major devices.
17:53 < midnightmagic> actually, I don't know about jupiters.
17:56 < maaku> MC1984: Python (twisted)
17:57 < gmaxwell> midnightmagic: so far the people complaining about jupiters have so far turned out to people with hosted ones, who also complain about stale rates on other pools. I don't know if people with regular jupiters are all happy or if none have tried.
17:57 < gmaxwell> The firmware and mining software for the jupiters has apparently turned out to be a bug fest.
17:57 < maaku> forrestv (or someone) should apply for money from the foundation to C++'ify it for mainline
17:57 < MC1984> i bet you could do a successful bounty to port it to c++
17:58 < MC1984> i have zero idea how hard that would be mind
17:58 < gmaxwell> it's a decenteralized consensus algorithim... not exactly the easiest stuff to work on.
17:58 < gmaxwell> It also goes further than strictly needed for just decenteralization purposes.
17:58 < maaku> MC1984: it would be a rather large undertaking.. and not necessarily worthwhile. it actually benefits a lot from the Python ecosystem
17:58 < gmaxwell> As I've been promoting, coinbase-only mining lets people keep something closer to the existing model.
17:59 < gmaxwell> And it avoids the need for a decenteralized consensus.
17:59 < midnightmagic> If I were to do it, it would end up as pure C. I'm not sure whether people would appreciate that..
17:59 < midnightmagic> Python is sooooo fast for prototyping.
18:00 < maaku> and for writing concurrent servers
18:00 < midnightmagic> the GIL is pretty annoying to get around tho
18:00 < maaku> eventlet, not multi-threaded is what i generally do
18:04 < maaku> gevent, actually
18:04 < midnightmagic> maaku: Is gevent friendly?
18:04 < maaku> it's pretty much a drop in for threading
18:04 < maaku> monkey patches all the APIs
18:06 < midnightmagic> cool
18:18 < gavinandresen> midnightmagic: I'd love to see a "start mining" button in bitcoin core that did the p2pool thing and knew how to find / talk to asics....
18:19 < gavinandresen> midnightmagic: or, actually, any other withing-an-order-of-magnitude technology for mining (still wondering how power-efficient the SHA256 Intel CPU instructions will be)
18:20 < gavinandresen> (order of magnitude power-efficient, I mean…)
18:25 < MC1984> sha256 acceleration wont be viable because the funciton is actually sha256^2 right
18:25 < maaku> MC1984: it isn't sha256 either
18:25 < maaku> it's a primitive you can use to build efficient sha256
18:25 < maaku> or sha256^2
18:52 < phantomcircuit> maaku, which actually might be better
18:52 < phantomcircuit> although i suspect it'll be the same thing as the AES-IN which are effectively a set and an update function
18:56 < gmaxwell> in intel the SHA256 stuff is just a function that implements two rounds of SHA256.
18:58 < gmaxwell> I think I figured a 3GH/s cpu would be a 50MH/s miner or something, with a guess at the throughput of the round function instruction.  So I don't think this will bring cpus back in the running for mining, though it may make other things we do faster...
18:59 < warren> block propagation?
19:00 < gmaxwell> I don't think hashing is the real barrier in performance there by far... but if everything else gets optimized it may be, so that would help then.
20:40 < midnightmagic> gavinandresen: ah cool
21:17 < amiller> i really like this tweet from matt green https://twitter.com/matthew_d_green/status/399236330581786624
21:17 < amiller> "Every new idea has already been discovered, inaccurately discussed & totally forgotten about on the Bitcoin forums."
21:24 < gmaxwell> amiller: Emin's character attacks on people expressing doubt about their work is exactly as I predicted.
21:33 < MC1984>  @matthew_d_green Every random noise channel will eventually transmit every transmissible message.
21:33 < MC1984> #iceburn
21:47 < amiller> actually, what do you mean by predicted
21:48 < amiller> predicted like based on this guy is, or predicted after first seeing the paper, or predicted about computer science academics looking at bitcoin generlaly
21:54 < gmaxwell> predicted after seeing his initial comments, and his sell pumping on twitter.
21:55 < amiller> yeah, he's such a douche bag and a bad example
21:57 < amiller> everything about it pisses me off, even the random noise comment
21:57 < amiller> there are at least a non-negligible polynomial number of ideas
21:57 < amiller> like 1/n of the user's have at least 1/k of their posts are good ideas
21:58 < amiller> the result is fine and i don't even care so much about the press whoring because frankly it's part of the process and if pr people suck up to university professors they've at least earned it or something, bitcoin companies etc do it too,
21:59 < amiller> i think what i hate most about the paper itself is that the proposed fixes are so dumb and introduce more problems and there's a specific section that's like "they should implement exactly these suggested patches immediately or else face imminent collapse" which is total crap
22:00 < gmaxwell> yea, the proposed fix is obviously pretty dumb.
22:00 < gmaxwell> And bytecoin's analysis was not random noise. He performed a simulation, posted figures. He considered a somewhat different model, indeed and it wasn't developed in the same direction or to the same extent as their work, and their work was interesting beyond it... but this isn't a complete surprise.  Amusingly, the most interesting proposed improvement in response I've seen is from bytecoin.
22:00 < amiller> it would be really sad if this causes other legit researchers just to steer away from the topic, i don't actually think it will have that effect
22:00 < amiller> yeah definitely
22:02 < gmaxwell> also the fact that there is no acknowledgment that they have an implicit incentives model which doesn't appear to be supported by reality is irritating.
22:04 < gmaxwell> e.g. assuming that miners are frictionless spherical objectivsts in simple harmonic motion.
22:06 < amiller> "the obviously desired and hinted-at theory is unsound under some circumstances" is a whole lot different than "this is about to collapse, panic immediately"
22:07 < gmaxwell> claims like "it shows that, even under the best of circumstances (i.e. the attacker has terrible network connectivity, no Sybils, no control over information propagation and loses to the honest miners every single time), defending against the attacker requires at least 2/3rds of the network to be honest"
22:07 < gmaxwell> are just outright untruths.
22:08 < gmaxwell> It's adding an additional assumption that an "honest" miner will behave adversely to bitcoin's long term interest if its more profitable to do so.
22:08 < gmaxwell> Thats not a very good defintion of "honest"
22:09 < amiller> no one is "honest", or else honest miners mine and donate the reward to p2pool
22:10 < amiller> it's a significant result to show that beyond 33% gets disproportionate reward, because other miners would want to join that pool so there's a slope toward larger and larger up to 50
22:10 < amiller> it's not an "attack" its just a lapse in the ideal incentives-keep-everything-okay argument
22:11 < gmaxwell> amiller: Sure but it isn't accurate, not even in the slightest or smallest way, to say that their 2/3rd number is a replacement for the majority number.
22:11 < amiller> well yeah
22:11 < amiller> the 51% number we're used to is 51% honest
22:12 < amiller> hypothetically we can imagine that people also believed that 51% is also the threshold for rational
22:12 < amiller> in that if no coalition controls more than 50%, then there is no way to profit by deviating from the protocol
22:12 < amiller> i think that is a realistic interpretation of what people have believed about bitcoin without stating it as such
22:12 < gmaxwell> yea, thats a stronger claim and there are a bunch of ways thats wrong.
22:13 < gmaxwell> amiller: they may have, they also think things like 1 confirm is safe.
22:13 < gmaxwell> You can find me disputing the claim that you need >50% to cause trouble all over the forum and on
22:13 < gmaxwell> IRC.
22:13 < gmaxwell> (though not on this particular basis)
22:14 < amiller> so they show one compelling way that it's not the case for x>33% and no one would really dispute that
22:14 < amiller> anyone who's bothered to state incentive-compatible as a goal would not have said that
22:14 < amiller> and it's nice of this paper to introduce incentive compatible and make it clear that's the desired goal
22:14 < amiller> so that whole set of ideas is great and is a good result
22:14 < gmaxwell> well, they haven't published their simulation source and are apparently not interested in doing so. so I'm not actually sure about the 33% number, bytecoin got a different figure in his simulation.
22:15 < amiller> maybe they should have shown the positive result that with x<33%, honest mining *is* incentive compatible!
22:15 < gmaxwell> I don't think honest mining is ever incentive compatible, sadly. Not with a wide enough net of possible bad behaviors.
22:15 < amiller> actually kroll davies and felten in their WEIS paper showed precisely that, but for a more restricted set of strategies (they didn't look at block delay, only which block you build on)
22:16 < amiller> yeah and i showed that it's not if there's a sufficiently big enough anomalous tx fee, but that is easy to fix except for coinbase maturity :3
22:16 < amiller> so does their result actually build *more* evidence that honest mining is incentive comaptible under a somewhat wider range of bad behavior?
22:16 < amiller> do you really think it's never the case?
22:17 < amiller> what else does it depend on, like your ability to pull off a double against against some 1-confirmers?
22:17 < gmaxwell> no. I'm just saying, I don't know how useful it is to show these things under restricted behavior. Peoples behavior is not restricted.
22:17 < gmaxwell> amiller: yes, thats one example. Or get paid to censor, as another.
22:18 < amiller> well maybe moving in that direction is the right idea
22:18 < amiller> maybe that's the thing to do is start with incentive compatible under restricted behavior and widen the net?
22:18 < gmaxwell> not just 1-confirmers... at anything under infinite confirms a <50% faction has improved ability to reverse than a smaller <50% faction.
22:19 < amiller> yeah but at some point you're just wasting money for a poor chance
22:19 < amiller> yes an adversary who just *has* a portion of the hash power can keep trying to get a streak-of-7 forever
22:19 < gmaxwell> e.g. the success rate at reversing 15 confirms is higher for a 40% faction than a 20% faction. So that just depends on how big a heist you can pull off. And the size of that depends on how many txn you can put in a block, and how many parties will be exploitable at a number of confirms.
22:20 < amiller> i think that's a game we can win
22:20 < amiller> for some kind of reasonable attack model
22:20 < gmaxwell> amiller: pratically nothing in bitcoin land waits for more than 6 confirms.  https://people.xiph.org/~greg/attack_success.html
22:20 < gmaxwell> 50% success rate for 40% hashpower.
22:21 < amiller> everyone who waits 6 blocks probably should wait longer?
22:21 < amiller> my only question is this
22:21 < gmaxwell> plus you can outsource the actual performing of attacks by just letting other people send their double spends to you directly, and they pay you a high fee and they get included in your attack blocks.
22:21 < amiller> is the overall network harmed by people setting their threshold too low?
22:21 < gmaxwell> yes, I think they are: you saw the ghash.io thread?
22:21 < amiller> it's like living in a neighborhood where no one buys door locks except you, and that attracts lots of criminals, one of those security analogies
22:21 < amiller> yes i saw the ghash.io thread
22:22 < gmaxwell> 25% miner attacking a zero confirm betting service (hurray!)
22:22 < amiller> but afaict that isn't affecting consensus or anyone with larger confirm therhold
22:22 < amiller> then just think of the stupid betting service as part of the 25% attacker
22:22 < amiller> it isn't a money pump exactly
22:23 < gmaxwell> yea but you now have a mining farm created of captive miners who have no control of their mining, which is controlled by people who can perhaps multiplicatively increase their income by playing games.
22:23 < amiller> let them bleed the zeroconfirm gambling thing dry?
22:23 < amiller> then they have to stop?
22:23 < amiller> i mean that's no different than subsidized mining to attract users and then use them for arbitrary double spends
22:23 < gmaxwell> they could profitably exploit the betting service even if they required 6 confirms, in fact.
22:24 < gmaxwell> (because the house rake on that betting service is only like half a percent or something)
22:24 < gmaxwell> though they might not like the variance of that game. :P
23:56 < ebfull> https://bitcointalk.org/index.php?topic=327064.0
23:56 < ebfull> re: this ^
23:56 < ebfull> when blocks are orphaned and their transactions are re-introduced into the mempool
23:56 < ebfull> what are the transactionseconds for those transactions?
--- Log closed Wed Nov 13 00:00:24 2013