| 00:40:43 | fanquake_: | fanquake_ is now known as fanquake |
| 04:29:05 | Pan0ram1x: | Pan0ram1x is now known as Guest76203 |
| 05:27:35 | coblee: | 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:13 | coblee: | Luke-Jr: Someone has successfully double spent against Coinbase by using the Eligius trick |
| 05:30:24 | coblee: | 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:02 | gmaxwell: | 'eligius trick'? |
| 05:32:31 | coblee: | send first txn with zero fees with an output to a gambling known address. send second double spend txn straight to eligius |
| 05:33:37 | coblee: | 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:49 | gmaxwell: | 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:06 | coblee: | i know |
| 05:34:18 | coblee: | so accepting 0-conf txn is risky |
| 05:34:28 | coblee: | the eligius trick is easy to perform though |
| 05:35:00 | coblee: | see https://blockchain.info/tx/ec0b3bdc47251c294d56ca8edf3d9fa730f7f7a4f8a0b3eff063e38b9c8c65a0 |
| 05:37:50 | coblee: | 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:10 | coblee: | and requiring 1-conf would really suck too |
| 05:40:59 | bramc: | The fix is generally to wait until the transaction is buried enough that this isn't a problem |
| 05:41:43 | BlueMatt: | 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:14 | coblee: | bramc: buried as in has a few confirmations, right? |
| 05:42:30 | coblee: | BlueMatt: can you elaborate. PM is fine also |
| 05:42:39 | bramc: | coblee, as in a few blocks have been mined since the transaction |
| 05:42:50 | BlueMatt: | coblee: green address, payment channel networks, etc |
| 05:44:36 | coblee: | BlueMatt: yeah, but that means it would suck to use a standard bitcoin client. |
| 05:54:30 | BlueMatt: | coblee: meh, what is a "standard bitcoin client"??? |
| 05:54:41 | coblee: | just meant bitcoin-qt |
| 05:54:51 | BlueMatt: | who uses bitcoin-qt??? |
| 05:54:56 | BlueMatt: | or...who will use bitcoin-qt in a few years? |
| 05:55:02 | BlueMatt: | no need to optimize for that... |
| 05:55:46 | coblee: | or blockchain |
| 05:55:47 | op_mul: | BlueMatt: non-core wallets are scary as fuck. |
| 05:56:37 | coblee: | Not accepting 0-conf would make the checkout experience horrible online and in person |
| 05:57:24 | op_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:45 | bramc: | What are green addresses and payment channel networks? |
| 05:59:32 | op_mul: | er, you're going to suffer some google-fu distress here. |
| 05:59:45 | coblee: | would suck if only payments sent from Coinbase or GreenAddress are instant. |
| 06:00:11 | bramc: | It looks like they amount to 'use a trusted third party' |
| 06:00:18 | op_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:35 | op_mul: | the promise was, nothing "from" that address would ever be a double spend, so you could trust it with 0 confirmations. |
| 06:01:18 | op_mul: | that never really gained traction because mt gox went down the shitter. |
| 06:01:48 | bramc: | That doesn't really help the problem because you need to have the foresight to send to that address to begin with |
| 06:02:19 | op_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:26 | bramc: | And, yeah, 'trusted' third parties in bitcoin have a bad track record |
| 06:03:20 | op_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:38 | bramc: | 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:03:45 | op_mul: | yes. |
| 06:04:11 | bramc: | Ah, that's a fairly good service then. Involves a bunch of transaction fees though. |
| 06:05:31 | op_mul: | * op_mul shrugs |
| 06:05:46 | op_mul: | if you want actual 2FA in a wallet, that's what you're going to have to do. |
| 06:11:53 | bramc: | It's really annoying how collaborative signature generation hasn't been built yet, but the math seems to be having some problems |
| 06:16:26 | op_mul: | there is one for ECDSA, actually. |
| 06:17:08 | bramc: | op_mul, link? |
| 06:17:20 | op_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:31 | bramc: | All I can find is this: https://freedom-to-tinker.com/blog/stevenag/new-research-better-wallet-security-for-bitcoin/ |
| 06:18:46 | bramc: | Note the caveat at the top saying 'our technique is busted' |
| 06:18:46 | op_mul: | https://webcache.googleusercontent.com/search?hl=en&q=cache%3Ahttp%3A%2F%2Fdiyhpl.us%2F~bryan%2Fpapers2%2Fbitcoin%2FRealizing%2520two-factor%2520authentication%2520for%2520the%2520Bitcoin%2520protocol.pdf |
| 06:20:42 | bramc: | That being not live is less than confidence inspiring |
| 06:22:47 | gmaxwell: | bramc: it works fine with a trusted dealer. |
| 06:23:05 | gmaxwell: | There is also another that only results in a one show signature; which is perhaps not that useful. |
| 06:23:43 | op_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:09 | bramc: | gmaxwell, Not sure what you just said. You mean the busted collaborative signature generation thing works okay when used properly? |
| 06:25:10 | gmaxwell: | bramc: it's only partially busted. |
| 06:25:18 | bramc: | 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:39 | gmaxwell: | 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:29 | bramc: | Does that make it not busted in the 2-of-2 case because one of the parties can be the trusted dealer? |
| 06:27:00 | bramc: | Is the scheme from 2004 busted? |
| 06:27:55 | gmaxwell: | 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:05 | gmaxwell: | Its useless, for example, to protect against backdoored hardware. |
| 06:28:19 | gmaxwell: | (since that centeral setup hardware could be backdoored) |
| 06:28:38 | bramc: | Oh I see what you're saying, I thought the trusted dealer was a bit weaker |
| 06:28:58 | bramc: | The most important case is 2-of-2 with no trusted dealer |
| 06:30:19 | bramc: | 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:58 | gmaxwell: | Most of the prior papers are dealing in the trusted dealer model. |
| 06:31:10 | gmaxwell: | (and if you go back too far they're usually not talking about something that works for ECDSA) |
| 06:32:16 | bramc: | 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:25 | bramc: | It explicitly says 2-of-2 and 'neither can alone' |
| 06:34:00 | bramc: | And the other thing claims to have made a working wallet based on it |
| 06:35:30 | gmaxwell: | 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:27 | bramc: | 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:54 | bramc: | Okay, you were right, it assumes a trusted third party in the 'initialization' section |
| 06:40:22 | bramc: | I feel cheated |
| 06:40:57 | gmaxwell: | yea; sorry, you get used to it. |
| 06:41:25 | gmaxwell: | A lot of cryptography papers are unhinged from application requirements. |
| 06:43:54 | op_mul: | like that newer BIP32 deriv method |
| 06:44:07 | op_mul: | awesome, but super not awesome. |
| 06:45:03 | gmaxwell: | 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:09 | bramc: | op_mul, What are you saying? I have yet to figure out what's going on with bip32 |
| 06:48:04 | op_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:53 | gmaxwell: | op_mul: well it was interesting, but it has linear costs, and just generating one off keys also has linear costs... sooo. |
| 06:50:04 | op_mul: | I can't find the original post for it |
| 06:58:01 | maaku: | maaku is now known as Guest16999 |
| 07:40:26 | bramc: | 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:44 | bramc: | Not a huge performance benefit, but some fun crypto |
| 08:35:56 | maaku: | maaku is now known as Guest86691 |
| 09:05:14 | morgan.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:14 | morgan.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:14 | morgan.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:14 | morgan.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:14 | morgan.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:40 | maaku_: | maaku_ is now known as maaku |
| 09:25:01 | execut3: | execut3 is now known as shesek |
| 13:31:31 | fanquake_: | fanquake_ is now known as fanquake |
| 13:37:11 | Luke-Jr: | coblee: even w/o policy diversity, there is no magic way to make an UNconfirmed tx anything but unconfirmed.. |
| 13:40:10 | andytoshi: | 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:06 | justanot1eruser: | justanot1eruser is now known as justanotheruser |
| 13:45:30 | andytoshi: | 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:09 | op_mul: | andytoshi: |
| 13:46:12 | op_mul: | :< |
| 13:46:51 | Luke-Jr: | indeed, quite off-topic for wizards, and something I would expect Coinbase to be familiar with a long time ago |
| 13:49:22 | justanotheruser: | andytoshi: If it was 0 bits wouldn't blocks take more time with more transactions? |
| 13:51:14 | andytoshi: | 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:59 | op_mul: | could have trimmed the block version size down a bit and used that for nonce instead |
| 13:53:22 | op_mul: | do we really need space for 4294967295 block versions? |
| 13:54:39 | justanotheruser: | Do we need a version number? |
| 13:56:07 | op_mul: | yes, we've already been through a couple |
| 13:56:43 | op_mul: | BIP62 specifies block version 3 |
| 13:57:11 | justanotheruser: | Do we need it in the block header I mean? |
| 13:57:52 | justanotheruser: | Might as well swap it with the extranonce |
| 17:31:17 | kanzure: | 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:36 | hearn: | hm? |
| 17:31:46 | hearn: | what sounds like an argument from authority? |
| 17:31:54 | kanzure: | weren't we just talking? |
| 17:31:58 | kanzure: | maybe it's a different hearn |
| 17:32:16 | hearn: | is this responding to the email on xgbtc? |
| 17:32:21 | kanzure: | yeah |
| 17:34:05 | hearn: | 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:24 | Profreid_: | Profreid_ is now known as Profreid |
| 17:34:36 | kanzure: | i would really appreciate links |
| 17:34:47 | kanzure: | in particular, my points were basically: |
| 17:34:48 | kanzure: | https://bitcointalk.org/index.php?topic=157141.msg1668659#msg1668659 |
| 17:34:51 | kanzure: | https://bitcointalk.org/index.php?topic=157141.msg1834361#msg1834361 |
| 17:35:12 | hearn: | the start of that thread? |
| 17:35:13 | kanzure: | 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:22 | hearn: | * 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:30 | hearn: | oops, huh, looks like i found a new keyboard shortcut |
| 17:36:33 | Oizopower_: | Oizopower_ is now known as Oizopower |
| 17:36:40 | hearn: | except the ones you used to pay them? |
| 17:37:20 | hearn: | 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:04 | kanzure: | "successfully confirmed payments" are created by mining known payments |
| 17:38:18 | hearn: | 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:55 | kanzure: | (by which i mean, "are created by mining blocks that contain those known payments") |
| 17:39:14 | hearn: | a lot of these debates, by the way, boil down to one core disagreement that surfaces in different forms |
| 17:39:26 | hearn: | some people assume miners will attempt to arbitrarily break anything they aren't incentivised by payments to not break |
| 17:39:46 | hearn: | 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:09 | kanzure: | if you were okay with trusting the miners like that, then why bother with bitcoin at all? |
| 17:40:19 | kanzure: | why all the indirection? etc |
| 17:40:55 | hearn: | 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:13 | hearn: | if all miners are collaborating to dick over the ecosystem in arbitrary ways and generally be dishonest, bitcoin doesn't work anymore |
| 17:42:06 | kanzure: | i suppose you and i might have very different ideas of what "working" means |
| 17:42:26 | hearn: | like i said, "a lot of these debates, by the way, boil down to one core disagreement that surfaces in different forms" |
| 17:42:38 | kanzure: | that's circular. |
| 17:42:56 | kanzure: | whereas my statement is not |
| 17:44:33 | hearn: | 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:33 | hearn: | profit in the next few hours, you don't want bitcoin |
| 17:45:36 | hearn: | 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:40 | kanzure: | who the hell cares about "majority of miners"?? why would that matter? |
| 17:45:54 | kanzure: | sorry, that freaked me out. you should know that the majority of miners does not matter at all... |
| 17:46:09 | hearn: | s/miners/hash power/. you know what i mean. |
| 17:46:24 | kanzure: | you are too generous, i often don't |
| 17:47:16 | fanquake_: | fanquake_ is now known as fanquake |
| 18:01:40 | kanzure: | i think there's a conflation of "honest" and "trust" there |
| 18:01:49 | kanzure: | releasing a known blockchain that causes a reorg is not particularly dishonest |
| 18:03:27 | kanzure: | that's essential for the whole system to work, even |
| 18:25:04 | op_mul: | is forking a piece of software from the block chain dishonest? |
| 18:25:16 | op_mul: | say, if you could fork bitcoin ruby off. |
| 18:25:27 | kanzure: | was there an actual definition of honest/dishonest in the paper? /me looks again |
| 18:25:54 | op_mul: | "honest nodes" |
| 18:26:01 | kanzure: | okay, so "correct nodes" |
| 18:26:17 | op_mul: | "honest block" |
| 18:26:34 | kanzure: | that's too vague... |
| 18:27:17 | op_mul: | he does actually talk about forks of the chain being in themself honest and dishonest |
| 18:29:59 | op_mul: | it's a bit crazy how far away bitcoin is from this paper |
| 18:46:36 | waxwing: | 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:37 | kanzure: | waxwing: this? http://www.metzdowd.com/pipermail/cryptography/2008-November/014818.html |
| 18:49:08 | waxwing: | must be. |
| 18:49:31 | waxwing: | you seem to be on top of things. i'll let you get on with it :) |
| 18:50:15 | kanzure: | nah that's just the bitcoin tumor in my head doing its job |
| 18:58:09 | op_mul: | I like the description of Bitcoin as a mental ailment. |
| 19:11:29 | justanotheruser: | 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:12:44 | faraka: | hello |
| 19:13:17 | op_mul: | justanotheruser: if you're relying on a remote peer to do filtering for you, sure there's nothing stopping that. |
| 19:13:24 | faraka: | what do you guys think of factom? |
| 19:14:10 | justanotheruser: | 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:13 | op_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:47 | Pan0ram1x: | Pan0ram1x is now known as Guest62639 |
| 19:16:52 | justanotheruser: | yeah, I was wondering if there was some solution to that. None are obvious to me |
| 19:18:18 | op_mul: | a way to ask peers for their full merkle tree? there's nothing pretty in any case. |
| 19:19:21 | justanotheruser: | 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:39 | op_mul: | just the merkle tree, not the transactions in it. |
| 19:19:59 | op_mul: | you'd know your own transaction, so you can fit it in and build a proof using it if you want. |
| 19:22:10 | amiller_: | justanotheruser, can the thin clients communicate directly to each other? |
| 19:25:25 | justanotheruser: | amiller_: I don't see why they couldn't |
| 19:26:42 | amiller_: | 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:19 | justanotheruser: | amiller_: that is what is done right now |
| 19:28:24 | justanotheruser: | but asking your peers deanonymizes you |
| 19:28:26 | faraka: | isn't factom a scam? |
| 19:28:36 | faraka: | wouldn't it be possible to do the same thing without a coin? |
| 19:28:49 | faraka: | a thir party is needed to verify existence of a physical object. |
| 19:29:17 | faraka: | a coin seems a redundant process |
| 19:29:28 | kanzure: | not all bad ideas are scams |
| 19:29:33 | amiller_: | 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:38 | kanzure: | and also, factom could be something other than a scam and still be a bad idea |
| 19:30:16 | justanotheruser: | amiller_: Well the best kind of anonymity is where only the sender knows you received it |
| 19:30:35 | op_mul: | amiller_: that's been shown to be almost totally ineffective. |
| 19:30:35 | faraka: | what would you propose as a better alternative kanzure? |
| 19:30:39 | justanotheruser: | If the sender is a full node he should send you the merkle branch |
| 19:31:06 | op_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:19 | kanzure: | 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:45 | faraka: | oh lol misread. sorry. |
| 19:31:54 | justanotheruser: | 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:11 | amiller_: | 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:15 | justanotheruser: | It will probably be easier to do this as sidechains are developed |
| 19:32:59 | amiller_: | 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:18 | op_mul: | amiller_: I think BIP37 should be deprecated. there's a better option. |
| 19:33:24 | kanzure: | amiller_: oh, i'm not sure if i meant to say that. |
| 19:33:35 | kanzure: | amiller_: oh wait, yes, you're right. some good ideas can be operated as scams. |
| 19:33:56 | faraka: | what's the development status on sidechains? |
| 19:37:53 | amiller_: | 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:34 | justanotheruser: | 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:22 | op_mul: | justanotheruser: using non-bip37 bloom filters does that anyway. |
| 19:40:00 | justanotheruser: | op_mul: hm? |
| 19:40:02 | op_mul: | you can sieve your cake and tell nobody about it. |
| 19:41:31 | justanotheruser: | hm |
| 19:41:40 | op_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:51 | justanotheruser: | They still need to ask for the merkle branch though? |
| 19:42:54 | op_mul: | I think phantomcircuit was talking about making a proof of concept, or had one, I can't remember |
| 19:43:00 | op_mul: | no, they download the whole block |
| 19:43:46 | justanotheruser: | oh, so they make their anonymity set every recipient in that block |
| 19:44:15 | op_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:15 | amiller_: | justanotheruser, better than that, the client doesn't reveal whether the client found what it was looking for in the block |
| 19:45:41 | amiller_: | nvm disgregard my last line |
| 19:46:25 | op_mul: | it reveals a little if you download the block straight from a peer that knows you are filtering. |
| 19:47:03 | dgenr8: | "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:27 | op_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:56 | op_mul: | it solves the problem of fully validating, but pruned nodes not being able to rescan a wallet. |
| 19:49:40 | op_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:15 | kanzure: | bitpay payment channel stuff http://impulse.is/impulse.pdf |
| 20:03:17 | dgenr8: | op_mul: i guess there's some room for disagreement on materially how far away from the original we are today |
| 20:04:18 | op_mul: | the bit about pruning spent transactions from merkle trees is outdated, you can agree on that |
| 20:15:54 | Pan0ram1x: | Pan0ram1x is now known as Guest28189 |
| 20:16:24 | op_mul: | op_mul has left #bitcoin-wizards |
| 20:24:16 | gmaxwell: | op_mul: the software never stored hash trees, sooo. |
| 20:36:58 | op_mul: | gmaxwell: yes, which makes part 7 of the whitepaper even more confusing. |
| 20:37:57 | gmaxwell: | 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:27 | op_mul: | right, hadn't realised that. sounds horrible to implement, though. |
| 20:42:27 | gmaxwell: | 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:56 | op_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:09 | gmaxwell: | nah. not really. |
| 20:59:24 | Profreid_: | Profreid_ is now known as Profreid |
| 21:06:17 | phantomcircuit: | gmaxwell, er that actually sounds non trivial unless you're relying the the fs to punch holes in the file efficiently |
| 21:06:21 | phantomcircuit: | (hint: they mostly dont) |
| 21:16:26 | imposter: | imposter is now known as satoshinakamoto |
| 21:23:17 | gmaxwell: | phantomcircuit: uh. you're overly constraining yourself. rewriting storage is no big deal. |
| 21:24:13 | d1ggy__: | d1ggy__ is now known as d1ggy |
| 21:36:29 | phantomcircuit: | gmaxwell, depends on whether you're pruning 1 tx at a time or not |
| 21:41:57 | rasengan: | rasengan has left #bitcoin-wizards |
| 22:35:40 | amiller_: | MRL-Relay, have you all thought of implementing private balances in cryptonote |
| 22:36:30 | amiller_: | MRL-Relay, you'd potentially cut way down on transaction size and also boost anonymity set |
| 22:43:04 | amiller_: | 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:35 | wallet42: | wallet42 is now known as Guest29993 |
| 22:57:35 | wallet421: | wallet421 is now known as wallet42 |
| 23:02:42 | amiller_: | 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:21 | nsh: | .wik groth sahai proof |
| 23:42:23 | yoleaux: | "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:50 | nsh: | .g Perfect Non-interactive Zero Knowledge ext:pdf |
| 23:42:51 | yoleaux: | http://www.cs.ucla.edu/~rafail/PUBLIC/71.pdf |
| 23:43:51 | nsh: | amiller_, any practical implementations of this latter (groth sahai) extant? |
| 23:44:36 | nsh: | * 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:06 | nsh: | nevertheless: |
| 23:49:06 | nsh: | -- |
| 23:49:09 | nsh: | 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:09 | nsh: | what is it measuring globally? |
| 23:49:09 | nsh: | 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:09 | nsh: | 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:13 | nsh: | (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:49:16 | nsh: | -- |
| 23:50:09 | nsh: | 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:31 | nsh: | so i was wondering if it would recall in someone something they could point me at to delve a bit deeper |
| 23:51:46 | nsh: | (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:00 | amiller_: | nsh, i don't know of any implementation of groth sahai proofs :( |
| 23:55:15 | amiller_: | nsh, isis lovecruft was beginning to implement them actually |
| 23:55:21 | nsh: | ah, hmm |
| 23:55:34 | amiller_: | i have a pretty good grasp of rsa group proofs and schnorr group proofs in general |
| 23:56:27 | amiller_: | a crs is required anyway so its not obvious if groth-sahai is better than rsa for whatever applicatin |
| 23:56:46 | amiller_: | by which i mean, a sensitive setup procedure ostensibly involving a trapdoor or else something complicated like a UFO is required |
| 23:57:03 | nsh: | right, there's an inherent trust-fragility to the set-up procedure |
| 23:57:25 | amiller_: | i think groth sahai should be doable though |
| 23:57:26 | kanzure: | nsh: there were a few phiosophers of statistis (like charles pierce?) but you might find that too ridiculous |
| 23:57:28 | nsh: | (which is not necessarily worse than the existing trust-fragilities of other sociotechnological systems, but unappealing) |
| 23:57:32 | kanzure: | *statistics |
| 23:57:55 | kanzure: | i think you can measure global hashrate by looking at infrared radiation |
| 23:57:58 | kanzure: | this places an upper bound |
| 23:58:22 | nsh: | 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:40 | nsh: | this is what allows a single point in the system to do a global measurement |
| 23:58:55 | nsh: | i think this is conceptually important, somehow, but i'm not sure exactly wht |
| 23:58:57 | nsh: | *why |
| 23:59:47 | nsh: | amiller_, is it conceivable that the universe somehow provides a CRS? |