02:02:00c0rw1n:c0rw1n is now known as c0rw|zZz
02:11:30kanzure:"“How can you make a reliable computer service?” the presenter will ask in an innocent voice before continuing, “It may be difficult if you can’t trust anything and the entire concept of happiness is a lie designed by unseen overlords of endless deceptive power.” The presenter never explicitly says that last part, but everybody understands what’s happening. Making distributed systems reliable is inherently impossible; we ...
02:11:34kanzure:... cling to Byzantine fault tolerance like Charlton Heston clings to his guns, hoping that a series of complex software protocols will somehow protect us from the oncoming storm of furious apes who have somehow learned how to wear pants and maliciously tamper with our network packets."
02:12:00kanzure:"Figure 1: Typical Figure 2 from Byzantine fault paper: Our network protocol"
02:12:13kanzure:"Figure 2: Our new protocol is clearly better."
02:13:04kanzure:"The caption will say something like “Figure 2: Our network protocol.” The caption should really say, “One day, a computer wanted to issue a command to an online service. This simple dream resulted in the generation of 16 gajillion messages. An attacker may try to interfere with the reception of 1/f of these messages. Luckily, 1/f is much less than a gajillion for any reasonable value of f. Thus, at least 15 gajillion messages ...
02:13:10kanzure:... will survive the attacker’s interference. These messages will do things that only Cthulu understands; we are at peace with his dreadful mysteries, and we hope that you feel the same way."
02:15:11kanzure:"Every paper on Byzantine fault tolerance introduces a new kind of data consistency. This new type of consistency will have an ostensibly straightforward yet practically inscrutable name like “leap year triple-writer dirty-mirror asynchronous semiconsistency.” In Section 3.2 (“An Intuitive Overview”), the authors will provide some plainspoken, spiritually appealing arguments about why their system prevents triple-conflicted ...
02:15:17kanzure:... write hazards in the presence of malicious servers and unexpected outbreaks of the bubonic plague. “Intuitively, a malicious server cannot lie to a client because each message is an encrypted, nested, signed, mutually-attested log entry with pointers to other encrypted and nested (but not signed) log entries.”"
02:15:47nsh:(it's probably easier to read from the pdf)
02:17:20kanzure:too bad that this is from 2013
02:20:14gmaxwell:kanzure: I mentioned it here when it was first published I think.
02:20:38kanzure:i wonder if this brand of humor goes over the head of altcoin designers
02:22:36kanzure:definitely needs to be a cryptocurrency version. lots to be said...
02:36:16nsh:* nsh smiles
02:42:24op_null:op_null has left #bitcoin-wizards
03:22:30kyletorpey:kyletorpey has left #bitcoin-wizards
03:32:27petertodd:sipa: I'm already booked to speak at the o'reilly bitcoin conference
03:32:53petertodd:sipa: (re: financial crypto conf)
03:39:39gmaxwell:o'ra is running a bitcoin conference in parallel to FC? :-/
03:40:08kanzure:this is why we invented simultaneous streaming to two conferences at once
03:40:12kanzure:just got to get the schedules aligned for your slot
03:40:48tromp_:not in parallel, it ends jan 18
03:41:15kanzure:if it was in parallel and your speaking schedule was aligned then you could even accept questions over irc from both conferences
03:41:22tromp_:well before fc starts on jan 26
04:23:53amiller:oh i didn't realize fc was that early
04:55:41petertodd:tromp_: I'm talking about this one: http://conferences.oreilly.com/bitcoin-blockchain-2015
04:56:08petertodd:gmaxwell: even worse, they're paying expenses... $2.5k vs. $0 isn't that hard of a decision...
04:56:54petertodd:kanzure: heh, I was supposed to be talking at some virtual conference, on the same day as I'll be in London at a real conference... but I wound up cancelling the former because I got sick and ran out of free time
05:04:55kanzure:"sorry i couldn't make it to your conference, i have sent a giant stick figure instead i hope that's okay"
05:05:30kanzure:stick figure: http://www3.pcmag.com/media/images/343623-double-telepresence-robot.jpg
05:06:13petertodd:kanzure: lol
05:06:14op_null:kanzure: you'd do better to send a life sized cardboard cutout of yourself.
05:08:44petertodd:kanzure: in all honesty I probably could pull it off... but ending up in hospital briefly, followed by talking to a friend whose partner just got diagnosed with likely incurable cancer kinda puts you in a "fuck it, why did I schedule four talks in a week?" mood :/
05:09:47gmaxwell:petertodd: yes, pleae do not kill yourself. Suicide by tour schedule ... most unglamorous way to go.
05:10:27petertodd:gmaxwell: I like to remind people there's nothing glamorous about spending a week in paris... and not once seeing the eiffel tower
05:10:54gmaxwell:I've done that.
05:11:05op_null:there's better things to do than look at the eiffel tower anyway.
05:11:29op_null:if you go to another country for the tourist things you might as well just buy the coffee table book and be done with it.
05:11:35kanzure:which cancer?
05:11:44gmaxwell:I managed to do a work trip through europe for a week where I never managed to see sunlight.
05:11:59petertodd:kanzure: more than one now - why it's likely incurable :(
05:12:30kanzure:one of my favorite things is telling people with incurable brain cancer about directed radiation and ultrasound ablation of deep brain tumors
05:12:30gmaxwell:op_null: AGREED. (it seems no one seems to understand my view that I'd rather read about the touristy stuff than visit it... reading about it so much more efficient and comprehensive)
05:13:06kanzure:"giant brain cyst? no problem! just melt your brain using this fancy apparatus"
05:13:45petertodd:op_null: I've very, very rarely done touristy things, and find them actually something I dislike - just feels weird to me when you're not getting "something done" in a country
05:14:28kanzure:i tried billing for plane time once
05:15:34gmaxwell:I did some zipline tour thing in hawaii which was actually fun, but otherwise? "I can relax when I'm dead"
05:15:59kanzure:pfft, somehow i doubt that. you seem like the type that would be relaxed by a good programming problem. (not the throw a laptop out the window kind)
05:16:12op_null:petertodd: it's not traveling unless you've butchered somebodies language. I held up a supermarket queue once because the shopkeeper made me pronounce the word over and over again until I got it right.
05:16:38gmaxwell:kanzure: well right, the touristy crap is mostly not relaxing to me at all.
05:16:43kanzure:s/window kind/window kind of problem
05:16:57petertodd:gmaxwell: see, for me hiking/caving/etc. are mentally "doing stuff", so they don't feel touristy - but trying to "immerse yourself in culture", fuck off
05:17:20petertodd:gmaxwell: vietnam was really weird for me that way
05:17:26op_null:petertodd: do you count "trying to fit in" in all of that?
05:17:26kanzure:i spent some time in vietnam
05:17:39petertodd:op_null: only if I'm trying to steal something
05:18:13Pasha:Pasha is now known as Cory
05:19:05petertodd:op_null: quite seriously, if you're trying to fit in because of *another* reason you want to be there, that's fine by me, but doing that for it's own sake is weird to me
05:19:42op_null:petertodd: in that case I was hungry and wanted to eat.
05:19:54petertodd:op_null: e.g. when I was in paris last I stayed for some of it by one of amirs squats near the sewage treatment plant - no-one there could speak any english - felt totally normal to me
05:20:12kanzure:petertodd: what would be a good alternative to the current format or structure of txin?
05:21:09petertodd:kanzure: serialization structure or *cryptographic* structure?
05:21:54kanzure:in very generic and vague terms i mean: some data structure suitable for referencing amounts of bitcoin that you want to be spent in some way
05:22:24kanzure:specifically this question came up earlier today (in here) because of me wondering about ways of not relying on merely (txid, vout)
05:22:27kanzure:because txid can change
05:22:33petertodd:kanzure: referencing txin by hash is a really, really, really good idea because it enforces determinism... but beyond that gets really complex
05:22:49lechuga_:i'd prob use a DHT
05:22:51petertodd:kanzure: see, you're talking about signatures, where some applications demand different sigs than others
05:22:55kanzure:txid in txin can change, so that doesn't sound like determinism to me
05:23:00petertodd:lechuga_: DHT gives me great trips too
05:23:02op_null:kanzure: the TX hash ideally won't be able to change soon.
05:23:20op_null:other than if the signer decides to, that is.
05:23:20petertodd:op_null: emphasis on "ideally" - I think that BIP is somewhat misguided
05:23:43petertodd:kanzure: but that's non-deterministic for the wallet - it is fully deterministic for the blockchain, in a sense
05:23:58kanzure:wallet determinism would be nice
05:24:05petertodd:kanzure: like, when you follow transactions back in time, you know *exactly* what data/txs went into proving that txout is real
05:24:24petertodd:kanzure: wallet's aren't consensus critical, so I'm happy for them to lose in favor of the important stuff
05:24:24kanzure:sure, i think preserving that is critical
05:24:47kanzure:right, i am not advocating a regression of consensus critical features
05:25:02kanzure:rather i think it may be possible to pick a method that is even more deterministic than present
05:25:09petertodd:kanzure: the only time tx mutability really matters is a) contracts and b) strings of transactions closely spaced enough for reorgs to matter.
05:25:46op_null:petertodd: and chains of unconfirmed transactions.
05:25:58petertodd:kanzure: the former can use other things, CHECKLOCKTIMEVERIFY/H(prevout.txout.scriptPubKey) hashing and the later can be largely mitigated with things like tx replacement
05:25:58kanzure:that seems to be b
05:26:06petertodd:op_null: which are by definition close enough for reorgs to matter :)
05:26:33op_null:hm? doesn't need a reorg. just needs a mutant to get into the next block to kill the chain.
05:26:59petertodd:op_null: I think you the joke ;)
05:27:11kanzure:presumably one block also counts as not spaced far enough
05:27:25op_null:petertodd: quite possibly
05:27:32petertodd:op_null: my mitigation suggestions work just fine for unconfirmed is the point
05:27:40kanzure:i don't really like the trend of "well if there's a large reorg we're all fucked anyway" thinking
05:27:45kanzure:no, it is definitively better to make good systems
05:28:16petertodd:kanzure: the alternatives to H(txid) are very likely worse for general purpose usage
05:28:16kanzure:you're not the only one to express that opinion of course
05:28:17op_null:well we are. 0.9 nodes can't handle very deep reorgs.
05:28:46petertodd:a deep reorg should damn well break the system from a social point of view, regardless of what it does from a technical point of view
05:29:23kanzure:from a social point of view i don't care if the blockchain changes as long as all of my transactions of interest are in the right spots and my chains aren't totally broken
05:29:31kanzure:and that i am not left waiting for others to sign new mutated transaction chains
05:29:41gmaxwell:things should handle them technically or risk introducing a corner case vulnerability; but yea.. I mean, you can't simply rewrite history and expect things to not be pear shaped as a result.
05:29:51gmaxwell:kanzure: then don't make #@$# malleable transactions?
05:29:56petertodd:kanzure: and if the reorg happened because of a *delibrate* technical decision, miners can easilly ensure tx's don't get broken
05:30:08kanzure:gmaxwell: i thought any transaction can be mutated by anyone?
05:30:10petertodd:kanzure: but if it happens because of an attack, yeah, bitcoin's fucked
05:30:49gmaxwell:kanzure: yes/no. For normal transactions there is only one piece of malleability left to anyone but miners, and BIP62 will close that.
05:30:49op_null:today *most* wallet software doesn't even rebroadcast it's own transactions after a reorganisation, or at all really. pretty sure a deep reorg would break lots of peoples systems.
05:31:05kanzure:gmaxwell: oh, then i will read BIP62.
05:31:14lechuga_:so it's assumed all potential sources are known?
05:31:29petertodd:op_null: yeah, getting txs back into the blockchain after a reorg is dodgy
05:31:51gmaxwell:kanzure: For standard transactions we're reasonably confident.
05:31:52petertodd:op_null: having explicit code that big pools could run to do it in a delibrate way wouldn't be an insane idea
05:32:01op_null:not rebroadcasting ever it a pretty stupid thing though
05:32:23kanzure:gmaxwell: so suppose there is a miner that is mining a reorg for whatever reason. someone else has a transaction they want to mutate. if bip62 is in universal use, can this non-miner send a mutant to the miner?
05:32:53kanzure:*a valid mutant to the miner
05:32:59gmaxwell:kanzure: _what_ mutant?
05:33:00petertodd:op_null: you know, not rebroadcasting probably makes big reorgs *more* likely to result in all previously confirmed txs getting into the chain again
05:33:11kanzure:okay cool
05:33:32petertodd:op_null: there's lots of wallets out there that double-spend accidentally, and with coinjoin we've got lots of mixing happening - any double-spend breaks all subsiquent txs after all
05:33:54op_null:lots of mixing happening where exactly?
05:34:10kanzure:weird how wallets aren't told to watch their own double spends
05:34:13kanzure:isn't that a good way to lose money?
05:34:21petertodd:op_null: coinjoin - darkwallet has auto-mixing now
05:34:25petertodd:kanzure: huh?
05:34:30gmaxwell:There are indeed non-trivial amounts of non-malicious double spends.
05:34:35gmaxwell:kanzure: huh?
05:34:51op_null:petertodd: I didn't think it was in anywhere near common use. I mean the software has huge warnings on the front not to use it at all.
05:34:51kanzure:oh sorry, i was thinking of double spends in the wallet sense, not outputs
05:35:25kanzure:i don't know how obvious it is but i have been in wallet land for a few weeks now :)
05:35:45petertodd:op_null: I'd guess there's mid five figures - maybe even six figures USD - of coins online being automixed on darkwallet right now in a given day
05:36:24petertodd:op_null: pretty reliable actually - haven't ever had a report of anyone losing money from it permanently, though there were a few issues where you needed a manual rescan
05:36:25kanzure:i also wasn't aware of the breakage with 0.9 about reorgs
05:36:41kanzure:so that does significantly entice me to consider any deep reorg to totally break everything
05:36:52op_null:petertodd: weird, didn't know it was that popular.
05:36:55gmaxwell:kanzure: well it won't reorg deeper than 750. It's fixed in 0.10.
05:37:04kanzure:oh. hrm.
05:37:11petertodd:op_null: doesn't take many people to get five figures...
05:37:30petertodd:op_null: probably still has in the realm of 100 regular users or something
05:38:21op_null:petertodd: still wish they hadn't written it in javascript.
05:39:14gmaxwell:op_null: well all software is broken, regardless of the language. :(
05:39:46op_null:in a browser extension though!@?
05:39:46petertodd:op_null: something we agreed on was to do up a CLI-based mixer in python that used bitcoin core as the wallet
05:40:03petertodd:op_null: the old vs debate
05:40:20op_null:no, it's just sloppy.
05:40:22petertodd:op_null: personally I would have written a python library first, followed by a delibrately ugly CLI, followed by...
05:40:53petertodd:op_null: software distribution is fucked, sorry. writing browser extensions is a good way to get to a huge number of people quickly
05:41:09petertodd:again, I wouldn't have done that... but the logic is sound for that team's goal
05:42:51op_null:petertodd: that sort of logic is why we have people fawning over the blockchain.info wallet which has probably lost millions of dollars easily.
05:43:19op_null:there's no "move fast and break things" in cryptography.
05:43:45petertodd:...you're totally missing my point...
05:44:07petertodd:there *is* a move fast and break things, and the *unfortunate* thing is it works great far too often
05:44:16op_null:I know what you're saying.
05:45:10petertodd:darkwallet is interesting because they both did that wrong, and also aren't using a strategy that results in actually moving fast - to do that strategy right they'd have included far fewer features and gotten a v1.0 shipped months ago
05:46:17petertodd:also writing libbitcoin - a rewrite of bitcoin core - was insane
05:50:21lechuga_:but fun i'm sure
05:51:16petertodd:lechuga_: yeah... so I found yet another consensus-critical detail we weren't testing for just the other day... and I figured out how to use it to implement rivests paywords!
05:51:32op_null:why did they even do that?
05:51:42op_null:seems like the dumbest thing they could have done with their time
05:51:57petertodd:(use OP_CODESEPARATOR to control which pre-made signature is valid - because OP_CODESEPARATOR is evaluated, not declaritive, so you can turn it off with OP_IF)
05:52:28petertodd:op_null: amir is a good programmer, but his understanding of consensus politics is shit, as is his understanding of *consesnsus* programming
05:52:32lechuga_:can u share your test case? :)
05:53:41lechuga_:op_null: it's at the very least a remarkable learning exercise
05:53:53op_null:no, no it's not.
05:54:21op_null:you do a learning exercise in the sandbox, you don't build systems working with other people's money on top of it.
05:54:22gmaxwell:op_null: pft be nice. Who are you to define how other people learn? :)
05:54:33gmaxwell:oh that point.
05:54:36gmaxwell:* gmaxwell quiets down
05:55:06petertodd:lechuga_: https://github.com/bitcoin/bitcoin/pull/5421
05:55:54lechuga_:ah sweet
05:56:21petertodd:gmaxwell: fuck yeah, I mean, we need to have standards and shit. You wouldn't want something crazy like, say, some loud-mouthed fine arts grad to start hacking on the core consensus code of a multi-billion financial system would you?
05:56:49petertodd:lechuga_: double-check those test cases 'eh? I'm pretty sure that code was finished...
05:57:22gmaxwell:lechuga_: please feel free to review petertodd's pull req.
05:58:48petertodd:thanks, bbl, got a flight to catch
05:59:06lechuga_:safe travels
06:29:01lclc_bnc:lclc_bnc is now known as lclc
07:37:01wallet421:wallet421 is now known as wallet42
09:05:16kornbluth.freenode.net:topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
09:05:16kornbluth.freenode.net:Users on #bitcoin-wizards: andy-logbot soundx damethos vmatekole Luke-Jr wallet42 koeppelmann fenn webdeli RoboTeddy paveljanik d4de rusty Cory shesek op_null prodatalab_ bit2017 bosma TheSeven bitbumper ryanxcharles super3 atgreen Starduster hashtagg_ luny tdlfbx koshii iambernie nubbins` go1111111 OneFixt mr_burdell hguux_ dgenr8 adlai devrandom Graftec Baz__ tacotime jgarzik davejh69 mkarrer Greed zibbo Emcy_ lnovy nsh_ c0rw|zZz yoleaux btc__ Graet roconnor
09:05:16kornbluth.freenode.net:Users on #bitcoin-wizards: Logicwax Baz___ Transisto gues samson_ warptangent andytoshi pi07r prepost SDCDev ybit Meeh_ starsoccer PaulCape_ DoctorBTC NikolaiToryzin nsh stonecoldpat waxwing btcdrak mappum tromp Guest45626 K1773R ahmed_ artifexd LarsLarsen nuke1989 iddo nanotube dansmith_ kanzure spinza Flyer33 arowser1 SubCreative Anduck null_radix Nightwolf hollandais berndj epscy jaekwon_ Hunger- HaltingState Pan0ram1x jaekwon lclc s1w Eliel_ bobke LaptopZZ isis
09:05:16kornbluth.freenode.net:Users on #bitcoin-wizards: sneak harrigan michagogo gavinandresen JonTitor phantomcircuit sl01 Grishnakh sipa Alanius jbenet HM kumavis Muis azariah4 MRL-Relay fluffypony BlueMatt a5m0 gazab AdrianG gwillen livegnik BananaLotus @ChanServ burcin coutts wizkid057 Dyaheon bbrittain forrestv nickler tromp_ Krellan poggy comboy mmozeiko Taek optimator_ [\\\] Apocalyptic throughnothing petertodd crescendo CryptOprah cfields-away Fistful_of_Coins gmaxwell kinlo so [d__d]
09:05:16kornbluth.freenode.net:Users on #bitcoin-wizards: espes BigBitz otoburb wumpus jaromil helo Keefe Iriez huseby phedny midnightmagic coryfields BrainOverfl0w warren pigeons asoltys gribble smooth amiller danneu catcow TD-Linux ryan-c roasbeef harrow lechuga_
09:13:15dansmith_:dansmith_ is now known as dansmith_btc
09:17:05lclc:lclc is now known as lclc_bnc
09:19:23lclc_bnc:lclc_bnc is now known as lclc
10:00:29Profreid_:Profreid_ is now known as Profreid
14:58:44Meeh_:Meeh_ is now known as Meeh
15:05:35lclc:lclc is now known as lclc_bnc
16:02:22Pan0ram1x:Pan0ram1x is now known as Guest6066
16:19:21kinlo_:kinlo_ is now known as kinlo
16:40:31andytoshi:o.O http://www.theregister.co.uk/2014/12/04/boffins_we_factored_143_no_you_factored_56153/ original paper http://arxiv.org/abs/1411.6758
16:44:46andytoshi:ah, here we go: in the arxiv paper they exploit the fact that the factors differ at only two bits, which ofc will be very unlikely for any non-cherry-picked numbers
16:47:08andytoshi:the math here is super straightforward, it is almost all elementary school arithmetic (well, in base 2), so it's worthwhile to read the paper
16:47:26tacotime:might be a good target for cherry picking if you plan to have a quantum computer before everyone else.
16:48:10andytoshi:a fun candidate for the underhanded crypto contest: try to generate an RSA modulus whose "random factors" differ in very few bits
16:54:59tdlfbx:Hmmm...bitcoin codes that e.g. steal funds would be a fun candidate for that contest...
16:55:25tdlfbx:Darn, submissions closed 2 days ago.
16:58:41nsh:andytoshi, i would be slow to scoff, progress is progress :)
16:58:52nsh:(not suggesting anyone's scoffing, but there's some temptation)
17:00:31andytoshi:nsh: there is a temptation, after all with assumption of such small bit-distances you can solve these classically very quickly :)
17:00:48nsh:well, right
17:00:50andytoshi:they point out you can brute-force it in 2^16 time. but agreed, progress is progress, this is really neat
17:00:54nsh:* nsh nods
17:19:16gmaxwell:andytoshi: that popular press article is ... uhh.
17:21:02hearn:any headline with "boffins" in it gets immediate credibility points with me
17:21:19helo:i hate that word so much
17:21:59hearn:you know what i hate? multi-dimensional state machines with a GUI and lots of things happening in parallel.
17:56:43gmaxwell:sipa: After we get through the 0.10 RC stuff, if you'd like to rebase the schnorr I can start seriously reviewing it.
17:59:53gmaxwell:I wonder if we should implement the threshold ecdsa ... it needs a trusted dealer, so I lost interest in it. ... but indeed it's not worthless.
18:05:52hearn:it'll probably end up being used for specialised tasks that aren't obvious to us at the moment
18:06:08hearn:they've implemented it for bitcoinj and told me they plan to open source the code
18:06:23hearn:so we could just wait and see if anyone does something interesting with it, and then do a native version in libsecp256k1 later
18:07:14amiller:gmaxwell, have you followed steven foldfeders progress on it at all
18:08:34andytoshi:gmaxwell: re the popular press article, yeah, wtf, i posted it before i read the paper and was expecting the paper to be way more opaque and impressive
18:09:38andytoshi:had they not said "the math is beyond us" i'd have read it first :/
18:42:26amiller:is there a place that public discussion about sidechains happens, besides here?
18:42:54amiller:anyway, i have a sidechains question i can see resolved in one of two ways
18:43:35amiller:the question is, what is the recommended behavior on the sidechain in the unfortunate event that there's a revision attack on the sidechain that effectively steals some money from its bitcoin reserve
18:44:32amiller:for example, suppose this is a 1:1 peg chain, and at the moment there are 100 sidecoins and 100 bitcoins in its reserve -- now an attacker somehow exfiltrates (just) 1 of the bitcoin reserves so there are 99 btc in reserve and 100 sidechain coins outstanding
18:45:46amiller:there are two easy policies i can imagine, A) is that sidechains are still redeemed for bitcoins from the reserve at 1:1 rate, except that if 99 of them are exchanged this way, there's someone left at the end who can't exchange his and is stuck with a sidecoin he can't redeem for btc
18:46:51amiller:B) is that the sidechain keeps track of its reserve funds, accounting for not just the 'valid-in-main-fork' withdrawal transactions, but also accounting for the bitcoin chain's view of history which may have processed double spends, and diminishes proportionally
18:47:22tromp_:the KISS principle says A
18:47:24amiller:now as long as there are no further double spends, there are 99 bitcoins in reserve and 100 sidecoins and you can exchange a sidecoin for 99 bitcents
18:47:37amiller:that's subjective these are both pretty simple
18:47:53amiller:let me discharge a few caveats i'm ancitipcaintg quickly before this conversation goes off the rails
18:48:42amiller:- i'm aware that an attacker doesn't just hve to do a *double spend* but could probably take all 100 bitcoin reserves at once, maybe there are ways around that, let me just assume that that kind of attack is somehow limited and it only happens for 1 coin
18:50:39amiller:maybe that was the only caveat i can't think of anything else
18:52:44amiller:the main simplicity advantage of option A is that the sidechain doesn't seem even to need to monitor the bitcoin fund account for this purpose
19:02:54andytoshi:amiller: the concern there is it'd cause a "bank run", it is not a dramatic increase in complexity to do (B)
19:03:45andytoshi:amiller: basically once we have the primitives in place to do things like reorg proofs (which are needed for the peg anyway) it is easy to provide the sidechain with a "proof of theft"
19:05:06amiller:yeah that makes sense
19:05:11kanzure:so some proof-of-theft has to invalidate chains of transactions on the sidechain?
19:05:29amiller:kanzure, if it's the same B) i'm talking about, it wouldn't invalidate anything
19:05:37andytoshi:kanzure: no, it would only change the peg exchange rate
19:05:39amiller:it would simply acknowledge that bitcoin thinks there are now 99 coins, yet there are 100 sidecoins
19:05:47amiller:therefore the new exchange rate is 0.99:1
19:06:13amiller:this ruleset is still 1:1 *as long as there are no huge history revisions* (or false spv proofs that go un-challenged)
19:07:18andytoshi:yup. fwiw there's a ton of design space for limiting this sort of attack (e.g. throttling the peg, increasing the conf times for large transfers, etc)
19:08:00amiller:yup, i meant to allude to those with my caveat :)
19:08:21andytoshi:yes, i caught that, thx for doing so :)
19:09:41andytoshi:so given the caveat (A) might not be as drastic ... after all, there is always some proportion of "lost coins"
19:10:01andytoshi:and if the theft can be throttled to always be less than that, and somehow everyone believes this, maybe there is no bank run
19:12:50zooko:* zooko reads with interest
19:13:46amiller:perhaps it can be a little-bit-of-bank-run and a little-bit-of-dillution
19:14:37andytoshi:mm, gmaxwell had an idea along those lines of temporarily charging withdrawal fees so the "bank runners" end up making up the theft
19:14:55andytoshi:i.e. you are punished for being a panicked pete
19:15:15andytoshi:which would discourage an avalanche effect
19:15:23amiller:that's good
19:16:38gmaxwell:This is actually covered in the paper, I thought. Or am I in draft-space-zone.
19:17:35andytoshi:oh, it is indeed
19:22:11amiller:hrm, yeah you're right, section 4.2 in the paper covers roughly all of these
19:22:15amiller:i don't know why i didn't remember that, sorry!
19:22:25kanzure:huh, why don't non-cryptocurrency-related-bank-runs do withdrawal fees during bank runs?
19:22:30kanzure:*do increased withdrawal fees
19:22:35kanzure:panic penalties, i mean
19:22:41andytoshi:might be illegal
19:22:45gmaxwell:thanks for finding the section number; didn't have the document on this system and on a slow link
19:40:21bramm:Hey everybody
19:40:28amiller:hi bramm
19:40:40bramm:amiller! Just the person I have questions for
19:41:42bramm:amiller, I'm reading through your nonoutsorceable paper and am having trouble figuring out figure 2 (I have trouble with math-style notation)
19:42:06amiller:okay, i can probably hash it out in words here...
19:42:29bramm:There's something about a merkle tree. What do you put into the leaves of the merkle tree?
19:42:51amiller:the leaves of the merkle tree just contain random strings
19:43:44amiller:more accurately, the hash of a random string
19:44:08bramm:Okay, and then you come up with some nonce which picks some number of leaves and then you do... something with them
19:44:28amiller:right the nonce picks some number of leaves, and you *hash them all up*
19:44:37amiller:then you check to see if you win
19:44:51amiller:slightly more complicated than that - you hash up all the leaves/branches that get picked
19:45:44bramm:Okay that I follow, but how is this any different from an ordinary proof of work? Where does the nonoutsourceability come in?
19:46:49amiller:the main difference is that the *destination* of the reward is not committed to when you are doing the work, but instead is bound *after* you find a solution
19:47:23bramm:That I really don't follow
19:47:26amiller:in bitcoin you commit to a coinbase transaction before mining, each attempt only has a chance of winning a block that pays out to that transaction
19:47:49amiller:this is why pools work, you can show that you're doing work that would pay out to the pool operator
19:48:02amiller:(or, in p2pool, to the stack of other peers)
19:48:07amiller:okay so here, ... you don't do that
19:48:25bramm:I'm not following what your construction does. What you're saying sounds impossible to me.
19:48:37amiller:basically the structure of this puzzle is meant to guarantee that if you are doing the mining work, you have the private key
19:48:43amiller:when you are doing work for a pool, you don't have the pool operators private key
19:48:57amiller:you commit to paying out to a public key that *you* don't have the correpsonding key for, and that works fine
19:49:15amiller:here, you commit to the root of a merkle tree which acts as a finite-use-signature scheme,
19:49:30amiller:and to actually do the mining work you have to know (a significant portion of) the private key
19:50:03bramm:Okay, I'm familiar with merkle trees as signature schemes
19:50:33bramm:How is the destination selected/revealed at the end?
19:51:17amiller:it's selected by the miner who finds the solution, and it's shown to the world by creating a signed message with that merkle-tree-key
19:53:02bramm:So you're using the merkle tree twice, once to verify that your mining was successful, and once to reveal/sign the destination?
19:54:00bramm:What's wrong with using a more common signature scheme, where you hash a public key to see if your mining attempt was successful, and then sign it something with it?
19:54:38amiller:if you hash a public key, you might not know the corresponding private key
19:55:03bramm:Oh right, a pool might send you then private key
19:55:07amiller:that means you can do some work while provably waiving your ability to steer the reward at the end
19:58:08bramm:I'm trying to think how this would interact with something like cuckoo
19:58:44amiller:so sirer and eyal came up with this two-phase thing
19:59:04amiller:that combines an ordinary scratch-off puzzle with a nonoutsourceable puzzle
19:59:07amiller:and is sort of best of both
19:59:15bramm:Got a link?
19:59:42amiller:the idea is that you just have two phases
19:59:43amiller:pick a nonce
19:59:54amiller:use the nonce to pick some leaves in this merkle tree as the first phase
20:00:08amiller:when you compute the hash, you don't immediately check to see if it's below a threshold, you use it as a nonce for a second phase
20:00:19amiller:e.g., as the macrononce for cuckoo cycle
20:01:14bramm:Couldn't the first phase be done by the pool and then the second phase farmed out to pool members?
20:01:28amiller:yes, but you have to do this roughly for *each attempt*
20:01:32amiller:so that would require a ton of bandwidth
20:02:05bramm:It would be nice to find something stronger than that
20:02:10amiller:i tried to write it out clearly so that it doesn't seem like this alternative bad scheme that i'm *not* describing, which is where you *first* try to grind out the first phase
20:02:27amiller:and *then*, having first found a phase1 solution, try to grind out a phase2 solution..... its' not that
20:02:52amiller:i don't think it's possible/necessary to find something stronger that, that's pretty goo
20:03:48bramm:I'll need to at least think about how to maximize the amount of bandwidth which needs to be used there
20:04:37amiller:okay so the way i described it is slightly simpler than what i described, and is *the maximized* setting
20:04:46amiller:slightly simpler than what *they* described i mean
20:04:57amiller:what they described there is a sort of difficulty balance parameter between phase 1 and phase 2
20:05:33amiller:that means, sometimes after having made half of an attempt, you can compare it against some weak threshold and figure out that that nonce definintely isn't a winner without having to do the phase 2 step
20:05:36bramm:I don't see any reason to put work difficulty in phase 1
20:05:50sipa:gmaxwell: rebased the schnorr implementation already
20:06:06amiller:bramm, the reason has to do with their motivation for this in the first place,
20:06:26amiller:which is to.... actually i kind of agree i don't know why you'd ever want to do that
20:06:52amiller:well okay the reason is
20:07:10amiller:suppose that one cuckoo attempt is still a lot faster than doing this signature thing
20:07:23bramm:... which it isn't
20:07:28amiller:then you're not really getting the benefit of cuckoo making ram dominate the costs
20:07:33amiller:okay well
20:07:46amiller:keep in mind their expressed motivation was to make existing miner asics compatible with the new scheme
20:07:52amiller:so clearly making one hash attempt is a lot faster than anything else
20:08:00amiller:*if* you buy that motivation,
20:08:12amiller:then the solution is to make the hash attempt the phase1 and the nonoutsourceable signature thing the phase2
20:08:28bramm:Changing the proofs of work in existing Bitcoin is in the list of Things Which Aren't Going To Happen
20:08:52amiller:then to set this phase1 difficulty parameter so that you spend sufficient amount of your time doing the phase 1 work
20:09:02amiller:bramm, yeah yeah yeah that's why we're in -wizards :)
20:09:52amiller:if i had to poll everyone's opinion about whether an idea was politically realizable or not i'd not have nearly as much fun doing research
20:10:03bramm:Also, if you're relying primarily and bandwidth costs killing miners, then a regular public/private key pair will have the same effect
20:10:11sipa:bramm: the purpose of this channel is pretty specifically not about Bitcoin itself
20:10:17amiller:bramm, maybe
20:10:19kanzure:i suspect that a good implementation would have a chance of adoption
20:10:50amiller:bramm, my first version of this just used arbitrary signatures like deterministic ecdsa or rsa
20:10:53sipa:doesn't mean that nothing here might end up in Bitcoin, or can't be intended as a "maybe one day Bitcoin should adopt this", but it's more about research/development than about actual production changes now
20:11:46amiller:bramm, but i wasn't able to prove anything because signatures don't generally guarantee that you can't make a defective private/public keypair that lets you do this kind of outsourcing thing somehow
20:12:18bramm:What do you mean by 'defective'?
20:12:22amiller:now that i use random oracles all my proofs work and no one really seems to feel excited enough to criticize it
20:12:45amiller:with a correctly generated public/private keypair, a signature is a proof of knowledge of the key
20:13:18amiller:however there is definition that guarantees that there is no alternate generation algorithm that gives you a private keypair that can only sign transactions that pay out to a pool
20:13:23gmaxwell:amiller: see the threshold ecdsa paper, it's possible to make delegatable signing with trusted setup...
20:14:37amiller:http://www.cs.princeton.edu/~stevenag/bitcoin_threshold_signatures.pdf this one i think you mean, for the self-containedness of the log transcript here
20:15:27amiller:anyway that's not exactly practical for this...
20:16:17amiller:i don't think there's any actual problem with using ordinary asymmetric crypto and having each scratch off attempt involve a signature
20:16:35bramm:I have a wonderful horrible idea
20:16:46amiller:on the other hand, the merkle tree one might be faster, and that makes it easier to tip the work balance towards cuckoo or whatever
20:16:49amiller:which i think is good
20:17:38bramm:A hash-based digital signature scheme involves selectively revealing some information based on a hash
20:17:39amiller:also its post quantum
20:17:56gmaxwell:bramm: we could call it... a lamport signature.
20:18:33bramm:cuckoo involves selectively revealing a selection of where some edges came from
20:19:16amiller:i guess you're suggesting intertwingling those two steps somehow...
20:19:33bramm:How about if we make each of the leaves of our tree responsible for some of the edges of the cuckoo?
20:20:29kanzure:for-pay remailers http://web.archive.org/web/20130513050640/http://finney.org/~hal/pay_remail.html
20:20:32kanzure:cc andytoshi
20:20:39kanzure:and bram i guess. but bram knows remailers.
20:21:01amiller:bramm, it seems like it would be tedious to work out that there isn't any gaming here or something, but it seems like it would work.... what is the goal you're hoping to get out of this thouhg?
20:21:05bramm:remailers unfortunately don't matter. People don't use email any more.
20:21:10amiller:just fewer steps or something compared to doing one then the other/
20:21:50bramm:amiller, trying to make it so that the amount of bandwidth which is necessary for outsourcing is nuts
20:22:44amiller:bandwidth is expensive and this requires a ton of it, i think you're doing a premature/unnecessary optimization
20:23:07amiller:bramm, i have a bunch of calculations about how this kind of pow scheme affects bandwidth and costs in the permacoin paper http://cs.umd.edu/~amiller/permacoin.pdf
20:23:26kanzure:why remailers 1 http://web.archive.org/web/20120216180743/http://finney.org/~hal/why_rem1.html
20:23:29kanzure:why remailers 2 http://web.archive.org/web/20130513043044/http://finney.org/~hal/why_rem2.html
20:23:39amiller:upshot: roughly at any parameter setting, the cost of bandwidth is through the roof even when you assume you're using like, industrialbulk peering rates
20:24:08bramm:amiller, I don't think my suggestion of mixing has any real downside
20:24:31amiller:bramm, okay fair enough
20:25:13kanzure:"detecting double spending" http://web.archive.org/web/20021106004752/http://www.finney.org/~hal/chcash1.html
20:25:14[Tristan]:[Tristan] is now known as Guest38445
20:26:18amiller:anyway, one way or the other we seem to agree it's plausible to combine cuckoo and nonoutsourceable and thereby get a pow that's hopefully both anti-delegation and anti-asic...
20:26:35bramm:Yeah the main problem is the size of the signatures
20:26:54amiller:why? just because they eat into the blocksize?
20:27:18amiller:40*32 bytes = >1k or so, i guess yeah
20:27:53kanzure:does anyone have a backup of rpow.net?
20:27:54amiller:(the 40 there comes from permacoin parameters which isn't necessarily a safe choice, could be worse)
20:28:28amiller:smaller signatures would be a good reason to want to use d-ecdsa vs hash-based-signature
20:28:30bramm:There are tricks for reducing the size of hash-based signatures which may be applicable
20:29:07amiller:yeah like winternitz compression
20:29:15amiller:i don't think nay of those buy you anything in this setting
20:29:24bramm:I'll have to think about it
20:29:28andytoshi:thx kanzure, unfortunately i don't have any spare cycles to think about high-latency mixers for the forseeable future
20:30:20amiller:actually here's the biggest problem i think with this cuckoo approach
20:30:28amiller:busting pools this way means we need to tolerate faster shares somehow
20:30:39amiller:and good parameters for cuckoo are already starting to require long attempts
20:31:02amiller:like, tens of seconds per attempt or something
20:31:11amiller:that definitely starts to interfere with the costly bandwidth argument
20:31:19bramm:Not sure what you mean. Cuckoo's long attempts are something which needs to be taken into consideration regardless.
20:31:32amiller:i guess that's true
20:31:51bramm:Long attempts are not in and of themselves disastrous because they can be done in parallel. Does create a minimum time between blocks, which might not be a bad thing.
20:32:03amiller:does it affect p2pool
20:32:07amiller:or any other way of lowering variance
20:32:22bramm:probably affects them a lot, I haven't thought it through yet
20:32:34bramm:And anyway, the idea is to fuck their shit up
20:32:38amiller:its one thing to compare it to the interblock time, but lower variance is achieved by having someone find a solution every few seconds or something
20:33:18amiller:yeah yeah but you have to provide low variance somehow, and the only way i know of how, even if pools are busted up, involves having frequent shares
20:33:27bramm:I'm liking this nonoutsourcing thing a lot more now that I know that it obliterates partials, that will really mess up pools something good.
20:34:26amiller:great :D
20:34:38amiller:although, i think pools aren't nearly as scary as hosted mining.
20:34:59bramm:There's another trick where you make there be two levels of mining success - one of which makes a new block and the other of which is a mining success. That can add a lot more rewards.
20:35:10amiller:bramm, yeah definitely
20:35:24amiller:bramm, but... actually i guess that doesn't hurt the progress free thing as much
20:35:51amiller:like if it takes 10 seconds to make an attempt, and several people win "shares" at the same time, they can still get some reward for it maybe
20:36:10bramm:It seems there's a long list of things which can be done to fuck with miners/asics/hosting/pools. No single one of them really fixes the problem, but all of them help a bit. If you're starting from scratch you can pull out all the stops
20:36:42bramm:There's another really neat thing which I'm keeping secret for now
20:36:53amiller:what is it
20:36:58bramm:It's a secret :-)
20:37:02amiller:you can tell us
20:37:05kanzure:the previous arguments about being ignorant in secret didn't work on you?
20:37:13amiller:why would you bother announcing a secret like that
20:37:16amiller:kinda rude!
20:37:39bramm:I've sort of announced it already. I posted about how I've found a more practical proof of sequential work
20:37:50amiller:proof of sequential work?
20:38:09amiller:like this one ?http://www.cs.virginia.edu/~mohammad/files/papers/15%20TimeStamp.pdf
20:38:29amiller:yeah those links coincide :)
20:38:36bramm:Yes, like that one, I figured out an improvement on it and something neat which can be done with it
20:38:55amiller:okay well i'm interested in that
20:39:18amiller:maybe you'll tell me in confidence if it's that big of a trade secret but you don't want to make me feel bad and waste time wondering about what it might be
20:39:46bramm:I'm sorry I mentioned it really, I didn't mean to taunt
20:39:54bramm:Just saying there are lots of things which can be done
20:40:01amiller:do you have a good undersatnding of that paper?
20:40:09amiller:i can't intuitively imagine what the structure of that expander graph thing looks like
20:40:35bramm:amiller, reasonably good, I have a much better intuitive understanding of my improved construction
20:40:41amiller:i get the idea that it's building up a dag of some kind with long paths through it and pretty low width but i can't figure out what it looks like and i haven't implemented the stupid zig zag expander thing
20:40:47bramm:Like, I forgot their construction after figuring out a better one
20:40:52Eliel_:I wonder if pools are actually necessary... I mean, individual miners could easily do optimistic tit for tat between themselves. The valuable thing being lower difficulty shares for blocks that'd pay the cooperating miners if it was a real block.
20:40:59amiller:is the thing that can be done with it also part of the secret?
20:41:06amiller:i'm not going to stay up at night wondering about the improved construction
20:41:49bramm:Yes the thing which can be done with it is the real secret. Although I feel silly talking about it as a secret, it was the first thing I thought of when the structure of bitcoin was explained to me.
20:42:39amiller:okwell i look forward to hearing about it later, you can rest your conscience because i've sort of stopped caring as much already, maybe i just have better discipline than last time this happened :)
20:43:53bramm:not sure what you mean about last time this happened
20:44:22amiller:last time someone told me there was a secret and i was butthurt for a wihle because i really wanted to know what it was
20:45:01amiller:btw i know a secret that you would probably pay like 10btc to know so there
20:46:43bramm:I'm being fairly open about ideas that I have, because in many cases other people have already thought of them, and even if they haven't they can often improve on them. I'm just keeping something particularly clever and particularly well buttoned down so I'm not so worried about screwing it up as a secret for now. All will be revealed in time.
20:48:13bramm:The question of how to have separate, or somewhat separate, mining rewards and block minting when you have a long cycle time like cuckoo is an interesting one
20:48:43bramm:I'm all ears about peoples's suggestions about that one. I've enumerated different approaches and am not particularly sold on any of them.
20:55:11bramm:Like, what's the incentive for including mining rewards for others in a new block? Does it make getting a new block more likely? Does it give a greater reward to the block maker?
20:56:40phantomcircuit:bramm, if you dont reference the actual current tip you increase the risk of an orphan substantially
20:57:40bramm:phantomcircuit, Well yes all successful mining operations have to reference either the most recent of a fairly recent head
20:57:58bramm:Otherwise you aren't really doing anything useful
21:01:03bramm:But there is a question of how long mining rewards which don't create a new block can sit around before being included and rewarded.
21:10:07bramm:I'm surprised that this sort of stuff hasn't been written about extensively already. It seems like a good way to reduce mining pooling is to make rewards more distributed to begin with.
21:13:32kanzure:was there a name for the sometimes-the-reward-is-10x proposal?
21:15:51phantomcircuit:bramm, i dont follow
21:16:08phantomcircuit:mining rewards are when a new block is created
21:19:21bramm:phantomcircuit, If you're making a new protocol from scratch you can make it so that near misses get credit
21:19:44bramm:kanzure, That's the opposite of what I'm suggesting
21:19:53Luke-Jr:bramm: if you're making a new protocol from scratch, then it's off-topic here; see ##altcoin-dev
21:19:55phantomcircuit:ah right
21:20:24kanzure:bramm: i didn't mean to claim it was your idea, or related, whoops
21:20:27phantomcircuit:Luke-Jr, eh i think it's on topic (this stuff easily applies to sidechains)
21:20:37kanzure:keeping secrets is off-topic and hostile
21:21:23Luke-Jr:phantomcircuit: not really if it's "from scratch" (and incompatible with bitcoin's existing financial commitments)
21:21:28bramm:Yeah side-chains can have whatever mining system they want
21:22:14Luke-Jr:I suppose demurrage could be done for this, but that'd be.. ugly
21:23:17Luke-Jr:bramm: sidechains can't just create bitcoins from thin air
21:23:55bramm:sidechains can create sidechain coins all they want and then have some mechanism for deciding how bitcoins get assigned to them
21:25:21bramm:And anyway, I am happy to discuss rejiggering mining rewards as a thing to be done to bitcoin, it's no more implausible than 90% of the other stuff we've been discussing
21:26:39c0rw|zZz_:c0rw|zZz_ is now known as c0rw1n
21:27:45phantomcircuit:Luke-Jr, afaik a sidechain could be implemented using close to arbitrary rules as long as you can generate a compact spv proof which works with whatever the op code does
21:28:21Luke-Jr:phantomcircuit: yeah, but that's just implementation - in the end, the bitcoins it has available are set
21:28:58bramm:phantomcircuit, doesn't even have to strongly justify itself to the main chain directly, just show that it's been consistent about a certain transaction for a while
21:32:36bramm:so anyway, if one were to have a policy of rewarding partials directly in new blocks in bitcoin, how would you incentivize it?
21:33:12bramm:One thing to do is count partials as affecting height
21:33:57bramm:So if you don't reward any partials in your block, it will wind up an orphan
21:36:03kanzure:they would just reward their own partials
21:36:38bramm:The idea is that everybody is incented to reward all partials
21:36:55bramm:although obviously you're more incented to reward your own
21:37:31andytoshi:you should hoard partials, then when a block appears you can copy all the partials from it, add your hoarded ones, then publish a conflict
21:37:40andytoshi:since you will have strictly more partials, if these affect height then you win
21:38:13bramm:andytoshi, There can be a rule that partials must be rewarded in the same or next block
21:38:45gmaxwell:would be the same block in what andytoshi is saying.
21:40:32bramm:Well, there is a potential problem that if partials are counted as part of height you can withhold them for a while and use that to reorg but hopefully by then something else already has greater depth and the height formula is such that it won't work any more
21:41:10bramm:The idea is that partials should be broadcast out to everyone in the same way that transactions are
21:41:42amiller:kanzure, i dunno, i think a phrase like "jackpot" or "high variance reward component" should evoke it pretty unambiguously
21:41:51amiller:"powerball-style bitcoin rewards"
21:42:15bramm:The ways in which partial inclusion can be rewarded are: direct reward amount, increased chances of success, and increased height
21:42:31bramm:I'm not even sure which one of them works best in principle
21:42:42andytoshi:"hopefully by then something else already has greater depth" i described an attack where you take the current greatest depth and create a reorg to a chain with your block with strictly greater depth
21:43:09bramm:andytoshi, I'm not sure what attack you're describing
21:43:35amiller:andytoshi, link?
21:44:01andytoshi:amiller: bramm: my two-line comment above
21:44:12andytoshi:"you should hoard partials..." is the attack
21:44:24andytoshi:because now you've got a situation where "last to publish their block wins"
21:44:27amiller:oh okay i understand
21:45:09bramm:We can have a system where, for example, partials are 1/128 and blocks which don't give rewards to at least 128 partials are treated as orphan. Then everybody posts their partials as if they're transactions, and peers glom up as many partials as they can to meet the threshold
21:45:36andytoshi:then by withholding partials you make it less likely that other miners can get a block
21:45:45andytoshi:so everyone only has their own partials, and that's not progress free
21:46:28bramm:But by hoarding partials you won't get the kickbacks for them when others make new blocks, and they become worthless as soon as a new block is hit
21:47:11bramm:The incentives are highly dependent on exact subtle details of the rules about what counts
21:47:18bramm:As are the potential attacks
21:50:48bramm:If you have less than 50% of the mining capacity then hoarding becomes a net loss
21:50:56bramm:At least in a simple threshold scheme
21:56:34bramm:Hey zooko
22:05:14Dizzle__:Dizzle__ is now known as Dizzle
22:24:15zooko:Hiya bramm!
22:26:07tromp_:hi, guys. what does the 2nd m in bramm stand for?
22:26:25helo:i hope it's muffins
22:26:31kanzure:probably stands for "someone else registered bram"
22:28:40tromp_:then i'd expect bramc. bramm smells of bram moolenaar (vim author)
22:29:04bramm:tromp_, It stands for 'I lost the bram login, along with all ops of any kind for #bittorrent disappearing, because I hadn't logged in in too long'
22:29:17bramm:oh, that didn't occur to me, I should use bramc
22:29:20bramm:bramm is now known as bramc
22:31:40zooko:* zooko reads IRC backlog and laughs
22:36:25bramc:zooko, How is that funny?
22:36:35zooko:I definitely think you should pay amiller 10Kⓑ quick, before it is too late.
22:37:07nsh:* nsh smiles
23:43:42c0rw1n:c0rw1n is now known as c0rw|zZz