--- Log opened Sun Nov 10 00:00:56 2013 16:23 < adam3us> hmm did people see this comment bytecoins thread about selfish-miners: 16:23 < adam3us> HanSolo said "For block-height ties, prefer the block whose locally-observed arrival time is closest to its internal timestamp." 16:23 < adam3us> that seems quite elegant and simple as a way to frustrate racing 16:25 < adam3us> there is a time in the coinbase, and a side effect of selfish withholding is that the time becomes stale; conversely if a selfish miner tries to correct by putting a futuristic time, it may overshoot and have a not-yet valid time 16:36 < Luke-Jr> indeed, I do like that idea 16:37 < Luke-Jr> but I may be biased since BFGMiner is probably the only miner that actually keeps the ntime header accurate :P 16:37 < adam3us> oh i suppose many f he asic miners load up a static coin base and dont want to reload as they have slow start time and lose mining duty cycle by updating time...hmm thats unfortunate 16:46 < adam3us> think thats fundamental or tough luck? 16:46 < adam3us> a small dis-economy of scale for asic miners 16:48 < gmaxwell> Does it really help that much? it still leaves you with the weird incentive that you can keep mining at the current block and replace a later announcement. 16:49 < gmaxwell> er earlier announcement. 16:49 < gmaxwell> e.g. say the earlier announcement wasn't so close (due to latency, whatever, and you have many observation points) 16:49 < gmaxwell> you're better off keeping mining at this block with your time set somewhat forward and then announcing when you'll nail the time. 16:50 < gmaxwell> plus you create huge incentives to slightly skew nodes times... potentially making the whole network britally dependent on ntp for subsecond accuracy. 16:52 < gmaxwell> oh the memory pool idea is interesting! 17:02 < gavinandresen> yes, very interesting… ByteCoin is always worth listening to 17:05 < gavinandresen> If we start relaying all valid chains (not just first one we've seen) then I'm not sure what will happen. There are lots of possible reasonable policies for choosing between two chains of the same height 17:06 < Luke-Jr> adam3us: no, it's mostly a software thing 17:06 < gavinandresen> I could imagine: pick the chain with the most transactions (discourage miners who mine single-transaction blocks). ByteCoin's algorithm. Pick one at random (Eyal/Sirer suggestion). Pick the one you saw first. 17:07 < gavinandresen> My intuition is that decision should be left up to miners, and that it is best if miners are somewhat uncertain what policy or policies other miners are using to decide. 17:07 < Luke-Jr> gavinandresen: might have to write code to fabricate dummy transactions so blocks get priority then.. 17:08 < gmaxwell> Luke-Jr: answered by uncertanty. 17:08 < Luke-Jr> gavinandresen: how about pick the one with the most elevens in the hash? 17:08 < gavinandresen> I know how much engineers LOVE uncertainty…. (not!) 17:08 < gmaxwell> E.g. if the network used most txn than that would be the case, and it would have bad anti-convergence outcomes. If only _some_ miners did, thats another matter. 17:08 < gavinandresen> Oooh! Elevenses! 17:09 < gmaxwell> But I don't think we have enough mining distribution to actually make uncertantly useful... you really only care about the policy of a super majority. 17:09 < Luke-Jr> I suppose realistically, it's a miner-specific policy in the end 17:09 < Luke-Jr> would be nice if there was a way to kick miners who insisted on using "bitcoind defaults" 17:09 < gmaxwell> plus at least today it's very hard to get most miners to adopt non-standard policy. 17:09 < Luke-Jr> force them to make some decisions 17:09 < gavinandresen> gmaxwell: it'd be pretty easy to code up three or four policies and pick one at random in the reference implementation if miner doesn't choose. 17:10 < Luke-Jr> would it be bad to block off getblocktemplate and getwork if the miner didn't set options? 17:10 < gavinandresen> Of course, if there is one we think has the most desirable properties then that could be default 17:10 < gmaxwell> I wish people accepting 1 confirmed transactions didn't seem to be so common now. :( 17:10 < gavinandresen> Forcing miners to choose is something I've been thinking about with respect to minimum acceptable fees/priority, too. 17:10 < gmaxwell> (because this sort of thing will increase the incidence of 1/2 high reorgs) 17:13 < Luke-Jr> gavinandresen: think something like that is simple enough to be merged easily? 17:14 < gavinandresen> something like what? block-tiebreaking logic? The hard bit is relaying orphans… depending on how we do it 17:14 < Luke-Jr> gavinandresen: denying GBT/getwork unless the mining options are explicitly set 17:14 < Luke-Jr> maybe with an error message that suggests random values (within reasonable ranges) as an example 17:15 < gavinandresen> Luke-Jr: I'd vote yes for that, I don't think it would be very controversial, it goes along with the whole "dev team shouldn't make policy decisions" notion 17:16 < gavinandresen> recommendations, yes, decisions, no 17:16 < Luke-Jr> as things stand right now with most pools, any recommendations will be decisions in practice :/ 17:17 < gmaxwell> I don't think any tiebreaking schemes should be offered without simulation results showing they don't produce much more/larger reorgs. We can't get away with offering someone that will cause harm saying that we're not making police, since many people will take the fact that we distributed it as proof that its good. 17:17 < midnightmagic> +1 analyses 17:17 < gmaxwell> also, if we're not able to make a strong recommendation, how are those pools to decide? 17:18 < Luke-Jr> we could recommend ranges 17:18 < gmaxwell> Most of the pool operators know less about how this work then we do collectively. (If nothing else, they are one or two man operations who have a lot more to worry about than their bitcoind) 17:18 < gavinandresen> yup, agreed 17:19 < gmaxwell> Luke-Jr: I suspect that would work okay for some things perhaps not others. 17:19 < gavinandresen> all of this is not high on my personal priority list, so I welcome analyses and simulation and debate 17:19 < gavinandresen> … as long as it doesn't suck up a ton of my time... 17:22 < amiller> i'm pretty opposed to any change in behavior that addresses some particular deviant strategy without any way of showing that it doesn't introduce poor performance against various other possible strategies 17:23 < amiller> i guess the idea is with simulation you can take all conceivable strategies and let them battle it out... 17:24 < adam3us> gmaxwell: yes ntp security is bad, adding dependence on time accuracy also bad; hard to eval anything without simulation - game theory permutations too complex 17:24 < adam3us> gmaxwell: it might not be inherently bad in the sense that if you tried to replace an old block, chances are someone else would extend it in the mean time then you wasted time 17:26 < adam3us> amiller: if nothing else this selfish-miner paper proves this is very complex and hard to exhaustively reason about, so +1 i think its a given, cant make changes eg until litecoin has canaried a well simulated and argued proposal for a year+ 17:26 < amiller> lol. 17:27 < adam3us> amiller: (i mean by fact that seemingly other than bytecoin and maybe petetodd, this >33% strategy existed for years without it registering to everyone there could be a problem) 17:28 < gmaxwell> the problem there is that all coins (other alts, litecoin, even — to some extent— bitcoin) have gone huge spans of time with _known_ eploitable vulnerabilities (e.g. to get a edge at mining) and without people exploiting them. live testing is very useful but doesn't really tell us an attack won't start. 17:28 < adam3us> gmaxwell: but i also was suspicious about the concept of relying on coordinated time, it doesnt really exist in a distributed system, and pretending it does is bad 17:28 < amiller> (i'm pissed i didn't think of it too, while thinking about related anomalously-large-txfee and feather-fork incentive-compatibility problems) 17:30 < adam3us> does bitcoin have some built in sanity check protocol for time 17:31 < gavinandresen> adam3us: yes, although there is a longstanding bug-- see discussions of "timejacking" 17:35 < adam3us> i liked the idea of discouraging blind pooled mining, maybe you could do it with a reward address being a chameleon hash, then the pool can be convinced reward is due, but the miners can selfishly withhold the key winning block and assign it to themselves 17:37 < amiller> adam3us, sounds like my non-outsourceable puzzle? 17:37 < amiller> i don't understand the difference if there's one 17:37 < adam3us> amiller: yes that was elicited the above 17:39 < adam3us> amiller: just suggesting the underlying problem is blind pools, and agreeing with your non-outsource motivation, and suggesting chameleon hash reward address could be an mechanism (i dint see a simple one in the thread)... in that way you can change the reward addr after the fact 17:41 < adam3us> amiller: (btw i was ging to ref the thread which i have open in a tab on other machine, but i couldnt remember if it was you or socrates ah.. you are socrates! that explains) 17:50 < maaku> adam3us: I haven't followed your latest discussions, but I understand it has something to with alternatives to blind signatures, right? 17:50 < maaku> I'm using 1024+ bit RSA blind signatures for CoinJoin 17:50 < maaku> is there a better primitive I could be using? 17:51 < adam3us> maaku: yes there is a schnorr blind sig which can be EC so thats more similar, n fact it can use the same keys and params as ECDSA 17:52 < adam3us> maaku: and if you need to encode a value to the blind sig, brands has an extended version of it i have code (non EC, but DL with openssl): google credlib brands 17:53 < maaku> adam3us: is there sufficient peer review of these schemes? 17:53 < adam3us> maaku: 1024 is weak you need really 3072 rsa to match 256 ec 17:53 < maaku> well, it's not long-term keys 17:53 < maaku> just need to be secure for the duration of the protocol 17:53 < maaku> hours to days max 17:53 < maaku> typically minutes 17:54 < amiller> adam3us, lol, yeah, i'm socrates1024. sock, for short 17:54 < adam3us> maaku: yeah brands phd supervisor was chaum (inventor of blind sigs & ecash) then when brands fell out with him, rivest & shamir or somethign 17:55 < amiller> adam3us, anyway the construction for that approach has the advantage of using exactly SHA2 as the underlying hash, no need for chameleon hash, so that's a benefit to miners, although the zero-knowledge puzzle-stealing option relies on generic zk snark 17:56 < adam3us> amiller: yes i saw zk snakr and thought... hmm complex, unproven, impractical as a starting point (though i know they compile based on existing zk constructs) 17:56 < amiller> it's not unproven... 17:56 < amiller> "GGPR" is the underlying scheme and proof https://usukita.org/sites/default/files/P3_rgennaro_quatradic_span_programs.pdf 17:56 < adam3us> amiller: i mean as in hasn survived 20 years of academic prodding, not in sense of not coming with security proofs, many things with proofs got broken 17:56 < amiller> ok well yeah 17:57 < amiller> fair enough 17:57 < adam3us> amiller: whereas a chameleon hash can be very simple, posted one in gmaxwells' thread which is basically like a schnorr sig, ultra simple 17:57 < adam3us> amiller: conventional simple ECDL & hash assumptions 17:58 < amiller> i'm not sure it's suitable for proof of work 17:58 < amiller> i mean, proof of work relies on much more than collision resistance 17:58 < adam3us> maaku: doesnt privacy rely on the blind sig? 17:58 < amiller> you need like n^th unbounded partial preimage resistance 17:59 < adam3us> amiller: i dont mean as the work hash, just the reward address 17:59 < amiller> i don't think that's sufficient to get the strong work-hiding property 17:59 < adam3us> amiller: put i the coinbase, rewardaddr=CH(addr,x) 17:59 < amiller> in other words you could still embed watermarks in the work and therefore the mining pool could enforce it by requiring a bond to participate 18:01 < adam3us> amiller: yes you do need the mechanism to be ZK basically, so in the chameleon case you need there to be no coercion way for the miner to prove he has disabled the hash malleability 18:02 < maaku> adam3us: no, at least with RSA blind sigs, breaking the key means someone else can impersonate the faciliator 18:02 < maaku> ... i think, i would suggest double-checking that 18:02 < maaku> but the blinding factor should make sure that privacy is preserved 18:03 < adam3us> maaku: yes you are right, its info theoretic privacy 18:03 < adam3us> maaku: but if they factor your key, and its long lived, tey can take your money 18:03 < maaku> well, the key doesn't outputs in this case 18:04 < adam3us> maaku: but are you wanting a single denomination only? chaum blind sig ecash has no denomination 18:04 < maaku> for a mixing coinjoin transaction, there's a pool of same-denomination outputs, and the facilitator generates a key specific to that pool 18:05 < maaku> the participants then blind their outputs, the facilitator signs them, then the participants disconnect, unblind, and reconnect anonymously to broadcast 18:05 < maaku> then the key is thrown away 18:07 < adam3us> maaku: ok; yes just to say if you want multi denomination brands can do it, though i suppose that wont be useful as diff denominations tend to correlate the inputs 18:07 < adam3us> maaku: ok; yeah rsa blind is very simple 18:09 < adam3us> maaku: i suppose rsa keygen is a bit entropy hungry and cpu expensive vs ec schnorr long term keys but otherwise it seems not much point switching 18:13 < adam3us> amiller: have to think about the zk coercion free possibility of chameleon hash for nonoutsourceable puzzle, seems like an interestingly simple mechanism if it could be shown secure 18:14 < maaku> adam3us: I'll probably continue to prototype with RSA (other advantage: implementation is dead simple) 18:14 < maaku> but it's nice to keep tabs on more efficient (space and time) solutions 18:14 < adam3us> maaku: yes exactly, simplicity tends to win 18:14 < amiller> adam3us, it seems like a premature optimization to me but i don't disagree really, i guess i'm personally more interested in seeing if i can get any better economic statement just by assuming we have a coalition-free puzzle 18:15 < maaku> i just wasn't aware there was much concensus on an EC blind signature scheme 18:15 < maaku> it's a primitive we need to have anyway for other uses... 18:17 < adam3us> maaku: yep its there i guess despite its brilliance no one really used brands stuff nor even chaum 18:22 < adam3us> maaku: btw p5 & 6 of this: http://www.di.ens.fr/~pointche/Documents/Slides/1996_asiacrypt.pdf talking about blind sigs mentions chaum and schnorr for backgrond 18:22 < adam3us> maaku: (gives the math on one slide) 18:33 < adam3us> amiller: btw in non-outsourceable puzzle thread you described motivation to prevent a hosted miner (by making it so the hosted miner could steal from the user) however i mean something related but different, discouraging pooled miners from not validating their own blocks (blind mining i mentionend it as) 18:35 < adam3us> amiller: you mention miner proving to the paying cleint that it is working for them, but i guess thats not how people are doing it, presumably they just audit loosely based on knowledge of power and expected return, and that could remain the case with a non-outsourceable puzzle 18:36 < amiller> well it guarantees you'll have no lucky streaks or something like that :/ 18:37 < adam3us> amiller: however users blindly using miners is bad, without validating their own blocks so i was interested in ways to make that (not creating your own coinbase from tx you got yourself) unsafe for the pool 18:37 < amiller> i see 18:37 < adam3us> amiller: yes but thats not a big disincentive 18:38 < amiller> you're right it's unfortunately sort of tricky there 18:38 < adam3us> amiller: its kind of the same thing but in the opposite direction --- Log closed Mon Nov 11 00:00:04 2013