--- Log opened Wed Nov 13 00:00:24 2013
00:01 < ebfull> if it's nil because the node never saw the transaction enter the mempool... then new blocks would have zero incentive to include those transactions because they could be orphaned so easily by a competing miner
00:02 < ebfull> if it does exist, we have to retain a transactionseconds map of arbitrary length to anticipate reorgs
01:32 < midnightmagic> lol. of course they're not interested in publishing their simulator. Why would they be? Fuck science.
01:33 < ebfull> who
01:35 < amiller> ebfull, the ES people with the selfish mining
01:35 < midnightmagic> the "bitcoin is dead unless you fix it with our patch specifically, and choose randomly between two possible forks of the blockchain"
01:35 < ebfull> they made a simulator and are not publishing it
01:35 < ebfull> maybe it sucks as bad as mine ^^
01:36 < ebfull> i actually tried their patch
01:36 < midnightmagic> Yeah, Eyal and Sirer.
01:36 < ebfull> it only slightly dampens the selfish mining attack
01:36 < ebfull> and in fact it makes sybil attacks less necessary
01:37 < midnightmagic> (apologies to channel for foul language.)
01:37 < ebfull> so you not only get the small benefit of the selfish mining attack above 30% or so, but you also don't have to sybil attack the network
01:37 < ebfull> i think they admitted in their paper it raises the threshold to 25% or something
01:37 < ebfull> i don't remember
01:38 < gmaxwell> ebfull: yea that was my immediate observation.
01:38 < gmaxwell> makes an immediate incentive for a large pool to delay their blocks. I generally worry about any scheme that isn't "earliest block first" in terms of the convergence behavior in a real network.
01:39 < ebfull> one thing i want to try to simulate
01:39 < ebfull> is the idea ByteCoin had on the forum
01:40 < ebfull> which was to choose the branch with the most transactions from the mempool (proportional to how long they were in the mempool)
01:40 < ebfull> since the selfish miner won't have as many as the honest miner
01:43 < gmaxwell> I thought that was interesting, but its complicated to consider possible strategies that encourages completely. e.g. will someone announce old transactions that are unattractive to mine but just enough to get into the mempool and mine those to win races?
01:55 < warren> any way to score quality ahead of quantity?
01:56 < gmaxwell> warren: most things like that are bad for convergence.
01:56 < gmaxwell> e.g. letting you continue to mine in competition instead of extending as long as you can produce a block with better quality.
01:57 < warren> Past assumptions about why big pools are not dangerous assumed that miners would realize the damage a bad pool is causing and move to another pool.  The recent huge hashes to the highest bidder makes that seem unlikely.
01:59 < gmaxwell> dunno whos past assumptions those are? not mine.  you miss me cheering about ghash.io attacking, and no one budging? :P (well, not for the attack but that I have a concrete example of what I believed)
02:00 < warren> does ghash own all the hardware that hashes there?
02:02 < gmaxwell> no.
02:03 < gmaxwell> ghash is a semi-public pool, most of its hashrate is owned by the public via cex.io. (which is probably really the same people as ghash.io through some wink and nod) but its all captive.
02:08 < midnightmagic> warren: They did leave deepbit when it was approaching the magic majority a while back.
02:08 < gmaxwell> midnightmagic: not ... quite.
02:08 < gmaxwell> more like deepbit left the miners. :P
02:09 < gmaxwell> (and not approaching, after it was a majority for a fair bit of time)
02:09 < midnightmagic> gmaxwell: Did deepbit kick out a botnet then? Why did its hashrate dip back?
02:09 < gmaxwell> midnightmagic: it was under heavy DDOS for over a week and was unreachable a lot of the time.
02:09 < midnightmagic> hrm..
02:09 < midnightmagic> I wonder if that was btcexpress.
02:13 < warren> gee, if only there were a way to do decentralized mining...
02:14 < gmaxwell> warren: decenteralized denial of service, thats almost like decentralized mining, right?
02:15 < warren> gmaxwell: given the fragility of these nodes ...
02:20 < gmaxwell> hm? pools are pretty hard to attack from a bitcoin perspective.
02:21 < gmaxwell> the dos attacks mostly try to run them out of bandwidth, sometimes try to break their poolserver stuff...
02:22 < gmaxwell> (they don't attack their bitcoin daemons because the attackers can't reach them)
10:10 < adam3us> btw people seemed to prefer hidden tx to committed tx as a descriptive name, but i chose the name originally as it is using a bit-commitment
10:10 < adam3us> (re conversation yesterday with gmaxwell, jtimon, maaku and a few others)
16:20 < gmaxwell> http://www.forbes.com/sites/kashmirhill/2013/11/13/sanitizing-bitcoin-coin-validation/   ... sigh.
16:21 < sipa> as long as they can do their job, our privacy isn't good enough
16:21 < gmaxwell> Right.
16:22 < gmaxwell> Making privacy better will be harder when people have made a business out of undermining it... though perhaps there will be more interest in improving it.
16:22 < sipa> so maybe that does provide a useful service''' making people realize that privacy needs actual work
16:23 < gmaxwell> Indeed. I guess we'll see how the harm— investment in screwing up privacy and promoting that privacy must be removed— balances against the benefit — making people realize that privacy is a problem.
16:46 < adam3us> man what a bad idea
16:47 < adam3us> (coin alidation)
16:48 < gmaxwell> maybe they'll pull a mastercoin next and raise a million dollars to fund their attack on bitcoin's fungibility? :P
16:48 < adam3us> need to figure out some way to compact committed tx without revealing
16:48 < adam3us> msc = moral hazard
16:50 < gmaxwell> Another interesting element to this risk:  If we don't fix the bitcoin ecosystem to make these businesses impossible it becomes more likely that some bitcoin clone which fixes them out of the box (perhaps just using things we could 'easily' deploy) will replace bitcoin.
16:51 < adam3us> gmaxwell: well so far we didnt figure out a fix - if we do i might start to soften my anti-alt stance if it was the only way to do it, but i think i'd go for staging method
16:51 < gmaxwell> adam3us: I think we have adequate fixes already.
16:51 < adam3us> gmaxwell: it seemed for a while there was actual interest in making an all zc alt for example; hal finney thought it was a cool idea
16:52 < gmaxwell> E.g. if all wallets were automatically doing coinjoins and coinswaps then such a business wouldn't be vilable.
16:53 < gmaxwell> you don't have to have perfect anonymity to throughly break that kind of business.
16:53 < adam3us> gmaxwell: yes.  it's clearly an improvement.  but i'd really like to see if anyone can figure out some crypto enforced fungibility
16:54 < gmaxwell> it's hard to even deploy that though, esp with funded attacks on privacy. The nice thing about things that don't change the network is that people can say "well, there is nothing we can do about that".
16:54 < adam3us> gmaxwell: if u could get clients to upgrade, they may work harder on analysis however - its like crap 1st gen security, it engenders an arms race of heavily funded 2nd gen attacks etc (sat tv content scrambler story)
16:55 < adam3us> gmaxwell: true, you are "just" using core features
16:56 < gmaxwell> adam3us: the security provided by coinjoins and coinswaps is not pretextual though. So yea, more powerful analysis weakens user privacy but but even assuming an optimal attacker, they do improve privacy.
16:56 < gmaxwell> a
16:57 < gmaxwell> adam3us: dunno if you played with the ZC codebase a lot... it ... doesn't seem too easy to integrate in a sane way.
16:57 < adam3us> gmaxwell: "hard to even deploy... esp with funded attacks on privacy."
16:57 < adam3us> gmaxwell: meaning? the network needs distribution or the anti-privacy lobby tries to shut it down early?
16:58 < gmaxwell> E.g. Peter Vessenes attacking bitcoin privacy at the conference .. until some folks pulled him aside and pointed out the fungiblity problems.
16:58 < adam3us> gmaxwell: no i didnt look at zc code
16:59 < gmaxwell> adam3us: the problem with changing the network is that you can't (safely) use the changes until some super majority of nodes, including jumpy business participants like mtgox, deploy the changes. There is a coordination problem there, and no real way to ease into it.
16:59 < adam3us> gmaxwell: here's my versoin of what could be done, i think you reache similar tec conclusions: full anon fungibiity, opaque pricvacy (user knows who's paying) rest as now; then you can subpoena recipient
17:00 < adam3us> gmaxwell: yes; maybe staging helps.. then they are bicoins and you can step in and out of them via p2p exchange
17:00 < gmaxwell> The people who see themselves as "working with" regulators can very easily be pushed into a corner where they oppose this stuff. Good luck deploying a soft fork with the foundation opposing it.  So thats why I think at least within bitcoin privacy features can't be driven by the network.
17:00 < adam3us> gmaxwell: if gox doesnt take staging, swap them for bitcoin main coins first
17:02 < adam3us> gmaxwell: mere thought of foundation opposing on political grounds (cringe).  the fork threat may not be enough ebcause of all these bitcoin businesses f the users depend on the businesses more than the biz depends on users
17:03 < gmaxwell> right.
17:04 < adam3us> gmaxwell: ok, but we can play games too; work out minimum required and otherwise useful enabling chnges, wait 6months, start using them
17:04 < gmaxwell> (In general thats why I've been really skeptical about "businesses will run full nodes!" as an argument for long term preservation of the system invariants... historically business interests tend to be very short term, and they haven't done a good job driving good monetary policy in other economicies)
17:04 < adam3us> gmaxwell: eg say coinjoin could work so much better if you had useful change x that also has useful biz value... etc you get it
17:06 < adam3us> gmaxwell: biz cant see past the next quarter, 2yrs if you're lucky; and unfortunately most suits dont much think or care about user/community interests - i mean this stuff could have society level implications if screwed up by a few ignorant/selfish suits
17:08 < adam3us> anyway put your thinking cap on :) this problem must be fixed
17:09 < adam3us> another opportunity btw is the scaling point  if offchain tx are needed, biz will be desperate to use them, devs figure out how to do it, implement it, fix a few ills along the way
17:13 < adam3us> (forbes article)"“We don’t want to be the sheriff of the Bitcoin community. We just want to create an ecosystem of clean addresses.” ... if anyone needs motivation to figure out some crypto fungibility before they defacto royally screw fungibility - what next - deals with miners to block the unclean one?
17:15 < gmaxwell> adam3us: no, step (2) is everyone rushing to pay for subscriptions to their feeds so that they don't accidentally accept an unclean coin and thereby make their own coins unclean.
17:15 < gmaxwell> step (3) is miners block them, saving everyone else the trouble.
17:15 < gmaxwell> :P
17:15 < gmaxwell> (or— even to prevent their fees from being declared dirty)
17:15 < adam3us> they are bitcoin scourge
17:16 < gmaxwell> Well, presumably they haven't thought this through.
17:16 < adam3us> i mean seriously - its  horrendous directin
17:17 < adam3us> outright destructive - 10x worse than satoshi dice.  if anyone knows those devs/tech guys they should reach out
17:18 < gmaxwell> I think I'm a little less shocked than you because I expected this (and we've seen it proposed by newbies enough times…)...
17:18 < adam3us> this is the kind of thing i was taking about fungibility introducing costs into the transactionlayer and pulling it down to the level of status-quo networks, its all wron
17:19 < adam3us> its also architecturally wrong - you need identity agnostic fungibility, and optional certified identity (required or not by the recipient by a peer choice)
17:20 < adam3us> and some transaction encryption really
17:20 < gmaxwell> adam3us: yea. identities are useful and don't require fungibility destruction or public privacy elimination.
17:20 < adam3us> so thats the design requirements in my view; the next challenge is how, its damn har
17:20 < adam3us> precisely
17:22 < adam3us> it maybe necessary to technologically disabuse them of their wrong headedness in the short term.  i mean if their service was used by any bitcin biz or miners at any scale, that could be a serious problem for fungibility
17:25 < gmaxwell> adam3us: more precisely, we can't get privacy measures adopted if there is too much important infrastructure which demands they don't exist.
17:25 < gmaxwell> or says my logs:
17:25 < gmaxwell> 13:47 <gmaxwell> yea, no idea. In any case, I'm glad for anyone to be
17:25 < gmaxwell> working on some of this stuff.  I worry if some of the stronger financial
17:25 < gmaxwell> privacy tools are not im plemented and widely used soon we'll grow too much infrastructure that assumes they don't exist.
17:25 < adam3us> yes, this is why the architecture is wrong - the biz people are making defacto architecture decisions
17:30 < sipa> i wish we had never stopped using pay-to-IP :(
17:31 < gmaxwell> petertodd: so, I realized last week that coinjoin and the replace-by-fee mutually assured destruction have a negative interaction potential.
17:31 < sipa> (and improved it with authenticated rather than replace it with pay-to-pubkeyhash)
17:31 < gmaxwell> petertodd: e.g. you CJ with someone to pay. And then your CJ party doublespends not paying your recipent. Then your recipent freaks the heck out and issues a destructive child...
17:39 < MC1984> the biz people are making defacto architecture decisions
17:40 < MC1984> whoops
17:41 < adam3us> i never got what replace-by-fee MAD was - petertodd wanted to be able to revise fees in case transactions got stuck, ok that has new problems for 0-confirms, then he proposed most things must remain as is, just the fee increase from a new input i presume, but how is that MAD?
17:41 < TD> sipa: what difference would that make?
17:42 < TD> sipa: the transactions are all still public
17:43 < sipa> TD: people would not consider key hashes to be "addresses" or things that hold a balance
17:43 < TD> i see
17:44 < TD> well, addresses became dominant for a reason ...
17:44 < sipa> pay-to-IP was obviously broken
17:45 < TD> in lots of ways
17:45 < sipa> but replacing them by static addresses was the easy way out, and i really wish it would have been replaced by a payment-protocol like system back then
17:46 < TD> it was broken because the person you were wanting to send money to would often be offline
17:46 < TD> that's the reason i remember for not using it, when i first used bitcoin 0.1
17:47 < TD> and you wouldn't know their IP anyway. it wasn't a stable identity whereas an address was
17:47 < sipa> yeah, forcing an intermediary for transactions between end-users isn't the best thing either
17:47 < TD> anyway addresses do have a balance. it's the sum of the unspent outputs with scripts that pay to that key  hash :)
17:47 < sipa> of course they do
17:48 < sipa> but thinking about it that way pretty much immeditately leads to key reuse
17:48 < TD> key re-use happens for technical reasons. i don't think it's so much a conceptual issue for end users
17:48 < sipa> i think it is
17:48 < sipa> people think about it as "their address"
17:49 < sipa> rather than "some key in their wallet"
17:49 < adam3us> TD: its a complex concept that your address is authorized to move a tx out and not the balance on the address
17:49 < TD> mostly it doesn't matter
17:49 < sipa> i think it does
17:49 < TD> once the payment protocol is more widely implemented we just need a pastebin type site
17:50 < TD> and then people can have "pay.to/sipa" as their ID instead. all the site has to do is pop a payreq off a queue and serve it
17:50 < sipa> right, and it can work with deterministic wallets
17:50 < TD> minimal infra required, should be a competitive marketplace
17:50 < TD> yeah
17:50 < sipa> that's still forcing an intermediary, but indeed, i think it's a nice solution
17:50 < sipa> it's still simple enough to run your own if you want to
17:51 < sipa> the only question is to what extent the payment protocol will take off, now that people are already trained to think of base58 strings as wallets :)
17:51 < adam3us> sipa: it would be nicer if the sender randomized the recipients address, and encrypted the randomization factor for their public key, as you could do that even ffrom  astatic web site, email, newspaper qr
17:51 < sipa> adam3us: yup
17:51 < adam3us> sipa: however its more costly to scan for
17:52 < sipa> it means you need to be told about incoming payments
17:52 < sipa> and imho, that's a good thing, but very different from how things work now
17:52 < adam3us> removes need for chaincode, counter, address pool
17:52 < sipa> it's still a privacy problem: everyone can see your transactions
17:53 < adam3us> maybe there's a way to do a bloom filter on it
17:53 < adam3us> sipa: no cos its encrypted
17:53 < sipa> oh right
17:53 < TD> or the wallet app can just upload a bunch of files
17:53 < TD> simple > complicated
17:53 < adam3us> sipa:  i mean a variant of bip 38 where Q'=xG+q and E(x) for recipient
17:53 < sipa> adam3us: yeah, i think ByteCode came up with something like that a long time ago
17:53 < sipa> *ByteCoin
17:53 < sipa> loi
17:54 < adam3us> sipa: yes gmaxwell mentioned that we were talking about it yday
17:54 < gmaxwell> 13:22 < gmaxwell> I know, bytecoin proposed exactly that a long time ago.
17:54 < gmaxwell> 13:28 < gmaxwell> adam3us: also, your scheme requires the recieve have an online decryption key to identify their own transactions. (so did bytecoins)
17:54 < adam3us> the missing thing is an efficient privacy preserving way to ask a full node to give you transactions
17:54 < gmaxwell> 13: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)
17:54 < gmaxwell> 13:32 < adam3us> gmaxwell: yes bytecoins seems similar and similar side effects.
17:55 < adam3us> (right, thanks for putting that backlog in for context!)
17:56 < adam3us> TD: well having to upload etc s complicated, if the crypto could be made to behave it could be very simple, and more convenient at user level & integrator level (no chain code, address pool, counter state to track etc)
17:56 < gmaxwell> (mostly I just continue to be amused by the apparent IRC substutuablity of Sipa and I.)
17:56 < adam3us> the missing thing is an efficient privacy preserving way to ask a full node to give you transactions
17:57 < TD> uploading is simple. you already have to calculate a big pile of keys for lookahead with deterministic wallets. uploading to some pastebin service is like, 100 lines of code
17:57 < TD> it's a for loop
17:57 < TD> i mean i love fancy crypto but sometimes, it might be overkill
17:57 < adam3us> sure, but my newspaper article cant do that
17:57 < adam3us> or the qr code in the shop window etc
17:57 < TD> your newspaper article says, visit,    pay.to/adam3us
17:57 < TD> ditto for the qrcode
17:58 < sipa> i think it's nice to have a mechanism that forces you to tell someone about the transaction
17:58 < gmaxwell> TD: and I am pay.to and I haz all the coins. :P
17:58 < sipa> as it means you can attach metadata to the transaction
17:58 < adam3us> TD: hmm boring ;)
17:58 < adam3us> sipa: it would be good to be able to send thing sto peers p2p
17:58 < adam3us> without full broadcast
17:59 < adam3us> sipa: maybe that couldve been the next step with auth
17:59 < sipa> you're reinventing pay-to-IP :D
17:59 < adam3us> sipa: yes but store and forward i mean with some redundancy, but not full; p2p email delivery
18:01 < adam3us> so cant one do attach some bloom bait to the outside of the encrypted/randomized addr to tag it up so you can ask an untrusted full node to give you your not directly linkable encrypted payent?
18:01 < midnightmagic> Sounds like Tor.
18:01 < adam3us> midnightmagic: no just to get a msg if the payer and the recipient are not online simultaneously
18:02 < midnightmagic> Hrm. Freenet then?
18:02 < gmaxwell> adam3us: in any case, another downside of the addition scheme is that its ecdsa centric. It doesn't work so well if your preferred payment script doesn't fit in a very narrow box, which is unfortunate.
18:02 < midnightmagic> I2PBote is an interesting anonymous mail mechanism in i2p-land.
18:03 < adam3us> midnightmagic: though bitcoin could do with some minimal tor like multi-hop tunneled link encryption - it can be dangerous to accept big bitcoins to geolocatable ip, people are logging ips looking out for this stuff
18:04 < adam3us> gmaxwell: yes its quite DL centric
18:04 < adam3us> gmaxwell: and actually you need the public key, which you do not currently have, just H(Q)
18:05 < midnightmagic> adam3us: I've taken to sendraw'ing all my txn through a tor-only node. b.i is blocked from my nodes, but dark many-connect siblings obviously aren't.
18:05 < gmaxwell> adam3us: yes, it requires another kind of address. but it would anyways, to indicate willingness.
18:05 < gmaxwell> adam3us: and perhaps key lifetime (do not use after x)
18:05 < gmaxwell> midnightmagic: it would be nice to get a list of those things.
18:05 < midnightmagic> gmaxwell: I agree!
18:06 < gmaxwell> midnightmagic: I've moved away from having ipv4 listeners or I'd offer to correlate with you.
18:06 < adam3us> midnightmagic: that was what i was referring to the dark-many connectors
18:06 < midnightmagic> hrm. IPv6 listeners. I'd forgotten about that as an option.
18:07 < gmaxwell> midnightmagic: my nodes are all either onion only or v4 outbound only + onion now.
18:08 < gmaxwell> I guess I need to fix that... annoying, I don't have stable v4 connectivity except at home and really don't want a public node running on that address.
18:08 < adam3us> oh BlueMatt mentioned that TD and/or gmaxwell had discussed a possibility for a multi-user extended variant of microtransacton channels
18:08 < adam3us> TD, gmaxwell: do tell - i thought that a potentially useful construct towards offchain
18:10 < TD> just making it work for the two party case is complicated enough, really
18:11 < gmaxwell> adam3us: there was a response on these lines in the coinswap thread.  Coinswap and the micropayment stuff are highly related protocols.
18:11 < adam3us> gmaxwell: yes that occurred to me also (that they seem very related)
18:12 < adam3us> ok so you or someone commented on this topic on that thread... i'll look
18:13 < gmaxwell> In general once you go beyond two parties in one of these interlocked protocols it becomes really tricky to implement, just from a pure software engineering perspective.
18:14 < adam3us> (still very irritated by the wanton destructiveness of the forbes article "coin validation" company - sabotaging the hard won bitcoin fungibility which is a large and core part of its value)
18:18 < gmaxwell> adam3us: so, I did have another idea related to the bloombait.
18:19 < gmaxwell> adam3us: you make the bloombait small. So that when your lite client fetches a block it can just get a map of bait to index for all transactions with acceptable cost.
18:21 < adam3us> gmaxwell: yes that makes sense
18:22 < gmaxwell> adam3us: then you define an error correcting code that every node can code the block with, this logically expands the blocks.  Now your client knows which indexes it needs for its transactions, and it can query N unrelated nodes for fractions of the block to retrive the txn its interested in. With appropiate scheme the servers learn nothing about which transactions you're fetching if non-colluding.
18:22 < gmaxwell> (I guess thats "information theoretic private information retrieval")
18:23 < adam3us> gmaxwell: yes.  there are also some computational versions with lower overhead, and even single db pir (though that one is not cheap)
18:23 < gmaxwell> lower communications overhead.
18:23 < gmaxwell> But not computational overhead.
18:24 < adam3us> gmaxwell: in fact yes
18:24 < adam3us> gmaxwell: (i mean i agree)
18:25 < gmaxwell> the computational ones use things like homorphic encryption and they're very slow on the server, which I think takes them out of the realm of viablitity. Vs the information theoretical constructions can just be done with xor, and can be stupidly fast. Though they'd have overhead on the order of the number of servers you need to be secure against colluding.
18:26 < gmaxwell> in other words, I think the information theoretic one is actually at least theoretically deployable in bitcoinland... which I think the single server ones not so much, at least not unless we can figure out how to pay a server to filter for you. If only we had digital cash. :P
18:30 < adam3us> gmaxwell: its not really clear what the bloombait could be as its sent by the spender in the clear, must produce something from a  predictable set or offloadably encrypted searcheable; any one can see the address and compute the bloombait set and infer who it is to
18:31 < gmaxwell> adam3us: well the point of the bait is that there would be lots of collisions but few enough to reduce the data sent to an acceptable amount.
18:31 < adam3us> friend of mine thought up a homomorphic equality test base on weil pairing years ago, but that only incues n^2 overhead vs on for scan for someone fishing for info which is not a convincing security argument
18:31 < gmaxwell> You don't have to have encrypted matching for the bait.
18:31 < gmaxwell> If the bate is small you just send the whole bait to index map.
18:32 < gmaxwell> Then the user does a PIR queries to get the indexes they want.
18:32 < adam3us> yeah
18:32 < gmaxwell> Other fun thing: you put the SPV proofs for the transaction in with the transactions, which will thus prove the query results were of the right database. :)
18:33 < adam3us> that makes sense eg hash public key 8 times with counter 1.. 10 pick 8 lsb, pick on eof those at random
18:35 < gmaxwell> adam3us: though its interesting that the PIR could be done block at a time... might actually be feasable to do single server PIR for a wallet... at least as a commercial offering. Dunno if it would get any customers though.
18:37 < adam3us> bandwidth is high for the client also, but yes thats probably effiicient enough with  some GPUs
18:39 < adam3us> gmaxwell: hmm yeah not working out too well so far, so TD's pragmatic view is winning still (i am not overl prone to pragmatism - getting the right communication matters in architecture even if you have to work hard to achieve it)
18:41 < gmaxwell> well single server can be low bandwidth, there are computational pir which have just small constant overhead (wtf?!), but they aren't fast. .. uh .. though there be dragons: I've never seen an implementation of any of these leading edge schemes, and sometimes the theoreticians are misleading. ... in any case, it would perhaps be interesting in the mobile context, where communication is costly and the server has a lot of computation ...
18:41 < gmaxwell> ... potentially.
18:43 < petertodd> gmaxwell: replace-by-fee scorched earth doesn't necessarily work unless the sending tx is of minimum size anyway unfortunately
22:50 < amiller> i broke and subsequently fixed my non-outsourceable puzzle.
22:50 < amiller> the solution, remarkably, involves hash-based signatures :)
22:55 < gmaxwell> amiller: does it result of your choice of two things to sign? if so, I came up with that too and it doesn't work because you can be forced to make the other one jibberish. :P
22:56 < amiller> nope
22:56 < amiller> the problem is just that i need a deterministic public key signature and those are expensive in pinocchio
22:56 < amiller> i could make the pow signatures under RSA for example
22:57 < amiller> or BLS if you want to use elliptic curves
22:57 < amiller> basically i want to have a default-option where an ordinary non-outsourcing user can just prove that work is valid without having to do a zk trick
22:57 < amiller> but it does have to avoid revealing the actual seret
22:57 < amiller> any public key signature would suffice here
23:01 < amiller> the problem with my scheme before is that i said the cheap option is the user just actually reveals the secret, but then anyone that sees that can do the zero-knowledge trick later so that's bad
23:01 < amiller> a race condition at best
23:02 < amiller> so any public key is sufficient, but then for the zero knowledge option the outsource server has to be able to relatively efficiently do a zk proof and that's a bitch with any actual publickey primitive
23:02 < amiller> but you can build a merkle tree just out of pretty simple hashes (ajtai lattice hashes in particular, would be efficient)
23:03 < gmaxwell> amiller: I suggest you go post someplace right now about your method for doing a determinstic signature that would be cheap under pinocchio. :P and which one you'd propose.
23:04 < amiller> you mean besides right here
23:07 < gmaxwell> so with your anti outsourcing.. say some miner manages a run of 6 consecutive blocks... can he not produce infinite variations on them and only later commit to them with more blocks? ... so really should we be counting zk blocks the same in security?
23:08 < amiller> you should add 1+ of security to the zk blocks
23:08 < amiller> they don't stack
23:08 < amiller> in other words suppose a miner connects to every single node
23:08 < amiller> finds a winning solution
23:09 < amiller> and gives each node a distinct winning block
23:09 < amiller> now every miner is working on n different forks of length 1, but as soon as one of them wins it, they are committing to a *single* one of those forks
23:09 < amiller> and everyone that builds on it is picking one
23:09 < gmaxwell> unless they zk that one too.
23:09 < amiller> the zk block does *not* hide the previous block it attaches to
23:10 < amiller> that's committed and can't be changed
23:11 < gmaxwell> gotcha. yea, hm. have to be careful that there are no free bits that can be used as marking.
23:13 < amiller> the previous blockhash is literally the only thing not hidden in the zk
23:16 < gmaxwell> being able to retime your blocks is interesting... :P
23:16 < gmaxwell> like ... my block is always 2 hours in the future. oh its a minute later? I've got a new block for you.
23:20 < amiller> i guess :p
23:20 < gmaxwell> I hate that all these ideas have so many angles you have to reason about to be sure you haven't created @#$@#ed up incentives.
--- Log closed Thu Nov 14 00:00:35 2013