00:56:46NewLiberty:NewLiberty is now known as NewLiberty-afk
01:08:38atgreen:jgarzik: awesome - thanks for merging
01:35:49phantomcircuit:gmaxwell, https://www.reddit.com/r/Bitcoin/comments/2qpdnc/gregory_maxwell_how_i_went_from_bitcoin_skeptic/cn896ly
01:36:46sipa:i believe he already saw it :p
01:39:45sipa:ah, the specific comment
01:39:52phantomcircuit:yeah
01:41:29rusty:Wow, I didn't know gmaxwell was the one who published those papers. Sweet...
01:43:55rusty:maaku: with your non-genesis target, did you want to exactly hit the target block, or is <= target block good enough?
01:46:25belcher:waxwing is in this chan, probably asleep though
02:03:24op_mul:rusty: I keep suffering from the opposite issue. I see something and go to suggest gmaxwell read it, only to realise that he was the author in the first place.
02:03:36rusty:op_mul: :)
02:06:27fanquake:I suffer from seeing op_mul and straight away thinking you gmaxwell
02:07:16op_mul:people have made assumptions to that end before, and seeing me as Satoshi too.
02:08:24fanquake:I think it’s me confusing op_mul and op_null
02:08:40op_mul:same person. op_mul is just funnier.
02:09:07fanquake:now I’m really confused
02:09:27op_mul:hold on. there's a picture which explains everything.
02:10:15moa:schizophrenia can be useful for maintaining multiple Nyms successfully
02:12:40op_mul:fanquake: I've been foiled by a person who doesn't know how to use git. anyhow, the nym was a reference to Andreas M. Antonopoulos publishing a book which told people to use OP_MUL in an example. being disabled it's a totally silly thing to do.
02:12:44adlai:for the N+1th time, schizophrenia a) is not dissociative identity disorder, and b) is kindof a madeup catchall for a bunch of conditions that nobody understands, except for maybe the people who suffer from them
02:13:21adlai:* adlai knows it was a joke but w/e. call it a "trigger", since that's the word all the cool kids use
02:13:35moa:ooops, di d I mean multiple personality disorder?
02:13:43adlai:probably :)
02:14:07adlai:right now they call it DID, although these things get new names every decade
02:15:06adlai:schizophrenia encompasses such a wide variety of conditions that it's about as precise a term as "insanity"
02:15:53op_mul:one could say it's become a generic term like "idiot" or "moron", which originally had very specific definitions.
02:16:39adlai:around these parts, it's practically synonymous with "homeless person", which is quite charming of the idiots using it that way
02:18:11sipa:"i used to suffer from multiple personality disorder, but we're okay now"
02:18:23op_mul:I imagine you'd like the dutch a lot. hard to find much profanity in dutch which isn't a disease or medical condition.
02:19:10op_mul:it's special type of language where you'll happily wish leprosy or the plague on another person.
02:20:03sipa:hmm, i've never known those used as curses in dutch :)
02:20:22sipa:(i'm flemish, and especially profanity differs a lot with dutch, but still...)
02:20:24adlai:well just yesterday i heard this dismissal of a disliked person's financial success: "may he spend it all on medical treatments"
02:21:02fanquake:op_mul heh I see.
02:21:36sipa:i do know that dutch people sometimes call eachother 'cancer'
02:21:49op_mul:fanquake: it didn't make it into the print version, though the bit where it tells people to make output scripts that don't contain signatures at all :(
02:22:35adlai:what's this?
02:23:01fanquake:op_mul Maybe It’s better that I don’t read that.
02:23:08op_mul:sipa: yes, that's one. you can tell someone to go get cancer.
02:23:18adlai:oh. this is in "Mastering Bitcoin"?
02:23:22op_mul:adlai: yes.
02:23:53adlai:glad i didn't order it yet!
02:24:05op_mul:please don't encourage it at all.
02:24:33op_mul:it's a terrible book that teaches all which wizards despise.
02:24:35adlai:i was planning on glancing through the github before doing so, but i guess that trouble has been saved.
02:26:10adlai:this reddit thread is full of people who haven't read the sidechains paper!
02:26:47jgarzik:atgreen, thanks for contributing
02:27:11jgarzik:atgreen, I had to disable the gdb build in the contrib script, as it was dying due to -Werror + warnings
02:30:16op_mul:"A common misconception about bitcoin transactions is that they must be "confirmed" by waiting 10 minutes for a new block, or up to 60 minutes for a full six confirmations."
02:30:43sipa:'must' depends on for what purpose
02:32:32op_mul:I think it's dangerou for anybody to make that assumption. it's free for anybody to make attempts at double spending against a merchant. in a lot of ways it would be nicer if the wallets attempted it by default.
02:36:26adlai:for most merchants (of the "brick and mortar" variety), fraud is far more easily accomplished by just walking out without paying
02:38:03op_mul:that would be a nice altcoin. the security model is just "nobody will bother attacking us". has instant confirmations!
02:38:26sipa:it's called credit cards?
02:38:53adlai:visacoin? americoin? mastercoin!
02:39:19op_mul:I feel you've somewhat missed the point.
02:44:42adlai:how are double spend attempts free? they might not cost bitcoin, but they identify you as a bad actor. whether that's by having your face on CCTV, or getting your IP address blacklisted, it's not free. of course, merchants who can't afford even a low level of fraud should adopt an appropriate confirmations policy, but the ubiquity of credit cards suggests that a low level of fraud is actually worth
02:44:45adlai:the convenience it extends to honest actors.
02:45:35op_mul:you think credit cards have a low level of fraud? :)
02:46:12adlai:compared to what?
02:48:13op_mul:why does Mastering Bitcoin say that most software feeds output from a RNG into SHA256 to make a private key. it's making it sound like asking for 32 bytes is just too hard.
02:48:42adlai:all i'm saying (which isn't much) is that there are certain situations where accepting unconfirmed transactions is a rational decision. nothing about how common those situations are compared to ones where you'd want confirmations.
02:48:43op_mul:adlai: to itself, really. if the fraud level was 10% I would say that's pretty high, for example.
02:49:56adlai:hey, at least he didn't say that private keys are made by the user picking 32 secret bytes of their choosing
02:51:09op_mul:still an odd thing to say, I don't know where he would have got that idea from.
03:14:14jgarzik:atgreen, hum. this gdb code executes a synchronous read(fd,buf,255) on a socket... is that correct?
03:14:30atgreen:* atgreen checks
03:15:14atgreen:correct
03:15:41jgarzik:atgreen, gdb always sends 255 bytes?
03:16:25jgarzik:atgreen, that code will hang if not
03:17:49atgreen:no, it doesn't always send 255 bytes. but it works - so let me think about this.
03:22:05atgreen:jgarzik: ok.. read() on sockets behaves like recv()
03:22:35atgreen:and recv() man page says: The receive calls normally return any data available, up to the requested amount, rather than waiting for receipt of the full amount requested.
03:22:36atgreen:
03:22:56atgreen:so that explains why it works.
06:07:04Pan0ram1x:Pan0ram1x is now known as Guest38034
06:34:03maaku:rusty: i want to exactly hit the target
06:34:33maaku:the goal is to prove connectivity, so it's important to actually hit the target
06:46:02merkle:what made vitalik contribute to storj? http://storj.io/storj.pdf ;)
06:48:03maaku:merkle: ask vitalik
06:49:24merkle:he maaky what do you think of factum?
06:49:34merkle:maaku*
06:50:12maaku:haven't looked at it
06:53:54op_mul:"Although the Bitcoin Core client includes a Type-0 wallet, using this wallet is discouraged by developers of Bitcoin Core."
07:02:15merkle:hmm shawn is a very smart guy, creating a metacoin on top of several blockchains
07:05:49op_mul:* op_mul facepalms
07:06:37op_mul:this book has an example which makes private keys with python's mersenne twister RNG
07:15:09gwillen:op_mul: o_O
07:15:19gwillen:does Andreas' bullshit know no bounds
07:15:23op_mul:hello 53 bit complexity private keys.
07:15:57gwillen:op_mul: that whole section about wallets seems to be full of "and this is referred to as "
07:15:59op_mul:probably less than that. I pulled 53 bit out of my head.
07:16:03gwillen:unless I'm just behind on my lingo
07:16:31op_mul:no you're not, he made up the term "encumbered" for output scripts.
07:19:36op_mul:yeah. 53 bit is wrong, that's relating to something else. the big red warning on python.org about it though. not cryptographically secure.
07:33:19gmaxwell:op_mul: I assume by "type 0" it means a normal randomly keyed wallet? we absolutely do not discourage that. (If anything I'd say we discourage the overuse of public derrivation.)
07:33:34op_mul:gmaxwell: yep.
07:34:16gmaxwell:It would take a 20 minute hack to make bitcoin core use one of the BIP32 modes in a rather dull way (e.g. just replace the random key generation with the BIP32 code and a counter). We have all the code for BIP32 internally.
07:36:13op_mul:I became less comfortable with HD wallets when I realised that backup safety for HD wallets is insanely sensitive. the nice thing about a non HD wallet is that over time a compromised backup becomes worthless.
07:36:42maaku:op_mul: you mean over time backups become worthless
07:37:05op_mul:yes.
07:37:33gmaxwell:op_mul: neighter extream is good. What you want is actual key management.
07:37:49gmaxwell:neither*
07:37:53maaku:so assuming you actually want a backup, you'll need to keep it current. and the risk of theft remains the same
07:38:32gmaxwell:maaku: the distinction is that old backups do not present the same risk of theft. e.g. that computer on the closet you haven used for three years that your wife gives away at a yard sale.
07:39:46gmaxwell:What you ideally want is a controlled risk, where only the backups you specifcally care about are a security concern, and not the older ones... all happening in an orderly, intentional way.
07:39:52adlai:isn't this rather fundamental, though? any backup which is useful to you is just as useful to a thief [who knows what to do with it]
07:40:33gmaxwell:adlai: Not so, a backup you've lost or has left your control is not at all useful to you. And a backup the theif doesn't have is not useful to the theif.
07:40:54maaku:* maaku makes a mental note to give the wife clear instructions about the computers in the closet when I get home
07:41:01adlai:well, I mean the contents of the backup itself
07:41:04gmaxwell:I don't mean that trivially. If you're making regular backups on a rotation you're most likely to still have control of the most recent one.
07:41:19op_mul:I guess you could see a non HD wallet as forward security.
07:41:49gmaxwell:op_mul: you could have a forward secure HD wallet. E.g. rotating out the roots according to your key management schedule.
07:42:14op_mul:* op_mul nods
07:42:37rusty:maaku: hmm, OK. Obviously that's overkill for SPV for header syncing, but I I guess there are other uses...
07:43:56maaku:rusty: sidechains
07:44:02gmaxwell:Really snazzy backup management would let you create a new backup and it would keep track of them, and let you selectively invalidate past ones.
07:44:55maaku:rusty: you need to be able to prove to one chain the inclusion or non-inclusion of a transaction in the most-work chain
07:45:06maaku:*of a transaction in a different chain
07:46:02rusty:maaku: and you don't want to trace back more than one input, so you need a proof since then.
07:47:21op_mul:"While you can deposit funds into a paper wallet several times, you should withdraw all funds only once, spending everything. This is because in the process of unlocking and spending funds you expose the private key and because some wallets may generate a change address if you spend less than the whole amount." what on earth
07:47:56maaku:rusty: hrrm not sure what you're trying to say. at one stage you need a proof of connectivity to genesis, at the other stage you need to be able to show a reorg by demonstrating that block at height #x has changed
07:48:37maaku:other slightly different constructions have different proof requirements, e.g. proving connectivity to the point where funds originally transferred in
07:48:38rusty:maaku: well, that's slightly different. You just need proof-to-anything-in-previous-proof.
07:49:05maaku:rusty: not anything, you definately need to establish whether block #x changed or not
07:50:01maaku:since if the hash changed, the conservative assumption that there was a double-spend comes into play and the protocol needs to be restarted
07:51:10rusty:maaku: ah, so you need a proof of Y which includes block X'?
07:52:31maaku:right, which is what we're calling a 'reorg proof'. it shows that block X, which you care about for whatever reason, is no longer in the most-work chain
07:53:11maaku:because the proof demonstrates more work than you previously knew about, and shows connectivity to a block at the same height as X, which has a different hash than X
07:53:36rusty:maaku: eg. the original from-sidechain uses proof Genesis->A->B->X->(X+N) and prove the from-sidechain TX in X. Then the reorg proof has to prove from Genesis, A or B -> X' -> (X'+N+1), right?
07:54:40maaku:right
07:55:45maaku:aside, since N is specified by the protocol you could optimize for that length proof, but I'd rather not go down that path. there are infinitely many sidechain protocols which involve proving arbitrary historical data from another chain
07:57:02rusty:maaku: OK. So, I'm testing the incremental approach, using that (almost) optimal incremental path approach. It works pretty well in the to-genesis case, and it's *simple*. I need to measure how it works in this case (and my previous non-genesis target simulations were flawed).
08:00:26phantomcircuit:op_mul, the paper wallet thing actually makes sense, before you spend the funds the public key is a secret
08:00:50op_mul:phantomcircuit: "you expose the private key"
08:01:19phantomcircuit:im going to give him the benefit of the doubt here (which he doesn't deserve, but well why not)
08:01:21rusty:op_mul: well, you have to enter it onto some machine somewhere, I guess....
08:01:34midnightmagic:op_mul: are you torturing yourself by reading crazy peoples' writings again?
08:01:51phantomcircuit:rusty, presumably that machine is secure, since if it wasn't then you just lost control of the coins anyways :P
08:02:03op_mul:midnightmagic: you know I have little to no self control.
08:02:28rusty:phantomcircuit: if you trusted your machines, you wouldn't need a paper backup :)
08:02:58op_mul:rusty: if you want to be like that, you might as well harp on the fact that it was made in JavaScript.
08:03:05midnightmagic:don't let it eat you up eh
08:03:22op_mul:oh I'm not, tears of laughter.
08:04:00midnightmagic::)
08:06:22op_mul:the best bit (sorry for the OT) is these two quotes juxtaposed. the first is from the book on the topic of RNGs, the second is from the CPP manual on a function used by the book to make private keys.
08:06:38op_mul:"Do not write your own code to create a random number or use a "simple" random number generator offered by your programming language."
08:06:51op_mul:"It is the library implementation's selection of a generator that provides at least acceptable engine behavior for relatively casual, inexpert, and/or lightweight use."
08:33:18op_mul:"he main bitcoin network, running the bitcoin P2P protocol, consists of between 7,000 to 10,000 nodes running various versions of the bitcoin reference client"
08:34:08gmaxwell:There are a lot more nodes than that, that count is just the IPv4 reachable ones.
08:34:32gmaxwell:probably closer to 80,000 though precise counting isn't possible.
08:35:08adlai:how'd you make that estimate?
08:35:13op_mul:that's close to my estimate based on the number of incoming peers on my nodes.
08:35:39gmaxwell:adlai: average number of connections per listening node, times the number of listening nodes, divided by the out degree of a node.
08:36:01phantomcircuit:adlai, ~6500 public nodes, averaging ~100 connections each, (100/8) * 6400 ~= 80-90k
08:37:49adlai:is that a typo or intentionally 6500 - 100 ?
08:38:32gmaxwell:I was just using 8k nodes * 80 connections / 8 = 80k because it made the math thoughtless.
08:39:10phantomcircuit:heh
08:39:25phantomcircuit:adlai, it's all esitmates
08:39:26adlai:why do you divide by the out degree? are we counting connections?
08:39:32phantomcircuit:yes
08:39:33adlai:* adlai tries deriving this formula to understand it
08:39:47op_mul:nodes make 8 outgoing connections always.
08:40:18gmaxwell:adlai: if there are 8000 nodes, and each has 80 incoming connections there are 640000 incoming connections in total.
08:40:35gmaxwell:Each node that exists (regardless of it accepting inbound connections or not) makes 8 outgoing connections.
08:40:45gmaxwell:so there should be 640000 / 8 nodes in total.
08:40:59phantomcircuit:gmaxwell, well and actually there's a bunch of node types which make < 8 connections
08:41:01phantomcircuit:ie spv clients
08:41:12op_mul:ugh, what SPV clients do that.
08:41:18gmaxwell:yea, bitcoinj make 4 connections normally.
08:41:18phantomcircuit:so there's very likely 2-3x what we're calculating
08:41:36gmaxwell:You can just exclude them from the count, thats part of why I used 80. :)
08:41:53op_mul:max-connections=999999999999 for total security and instant transactions!
08:41:56gmaxwell:but this is pretty approximate, we don't know the average connection count (though we can look at single nodes and assume they're representative)
08:42:15op_mul:I haven't looked of late, but mine average around 60.
08:42:16adlai:makes sense, thanks for helping me there. so you could improve your estimate by estimating the breakdown of node types, knowing how many connections each type makes.
08:42:59gmaxwell:adlai: right, well I think the result is mostly bitcoinj == 4; others == 8 ... plus some noise from some crazy people who have run hacked up things to connect to many more which should be elimaitated by ignoring peers that are connecting to many things.
08:43:17gmaxwell:op_mul: yea, thats a bit hard to measure because it depends on how many nodes share your /16.
08:43:31gmaxwell:if you're in some residential broadband segment where there are a dozen other nodes, you're going to get fewer connections.
08:43:39op_mul:good point.
08:43:41adlai:* adlai feels a little silly now for having told an interested but cautious friend last night that there were only about 7k copies of the blockchain
08:44:15gmaxwell:adlai: yea, there are more than that. Though who knows how reliable any of those are. Many of them could be corrupted etc.
08:44:45adlai:well, SPV clients shouldn't count as full blockchain copies, but there could easily be plenty of full nodes that just aren't publicly listening.
08:44:49gmaxwell:it's shocking how unreliable random people's computers are. We see constant reports of machines that corrupt their block data in #bitcoin and #p2pool
08:44:57adlai:could easily be / are
08:46:27op_mul:gmaxwell: I guess we are the first people doing massive redundant computing with a way of detecting it
08:47:50gmaxwell:yea, I'd probably give a hard lower bound on the number of complete and correct copies of the blockchain in existance at 10k and an upper bound probably about 200k.
08:48:35gmaxwell:and with perhaps 90% of my confidence between 60 and 100k.
08:49:02op_mul:... 60?
08:49:12op_mul:I must have 10 good copies just sitting around in my house.
08:49:22op_mul:oh 60 thousand.
08:49:32op_mul:* op_mul hides from the shame
08:49:49adlai:five core developers + satoshi, 10 copies per house!
08:51:00gmaxwell:op_mul: I expect most of those copies are not current.
08:52:18gmaxwell:I have 4 complete copies, plus who knows many out of date ones ones. I have three more machines synching the block chain right now... doing repeated resync tests of 0.10.
08:54:38op_mul:you're right. my nodes all have pruned copies, my minnowboard max has one full copy and the odroid has another. rest of the copies would be stale to some extent.
08:55:30midnightmagic:i have 5 complete copied in various states; along with a handful more nodes out scattered around the continent
08:56:14midnightmagic:(various states being "this one was alive to hear those orphans, and that one didn't")
08:56:22op_mul:(I highly suggest the minnowboard max if you ever need more toys)
08:57:13op_mul:wonder if there's any cope of the block chain that has been running since 2009.
08:57:22gmaxwell:oh neat: http://www.amazon.com/Seagate-ST8000AS0002-20PK-ARCHIVE-128MB-3-5IN/dp/B00QPMRIFM nearline storage cost now down to. $33.25/TB.
08:57:28adlai:has there been any thought on using a proof-of-retrievability (the one I read about is Permacoin) to ensure that the network maintains >N complete blockchains?
08:57:48adlai:(so that pruning can be a default behavior)
08:57:50op_mul:adlai: that's harder than it sounds due to the sybil problem.
08:58:12op_mul:a node can just fetch a block from a peer if you try to use that as proof.
08:58:32gmaxwell:adlai: doesn't seem very interesting in general. The Permacoin approach is vulnerable to the CSPRNG attack too which is a bit unfortunate but might not matter for what you want.
08:59:02gmaxwell:and just requiring a miner to have the blocks doesn't mean he'll actually tell anyone else about them.
08:59:11gmaxwell:(other than what he must leak in his proofs)
08:59:13maaku:gmaxwell: what am I looking at? I see "1 new from $5,320.00"
08:59:26gmaxwell:maaku: 20 8TB hard drives.
08:59:32maaku:ah
08:59:45gmaxwell:maaku: in other words $266 each in Q20.
08:59:53op_mul:gmaxwell: if you want to buy that, you have too much toy money.
09:00:01maaku:nice
09:00:16maaku:op_mul: eh, i'm scrounging together a 24-disk nas
09:00:20gmaxwell:op_mul: well they're just out, I expect they'll be on newegg for $10 more in q1 in a couple weeks.
09:00:33midnightmagic:i'd be leery of homogeneous drives after that 12-drive failure I had
09:00:44maaku:if you want to buy that you're probably a hoarder :P
09:01:03op_mul:gmaxwell: wouldn't this be a lot more fun for the dollar? http://www.minnowboard.org/meet-minnowboard-max/
09:01:47gmaxwell:op_mul: I dunno, navspark looked a lot of fun per dollar.
09:02:07op_mul:gmaxwell: true. do you own a box of them yet?
09:02:15gmaxwell:probably the most fun per dollar electronics is a $0.01 RGB LED.
09:03:11gmaxwell:op_mul: no, not yet, they were not generally purchasable for a while when I wanted to buy one. I'm hoping to hear from you that you figured out how to get all the toolchain for them setup so you could just tell me and I don't have to worry about that.
09:03:20op_mul:gmaxwell: I invented a new bit of kit with the navspark actually. you know warw alking for wifi? I gave geiger war walking a go. results were predictably boring. all down in the noise floor.
09:03:53phantomcircuit:gmaxwell, are those 8TB hdds? o.o
09:04:05gmaxwell:phantomcircuit: _yes_
09:04:06maaku:* maaku sets out to build a $83k 4k resolution led tv
09:04:21gmaxwell:maaku: lol
09:05:00gmaxwell:op_mul: oh wow, thats a really neat idea. The problem is your integration time will be too low. You need to put it on a stick you can stick in the ground and leave for a day at a time to collect data.
09:05:15wilhelm.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:15wilhelm.freenode.net:Users on #bitcoin-wizards: andy-logbot hashtagg_ siraj d1ggy CoinMuncher null_radix tacotime op_mul merkle Elio19 bsm1175321 Guest38034 coiner catlasshrugged rusty shesek SubCreative otoburb Starduster c0rw1n hashtagg Emcy LarsLarsen pi07r epscy nuke1989 koshii dgenr8 everettForth optimator_ Greed Dyaheon Tjopper1 lclc sl01 nsh todaystomorrow HarusameNyanko digitalmagus8 spinza harrow gmaxwell gavinandresen NikolaiToryzin waxwing go1111111 atgreen Cory copumpkin isis
09:05:15wilhelm.freenode.net:Users on #bitcoin-wizards: e1782d11df4c9914 adlai samson_ grandmaster2 iddo Luke-Jr s1w gnusha jaekwon sadgit brand0 mortale eric roasbeef mr_burdell hktud0 Krellan HaltingState fanquake luny berndj jgarzik @ChanServ jaromil jbenet poggy_ petertodd Apocalyptic Meeh tromp__ PaulCapestany tromp DougieBot5000 helo v3Rve midnightmagic espes__ Iriez fluffypony hollandais thrasher` butters nickler Logicwax lnovy ahmed_ warren fenn jchp mkarrer phantomcircuit Graet morcos
09:05:15wilhelm.freenode.net:Users on #bitcoin-wizards: [\\\] michagogo mappum Muis kanzure gribble MRL-Relay maaku wizkid057 Graftec bobke huseby [d__d] BananaLotus amiller artifexd kumavis coryfields BigBitz coutts BlueMatt cfields Anduck Eliel nanotube hguux_ AdrianG gwillen CryptOprah btc__ wumpus stonecoldpat dansmith_btc toddf heath bbrittain DoctorBTC EasyAt starsoccer danneu catcow TD-Linux ryan-c smooth mmozeiko Alanius JonTitor asoltys_ K1773R a5m0 comboy btcdrak Nightwolf pigeons
09:05:15wilhelm.freenode.net:Users on #bitcoin-wizards: andytoshi lechuga_ warptangent Fistful_of_Coins HM2 Guest38445 kinlo azariah yoleaux sneak harrigan sipa livegnik burcin Taek throughnothing crescendo so Keefe phedny BrainOverfl0w
09:06:40midnightmagic:op_mul: I've wanted to install an auto-uploading car-based radiation counter + gps stamper for years but all the electronic-output devices I've seen are in the $500 range which seems excessive
09:09:48op_mul:midnightmagic: I'm using one of these (though I have a better one now) and a horrible power supply I made from things I had lying about. it's a beta + gamma detector. http://gstube.com/data/2398/
09:11:37midnightmagic:what the hell, $24?!
09:12:09op_mul:I paid like, 8 USD. shop around. remember that's just the tube, but the supporting electronics aren't very hard.
09:12:50midnightmagic:did you verify it against a known source?
09:13:53midnightmagic:woops. -wizards. sorry for topic skew
09:14:31op_mul:no, but the numbers seem sane enough for background radiation. I have no desire to go messing about with radioisotopes just for safety / legality. the only reason I wanted to play with them in the first place was for a RNG.
09:14:59op_mul:as an RNG it works just fine. it's dog slow. you can make a bitcoin private key in a few minutes.
09:15:51phantomcircuit:op_mul, you can purchase point sources of various isotopes online for tens of dollars
09:16:03phantomcircuit:they're so small as to be not dangerous in any meaningful way
09:16:20phantomcircuit:(just dont push them into your eyeball)
09:17:56op_mul:breathing or ingesting them is more the worry. I'm anxious enough without maybe having alpha emitters lurking around my kitchen table.
09:18:44phantomcircuit:op_mul, then get a co-60 point source
09:21:19phantomcircuit:op_mul, https://unitednuclear.com/index.php?main_page=product_info&cPath=2_5&products_id=819
09:21:27phantomcircuit:loverly gamma only sources
09:23:26midnightmagic:i would love a hunk of uranium ore on a bookshelf.
09:23:37op_mul:phantomcircuit: first of all I'm not in the US, even if I was mail order radioisotopes is a sentence that just sounds totally wrong
09:25:29phantomcircuit:op_mul, shrug, it's entirely legal
09:25:41phantomcircuit:they're really small
09:25:56phantomcircuit:the amount you'd have to order for it to be dangerous to anybody would set off all kinds of alarms
09:26:15phantomcircuit:otoh some idiot kid tried to build a fission reactor in his backyard that one time...
09:27:03gmaxwell:midnightmagic: not quite $8+$parts but also less than $500: http://www.gqelectronicsllc.com/comersus/store/comersus_viewItem.asp?idProduct=4579
09:27:25midnightmagic:Ooo nice.
09:27:41op_mul:great. next time I see some fool writing terrible bitcoin code I'm going to be thinking "at least they aren't messing with radioisotopes"
09:27:55midnightmagic:hehe
09:28:11op_mul:gmaxwell: building one is more fun.
09:30:22op_mul:good idea with the screen though. that'd be a good addition.
09:31:51gmaxwell:op_mul: wrt samples, you could just get a lantern mantle.
09:35:16op_mul:gmaxwell: I was going to go for thrift store 70s plates actually.
09:35:57op_mul:er earlier than that. whenever the stupid orange color was in fashion.
09:37:28gmaxwell:well now that you've got the working detector you can go scope out indigivual plates.
09:39:33op_mul:yup.
09:46:42midnightmagic:thorium lantern mantles can still be had. i used to have some, don't know where they went.
11:22:42rusty:maaku: OK, the bad news is that the simple store-incremental-previous-proof scheme sucks for the "block 1M to block 1M-150" test. Which is not unexpected. But that's not really what you need, since we can prove to any prior block, which should be fine.
14:52:58maaku:rusty: "prove to any prior block" -- not sure that's what we want. in the sidechain case at least proving back ~150 blocks is the most common use case
14:53:15maaku:maybe I'm misunderstanding?
18:51:23luke-jr_:luke-jr_ is now known as Luke-Jr
19:12:42adam3us:hmm so i've been trying various attempts to better the IBE address solution to scanning last few days, and one approach is to make smaller encrypted addresses. i think i made some progress on that topic.
19:14:24adam3us:if elgamal encrypt is (A,B)=(kG,M+kQ) and decrypt is M=B-dA
19:14:50adam3us:then the ciphertext is 2x32=64bytes at 256-bit EC curve sizes.
19:15:21adam3us:so instead for small msgs eg in (0,2^16), one could instead compute
19:25:27adam3us:call M'=(0,2^16) and M'=M mod 2^16 and M=M"||M' then find k st kG=kQ-M' mod 2^16, then M=kQ-kG (and M mod 2^16==M') and you can send A alone because B=A. decrypt is M'=A-dA mod 2^16.
19:27:06adam3us:so the msg might be M
19:27:12adam3us:so the msg might be M
19:28:06adam3us:(gah ' next to enter) so the msg might be M'==0 means msg is for me, and anything else means ignore. then that has a 2^-16 false positive rate
19:34:22lclc:lclc is now known as lclc_bnc
19:40:01gmaxwell:I'm not following here. So in the existing solution the address encodes two points P1, P2, sender picks a nonce K, and sets their scriptPubkey to P1 + H(kP2)G and includes kG in the transaction.
19:40:41gmaxwell:so the overhead is |kG|, or about 33 bytes.
19:42:24adam3us:gmaxwell: yeah its not smaller but its a different use, for something compact for scanning (and info theoretically secure privacy tho that doesnt help much give rest of leaks)
19:44:12tacotime:ehm... is this for stealth addresses or a bip32 variant?
19:44:14gmaxwell:So are you suggesting adding a P3 to the pubkey and 33 bytes for a elgamal test?
19:45:17gmaxwell:tacotime: it's for reusable addresses which aren't a lie, the stealth address construction just ends up with all the users giving their scanning keys to foochain.info.
19:45:18adam3us:gmaxwell: probably confusing because i'm not really saying much, other than hey look a single key way to encrypt a small msg with an intentional false positive
19:46:00gmaxwell:tacotime: so he's trying to find a scheme where someone can scan on your behalf without totally giving away all the address linkages.
19:46:06tacotime:gmaxwell: right, that's how mymonero.com is setup and it's less than ideal. but without it we currently have no easy way for anyone to use monero, and we're looking at different mtds in the future.
19:46:18tacotime:ah, i see. that'd be super useful for us.
19:47:35gmaxwell:tacotime: well this was talked about in here previously. We had a scheme that allowed per-block (group) delegation, e.g. where you could have someone scan for you but only for the block you asked them for, but it had high overhead, among other problems.
19:47:39adam3us:gmaxwell: well (to explain further) its all confusing to me too at present but i was trying to meet in the middle with a new tack: use the bloom filter of the block, but in a way where you cant detect presence without a private key. (kind of private key bloom filter!)
19:48:23adam3us:gmaxwell: sorry public key bloom filter. not working out for me so well this far. but one part of it was to see if one can get smaller, like domain preserving smaller, public key encrypted messages with tunable false positive rates.
19:49:35tacotime:well, if it just involves appending some extra data to tx we could trial it on our testnet. i think our serialized tx structure allows for an extra 256 bytes to be appended of whatever.
19:49:45gmaxwell:adam3us: I had found a way to do private testing but it ended sending as much data as there were addresses in the block, so no gain.
19:51:24adam3us:gmaxwell: yes but this time i was thinking download the block bloom, and test it yourself. kind of hard. other strand is to find even smaller public key encryption that is bloom filter like in its output (1 bit that is either maybe, or no)
19:54:25adam3us:gmaxwell: the line of investigation was is there a public key algorithm or variant of it that can allow the sender to decrypt as well as the recipient such that you can massage the ciphertext so its mostly 0s and then only send the trailing bit (without a 2^240 brute force)
19:54:30gmaxwell:adam3us: oh thats a cute idea. Sure, even take the original reusable address scheme. pay=P1 + H(kP2)G you give the server P2 and not P1. and for each pubkey output point P it computes T_n = P_n - H(kP2)G and puts the T_n in a bloom filter.
19:58:54adam3us:gmaxwell: would that work? i think you're also still on the outsource the scan track, i am on a new track of have miners make a committed bloom filter of the block, and download that for all blocks and scan for yourself with your private key.
19:59:42gmaxwell:tacotime: I guess its "nice" to see confirmation of how I expected that functionality would turn out in practice. ... kinda surprised to see that running, seems like a huge subpoena magnet.
20:00:47gmaxwell:adam3us: ah, now I follow you. Yes, I was still on an outsource the scan track. Yes it would work, but OTOH it's linkable by any scanner who's also heard of your address.
20:02:14gmaxwell:it's also linkable over time (e.g. with reuse) so probably not that useful.
20:03:15tacotime:gmaxwell: maybe someday, if people actually use monero for anything other than speculating. we aren't really even applicable to openbazaar until we implement a SSS-style protocol for threshold signatures.
20:04:10gmaxwell:tacotime: your cryptosystem directly supports threshold signatures.
20:04:54tacotime:right, but i don't know of an available implementation, and we're kinda pressed right now to even get our db working.
20:05:06gmaxwell:it just needs interactive setup to establish the keys for anything other than N of M where N==M.
20:05:46tacotime:i wanted to use the scheme described here: http://link.springer.com/chapter/10.1007/3-540-47719-5_33
20:06:35tacotime:but i don't trust myself to implement the pure crypto i guess, and i'm time limited by the more boring contract work i have to do to survive.
20:07:28tacotime:admittedly i haven't read your/andytoshi's proposal closely, is it a big improvement?
20:08:02gmaxwell:tacotime: IIRC that paper requires a trusted dealer.
20:08:28tacotime:there's a section that described setup with a non-trusted dealer. hum, i had a copy of it somewhere.
20:08:32adam3us:gmaxwell: in principle you might even be able to private scan via boolean AND if it works out. you'd need an efficient way to setup the bloom filter for all possible ciphertexts in a sparse ciphertext encoding. i think sparse ciphertext could be engineered from non-sparse.
20:09:30adam3us:gmaxwell: eg c'=f(H(1,Q,m)||H(2,Q,m)||...)
20:10:03tacotime:oh, no, i'm thinking sig generation. yeah, it looks like initial setup needs a dealer.
20:10:34adam3us:gmaxwell: but being able to insta-populate the sparse ciphertext bloom filter is going to be tough. the defence is its too large to brute force.
20:10:36tacotime:but 2.4 talks about how to do a distributed setup
20:11:01adam3us:gmaxwell: so the attacker cant enumerate all to distinguish
20:11:32tacotime:"Each player Pi chooses ri, r'i E Zq at random and verifiably shares (ri, r'i) acting as the dealer according to Pederson's VSS described above."
20:11:37gmaxwell:tacotime: there is a much easier scheme.
20:11:49tacotime:Is that the one described in brs.pdf?
20:12:11tacotime:i'll have to read it more closely.
22:06:29maaku:maaku is now known as Guest87632
23:17:54rusty2:Guest87632: sorry, it was a brain fart. OK, so, average 382 hashes to get back 150, vs 474 back to genesis, which is really bad.
23:17:57rusty2:rusty2 is now known as rusty
23:52:53danneu:jesus