00:01:12 wow 00:01:57 such theory 00:03:12 maybe I can extract some data from the gridseed folks to allow for a scrypt asic cost model that includes energy. 00:03:53 (what I can't just extract from their data sheets is how the energy usage scales with the memory hardness parameter, not without knowing how much of their power is used by the dram vs the rest.) 00:07:08 go1111111 has joined #bitcoin-wizards 00:09:13 Anyone have any tips on boarding in Miami Beach? :/ 00:09:44 don't tell them you have a bomb 00:10:29 … 00:10:34 s/boarding/lodging/ 00:12:24 sipa: the NSA will never let Luke-Jr board the plane now 00:12:41 NSA has no authority over that :P 00:13:35 TSA...NSA... just 3 bits difference 00:13:53 lol 00:15:11 I'm sure those guys get a shot at the no-fly list 00:20:27 go1111111 has quit 00:24:33 gmaxwell: I'm thinking of just hiring someone with ASIC design experience to look at this stuff frankly 00:25:16 gmaxwell: the EE I was talking to yesterday said he had some contacts 00:25:24 petertodd: actually having built a scrypt asic trumps abstract expirence. :P 00:26:29 justanotheruser has joined #bitcoin-wizards 00:27:49 adam3us: the FPGA overhead might get closer to ASIC overhead, but only in the sense of power limitations - you'll never get similar space limitations unless ASIC tech changes pretty drastically in ways that are rather unpredictable 00:28:38 gmaxwell: the ASIC was a single performance point - scrypt is tunable after all 00:29:00 justanotheruser1 has joined #bitcoin-wizards 00:29:29 petertodd: yes, but my _suspicion_ now that I've though about it is that the power usage per user-tolerance-unit will go down as memory usage increases. 00:29:46 esp once memory usage is high enough to not fit in cache on commodity hardware. 00:30:29 gmaxwell: as is mine, but does that make asics more or less attractive? potentially *less* if commodity dram can be tuned the way we want it to be 00:30:50 justanotheruser has quit 00:30:50 orperelman has quit 00:31:48 I don't follow your argument but I suspect its on an entirely different subject matter than I'm talking about. I'm specifically concerned with scrypt as a KDF here, and I think this thinking invalidates the argument given in the scrypt paper, and that the result might be that scrypt reduces security against a well funded attacker cracking your password. 00:31:52 gmaxwell: e.g. scrypt with 4GiB might stress random access latency so much that everything but the ram doesn't matter at all 00:32:35 gmaxwell: no, I'm talking about KDF's - they're an easier problem that ASIC-hard PoW functions 00:34:22 orperelman has joined #bitcoin-wizards 00:34:24 petertodd: right, and if the power costs dominate after N months of operation, and the custom cracker has 10 fold lower power usage than an alternative one that used the same amount of user-tolerance budget but used sha256, then it wouldn't be a win. 00:36:22 gmaxwell: that's the thing though, your random access related hardware needs to run at full power and high speed, so the rest of the system may not be a big difference in terms of power 00:36:53 gmaxwell: of course, down the road FRAM tech could blow all these assumptions out of the water too 00:38:35 petertodd: well one way of looking at it once thinking about energy— given commodity hardware is actually often made using state of the art technology, the task is to make the most use of the hardware the user has— so how can you make commodity hardware use the most energy possible. Grinding against dram is _not_ the way to do that. 00:39:08 on a desktop PC, sitting in a tight inner loop on the SIMD registers in the cpu is. 00:39:43 gmaxwell: Are you sure about that? Because I'm not. 00:40:06 what gmaxwell just said is definately, 100% true 00:40:16 waiting on the ram bus idles the CPU 00:40:19 gmaxwell: that *might* be true if the SIMD registers were power limited, but that's not at all a given 00:40:31 maaku: ram uses power to access 00:41:00 very, very little power by comparison 00:41:02 it does but the power distribution is just not compariable. you're talking about 20w vs 100 watts. 00:41:05 gmaxwell: the problem is if you're algorithm ever winds up not being power limited, then someone can go build an ASIC for it 00:41:37 petertodd: yea sure, the assumption I started out with is that the commidity hardware is already an efficient implementation of everything it does, which isn't true... indeed. 00:42:01 But to the extent its true the KDF problem is just a matter of using all thats available... use the most gates the most power.. etc. make the most use. 00:42:39 gmaxwell: yeah, and that's an enormous problem. I'm sure you can make a PoW/KDF algorithm that targets *a* cpu family and uses it 100%, but that's not very interesting - you'd just as easily use a KDF with very tunable params to economically stay ahead of attackers with ASIC-dev costs 00:42:46 is it plausable that energy costs would be a limiting factor or is this just a mental exercise? 00:43:02 poggy: it's plausible, but not certain 00:43:20 And if power costs dominate, you probably don't want to touch the memory at all... because the computer cannot burn 100watts accessing ram. and even if you imagine that its ALU is 4x less efficient than an optimized one, it probably still can burn more efficiency-weighed-power in the ALU. 00:44:05 poggy: it is the case that for computation tasks operating longer than a few months energy is more expensive than fabrication with modern processes. 00:44:25 ah ok 00:44:27 How that balances out exactly is another question. 00:44:47 You have to run for a long time before fabrication is negligible. 00:45:02 gmaxwell: but look at the system as a whole: quite possible the lower power density of ram per unit area is irrelevant on a system wide level because you can't necessarily remove head from higher density effectively anyway 00:45:39 s/head/heat/ 00:45:41 that works against the user, not against the attacker. 00:46:38 no, it works against the attacker for PoW for sure: removing low-grade heat cheaply with fans costs very little. For KDFs, that's less certain. 00:47:12 remember for PoW one argument for decentralization is that the heat can be useful - of course if someone comes out with a ASIC process that can run at hotter temps... 00:47:23 oh I misunderstood what you were saying, I was not arguing in terms of unit area. 00:47:32 I'm arguing in terms of whats actually in a PC. 00:47:50 are there any hybrid functions? 00:47:57 e.g. how much attacker joules can 1 second of a PC possibly require. 00:48:08 requiring both memory and gpu(or whatever) 00:48:34 And I believe that large memory memory hard requires fewer attacker joules simply because the PC only has— say— 20 watts of ram. 00:48:48 gmaxwell: ah, well that's a better argument come to think of it. 00:49:24 gmaxwell: although like I say, for the KDF use-case you might as well just make a whole bunch of them, targetted to specific cpu's 00:49:35 gmaxwell: use whatever one the user happens to have 00:50:56 gmaxwell: and... might as well make it memory-hard too, and get that extra 20W 00:52:22 petertodd: the premise under scrypt is really two fold: memory technology is uniform decreasing the attackers advantage, and that computers have a lot of gates as memory. Counter arguments are that once you are talking about power memory for a cracker might not be as uniform as thought, and when talking about power a computer doesn't actually have that much memory. 00:54:09 gmaxwell: yes, I'm not claiming that's a good premise, I'm claiming that in the case of a KDF *because* you have so much algorithm agility (make it a library!) optimal is to use a per-cpu-arch algorithm like your suggestion and make it depend on memory as well 00:54:36 gmaxwell: which means the salsa20 core in scrypt probably should be replaced by a series of algorithms that do well on simd 00:55:11 gmaxwell: dunno if you noticed but I did change my mind there :P 00:55:11 yea, sure, I don't think anything I've argued suggests that using memory is terrible, just that it may not be as automatically good as it seemed. 00:55:52 anyway, my *main* argument is that neither of us knows much about digital logic technology so... 00:56:42 sort of troubling that it seems no one has explored the energy cost angle on this. :-/ 00:56:56 would be ironic if the recommended scrypt parameters lowered attack costs. 00:57:33 meh, wouldn't be the first time 01:02:37 go1111111 has joined #bitcoin-wizards 01:09:59 orperelman has quit 01:10:34 DougieBot5000 has quit 01:15:08 go1111111 has quit 01:15:41 wallet42 has joined #bitcoin-wizards 01:29:09 Ursium has quit 01:29:30 Ursium has joined #bitcoin-wizards 01:42:11 Muis has quit 01:42:38 Muis has joined #bitcoin-wizards 01:46:25 huh that's interesting 01:46:34 gmaxwell, i think cex.io moved all their hardware 01:47:11 phantomcircuit: interesting! 01:54:14 jtimon has quit 02:07:00 jps has quit 02:14:13 justanotheruser has joined #bitcoin-wizards 02:16:44 justanotheruser1 has quit 02:19:09 justanotheruser has quit 02:27:50 justanotheruser has joined #bitcoin-wizards 02:38:38 go1111111 has joined #bitcoin-wizards 02:49:24 justanotheruser1 has joined #bitcoin-wizards 02:50:13 justanotheruser has quit 02:50:41 justanotheruser has joined #bitcoin-wizards 02:50:51 justanotheruser has quit 02:50:52 justanotheruser has joined #bitcoin-wizards 02:54:14 justanotheruser1 has quit 03:00:00 wallet421 has joined #bitcoin-wizards 03:00:00 wallet42 is now known as Guest95284 03:00:00 Guest95284 has quit 03:00:00 wallet421 is now known as wallet42 03:11:26 <_ingsoc> _ingsoc has joined #bitcoin-wizards 03:22:51 <_ingsoc_> _ingsoc_ has joined #bitcoin-wizards 03:24:10 <_ingsoc> _ingsoc has quit 03:25:04 <_ingsoc_> _ingsoc_ is now known as _ingsoc 03:38:59 <_ingsoc> Does anyone remember that guy who talked about rewarding miners for putting energy into the grid? 03:45:57 _ingsoc: seems interesting, but not sure how you can prove you put energy into the grid 03:47:00 go1111111 has quit 03:47:10 <_ingsoc> That was the problem if I remember correctly, needed some physical layer. 03:59:49 go1111111 has joined #bitcoin-wizards 04:19:31 mappum has joined #bitcoin-wizards 04:26:28 andytoshi has joined #bitcoin-wizards 04:32:06 <_ingsoc> _ingsoc has quit 04:34:13 qwertyoruiop has quit 04:37:35 rdymac has quit 04:37:44 justanotheruser1 has joined #bitcoin-wizards 04:38:53 justanotheruser2 has joined #bitcoin-wizards 04:38:53 justanotheruser2 has quit 04:38:53 justanotheruser2 has joined #bitcoin-wizards 04:40:43 justanotheruser has quit 04:42:13 justanotheruser1 has quit 04:42:27 rdymac has joined #bitcoin-wizards 04:49:29 go1111111 has quit 04:52:18 qwertyoruiop has joined #bitcoin-wizards 05:24:54 zacm has quit 05:25:42 zacm has joined #bitcoin-wizards 05:31:14 <_ingsoc> _ingsoc has joined #bitcoin-wizards 05:31:15 <_ingsoc> _ingsoc has quit 05:32:53 <_ingsoc> _ingsoc has joined #bitcoin-wizards 05:36:09 go1111111 has joined #bitcoin-wizards 05:47:44 zacm has quit 05:52:25 zacm has joined #bitcoin-wizards 06:28:19 midnightmagic has quit 06:29:49 midnightmagic has joined #bitcoin-wizards 06:41:36 justanotheruser2 has quit 06:58:05 <_ingsoc> _ingsoc has quit 07:36:14 MoALTz_ has quit 07:37:03 MoALTz_ has joined #bitcoin-wizards 08:21:49 <_ingsoc> _ingsoc has joined #bitcoin-wizards 08:26:48 Ursium has quit 08:37:57 <_ingsoc> _ingsoc has quit 08:42:21 <_ingsoc> _ingsoc has joined #bitcoin-wizards 08:42:46 <_ingsoc> _ingsoc is now known as Guest12197 08:43:38 Guest12197 has quit 08:43:59 <_ingsoc_> _ingsoc_ has joined #bitcoin-wizards 08:46:51 zacm has quit 08:48:00 zacm has joined #bitcoin-wizards 08:55:19 mappum has quit 08:56:36 wrabbit has quit 08:57:16 wrabbit has joined #bitcoin-wizards 08:57:29 Ursium has joined #bitcoin-wizards 09:06:13 midnightmagic has quit 09:06:13 Graet has quit 09:11:19 midnightmagic has joined #bitcoin-wizards 09:11:20 Graet has joined #bitcoin-wizards 09:12:13 rdymac has quit 09:13:48 midnightmagic has quit 09:13:48 Graet has quit 09:14:13 roidster has quit 09:15:35 midnightmagic has joined #bitcoin-wizards 09:18:01 Ursium has quit 09:20:32 midnightmagic has quit 09:22:05 midnightmagic has joined #bitcoin-wizards 09:23:45 <_ingsoc> _ingsoc has joined #bitcoin-wizards 09:25:55 <_ingsoc_> _ingsoc_ has quit 09:27:37 <_ingsoc> So, get a hold of this Ethereum! 09:27:39 <_ingsoc> Thoughts? 09:35:18 jtimon has joined #bitcoin-wizards 09:40:40 Graet has joined #bitcoin-wizards 09:43:28 Ursium has joined #bitcoin-wizards 09:45:33 adam3us1 has joined #bitcoin-wizards 09:49:02 Ursium has quit 09:50:08 adam3us has quit 09:50:58 adam3us has joined #bitcoin-wizards 10:01:15 adam3us has quit 10:05:00 <_ingsoc> _ingsoc has quit 10:06:57 <_ingsoc> _ingsoc has joined #bitcoin-wizards 10:08:09 hnz has quit 10:12:19 hnz has joined #bitcoin-wizards 10:16:46 <_ingsoc> _ingsoc has quit 10:17:24 <_ingsoc> _ingsoc has joined #bitcoin-wizards 10:17:48 Ursium has joined #bitcoin-wizards 10:23:47 orperelman has joined #bitcoin-wizards 10:42:58 Ursium has quit 10:59:29 adam3us has joined #bitcoin-wizards 11:00:10 Special ones.. I am loving ou now. 11:05:29 <_ingsoc_> _ingsoc_ has joined #bitcoin-wizards 11:06:56 <_ingsoc> _ingsoc has quit 11:23:37 ssshhh has left #bitcoin-wizards 11:33:26 Coinsey221 has joined #bitcoin-wizards 11:36:32 Coinsey221 has quit 11:43:14 <_ingsoc_> _ingsoc_ has quit 11:44:03 Coinsey221 has joined #bitcoin-wizards 11:48:07 Coinsey221 has left #bitcoin-wizards 11:53:04 Ursium has joined #bitcoin-wizards 12:04:35 TD has joined #bitcoin-wizards 12:13:57 vdo has joined #bitcoin-wizards 12:19:54 andytoshi has quit 12:26:20 Ursium has quit 12:32:32 adam3us: schnorr multisignature seems to be naturally sidechannel busting. 12:32:52 adam3us: e.g. you do 2-of-2 with the hardware wallet signing first... and the final R,S could be anything. 12:33:36 and avoids the other complexities with the device knowing what its signing when the signature is blind. 12:33:37 gmaxwell: yes. i mentioned two variants of the wallet observer thing on https://bitcointalk.org/index.php?topic=428494.new#new 12:34:06 gmaxwell: the basic one that brands talks about uses blind sig so the wallet has no subliminal channel 12:34:50 gmaxwell: but using brands ZKP issuing protocol, you can also prove to the wallet what it is blind signing, so it can show it on screen for approval with a hw wallet with screen like trezor, and STILL not have a subliminal channel 12:35:30 gmaxwell: i'm sure brands covered that somewhere in his thesis, the guy is exhaustively inventive. 12:36:09 gmaxwell: but yeah the subliminal channel freedom is beautiful thing to have as a building block 12:37:51 adam3us: Right but I believe that a regular 2 of 2 threshold signature has the same sidechannel elimination effect without requring the ZKP proof of what its signing. 12:38:25 gmaxwell: ah gotcha. yes that appears to be true also :) and nice and simple 12:45:57 TD has quit 12:50:03 wallet42 has quit 12:50:56 TD has joined #bitcoin-wizards 12:52:17 gmaxwell: btw other than adding cc other authors, about the private key issue, another step could be to make an ID / RFC on EdDSA as a complement to the safe curve focused ID that Watson Ladd on IRTF CFRG is doing. i thnk the lowest 3 bits=0 is just a optimization, I dont immediately see why that cant be removed and multiply by 8 somewhere in the verification relation, and the bit 254 I think is just defensiveness 12:53:34 gmaxwell: ie bit 254 is not necessary for security, just that the montgomery ladder start at bit 254 whether its 0 or 1 to avoid a timing side-channel. thats all if anyone had time/energy for an RFC process but it would be a natural way to extract feedback from the algorithm authors 13:02:29 <_ingsoc> _ingsoc has joined #bitcoin-wizards 13:10:37 skinnkavaj has joined #bitcoin-wizards 13:17:24 wallet42 has joined #bitcoin-wizards 13:23:27 <_ingsoc> _ingsoc has quit 13:52:40 shesek has quit 13:53:59 adam3us has quit 13:55:35 rdymac has joined #bitcoin-wizards 14:00:46 TD has quit 14:07:13 TD has joined #bitcoin-wizards 14:12:55 andytoshi has joined #bitcoin-wizards 14:41:17 adam3us has joined #bitcoin-wizards 14:45:40 TD has quit 14:46:20 <_ingsoc> _ingsoc has joined #bitcoin-wizards 15:00:25 adam3us has quit 15:14:50 gavinandresen has joined #bitcoin-wizards 15:15:12 TD has joined #bitcoin-wizards 15:21:37 TD has quit 15:25:09 wallet421 has joined #bitcoin-wizards 15:25:10 wallet42 has quit 15:25:10 wallet421 is now known as wallet42 15:25:32 adam3us has joined #bitcoin-wizards 15:28:01 roidster has joined #bitcoin-wizards 15:28:15 roidster is now known as Guest66358 15:28:42 ghtdak has quit 15:33:49 otoburb has joined #bitcoin-wizards 15:59:11 DougieBot5000 has joined #bitcoin-wizards 16:42:28 adam3us has quit 17:00:02 vdo has quit 17:04:39 nsh has quit 17:05:46 adam3us has joined #bitcoin-wizards 17:09:10 <_ingsoc> _ingsoc has quit 17:11:05 <_ingsoc> _ingsoc has joined #bitcoin-wizards 17:12:05 nsh has joined #bitcoin-wizards 17:12:21 nsh has quit 17:12:22 nsh has joined #bitcoin-wizards 17:24:18 MoALTz_ has quit 17:24:41 MoALTz has joined #bitcoin-wizards 17:25:18 maaku,what if we start with the private chains? http://freicoin.freeforums.org/freimarkets-t717.html#p6913 17:25:47 not sure if wrong forum or not...I'll say the same on #freicoin just in case 17:38:51 warren has quit 17:43:58 warren has joined #bitcoin-wizards 18:29:51 wallet42 has quit 18:39:55 ielo has joined #bitcoin-wizards 19:00:29 jtimon has quit 19:07:55 andytoshi has quit 19:12:38 lol twister: https://groups.google.com/d/msg/twister-dev/h2ukT1msggc/Jbh-UPYPGiIJ 19:12:44 "May someone suggest a good free captcha generator for text that is OCR 19:12:47 resistant?" 19:12:59 apparently they have a namesquatting problem... 19:13:24 they also have implemented ripple-style soft-consensus to prevent rewrite attacks 19:13:53 uh.. how does that work with anonymous participation? 19:14:08 good question! 19:14:15 that's the lead dev suggesting that! 19:15:13 they don't even use namecoin-style two-stage commit-reveal, so an attacker can watch the network for new name registrations and register all new names for themselves 19:15:52 lol 19:16:25 facepalm 19:16:49 I almost want to fire up some ec2 instances and 51% the network with empty blocks just to see how they'll react - it's a social experiment at this point 19:17:06 I think I like how with namecoin, if two people register the same name concurrently, both lose their coins ;) 19:17:17 I take it this isn't merged mined? 19:17:21 gmaxwell: nope 19:17:31 sha256 pow? 19:17:32 Guest66358 has quit 19:17:50 gmaxwell: and they changed the block header so standard scryptminers don't work, but with some effort you can still modify litecoin scrypt miners to mine it 19:18:01 ah. scrypt. 19:18:02 gmaxwell: they added CBlockHeader.nHeight 19:18:14 roidster has joined #bitcoin-wizards 19:18:25 and just made the header a bit longer or? 19:18:35 but they left nVersion=2 and the supermajority code in for nVersion=2! 19:18:38 gmaxwell: yup 19:18:54 that probably actually won't break the gridseed asics, the work generator is apparently microcoded. 19:19:00 gmaxwell: I haven't looked into how hard it'd be to adapt a scrypt miner to that 19:19:04 gmaxwell: oh nice! 19:19:34 (they have an on chip work generator and increment logic which is apparently all microcoded) 19:20:54 gmaxwell: amir was trying to convince them to just use namecoin 19:21:26 namecoin codebase is nearly unmaintained. :( 19:21:39 twister codebase is worse than unmaintained 19:21:40 jps has joined #bitcoin-wizards 19:22:57 andytoshi has joined #bitcoin-wizards 19:23:01 hopefully once scrypt mining asics exist in large enough quantities to have driven everyone off gpu mining people will go back to making merged mined things. 19:23:43 meh, merge-mining is no perfect solution either - just makes it easy to be attacked early on 19:24:05 petertodd: changes who can attack, for something which isn't compeating with bitcoin it's probably fine. 19:24:40 gmaxwell: you can be in trouble by competing with another merge-mined system you realize... 19:25:24 perhaps, but it's not clearcut. if 60% of your hashrate is really bitcoin miners who totally don't give a shit about any of these things attacking becomes hard. 19:25:47 gmaxwell: I think scrypt mining asics will just drive people to a wakier-proof-of-work-coin (Quark maybe). 19:26:42 gmaxwell: easy to start offering people >100% paying shares to quickly buy hashing power for an attack 19:26:51 gavinandresen: Thats a point! "DDD coin's Proof Of Work involves ringing peoples doorbells and running." 19:27:10 gmaxwell: lol 19:33:10 gmaxwell: anyway, I think I've got my "tree-chains" concept in decent shape: blockchian is a sharded tree, each node in the tree has left and right leaves that are half the difficulty of the parent node/chain. have participants have consensus about the contents of the blocks in the parent chain, and the blockheaders for left and right. the rule for left and right child chains is that full-diff PoW solution "locks" the order of the chain, so ... 19:33:16 ... re-ordering takes 51% with respect to the parent work. However contents are subject to 25% majority. You solve the "lost-data" problem by allowing the mining of a challenge - a tx that you want to see mined - and that tx must either be proved to be not minable (e.g. succinct MMR TXO) or prove that the tx was mined. If nothing happens, eventually the child chain can be re-orged. 19:34:20 Guest72236 is now known as jarpiain 19:34:30 Security guarantees are resistant to 50% attack for re-ordering transactions, 25% for censorship - however you can pay higher fees/work to force a tx to get mined. Done recursively you *will* get to the point where the PoW effort is too low to be secure, but at least that's an adjustable parameter. 19:34:53 It looks like merge-mining in a sense, but the challenge rule improves the security guarantees. 19:35:30 Dunno yet how you'd spend coins from one multi-level deep child chain to a different one - easy to think of cases where you allow inflation attacks. 19:35:31 dlidstrom has joined #bitcoin-wizards 19:37:04 gmaxwell: Note how all this is easiest to think about with per-tx work - IE one block == one tx. Also easiest to think about it in practice as a token transafer system - how you'd use it with unrestricted values is an interesting question given the inflation issue. 19:50:58 orperelman has quit 19:54:58 selifanoff has joined #bitcoin-wizards 19:55:13 selifanoff has quit 20:34:48 <_ingsoc> _ingsoc has quit 20:35:10 <_ingsoc> _ingsoc has joined #bitcoin-wizards 20:52:41 grazs has joined #bitcoin-wizards 21:09:55 wallet42 has joined #bitcoin-wizards 21:13:40 shesek has joined #bitcoin-wizards 21:19:19 orperelman has joined #bitcoin-wizards 21:26:16 jps has quit 21:29:04 <_ingsoc> _ingsoc has quit 21:36:06 RoboTeddy has joined #bitcoin-wizards 21:39:33 <_ingsoc> _ingsoc has joined #bitcoin-wizards 21:39:55 <_ingsoc> _ingsoc has quit 21:40:16 <_ingsoc> _ingsoc has joined #bitcoin-wizards 21:46:23 jps has joined #bitcoin-wizards 22:17:08 arbart has joined #bitcoin-wizards 22:17:50 what is the state of the art of enabling microtransactions? 22:22:59 bitcoin (at the protocol level) isn't designed for microtransactions 22:23:45 qwertyoruiop has quit 22:27:49 arbart, trust a third party 22:27:55 remember that the transactions are micro 22:30:57 #bitcoin-dev please, btw 22:31:18 sipa, cool, that is what i was wondering then i guess 22:31:42 and alright, what is the purpose of this channel then, I thought it was similar? 22:33:04 this channel is more like extreme advanced stuff that isn't really practical :p 22:33:33 well that is what I like :) 22:33:58 arbart: oh, i misread your line 22:34:21 i thought you said "what is the state of enabling microtransactions", which would apply to bitcoin-as-it-exists today 22:34:34 for state-of-the-art, there are some more interesting ideas 22:34:40 like probabilistic transactions 22:34:58 yes, now you are talking :) why i came here 22:36:56 probablistic transactions are more of a social/political challenge than a technical one. (I think the lottery protocols iddo/adam3us worked on can basically be applied directly to create a probablistic payment) 22:37:17 ah interesting, i didn't find this before, now searching 'probabilistic transactions', i find much stuff! sipa, thank you already! 22:37:59 arbart: gmaxwell certainly has more state about it than i do 22:39:21 gmaxwell: what is the social/political challenge you see with it? 22:39:33 … 22:39:57 arbart: 'probabilistic transactions' essentially means 9 times out of 10, you get nothing, and the 1 other time you get a penny 22:40:17 arbart: Many people seem to not regard a probablistic payment as a payment. 22:41:35 ok, i'm starting to see. reading https://bitcointalk.org/index.php?topic=62558 right now. 22:43:53 gmaxwell: many seem to not regard playing lotto as paying tax either 22:46:00 sipa: People are implementing batch DSA verification in this thread: https://bitcointalk.org/index.php?topic=427025.0 22:46:04 it is interesting so far :) 22:46:29 i understand it now 22:47:41 gmaxwell: how do they overcome not knowing R.y? 22:47:54 i think i am in -wizards and not -dev is because stuff like that gmaxwell is good to have, but not enough a solution, something more extreme :) is needed 22:48:57 sipa: brute force. 22:49:20 i suppose it is hard to tell though, that looks interesting, and combined with pruning and all, might be enable native nanotransactions 22:50:03 arbart: pruning doesn't make the bandwidth problem go away unfortunately 22:50:07 sipa: basically you guess the sign and test and apparently this still comes out ahead. 22:50:19 arbart: native nanotransactions 22:50:27 doesn't really sound sensible in a global consensus system. 22:50:32 :) 22:50:47 Now, you can do things to perform them non-globally and that perhaps becomes more interesting. 22:50:50 hmm :) 22:50:57 arbart: now, an interesting question is if you really need global consensus? I think there are blockchain structures that don't 22:51:00 ahh, right 22:51:17 So there are a couple paths to relaxing that which have different tradeoffs. 22:51:22 arbart: right now just trusting a third-party is probably far more practical 22:51:45 maybe global checkpointing, but only local is interested in the details usually, etc? 22:52:00 arbart: trusting third-parties and non-global-consensus blockchains have interesting convergence re: security I suspect 22:52:13 are you just stringing words togeather? :P 22:52:17 i understand the third-party thing, another avenue im interested in 22:52:19 arbart: global *ordering* is a better term 22:52:50 arbart: heh, lets see if I can explain my pet idea to you re: tree-chains... so imagine you have a blockchain, and you merge mined two child chains with it, left and right. 22:52:57 only out of the necessity you think is there 22:52:57 arbart: you know what merge-mine means? 22:53:31 ok, i get that term 22:53:50 petertodd: not yet 22:54:23 mining: I find a pow solution so that my block will be part of the consensus 22:54:55 merge-mining: the rules of the system let me re-use a pow solution from a different consensus system, letting me do one bit of work, yet get two blocks from two different systems 22:54:56 ok, intuitive :) 22:55:40 merge-mining is implemented by just letting you prove the block solution for sytem #2 by showing a merkle path through some tree that terminates in the blockheader for system #1 22:55:51 (namecoin does this) 22:56:11 ok, i was guessing that, so i think i got it :) 22:56:55 right, so we have the parent chain, and two child chians, left and right, got that? you can mine the parent chain, or the parent chain and the left chain, or parent and right chain (in our system) 22:57:05 petertodd: was just about to prod you :) 22:57:15 basically it's *exclusive*, you can only mine the left *or* right child chain (or neither) 22:57:31 oh ok, noted 22:58:03 this means the work done on these child chians will tend to be half that of the parent (assuming the reward is halved for instance) 22:58:44 however, this also means that a given miner only needs the data, and thus bandwidth, cost of the parent and one child. so the total # of transactions in both children can be higher and the system still works 22:59:06 the downside is that transactions in either child chain have less security, it only requires 25% of the hashing power to reorg that chain as the parent chain 22:59:20 got that? 22:59:53 oh wow, yes, a load balancing mechanism :) thinking about the security aspect though 23:00:50 yeah, so we've figured out how to make it more scalable, now, what about the security? well, lets make a new rule! if a pow solution for a child chain *also* meets the difficulty of the parent, we say that block is fixed - it's only allowed to be reorganized if the parent chain itself gets reoganized 23:01:14 now it takes 50% of total hashing power to attack the child chain right? nope 23:01:19 can you guess why? 23:01:21 i guess im missing the reorganized part 23:02:04 reorg just means work is done to extend a block other than the current best block, so when your node learns about the longer chain, suddenly the shorter one is made invalid by definition 23:02:14 well at least because only half the network is working on each side of the chain? 23:02:17 remember, the problem bitcoin is trying to solve is consensus on what's the longest chain 23:02:25 <_ingsoc> _ingsoc has quit 23:02:36 ah nice okay, was just missing that definition 23:02:42 arbart: sure, but an attacker can still get some hashing power somehow and reorg one of those child chians, and they only need 25% of the total hashing power to do that 23:02:43 or word i mean 23:03:17 good 23:03:40 ah right, half of half, got it now. 23:03:48 yup 23:04:04 petertodd: you coming to Miami? 23:04:23 so here's the question: with this fancy "parent chain locks things" scheme, why can the child chain be still attacked with just 25% hashing power? 23:04:33 Luke-Jr: isn't that, like, right now? 23:04:38 petertodd: tomorrow :p 23:04:52 Luke-Jr: heh, nah, tomorrow's my last day of work, couldn't make it 23:05:12 Luke-Jr: how long does it go? I guess I could strictly speaking... :P 23:05:13 Saturday and Sunday is the main conference! :p 23:05:24 Luke-Jr: heh, nah, too tight 23:05:27 hmm, that is a sucky result, a good question to analyze, in order to make sure it is right :) 23:05:30 Friday is just the pre-conference thing 23:05:43 arbart: Well, lets think this through: what does attack mean anyway? 23:06:14 arbart: So, I could attack the chain by making only empty blocks and make it useless, I could also attack it by reorganizing it and double-spending transactions... but there's one other thing I can do. 23:06:29 well the value of what they are attacking is also half i suppose. that counts for enough to throw the game theory? 23:06:39 orperelman has quit 23:06:42 petertodd: the first case is debatable 23:06:54 arbart: maybe! but what if they're just assholes and want to burn the world? 23:07:02 arbart: we might as well know how much said assholes need to spend 23:07:12 so the one you didn't list is to just not allow new txs to be added? 23:07:19 Luke-Jr: for sake of argument, we'll say empty blocks are an attack 23:07:25 arbart: yup 23:07:26 "making only empty blocks and make it useless" 23:07:36 ok, heh, that is the main one i knew about 23:07:46 arbart: oh, sorry, no, there's one I didn't list that's more subtle 23:08:03 petertodd: ok, i understand, and agree with that knowledge being valueable! 23:09:01 arbart: I'll give you a hint: this rule where a particularly good PoW "locks" in the chain, how would you actually implement that? 23:10:09 oh my, so put in their own entire child chain? 23:10:46 well, here's the big thing: in this scheme I'm assuming that miners mining these child chains also have full consensus on the parent, and all associated data 23:10:58 i wondered about the exact implementation of what you asked there, but did not forumlate or see how it is done yet. 23:11:09 yeah, implementation is critical 23:11:20 ok, 23:11:32 i was thinking it wouldn't be that easy for my fear there 23:11:35 jps has quit 23:11:41 see, I'm thinking that the fact that a child block was found would be known from examining *just* the parent blockchain, IE, put the child blockheaders in the parent blocks 23:12:42 makes sense, it is a worked on (child) block with provable difficulty, some hash of it in the parent blockchain, something like that right? 23:13:24