01:24:24stqism:stqism is now known as NikolaiToryzin
01:35:40NikolaiToryzin:NikolaiToryzin is now known as NikolaiTalyzin
01:35:53NikolaiTalyzin:NikolaiTalyzin is now known as NikoliaTalyzin
01:36:07NikoliaTalyzin:NikoliaTalyzin is now known as NikolaiToryzin
01:36:36NikolaiToryzin:NikolaiToryzin is now known as YuriGagarin
01:41:00stqism:stqism is now known as YuriGagarin
02:16:54YuriGagarin:YuriGagarin is now known as stqism
02:17:09stqism:stqism is now known as YuriGagarin
05:21:55YuriGagarin:YuriGagarin is now known as stqism
09:58:42fanquake:fanquake has left #bitcoin-wizards
13:13:28stonecoldpat:does anyone know of a bitcoin paper that described a good adversary model?
15:18:55adam3us:gmaxwell: saw something a few days up in scrollback re primecoin not hashcash, yes i agree it seems to be the case. i noted it here https://en.bitcoin.it/wiki/Factual_inaccuracies_in_videos search primecoin
15:19:31adam3us:gmaxwell: "It was incorrectly claimed that Adam Back invented the concept of proof of work. Bitcoin does use Back's hashcash proof-of-work because bitcoin needs specific properties and hashcash is the simplest (and so far only) proof of work with these required properties (primecoin maybe the new exception). But the PoW concept is older, and due to Dwork & Naor in their crypto 1992 paper."
15:20:38vetch:primecoin fails the retirement of being simple to verify, right?
15:21:45tromp_:there are simple primality tests (with tiny prob. of false positive)
15:21:47adam3us:vetch: somewhat. presumably need a bignum library
15:21:58adam3us:tromp_: right.
15:22:18tromp_:much less work than verifying scrypt
15:22:22vetch:but the pines they use are big.
15:22:29tromp_:obviously more than sha256
15:22:32vetch:scrypt at least has small proofs.
15:22:59tromp_:how many bytes is primecoin's proof?
15:23:07adam3us:tromp_: also the dwork & naor PoW have similar properties. the PoW takes more space as the difficulty goes up. (And theirs have more problems, but kudos to them for first-to invent. hashcash was a concept reinvention as i was not aware of their paper)
15:23:29vetch:tromp_: big. I forget how big.
15:24:04adam3us:tromp_: (Dwork & Naor: also all bignum based square-root or weakened instances of sig algorithsm where the work is to forge the sig)
15:25:24adam3us:tromp_: actually i thought about bignum/asym crypto and floating-point and memory etc complexifications to frustrate asic back in 1997, but rejected it all in favor of simplicity. turns out so far correct coincidentally.
15:29:48tromp_:the primecoin whitepaper is short on details. need to study source or blockchain to find proofsize
15:30:34tromp_:it could be variable length in principle
15:36:25tromp_:last blocks' origin was 326 bits, or just over 40 bytes
16:01:11tromp_:adam3us: where can i find technical details of 2-way pegging for sidechains?
16:01:34adam3us:tromp_: post on bitcoin-dev is a summary.
16:01:59adam3us:tromp_: also see replies by others and post by maaku on compact spv proofs
16:03:29adam3us:tromp_: https://soundcloud.com/epicenterbitcoin/eb15-guest-host-joel-hampton offset 53:00 is best high level + arugments, but probably too high level for this readership. by @crainbf
16:03:45adam3us:tromp_: there is also a ton of stuff on reddit for some reason.
16:04:00adam3us:tromp_: search side-chains on reddit.
16:04:06tromp_:i listened to the interview on letstalkbitcoin
16:04:21tromp_:but fond it short on details
16:04:32adam3us:tromp_: brian does a better job :) yes likewise on brians job tho
16:25:13adam3us:gmaxwell: did anyone try to figure out what amincd was trying to say with "idea for enabling BTCbacked aternate cryptocurrencies" some people are referring to that post from reddit threads as "proof of transaction"
16:25:38adam3us:gmaxwell: as if that is somehow different. or does he not have isolation of knowledge of side-chain internals?
16:59:26jgarzik:jgarzik is now known as home_jg
17:26:45diesel_:diesel_ is now known as Dizzle
18:07:10amincd:adam3us: I believe the "idea for enabling BTC-backed alternate cryptocurrencies" proposal has the same core feature as the side-chain proposal your group proposed.
19:53:04jgarzik:jgarzik has left #bitcoin-wizards
20:22:27adam3us:so how much hashrate does bitundo have anyway?
20:26:46Apocalyptic:over 9000 Hashes/sec
20:26:50home_jg:home_jg is now known as jgarzik
20:32:01adam3us:Apocalyptic: oh so about 0.01% chance of undo:) (assuming non-instant cancel)
20:32:24warren:adam3us: isn't the point of it to offer the reward to mining pools to accept those transaction?
20:34:35adam3us:warren: i dunno. do they take a 0-conf fee and add to the tx fee for the undo (pay to self) tx?
20:35:53adam3us:warren: would be funny if u could double-spend the fee u sent to them. or use them to undo it. ha
20:36:24adam3us:warren: they cant hang around wait for confirmation on your undo fee as your tx is in-flight seconds ticking
20:53:25vetch:adam3us: can't say. I was going to use GBT to try and sniff out their blocks but they have disabled it for "privacy"
20:53:29vetch:I doubt much though.
20:56:03gmaxwell:oh awesome, so not only are they adopting a potentially hostile policy but they're hiding what they're mining?
20:56:22gmaxwell:sadly it's hard to come down hard on that because other large pools hide what they're mining.
20:57:45vetch:gmaxwell: well, they offer reversed transactions without broadcasting them. you know. for all the legitimate reasons for that. GBT would ruin the "privacy" of the whole thing.
20:58:05adam3us:gmaxwell: i guess someone (i guess we know someone inclined:) could send small tracer payments to the undo server, and then use hash superiority to orphan its blocks with some reasonable bias
20:58:08jgarzik:gmaxwell, disagree -- come down hard on everyone equally ;p
20:58:39vetch:adam3us: I didn't say I'd given up, I can still attempt to sniff their blocks with stratum and latency
20:58:48gmaxwell:jgarzik: just pratically speaking I mean. "It's all terrible and doom!" is not a call to action.
20:59:10jgarzik:gmaxwell, "list of assholes" 1. ... 2. ...
20:59:34vetch:in that venture i've found that pool servers are incredibly latent. from first block announce to last there's almost 15 seconds sometimes. I expected a lot lower.
20:59:42gmaxwell:vetch: ... Okay, I think you just broke my suspension of disbelief that they're not really trying to enable fraud.
21:00:13gmaxwell:vetch: yea, they are. It's hard to longpoll thousands and thousands of sockets. Some pools prioritize their longpolling by hashrate, and in that comparison you lose.
21:00:46jgarzik:gmaxwell, At a higher level... bullying just really gets my goat. I dislike John Dillon-esque tactics that force immediate responses, without letting the wider community understand and digest whatever is going on.
21:01:10jgarzik:gmaxwell, unfortunately that is The Game That Some People Will Play
21:01:21gmaxwell:Oh I agree. I wasn't really pleased with Mike's response to this thing though.. e.g. saying it makes bitcoin useless and other such hyperbole.
21:01:26vetch:gmaxwell: still pretty to see my 10 odd stratum sockets light up ages before I even see a block on my local or edge node, even if it's not perfect.
21:01:45adam3us:jgarzik: seems a bit scorched earth if u know what i mean
21:01:50jgarzik:+1
21:01:53Apocalyptic: Oh I agree. I wasn't really pleased with Mike's response to this thing though.. e.g. saying it makes bitcoin useless and other such hyperbole. // Hearn ?
21:02:03gmaxwell:Yes. (on reddit)
21:02:06Apocalyptic:...
21:02:35adam3us:jgarzik: there's a phraseology hint in the reuse of that phrase
21:03:12vetch:oh that's nice. bitundo offers a websocket for all of their public "undos".
21:03:41adam3us:gmaxwell jgarzik: so constructively relay double-spends marked as such? does that get 0-conf back approx to its current sort-of-working if most are honest but non consensus enforceable model
21:04:10vetch:and the author is intending on paying wallet developers to include the "undo" button
21:04:31jgarzik:adam3us, I'm still OK with relaying a first dbl spend, though it is worth considering how the payment protocol might change transaction flows
21:04:45adam3us:kind of ugly for SPV clients i guess. they go find out if they received a payment then the find out they didnt
21:05:54adam3us:jgarzik: introduces more revisionism. i guess its not unlike a reorg except reorg tx almost always conf just later. these are like conf -1 once they're gone
21:06:04gmaxwell:adam3us: careful with the sort of working for current, what we have prior to this is more fragile than a lot of people realize. Right now you can doublespend with a very high success rate by simply announcing one spend to a large pool and concurrently announcing the conflict everwhere else. The recieve will very likely never even hear the double spend (until its too late).
21:06:06adam3us:jgarzik: -1-conf i mean vs 0-conf
21:06:38gmaxwell:thats one of the reasons that I think this crap is more noise than substance at the moment.
21:06:42vetch:gmaxwell: or as was brought up earlier, abusing the fact that Eligius doesn't mine blocks with betting site addresses in them. no race needed.
21:06:59adam3us:gmaxwell: yeah no illusions. but seemingly market forces are telling us the bitcoin-internet is still in a friendly era
21:07:15gmaxwell:vetch: you still want to race some in order to prevent the merchant from even hearing the conflict.
21:07:54adam3us:vetch: ? really.
21:08:07vetch:gmaxwell: I thought the implication was that you could send TX to merchant that had their spend plus an output to a betting site, then at your leisure send a conflicting one to Eligius without that output.
21:08:37gmaxwell:vetch: oh point.
21:09:39adam3us:gmaxwell: so would relay of first double-spend marked as such be strictly no worse than current (ignoring even the new intentional abuse of current for undo)
21:10:52gmaxwell:adam3us: I can't say strictly no worse, since it actually enables greedy mining. :)
21:11:06gmaxwell:e.g. you can use the double spend relay to decide thats the one you want to mine. :)
21:11:31adam3us:gmaxwell: oh right. i was thinking also then undo people will send the tx, wait 30sec, then send the undo (whatever time-threshold the merchant waits for double-spend notification)
21:11:42gmaxwell:but I think its an improvement overall assuming that its done in a way that doesn't open up griefing.
21:12:04adam3us:gmaxwell: or i guess just mine the undo, dont send it.
21:12:09gmaxwell:adam3us: lowers their success rate if they do that, which is really what all zero conf security is about... success rates.
21:12:25gmaxwell:and yes, mine it yourself always works but .. again, success rates. :)
21:12:26petertodd:gmaxwell: I'm writing up an app to automate double-spend via min fee differences and accepted-to-mempool differences right now actually, along with another quick one to bump fees
21:12:55petertodd:see: https://blockchain.info/tx/2418f634fa4acd4f18c3b282d39dc5c618180f1a9d1d92a37b9dfda6a77a32f6 vs. https://blockchain.info/tx/2b94de011d24c057b8c41ca52701f7357ff9066d342569ecc03494da624f8827
21:13:43gmaxwell:adam3us: I do think we'll need to make a hard push to stop pools from hiding the block content. However the problem then becomes we don't have an alternative to give them.
21:14:13petertodd:gmaxwell: I can't see that ever working given that not hiding it incurs very real overhead costs, and makes it easier to attack said pools
21:15:14gmaxwell:petertodd: meh, the overhead is pretty minor compared to the self imposed overhead they're all currently taking due to using really low difficulty shares.
21:16:01gmaxwell:e.g. eligius is doing many tbytes a day inbound for shares because they maintain sharerates far far higher than needed to measure miner work with acceptable variance. In fact they actually subset the data for computing payouts. (the tiny shares are just used for graphing)
21:16:04adam3us:gmaxwell: justusranvier was suggesting to have a pproposed block then users sample random tx to add to it (or remove from it) to reduce bw of being a semi-full node
21:16:33petertodd:adam3us: you can't double-spend the fee you send them - the fee is achieved by just having the double-spend tx pay out to an address they control
21:16:57adam3us:petertodd: got it
21:17:12adam3us:petertodd: pity. would've seemed like poetic justice :)
21:17:32petertodd:gmaxwell: users like low diff shares; not having them incurs a cost
21:22:22gmaxwell:petertodd: I did the crunching on eligius data and concluded you needed something like 300mbytes/day of share data to get every user down to 0.5% _daily_ variance.
21:22:52petertodd:and so what? people like their pretty graphs
21:22:59gmaxwell:So sure, users like having low diff shares; users should also like their mining pools not using their hashpower to mine things secretly.
21:24:55petertodd:Why should they care? They earn the same amount of money.
21:24:57gmaxwell:My point was that there are other optional-preferency things that have a much greater cost.
21:25:17gmaxwell:petertodd: no they don't— not if the pool is using the hashpower maliciously (or just outright robbing them)
21:25:42gmaxwell:There have also been several incidents of mining pool hashpower being redirect via address space hijacking recently (though mostly? on altcoins)
21:25:49gmaxwell:redirected*
21:27:10petertodd:So what? If they end up being able to trust the pool for whatever reason - maybe because they're earning enough extra money to pay out for attacks because of their hidden mining, or less infrastructure costs - they come out ahead.
21:27:29petertodd:Secondly, they can't *measure* the cost of those problems very well anyway.
21:28:07gmaxwell:Yes, on the latter, but thats what education is about.
21:28:18gmaxwell:But it also requires having good alternatives to point people to.
21:28:26adam3us:petertodd: seems iike we're sliding into economics 2.0 (what charlie stross called optimally scamming bots that robbed every semi-honest player blind)
21:29:33adam3us:petertodd: or that which can not be cryptographically assured or via balanced mutual distrust is systematically abused to the max by everyne
21:30:04petertodd:adam3us: indeed, that's just the price of anonymous decentralized systems, and if they're otherwise, they're nowhere near as valuable
21:31:43adam3us:petertodd: you know while it wasnt assured to the same extent there was/is a fragile meta-game-theory that 90% of regular users are mutually self-intereste in the system surviving and exhibiting some useful non cryptogaphically assurable best effort propertes
21:32:11petertodd:adam3us: yes, that's a nice fallback. lets keep that in reserve
21:32:12adam3us:petertodd: that equilibrium could be rocked or broken by seeding such a strategy
21:32:58petertodd:indeed, and sadly the equilibrium didn't have to be rocked - we could have easily said a year ago "Core dev team is changing things so we all make more secure systems."
21:33:19adam3us:petertodd: err i dont know it would be that easy to rebuild if it were broken (fallback implies u could get back to the best effort mutual interest equilibrium once broken)
21:34:18petertodd:adam3us: point is we could have shipped bitcoin core with replace-by-fee, and in parallel shown people how to do zeroconf safely - from a social perspective the equilibrium woulkd *not* have been broken. instead it is at risk of being broken because of *how* this is being presented
21:36:10adam3us:petertodd: well the replace by fee that was being discussed (in any seriousness) was constrained to same recipient. so that was not an undo. how do u do 0-conf safely?
21:36:46petertodd:lots of ways - off-chain, micropayment channels, scorched earth, escrow etc. etc.
21:37:08petertodd:when was it ever discussed to same recipient? that's just tx replacement for fee bumping
21:37:56adam3us:petertodd: as i recall that was the form people found acceptable
21:38:11adam3us:petertodd: (yes fee bump) scorched earth = ?
21:38:23petertodd:*some* people, others found even that unacceptable
21:38:58adam3us:petertodd: i dont see why right now, but maybe they had a rationale
21:39:13petertodd:scorched earth = https://bitcointalk.org/index.php?topic=251233.msg2669189#msg2669189
21:48:02adam3us:petertodd: ok that i read in the past. basically a game-theory thing where the cheated victim gives all funds to miners by replace-by-fee with the entire tx value (large fee rule includes not yet confirmed parent-tx)
21:49:15petertodd:yup
21:50:03adam3us:petertodd: if thats the intent maybe you could alterntively make a rule that a miner can jut pre-emptively take any funds if a double-spend exists. or the cryptographic version of that the one-show signature i mentioned before where if u make two sigs the private key is revealed via simul eqn and then the miner can take the coin
21:50:33petertodd:yes, in a soft-fork, in a soft-fork you can do all sorts of crazy shit
21:51:03petertodd:I mean, hell, my first post to bitcoin-development was something along those lines
21:51:12adam3us:petertodd: its very simple and generic, the addr=H(r,Q) and sig=Q,r,s
21:52:00petertodd:again, soft-fork - I'm talking about things we can do now, and even if you *did* do that replace-by-fee still makes sense, never mind the engineering issues surrounding "accidentally double-spend anything at all and you're fucked"
21:53:31adam3us:petertodd: ok fine, so this replace by fee is policy not soft fork. if u accidentlly double spend a merchant might spend your money to miners also.
21:54:27warren:https://blog.goeswhere.com/2010/12/git-set-commit-id/ I'm not sure if this was meant to be a joke.
21:55:04petertodd:adam3us: yeah, just policy, which importantly is also pointing out the limits of defacto policy in a decentralized environment
21:55:32adam3us:petertodd: meaning what? that policy is too powerful?
21:56:19petertodd:adam3us: no, that defacto policy is too weak
21:57:38adam3us:petertodd: but do you mean the current policy is too weak in your opinion or the power of the policy mechanism. you mean the former right?
21:57:59petertodd:the former, as in, depending on defacto policy is dangerous because it's so weak
21:58:18petertodd:warren: lol, that's brilliant
21:58:58adam3us:petertodd: but weak as in what specifically. eg in relation to not supporting replace by fee right no? or more meta point?
22:00:14petertodd:assuming nodes only accept the first seen block is weak because absolutely nothing stops them from doing otherwise. furthermore even slight changes to acceptance policy break "accept first tx" further
22:00:37petertodd:OTOH PoW confirmations are extremely strong because real work had to be done to generate the confirmation
22:02:16adam3us:petertodd: well there is some first seen block defense... due to non-relay of double-spend you dont see them often.
22:02:53petertodd:first seen block defense?
22:03:43adam3us:petertodd: u said "first seen block is weak because absolutely nothing stops them from doing otherwise" i am saying one thing that stops them is they only see one block becaue of this relay policy
22:03:56petertodd:no, first seen *tx* is weak
22:04:34adam3us:petertodd: well i know its weak, they can make lots of probes into the network and hope to collect more profitable ones, but its not completely free nor in protocol
22:04:35petertodd:first seen block is just a rational policy to follow for miners, and not really part of wallet tx security anyway (one confirmation is sitll kinda weak)
22:31:05zzyzx:zzyzx is now known as roidster
22:31:35roidster:roidster is now known as Guest95887
23:27:54jaekwon:Hi all.
23:28:04jaekwon:does anyone know a way to reach David (Joel) ?
23:29:20nsh:i know how to contact a David and/or a Joel, if that helps...
23:29:35jaekwon:heh.
23:29:59jaekwon:No, I need a specific David (Joel).
23:30:04nsh:sucks :(
23:30:18jaekwon:The chief cryptographer of ripple.
23:30:33sipa:mail him?
23:30:59jaekwon:i should yeah.
23:31:02sipa:send a twitter dm
23:31:37jaekwon:mmm i don't really use twitter. do i just "@joelkatz Hi" him ?
23:31:45sipa:no
23:31:51nsh:imagine the linkedin connects you get with "chief cryptographer of ripple" on your bio
23:31:56sipa:this is quite offtopic here
23:37:38jaekwon:for something more on topic… does Ripple's consensus ledger algorithm (the 50%, 60%, 70%, 80% thing) have an actual academic paper with peer reviews to back it up?
23:38:58jaekwon:somebody told me that it was reviewed by some folks at MIT.
23:39:42phantomcircuit:jaekwon, i have never seen a formal review by anybody
23:42:28jaekwon:hmm yeah me neither. i would think that existing research on the asynchronous authenticated byzantine consensus problem would say that you can't get consensus with a fixed number of rounds, but … i don't know for certain.
23:50:45kanzure:somewhat related, but i'm collecting papers somewhat related to byzantine/incentive issues here http://diyhpl.us/~bryan/papers2/incentives/ and of course here http://diyhpl.us/~bryan/papers2/bitcoin/
23:52:25phantomcircuit:jaekwon, they're not actually trying to solve that problem, they cheated and are using central authenticators
23:52:32phantomcircuit:no matter how many times they claim otherwise
23:52:50phantomcircuit:Ripple(tm) is nothing more than an exceptionally complicated bank
23:52:54phantomcircuit:actually
23:53:05phantomcircuit:Ripple(tm) is nothing more than an exceptionally complicated system of issuing and transfering IOUs
23:56:16nsh:(i would suggest there's scope for some minor quibble over just how exceptionally complicated it is in comparison to existing systems of issuing and transferring IOUs)
23:56:32gmaxwell:jaekwon: see also my WTF happened to ripple thread.
23:56:35nsh:(still stupid but)
23:56:55jaekwon:phantoncircuit: perhaps. right now I'm mostly concerned with precisely the consensus ledger part, and whether that can achieve consensus. it's an interesting problem on its own right. For example, this paper: "Another Advantage of Free Choice:
23:56:56jaekwon:Completely Asynchronous Agreement Protocols" says that consensus is possible in a constant number of rounds if the number of byzantine nodes is < sqrt(n)
23:57:04gmaxwell:Opencoin ripple is basically a federated bank. Which is a fine thing. They're not really clear with the public on what their security model is though.
23:57:26nsh:https://bitcointalk.org/index.php?topic=144471.0 (WTF happened to ripple?)
23:57:41jaekwon:kanzure, add "Another Advantage of Free Choice:
23:57:41jaekwon:Completely Asynchronous Agreement Protocols" to the list.
23:58:23kanzure:paperbot: http://dl.acm.org/citation.cfm?id=806707
23:58:26paperbot:http://libgen.org/scimag/get.php?doi=10.1145%2F800221.806707