00:40:43fanquake_:fanquake_ is now known as fanquake
04:29:05Pan0ram1x:Pan0ram1x is now known as Guest76203
05:27:35coblee:hey guys. I'm trying to figure out the best way to prevent a double spend attack. I figure I should ask here
05:29:13coblee:Luke-Jr: Someone has successfully double spent against Coinbase by using the Eligius trick
05:30:24coblee:When I first realized this was possible, we didn't spend too much time trying to fix it because we haven't seen it in the wild. Now that we have, we will need to fix it before someone really hurts us
05:32:02gmaxwell:'eligius trick'?
05:32:31coblee:send first txn with zero fees with an output to a gambling known address. send second double spend txn straight to eligius
05:33:37coblee:eligius will ignore the first txn due to its non-standard rejection of gambling txns. and eligius will accept the double spend. the double spend might get mined before the first zero fee txn
05:33:49gmaxwell:Ah there are also other miners with various inconsistent policies too, so you can't hope to e.g. enumerate the weirdness; as the policy is opaque to you.
05:34:06coblee:i know
05:34:18coblee:so accepting 0-conf txn is risky
05:34:28coblee:the eligius trick is easy to perform though
05:35:00coblee:see https://blockchain.info/tx/ec0b3bdc47251c294d56ca8edf3d9fa730f7f7a4f8a0b3eff063e38b9c8c65a0
05:37:50coblee:i would hate to have to copy eligius' code and look for bad looking txns. as you say, there are other pools with inconsistent policies. so hard to figure them all out
05:38:10coblee:and requiring 1-conf would really suck too
05:40:59bramc:The fix is generally to wait until the transaction is buried enough that this isn't a problem
05:41:43BlueMatt:coblee: there are other ways to go about accepting transactions quickly, 0-conf is not the only one, and is probably one of the worst
05:42:14coblee:bramc: buried as in has a few confirmations, right?
05:42:30coblee:BlueMatt: can you elaborate. PM is fine also
05:42:39bramc:coblee, as in a few blocks have been mined since the transaction
05:42:50BlueMatt:coblee: green address, payment channel networks, etc
05:44:36coblee:BlueMatt: yeah, but that means it would suck to use a standard bitcoin client.
05:54:30BlueMatt:coblee: meh, what is a "standard bitcoin client"???
05:54:41coblee:just meant bitcoin-qt
05:54:51BlueMatt:who uses bitcoin-qt???
05:54:56BlueMatt:or...who will use bitcoin-qt in a few years?
05:55:02BlueMatt:no need to optimize for that...
05:55:46coblee:or blockchain
05:55:47op_mul:BlueMatt: non-core wallets are scary as fuck.
05:56:37coblee:Not accepting 0-conf would make the checkout experience horrible online and in person
05:57:24op_mul:BlueMatt: even the ones written by people who should know what they are doing seem to often have absolutely insane flaws. I'd much rather use the one that has at least some code review and eyes watching over it.
05:57:45bramc:What are green addresses and payment channel networks?
05:59:32op_mul:er, you're going to suffer some google-fu distress here.
05:59:45coblee:would suck if only payments sent from Coinbase or GreenAddress are instant.
06:00:11bramc:It looks like they amount to 'use a trusted third party'
06:00:18op_mul:originally, some services like a mining pool (forget which) and Mt Gox made something called a "green address". it was a static address which they owned, and sent "green" payments using outputs at that address.
06:00:35op_mul:the promise was, nothing "from" that address would ever be a double spend, so you could trust it with 0 confirmations.
06:01:18op_mul:that never really gained traction because mt gox went down the shitter.
06:01:48bramc:That doesn't really help the problem because you need to have the foresight to send to that address to begin with
06:02:19op_mul:with a service like greenaddress.it customers hold one part of a 2-of-2 and the service holds the other. this allows the service to do 2FA and things for it's clients, but it also means that the service can promise their clients will never sign a double spend.
06:02:26bramc:And, yeah, 'trusted' third parties in bitcoin have a bad track record
06:03:20op_mul:well, GAit isn't really trusted at all other than not to double spend. if they refuse to sign transactions for their clients, the client can use an nlocktime'd trapdoor to escape.
06:03:38bramc:Oh, that makes sense. Do they also have timelocked return transactions so people can get back their deposited utxos if the service goes down?
06:04:11bramc:Ah, that's a fairly good service then. Involves a bunch of transaction fees though.
06:05:31op_mul:* op_mul shrugs
06:05:46op_mul:if you want actual 2FA in a wallet, that's what you're going to have to do.
06:11:53bramc:It's really annoying how collaborative signature generation hasn't been built yet, but the math seems to be having some problems
06:16:26op_mul:there is one for ECDSA, actually.
06:17:08bramc:op_mul, link?
06:17:20op_mul:someone linked to it a while ago. there's a two factor wallet which makes a collaborative signature for a PKH transaction which is identical to a normal one. let me see if I can find it.
06:17:31bramc:All I can find is this: https://freedom-to-tinker.com/blog/stevenag/new-research-better-wallet-security-for-bitcoin/
06:18:46bramc:Note the caveat at the top saying 'our technique is busted'
06:20:42bramc:That being not live is less than confidence inspiring
06:22:47gmaxwell:bramc: it works fine with a trusted dealer.
06:23:05gmaxwell:There is also another that only results in a one show signature; which is perhaps not that useful.
06:23:43op_mul:bramc: live? I linked to the cache because I don't like loading PDFs. there's a direct link in the header if you don't want the safe version.
06:24:09bramc:gmaxwell, Not sure what you just said. You mean the busted collaborative signature generation thing works okay when used properly?
06:25:10gmaxwell:bramc: it's only partially busted.
06:25:18bramc:Why is there a paper from 2014 saying how to do collaborative signature generation when there's already a perfectly good paper from 2004 doing the same thing?
06:25:39gmaxwell:they give multiple schemes and the ones with a trusted dealer (a centeral point generates the key which gets split) works IIRC. The scheme with distributed generation does not.
06:26:29bramc:Does that make it not busted in the 2-of-2 case because one of the parties can be the trusted dealer?
06:27:00bramc:Is the scheme from 2004 busted?
06:27:55gmaxwell:bramc: Not sure if you follow what trusted dealer means; it means that that key starts out non-distributed. This is fine in some cases, and useless in others.
06:28:05gmaxwell:Its useless, for example, to protect against backdoored hardware.
06:28:19gmaxwell:(since that centeral setup hardware could be backdoored)
06:28:38bramc:Oh I see what you're saying, I thought the trusted dealer was a bit weaker
06:28:58bramc:The most important case is 2-of-2 with no trusted dealer
06:30:19bramc:This is all very confusing. The earlier paper from 2004 seems to date even farther back to 2001, but published at a different conference? Maybe the exact same thing? And it claims to be provably secure
06:30:58gmaxwell:Most of the prior papers are dealing in the trusted dealer model.
06:31:10gmaxwell:(and if you go back too far they're usually not talking about something that works for ECDSA)
06:32:16bramc:gmaxwell, I'm specifically talking about this, which is from the link op_mul just gave http://link.springer.com/chapter/10.1007%2F3-540-44647-8_8#page-1
06:32:25bramc:It explicitly says 2-of-2 and 'neither can alone'
06:34:00bramc:And the other thing claims to have made a working wallet based on it
06:35:30gmaxwell:bramc: yes, the trusted dealer schemes achieve that property _after_ the dealer is done. In any case; perhaps I'm not looking at it right now, just take care a lot of papers are tremendously opaque about their actual assumptions.
06:36:27bramc:Oh, well maybe there's a caveat somewhere in there that they require a trusted third party. That should really be mentioned in the abstract if so though.
06:38:54bramc:Okay, you were right, it assumes a trusted third party in the 'initialization' section
06:40:22bramc:I feel cheated
06:40:57gmaxwell:yea; sorry, you get used to it.
06:41:25gmaxwell:A lot of cryptography papers are unhinged from application requirements.
06:43:54op_mul:like that newer BIP32 deriv method
06:44:07op_mul:awesome, but super not awesome.
06:45:03gmaxwell:really for some applications the trusted dealer is fine (e.g. your risk is theft of the key "at rest"); for others (dishonest participants, dishonest hardware) it makes the whole thing pointless.
06:45:09bramc:op_mul, What are you saying? I have yet to figure out what's going on with bip32
06:48:04op_mul:er trying to find it. gmax will be able to answer better, but it was a new derivation method but with the cost of unreasonable storage sizes
06:48:53gmaxwell:op_mul: well it was interesting, but it has linear costs, and just generating one off keys also has linear costs... sooo.
06:50:04op_mul:I can't find the original post for it
06:58:01maaku:maaku is now known as Guest16999
07:40:26bramc:Today I figured out how to make it so my proofs of work can be queried for only a single bit without having to return the whole thing, to make it more bandwidth efficient for a light client to sample them
07:40:44bramc:Not a huge performance benefit, but some fun crypto
08:35:56maaku:maaku is now known as Guest86691
09:05:14morgan.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:14morgan.freenode.net:Users on #bitcoin-wizards: andy-logbot maaku_ jb55 Guyver2 Shiftos coiner RoboTeddy execut3 HaltingState op_mul coblee TheSeven Guest76203 Dr-G e1782d11df4c9914 DougieBot5000 qwopqwop ryanxcharles ryan-c zwischenzug fanquake c0rw1n atgreen catcow afk11 MoALTz iyoki Guest30376 justanotheruser ajweiss Adlai Quanttek luny zooko DoctorBTC mkarrer nuke1989 gavinandresen nsh Graftec wizkid057 hashtag_ koshii stonecoldpat davout hollandais warren bosma forrestv dgenr8 d1ggy__
09:05:14morgan.freenode.net:Users on #bitcoin-wizards: otoburb ahmed_ tlrobinson PaulCapestany phantomcircuit mortale gribble copumpkin [d__d] lechuga_ nanotube hashtag so HM2 bbrittain Hunger- phedny comboy_ MRL-Relay Alanius cluckj optimator_ earlz cryptowest weex wiz artifexd coryfields_ kumavis harrow` tripleslash brad___ thrasher` Graet helo throughnothing nickler_ Adrian_G Iriez fenn yrashk sl01 mr_burdell JonTitor roasbeef Keefe espes__ Logicwax petertodd dansmith_btc lclc poggy sadgit heath
09:05:14morgan.freenode.net:Users on #bitcoin-wizards: kanzure fluffypony xabbix_ catlasshrugged pigeons Krellan Luke-Jr null_radix dasource Guest74833 Eliel_ morcos K1773R _v3Rve Dyaheon tromp amiller_ brand0 LarsLarsen asoltys_ isis livegnik go1111111 waxwing tacotime BlueMatt gmaxwell gsdgdfs eric azariah kobud Taek jaekwon_ crescend1 berndj EasyAt Starduster_ jaromil OneFixt d9b4bef9 nick1234abcd__ samson_ bepo_ NikolaiToryzin TD-Linux warptangent pi07r_ deego coryfields mappum SubCreative
09:05:14morgan.freenode.net:Users on #bitcoin-wizards: Emcy_ tromp_ sdaftuar lnovy midnightmagic delll iddo huseby Xzibit17 Oizopower BigBitz yoleaux hguux_ BrainOverfl0w wumpus sneak btcdrak Anduck BananaLotus jcorgan s1w Meeh epscy Fistful_of_Coins starsoccer a5m0 Nightwolf spinza burcin gnusha @ChanServ gwillen andytoshi kinlo Apocalyptic CryptOprah Muis btc___ jbenet michagogo rasengan
09:06:40maaku_:maaku_ is now known as maaku
09:25:01execut3:execut3 is now known as shesek
13:31:31fanquake_:fanquake_ is now known as fanquake
13:37:11Luke-Jr:coblee: even w/o policy diversity, there is no magic way to make an UNconfirmed tx anything but unconfirmed..
13:40:10andytoshi:earlz: regarding "should the nonce be bigger" no, the merkle root is perfectly capable of acting as a nonce so arguably every bit of the nonce is wasted header space, better it be 0 bits than 64 :)
13:44:06justanot1eruser:justanot1eruser is now known as justanotheruser
13:45:30andytoshi:coblee: you should ask about unconfirmed txes in #bitcoin, there are almost no circumstances where requiring confirmations results in a bad user experience and this has been beaten to death many times before
13:46:51Luke-Jr:indeed, quite off-topic for wizards, and something I would expect Coinbase to be familiar with a long time ago
13:49:22justanotheruser:andytoshi: If it was 0 bits wouldn't blocks take more time with more transactions?
13:51:14andytoshi:justanotheruser: ah, yeah, you'd need to change the merkle tree structure (maybe have the root be H(nonce || actual root) so effectively your leftmost branch always has length one)
13:52:59op_mul:could have trimmed the block version size down a bit and used that for nonce instead
13:53:22op_mul:do we really need space for 4294967295 block versions?
13:54:39justanotheruser:Do we need a version number?
13:56:07op_mul:yes, we've already been through a couple
13:56:43op_mul:BIP62 specifies block version 3
13:57:11justanotheruser:Do we need it in the block header I mean?
13:57:52justanotheruser:Might as well swap it with the extranonce
17:31:17kanzure:hearn: so that's cool and all... but that sounds like argument from authority... is there a link with explanations and wordtext instead?
17:31:46hearn:what sounds like an argument from authority?
17:31:54kanzure:weren't we just talking?
17:31:58kanzure:maybe it's a different hearn
17:32:16hearn:is this responding to the email on xgbtc?
17:34:05hearn:oh, i see. i think the bitcointalk thread has explanations in it? i don't think it was extensively discussed since then, or if it was then i forgot.
17:34:24Profreid_:Profreid_ is now known as Profreid
17:34:36kanzure:i would really appreciate links
17:34:47kanzure:in particular, my points were basically:
17:35:12hearn:the start of that thread?
17:35:13kanzure:of course, i know that links are not always available because words happen elsewhere, but perhaps you can paste those words or make them again
17:36:22hearn:* hearn what is the problem you are worried about? that miners would re-mine new chains without any transactions in except the ones you
17:36:30hearn:oops, huh, looks like i found a new keyboard shortcut
17:36:33Oizopower_:Oizopower_ is now known as Oizopower
17:36:40hearn:except the ones you used to pay them?
17:37:20hearn:there's no point in miners doing that because the inputs to the contracts actually do need to come from successfully confirmed payments. they can't just strip out all the transactions except the contracts for very long before everything stops working and then they earn no money at all
17:38:04kanzure:"successfully confirmed payments" are created by mining known payments
17:38:18hearn:but honestly, i'm not sure i want to go around this debate again tonight. who cares? block subsidies are so huge that we have entire datacenters doing nothing but mining, yet are owned by one person. hash rates could fall a lot without any major problems, i think, so it could be a loooong time before this becomes an issue
17:38:55kanzure:(by which i mean, "are created by mining blocks that contain those known payments")
17:39:14hearn:a lot of these debates, by the way, boil down to one core disagreement that surfaces in different forms
17:39:26hearn:some people assume miners will attempt to arbitrarily break anything they aren't incentivised by payments to not break
17:39:46hearn:others assume they will not, because they are incentivised to ensure bitcoin is generally useful and adopted, as that is what gives the coins they mine value
17:40:09kanzure:if you were okay with trusting the miners like that, then why bother with bitcoin at all?
17:40:19kanzure:why all the indirection? etc
17:40:55hearn:miners have always been trusted like that. go read the white paper - it says in the opening bitcoin is a system that works when the majority of miners are "honest". the goal of mining is to handle the case of an occasional or minority dishonest contingent.
17:41:13hearn:if all miners are collaborating to dick over the ecosystem in arbitrary ways and generally be dishonest, bitcoin doesn't work anymore
17:42:06kanzure:i suppose you and i might have very different ideas of what "working" means
17:42:26hearn:like i said, "a lot of these debates, by the way, boil down to one core disagreement that surfaces in different forms"
17:42:38kanzure:that's circular.
17:42:56kanzure:whereas my statement is not
17:44:33hearn:no, it's not circular. you appear to be unsatisfied with any argument that boils down to "the majority of miners will do this, because it makes bitcoin work better / increases its value / follows the rules". but that is the original bitcoin argument made by satoshi - it's exactly the threat model always used. if you want a system that works even when all miners are willing to burn the whole system to the ground for 1 cent of extra
17:44:33hearn:profit in the next few hours, you don't want bitcoin
17:45:36hearn:anyway, these debates rapidly become entirely philosophical. we're not going to get to find out what actually happens for a long time.
17:45:40kanzure:who the hell cares about "majority of miners"?? why would that matter?
17:45:54kanzure:sorry, that freaked me out. you should know that the majority of miners does not matter at all...
17:46:09hearn:s/miners/hash power/. you know what i mean.
17:46:24kanzure:you are too generous, i often don't
17:47:16fanquake_:fanquake_ is now known as fanquake
18:01:40kanzure:i think there's a conflation of "honest" and "trust" there
18:01:49kanzure:releasing a known blockchain that causes a reorg is not particularly dishonest
18:03:27kanzure:that's essential for the whole system to work, even
18:25:04op_mul:is forking a piece of software from the block chain dishonest?
18:25:16op_mul:say, if you could fork bitcoin ruby off.
18:25:27kanzure:was there an actual definition of honest/dishonest in the paper? /me looks again
18:25:54op_mul:"honest nodes"
18:26:01kanzure:okay, so "correct nodes"
18:26:17op_mul:"honest block"
18:26:34kanzure:that's too vague...
18:27:17op_mul:he does actually talk about forks of the chain being in themself honest and dishonest
18:29:59op_mul:it's a bit crazy how far away bitcoin is from this paper
18:46:36waxwing:i have a memory of a quote somewhere where satoshi expressed discomfort at his use of the term "honest" in the paper. something like, he couldn't find a better word to express the concept.
18:48:37kanzure:waxwing: this? http://www.metzdowd.com/pipermail/cryptography/2008-November/014818.html
18:49:08waxwing:must be.
18:49:31waxwing:you seem to be on top of things. i'll let you get on with it :)
18:50:15kanzure:nah that's just the bitcoin tumor in my head doing its job
18:58:09op_mul:I like the description of Bitcoin as a mental ailment.
19:11:29justanotheruser:Given that we have a UTXO merkle tree in a block, is it possible for a thin client to pay to a think client without a server? It is pretty obvious how a full node could pay to a thin client and tell them which block and which branch the transaction is, or how a thin client could pay a full node without a server. Is there a way to do it where both the payer and the receiver are serverless thin clients?
19:13:17op_mul:justanotheruser: if you're relying on a remote peer to do filtering for you, sure there's nothing stopping that.
19:13:24faraka:what do you guys think of factom?
19:14:10justanotheruser:op_mul: well if of the two people involved in a transaction is a full node, there doesn't need to be a server telling the recipient which tx is theirs
19:15:13op_mul:with two SPV peers you're going to be relying on at least one of them connecting to a full node and using them for filtering.
19:16:47Pan0ram1x:Pan0ram1x is now known as Guest62639
19:16:52justanotheruser:yeah, I was wondering if there was some solution to that. None are obvious to me
19:18:18op_mul:a way to ask peers for their full merkle tree? there's nothing pretty in any case.
19:19:21justanotheruser:yeah, you can ask for as many transactions as you want to increase the size of your anonymity set, but you can only increase it so much until you become a full node :p
19:19:39op_mul:just the merkle tree, not the transactions in it.
19:19:59op_mul:you'd know your own transaction, so you can fit it in and build a proof using it if you want.
19:22:10amiller_:justanotheruser, can the thin clients communicate directly to each other?
19:25:25justanotheruser:amiller_: I don't see why they couldn't
19:26:42amiller_:so thin client A sender can send the transaction hash to thin client B receiver, now thin client B can ask its peers to filter for it and see when its included in a block?
19:27:19justanotheruser:amiller_: that is what is done right now
19:28:24justanotheruser:but asking your peers deanonymizes you
19:28:26faraka:isn't factom a scam?
19:28:36faraka:wouldn't it be possible to do the same thing without a coin?
19:28:49faraka:a thir party is needed to verify existence of a physical object.
19:29:17faraka:a coin seems a redundant process
19:29:28kanzure:not all bad ideas are scams
19:29:33amiller_:justanotheruser, oh... what kind of anonymity would be considered sufficient? you could hack a little bit by asking for a filter that includes lots of chaff transactions
19:29:38kanzure:and also, factom could be something other than a scam and still be a bad idea
19:30:16justanotheruser:amiller_: Well the best kind of anonymity is where only the sender knows you received it
19:30:35op_mul:amiller_: that's been shown to be almost totally ineffective.
19:30:35faraka:what would you propose as a better alternative kanzure?
19:30:39justanotheruser:If the sender is a full node he should send you the merkle branch
19:31:06op_mul:amiller_: there's a paper where they were using a > 30% false positive rate and it still provided close to no privacy.
19:31:19kanzure:faraka: what do you mean? i was just suggesting to you that even if it's not a scam, it might still be a bad idea.
19:31:45faraka:oh lol misread. sorry.
19:31:54justanotheruser:faraka: yeah, you can do it without a coin. send a mining pool merged mining info and a merkle tree will be constructed with all your commitments with the merkle root in the coinbase
19:32:11amiller_:op_mul, yes but there are possible countermeasures and further this need not involve just addresses but specific tx hashes which is a little more favorable
19:32:15justanotheruser:It will probably be easier to do this as sidechains are developed
19:32:59amiller_:kanzure, those were two ways of saying the same thing :p i think you meant to say: also some scams are even good ideas!
19:33:18op_mul:amiller_: I think BIP37 should be deprecated. there's a better option.
19:33:24kanzure:amiller_: oh, i'm not sure if i meant to say that.
19:33:35kanzure:amiller_: oh wait, yes, you're right. some good ideas can be operated as scams.
19:33:56faraka:what's the development status on sidechains?
19:37:53amiller_:justanotheruser, okay so i don't see anyway that utxo commitments help, but it also seems like its already solved, unless im missing some extra constraint you posed
19:38:34justanotheruser:amiller_: my constraint is 2 spv clients, one paying the other without giving up anonymity by allowing a full node to see which tx you want
19:39:22op_mul:justanotheruser: using non-bip37 bloom filters does that anyway.
19:40:00justanotheruser:op_mul: hm?
19:40:02op_mul:you can sieve your cake and tell nobody about it.
19:41:40op_mul:transaction contents of a block are built into a filter by the miner. the filter is embedded into the merkle tree. to find if the block is "interesting" or not, the SPV client asks a peer for the header + bloom filter + proof. the SPV client matches with the bloom filter without revealing their interest.
19:42:51justanotheruser:They still need to ask for the merkle branch though?
19:42:54op_mul:I think phantomcircuit was talking about making a proof of concept, or had one, I can't remember
19:43:00op_mul:no, they download the whole block
19:43:46justanotheruser:oh, so they make their anonymity set every recipient in that block
19:44:15op_mul:and they can do interesting things like requesting false positives, or requesting from other peers, or even peers they've never connected to at all.
19:44:15amiller_:justanotheruser, better than that, the client doesn't reveal whether the client found what it was looking for in the block
19:45:41amiller_:nvm disgregard my last line
19:46:25op_mul:it reveals a little if you download the block straight from a peer that knows you are filtering.
19:47:03dgenr8: "it's a bit crazy how far away bitcoin is from this paper" Then again, none of us designed it, and would the person who thinks he/she would ever have done so, please raise their hand?
19:47:27op_mul:the main advantages are that you don't give your whole filter to a single person in the network, and also that you can retain the filters and use them at a later date to do a rescan.
19:47:56op_mul:it solves the problem of fully validating, but pruned nodes not being able to rescan a wallet.
19:49:40op_mul:dgenr8: you missed what I had in mind. I was just saying that a few of the goals are better understood now, and some of the things don't exist as features or problems anymore.
19:57:15kanzure:bitpay payment channel stuff http://impulse.is/impulse.pdf
20:03:17dgenr8:op_mul: i guess there's some room for disagreement on materially how far away from the original we are today
20:04:18op_mul:the bit about pruning spent transactions from merkle trees is outdated, you can agree on that
20:15:54Pan0ram1x:Pan0ram1x is now known as Guest28189
20:16:24op_mul:op_mul has left #bitcoin-wizards
20:24:16gmaxwell:op_mul: the software never stored hash trees, sooo.
20:36:58op_mul:gmaxwell: yes, which makes part 7 of the whitepaper even more confusing.
20:37:57gmaxwell:op_mul: well what it means is that you can still serve spv clients about available coins withtout keeping all the block's data.
20:41:27op_mul:right, hadn't realised that. sounds horrible to implement, though.
20:42:27gmaxwell:It would have been straight forward-ish in the original implementation. you'd just delete txn and replace them with the missing hashes in the database.
20:43:56op_mul:partly what I meant by outdated, it seems like a horrific amount of disk operations to get that working in the current client
20:56:09gmaxwell:nah. not really.
20:59:24Profreid_:Profreid_ is now known as Profreid
21:06:17phantomcircuit:gmaxwell, er that actually sounds non trivial unless you're relying the the fs to punch holes in the file efficiently
21:06:21phantomcircuit:(hint: they mostly dont)
21:16:26imposter:imposter is now known as satoshinakamoto
21:23:17gmaxwell:phantomcircuit: uh. you're overly constraining yourself. rewriting storage is no big deal.
21:24:13d1ggy__:d1ggy__ is now known as d1ggy
21:36:29phantomcircuit:gmaxwell, depends on whether you're pruning 1 tx at a time or not
21:41:57rasengan:rasengan has left #bitcoin-wizards
22:35:40amiller_:MRL-Relay, have you all thought of implementing private balances in cryptonote
22:36:30amiller_:MRL-Relay, you'd potentially cut way down on transaction size and also boost anonymity set
22:43:04amiller_:im probably really late to this, i know such proof systems have been discussed here before, and im probably the last one to grok cryptonote so i dont know if its been discussed in that context
22:57:35wallet42:wallet42 is now known as Guest29993
22:57:35wallet421:wallet421 is now known as wallet42
23:02:42amiller_:to do range proofs im pretty sure need either groups with unknown order (including RSA groups, but excluding elliptic curve groups) or groth sahai proofs (which also need trusted setup of some kind)
23:42:21nsh:.wik groth sahai proof
23:42:23yoleaux:"Non-interactive zero-knowledge proofs are a variant of zero-knowledge proofs in which no interaction is necessary between prover and verifier. Blum, Feldman, and Micali showed that a common reference string shared between the prover and the verifier is enough to achieve computational zero-knowledge without requiring interaction." — http://en.wikipedia.org/wiki/Non-interactive_zero-knowledge_proof
23:42:50nsh:.g Perfect Non-interactive Zero Knowledge ext:pdf
23:43:51nsh:amiller_, any practical implementations of this latter (groth sahai) extant?
23:44:36nsh:* nsh is (unrelatedly) tempted to share an intuition he had about the blockchain and tried to explicate in another channel, but it will probably be poorly-received
23:49:09nsh:oh this might relate to a half intuition i had about part of the magic of the blockchain. that it cheats and uses the magic of statistics that allows a local point to make a global measurement
23:49:09nsh: what is it measuring globally?
23:49:09nsh:it's to do with the consensuation of the retargeting. somehow everyone has to agree on something so that some other things happens as a poisson process with a fixed approximate mean. (mining a block)
23:49:09nsh:but you can't measure global hashrate. that would be an absurdly ambitious undertaking, naively. figuring out how much hashpower everyone has, whether it's turned on, which hashes it's grinding. but you can actually access that information through the holistics of statistics. because the time it takes for someone to win the hashing 'magically' subsumes all that information
23:49:13nsh:(but only magically because everyone who wins has an incentive to shout about it and the rules are designed to amplify and verify the validity of their MEMEMEMEMEME!)
23:50:09nsh:anyway, this 'holistics of statistics' notion is something i've wondered about since early childhood and it hasn't really cropped up much in formal or informal education
23:50:31nsh:so i was wondering if it would recall in someone something they could point me at to delve a bit deeper
23:51:46nsh:(i mean, surely everyone has at some point thought: "how do all the independent coin tosses conspire to the average?", right? or is this a product of nsh-brainweirds?)
23:55:00amiller_:nsh, i don't know of any implementation of groth sahai proofs :(
23:55:15amiller_:nsh, isis lovecruft was beginning to implement them actually
23:55:21nsh:ah, hmm
23:55:34amiller_:i have a pretty good grasp of rsa group proofs and schnorr group proofs in general
23:56:27amiller_:a crs is required anyway so its not obvious if groth-sahai is better than rsa for whatever applicatin
23:56:46amiller_:by which i mean, a sensitive setup procedure ostensibly involving a trapdoor or else something complicated like a UFO is required
23:57:03nsh:right, there's an inherent trust-fragility to the set-up procedure
23:57:25amiller_:i think groth sahai should be doable though
23:57:26kanzure:nsh: there were a few phiosophers of statistis (like charles pierce?) but you might find that too ridiculous
23:57:28nsh:(which is not necessarily worse than the existing trust-fragilities of other sociotechnological systems, but unappealing)
23:57:55kanzure:i think you can measure global hashrate by looking at infrared radiation
23:57:58kanzure:this places an upper bound
23:58:22nsh:well, the point is you don't have to if you can amplify, verify and consensuate the first person who chances on the target
23:58:40nsh:this is what allows a single point in the system to do a global measurement
23:58:55nsh:i think this is conceptually important, somehow, but i'm not sure exactly wht
23:59:47nsh:amiller_, is it conceivable that the universe somehow provides a CRS?