| 05:03:38 | Luke-Jr: | * Luke-Jr ponders if it would be a good idea to make a webwallet-resistent cryptocurrency :P |
| 05:04:36 | gmaxwell: | for that goal? no. for that goal you want webwallet resistant users— and I suspect the bitcoin webwallets will eventually make a bunch of those. |
| 05:21:03 | petertodd: | https://github.com/zack-bitcoin/basiccoin |
| 05:21:12 | petertodd: | "The smallest currency I can make" |
| 05:21:36 | petertodd: | gmaxwell: sometimes webwallets have better security than what the user would be using after all... |
| 05:26:15 | andytoshi: | it would be cool if we could use bitcoin as a killer app for browser extensions which do digital signatures, decryption etc. |
| 05:26:18 | andytoshi: | and kill passwords |
| 05:26:45 | petertodd: | it'd be cooler if someone could explain why exactly that will help things... |
| 05:28:21 | andytoshi: | i dream that it'd stop users from getting key material out of their own heads, and using challenge/response instead of transmitting passwords means less damage from server compromise |
| 05:28:57 | petertodd: | google auth does that too |
| 05:42:47 | petertodd: | gmaxwell: "sane subset"? "upgrade safe"? |
| 05:43:03 | petertodd: | "soft-fork safe"? |
| 05:46:10 | midnightmagic: | I've always wanted more universal client-cert identity authentication.. |
| 05:48:56 | gmaxwell: | petertodd: I'm not sure I like sane just because sane often means more opinion than this is... One of the reasons for extracting this stuff from IsStandard is the hope that people who disable IsStandard don't go disabling it. softfork-safe might be good. |
| 05:52:30 | petertodd: | softfork-safe it is then - the process of upgrading is certainly trick enough as it is given there's no way for a miner to prove what they'll do after the majority is reached... |
| 05:55:49 | gmaxwell: | well, it's your own interest to be with the majority so... |
| 05:56:22 | petertodd: | yes, but if you don't like where the majority is going, you can slow them down with fud about whether or not the upgrade will work |
| 05:57:24 | gmaxwell: | oh right you can claim to not follow and follow anyways, sure. |
| 05:57:47 | petertodd: | indeed, or conversely, claim others are doing that! |
| 05:58:22 | gmaxwell: | though really, thats always true in a soft forking change. It's a bit coercive that way. |
| 05:58:23 | petertodd: | ultimately nVersion is a gentleman's agreement |
| 05:59:33 | gmaxwell: | petertodd: it should probaby be 1/10th fwiw, since the size limit we do is 1/10th the maximum, so if you translat the sigs into size scaled for an equal portion of the limit, thats where you end up. |
| 06:00:39 | petertodd: | gmaxwell: actually that's why I picked 1/5th: a transaction consisting of a single input and a pile of outputs works out to be ~35 bytes per sigop, comfortably over the margin so existing software won't notice |
| 06:02:31 | petertodd: | (notice how there's your incentive for having lots of inputs for once!) |
| 06:02:38 | gmaxwell: | well the limit ratios are 1e6/2e4 = 50 bytes. You can't actually usefully code one sigop per 50 bytes. the minimum is ~75 unless you're doing psycho stuff like having signatures in the script pubkey. :P |
| 06:03:15 | petertodd: | but remember that sigops in *outputs* count too, which was an insane design decision, but that's what happened |
| 06:03:29 | petertodd: | in fact, originally it was only outputs, which is just backwards |
| 06:04:16 | gmaxwell: | ah, I had indeed forgotten about that. |
| 06:05:02 | petertodd: | that's because as you get older your brain discards information that doesn't make sense |
| 06:05:27 | gmaxwell: | hahah |
| 06:05:55 | gmaxwell: | Well I did remember that it counted crap in the coinbase. |
| 06:06:38 | petertodd: | indeed, you remembered the weird oddity, but not the WTF staring right at you :P |
| 09:41:08 | Vitalik_: | Vitalik_ is now known as r |
| 09:41:15 | r: | r is now known as Vitalik |
| 11:50:28 | Anduck_: | Anduck_ is now known as Anduck |
| 13:41:57 | jgarzik: | amiller, we need a countdown clock for the predicted change away from 2xsha256... the change is coming soon! |
| 13:42:00 | jgarzik: | https://storify.com/socrates1024/bitcoin-pow-bet-10btc-jgarzik-vs-dakami-may-2014?utm_source=t.co&utm_content=storify-pingback&utm_campaign=&awesm=sfy.co_db4W&utm_medium=sfy.co-twitter |
| 14:29:09 | stqism: | stqism is now known as mahkoh |
| 15:36:06 | kdomanski__: | kdomanski__ is now known as kdomanski |
| 15:36:29 | kdomanski: | kdomanski is now known as kdomanski__ |
| 15:36:38 | kdomanski__: | kdomanski__ is now known as kdomanski |
| 16:07:57 | ryan`c: | ryan`c is now known as ryan-c |
| 16:38:08 | Quanttek_: | Quanttek_ is now known as Quanttek |
| 16:51:22 | Quanttek_: | Quanttek_ is now known as Quanttek |
| 17:03:17 | michagogo|cloud: | jgarzik: congratulations on winning the bet |
| 17:03:29 | michagogo|cloud: | (though IMHO it was really a no-brainer) |
| 17:29:44 | sipa: | which bet? |
| 17:30:58 | shesek: | sipa, https://storify.com/socrates1024/bitcoin-pow-bet-10btc-jgarzik-vs-dakami-may-2014 |
| 17:31:23 | shesek: | that the PoW would be changed by this month |
| 17:31:33 | shesek: | PoW function, that is |
| 17:31:49 | sipa: | oh yes, i remember; i was there :D |
| 17:34:33 | jgarzik: | michagogo|cloud, I think technically it is not won until May 19th, or to be generous, the end of May. |
| 17:36:05 | midnightmagic_: | midnightmagic_ is now known as midnightmagic |
| 17:36:34 | michagogo|cloud: | jgarzik: okay, but we aren't going to have a hardfork in the next 3 weeks. |
| 17:36:55 | michagogo|cloud: | I'm willing to bet on it :-) |
| 17:39:08 | jgarzik: | dakami is fun but a bit of a ham. People invite him to conferences to be dramatic. |
| 17:39:39 | jgarzik: | But if someone thought-balloons a ridiculous notion, it's worth throwing a dart at it. |
| 17:39:56 | benji: | cheers everyone |
| 17:40:07 | benji: | benji is now known as Guest70575 |
| 17:41:05 | Guest70575: | I've been outside the bitcoin space on sabbatical for about 8 months. Anything new on the technology side that's interesting? |
| 17:42:45 | Guest70575: | Ok then I'll start, I noticed two new things NxT and Ethereum |
| 17:42:48 | Guest70575: | any opinions? |
| 17:43:37 | sipa: | NxT: ignore |
| 17:43:55 | Guest70575: | The distribution looked a little P&Dish |
| 17:44:25 | Guest70575: | From the source that I was to see, it looks like pretty rubbish java code |
| 17:44:57 | Guest70575: | Why are a lot of people praising it? Sockpuppets? |
| 17:45:49 | sipa: | ethereum: one of the first that actually innovate and experiment, though I feel they're not focussing on the right problems (kitchen sink of features, without investigating the impact on scalability and trustlessness), and too much marketing :) |
| 17:46:33 | Guest70575: | Yeah I saw this Ethereum thing. Who's behind it? |
| 17:48:12 | jgarzik: | sipa, ethereum -- good on ideas, fail on over-marketing, over-hyping, and IPO'ing. And I'm not a fan of a few of the hangers-on. |
| 17:48:22 | tacotime: | Charles H formerly of Invictus is running that show |
| 17:48:57 | Guest70575: | Not familiar with him. Any good? |
| 17:49:10 | Guest70575: | I heard Vitalik from Bitcoin Mag is also there |
| 17:49:49 | tacotime: | vitalik is part of the dev team yeah |
| 17:49:53 | tacotime: | (and is also here) |
| 17:50:15 | tacotime: | http://www.linkedin.com/pub/charles-hoskinson/29/983/662 |
| 17:50:42 | Guest70575: | yeah I saw him on the intro video. Not much is online about him besides that |
| 17:50:45 | gmaxwell: | Hoskinson is sleezy. I think most of the non-technical people involved with ethereum are sleezy. |
| 17:51:09 | gmaxwell: | Guy tried strong arming me into endorsing one of his prior altcoin ventures. |
| 17:51:33 | gmaxwell: | But thats more or less orthorgonal with the technology. |
| 17:51:50 | Guest70575: | @gmaxwell has he done anything sleezy with ethereum? I saw that Koblitz is listed on their website |
| 17:51:52 | gmaxwell: | (except to the extent that sleezy behavior lands folks in court before the work is done) |
| 17:52:12 | tacotime: | ethereum is marketed rather heavily. |
| 17:52:19 | jgarzik: | over- |
| 17:52:24 | tacotime: | heh. |
| 17:52:26 | Guest70575: | @tacotime so mostly just hype then? |
| 17:52:30 | jgarzik: | IPO pimping |
| 17:52:59 | sipa: | * sipa has an Ethereum t-shirt |
| 17:53:01 | tacotime: | Guest36916, for now I suppose, I'm not an IPO fan but maybe it will work out well for them. |
| 17:53:03 | sipa: | does that say enough? |
| 17:53:07 | tacotime: | hahaha. |
| 17:53:17 | tacotime: | bitcoin expo? i had one too, gave it to my friend. |
| 17:53:19 | Guest70575: | They have t-shirts? lol |
| 17:53:32 | pigeons: | they had t-shirts before they had code i believe |
| 17:53:41 | sipa: | gave them away for free when they attended the zurich bitcoin meeting |
| 17:53:46 | Guest70575: | Has anyone gone through the code itself or looked at the design |
| 17:53:48 | gmaxwell: | I consider ethereum's marketing to be dishonest. It conviently confuses people about whats possible or what they're attempting and leaves them that way, but meh. In general I'm highly skeptical about that kind of funding model, I don't think it's ethical to ask for large unfront investments from the general public. |
| 17:53:51 | Guest70575: | They are in switzerland? |
| 17:54:31 | tacotime: | Guest36916, yeah, I have no idea how their banking is setup but I don't think it's anything North American. |
| 17:54:49 | gmaxwell: | Guest70575: the latest design documents don't have much to do with the publish code. It's been redesigned so many times at this point that I doubt many people are paying attention anymore— it's good that they're evolving their design, don't get me wrong, but it makes it unreasonable to review. |
| 17:55:01 | gmaxwell: | s/publish/published/ |
| 17:55:26 | tacotime: | gmaxwell, yeah, I stopped keeping up after Feb and am just waiting on what the final specifications are. |
| 17:55:31 | Guest70575: | what about the yellow paper? it seems to be the latest design: http://gavwood.com/paper.pdf |
| 17:55:53 | jgarzik: | ethereum tech is not hype |
| 17:56:08 | jgarzik: | I wish ethereum would separate the IPO pump from the project |
| 17:57:21 | Guest70575: | What got my attention was having Vitalik, Koblitz and now apparently Merkle on the team. So they haven't been funded yet. How are they paying for the talent? |
| 17:57:32 | tacotime: | Guest36916, CH is |
| 17:58:00 | gmaxwell: | They've also been doing a lot of whitepaper innovation against any design criticism. So basically if you critique the design, they add more complexity to specifically address the critique. On one side its great they're responding, on the other adding complexity often just makes the design hard to analyize, not secure. |
| 17:58:00 | Guest70575: | CH is loaded? |
| 17:58:02 | tacotime: | For now, and a lot of the work has been volunteer as well. |
| 17:59:03 | Guest70575: | @gmaxwell I agree that seems to be a mistake |
| 17:59:15 | tacotime: | gmaxwell, Vitalik also released "serpent" recently for contract design, which is an interpreter analogous to python. Have been mixed as to whether or not that's a good idea for financial contracts, but time will tell. |
| 17:59:37 | gmaxwell: | So I feel like it's a pretty poor marginal return on review... if you review it they'll add some complexity that just takes more work to review. Invictus did this too. |
| 17:59:44 | Guest70575: | So it's a VM running some sort of assembly and a HLL compiles into it? |
| 18:00:09 | tacotime: | Yeah, apparently. |
| 18:00:31 | Guest70575: | so serpent is a python like HLL and it compiles into the LLL |
| 18:00:47 | tacotime: | yeah. |
| 18:00:50 | Guest70575: | Can I actually write a contract? |
| 18:01:04 | tacotime: | yes, contracts are running live on the proof of concept chain. |
| 18:01:27 | Guest70575: | how does it scale? |
| 18:01:28 | tacotime: | https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-Serpent-programming-language-operations |
| 18:01:47 | tacotime: | and |
| 18:01:48 | Guest70575: | Does every node have to process every contract? |
| 18:01:48 | tacotime: | https://pypi.python.org/pypi/ethereum-serpent/1.1.8 |
| 18:01:48 | gmaxwell: | (e.g. I throughly broke their POW function— taking it from requiring 128M memory to 8k, or 0 memory but it was only correct most of the time,... suggesting that they really should avoid inventing novel cryptosystems unless they really have to, and that POW is a solved problem... and their response was to claim that the code was merely a placehold (in spite of the pages of marketing material and documentation extolling its merits), ... |
| 18:01:54 | gmaxwell: | ... and to replace it with something else totally crazy in under 24 hours. |
| 18:02:31 | Guest70575: | @gmaxwell you broke ethereum's pow? |
| 18:02:56 | gmaxwell: | and of course that crazy thing got compromised by someone else— obviously I wasn't going to waste my time on more cryptanalysis for them—, and then they had some contest and the next design got killed too.. then they went into production with yet another design, and that also got exploited) |
| 18:03:09 | pigeons: | jtimon was telling us he saw vitalik give a presentation on "a simulated quantum computer that runs faster than its von neumann host" and it was lolzy |
| 18:03:45 | gmaxwell: | Guest70575: no, Invictus. Though IIRC ethereum has also cycled out its POW several times due to attacks now. |
| 18:04:19 | Guest70575: | @gmaxwell invictus seemed to me to always be really scammy. Does CH still have any connections there? |
| 18:04:30 | tacotime: | Guest70575, no |
| 18:04:45 | tacotime: | There's a long, dramatic story I'm not at liberty to talk about. |
| 18:05:26 | gmaxwell: | There is this kind of terrible thing you can do where you spend only enough design effort to make something pass a first glance, then advertise it as secure and hope critics show up to act as design oracles. It's quite possible to do this accidentally too... beyond it wasting time, one result is that it often doesn't produce good designs, just designs that take too much work to analyize for free. :) |
| 18:05:58 | Apocalyptic: | pigeons, heh |
| 18:06:10 | Guest70575: | @tacotime @gmaxwell so who is writing the code at ethereum? Is CH involved in that? |
| 18:06:58 | tacotime: | Guest70575, there are many devs, vitalik does python, gavin wood (former mostly audio software dev afaik) does C++, there's a Go coder too |
| 18:07:00 | Apocalyptic: | gmaxwell, " suggesting that they really should avoid inventing novel cryptosystems unless they really have to" that's a general rule one should stick to |
| 18:07:09 | Apocalyptic: | even on a more general scope than cryptocurrencies |
| 18:07:52 | Guest70575: | I looked at the python code. I'm not a C++ guy. Is Gavin any good? |
| 18:08:01 | Eliel_: | somehow a python like scripting language sounds like a bad idea to me in ethereum. |
| 18:08:02 | Guest70575: | I noticed on the yellow paper a Dr. |
| 18:08:15 | Guest70575: | Any idea what's that in? |
| 18:08:42 | tacotime: | Eliel_, that was my feeling |
| 18:08:57 | Eliel_: | I think the language should be strictly functional. Haskell-like. |
| 18:09:14 | tacotime: | http://uk.linkedin.com/pub/gavin-wood/16/433/888 |
| 18:09:16 | Guest70575: | LISP would make an ideal candidate it seems |
| 18:09:28 | gmaxwell: | I don't really agree. |
| 18:10:01 | tacotime: | "Doctor of Philosophy (PhD), Music Visualisation for Human Computer Interfacing" |
| 18:10:30 | gmaxwell: | The most important thing you should have in these tools is facilitating static analysis. It should be possible to build tools that can soundly analyize the script and tell you all the ways it can be satisfied in a human comprehensible form. |
| 18:10:30 | tacotime: | The Bitcoin FORTH-like script, while cumbersome, is nice in that it mostly does what you want it to. |
| 18:10:54 | tacotime: | Without doing unexpected things. |
| 18:10:57 | Guest70575: | Is his code any good? |
| 18:11:19 | tacotime: | I dunno, I'm not a huge C coder (despite maintaining monero lately) |
| 18:11:27 | gmaxwell: | FORTH like at least strikes a nice balance between expressive power and avoiding hiding behaviors. With the right limitations its reasonably compatible with static analysis too. |
| 18:12:02 | Eliel_: | gmaxwell: the reason I want it strictly functional is to eliminate any potential for side effects. That should make analysis simpler. |
| 18:12:12 | Guest70575: | Alright so what's the story then behind the big names like Koblitz and Merkle? What are they doing? |
| 18:12:44 | Apocalyptic: | Guest70575, re Koblitz : http://www.math.washington.edu/~koblitz/ |
| 18:12:48 | gmaxwell: | Getting paid? :P Who knows— they're certantly not working on crypto code... the ecc code ethereum is using is sipa's. |
| 18:12:53 | Guest70575: | I know who he is |
| 18:13:18 | Guest70575: | And neal isn't a programmer |
| 18:13:29 | tacotime: | gmaxwell, that's my guess too, they're their for twitter-ops for celebrity status and as high level consultants. |
| 18:13:38 | tacotime: | s/their/there |
| 18:14:17 | gmaxwell: | You don't need to be a programmer to do review... it's been aggrivating that few seem to be interested in reviewing secp256k1, instead they're just happy deploying it in production to unsuspecting users. :) |
| 18:14:59 | Guest70575: | OpenSSL showed us why that's a really bad idea |
| 18:15:17 | sipa: | except OpenSSL is much more reviewed than libsecp256k1... |
| 18:15:25 | sipa: | (i hope) |
| 18:15:47 | Guest70575: | Except for the times a person's heartbleeds |
| 18:15:52 | Guest70575: | :) |
| 18:15:54 | gmaxwell: | sipa: don't count on that. :( |
| 18:16:13 | sipa: | gmaxwell: if not, i'm not sure whether i should be sad or honored :p |
| 18:16:37 | gmaxwell: | sipa: you should have slipped in a canary bug. :) |
| 18:17:08 | Guest70575: | Ok, I'm still trying to gather all the details. They are in Switzerland and CH is in charge plus there are lots of devs around the world |
| 18:17:23 | Guest70575: | And CH is bankrolling it |
| 18:17:36 | Guest70575: | until an IPO. Is it like mastercoin in that respect? |
| 18:19:43 | jtimon: | pigeons: to be fair they were asking for money to find out if the faster simulated computer was possible or not, didn't claimed it was possible for sure |
| 18:20:59 | pigeons: | oh ok thanks |
| 18:21:02 | pigeons: | :) |
| 18:21:53 | jtimon: | personally I don't like to call them IPOs you can't sell "shares" of a free software project that can be forked from day 0 (well, even earlier) |
| 18:22:21 | petertodd: | jtimon: you can however sell "shares" of the guys working on that project getting paid by said shares |
| 18:22:21 | jtimon: | "sold into existence issuance mechanism" seems more appropriate |
| 18:22:24 | gmaxwell: | In any case, I certantly wish them luck, hopefully they'll discover some interesting things— though I do hope that these investment-scheme coins don't disenchant the public from development in this space. |
| 18:22:47 | Guest70575: | Has anyone met anyone on the team? |
| 18:22:51 | jtimon: | petertodd sure, or shares of a company directly |
| 18:22:55 | tacotime: | gmaxwell, as long as it's open source, i guess we shouldn't complain. |
| 18:23:05 | petertodd: | Guest70575: I spent a week at their switzerland hackerspace |
| 18:23:13 | tacotime: | Guest70575, I've met most of them too |
| 18:23:30 | Guest70575: | Who was in Switzerland? |
| 18:24:02 | jtimon: | I'm talking about the terminology, not comparing sellling into existence with mining subsidies as distribution mechanism, which I don't think it's ideal either |
| 18:24:22 | petertodd: | jtimon: ideally software would be conjured into existance... |
| 18:24:48 | petertodd: | Guest70575: charles, mihai, and a bunch of others. met them all again the next week at the toronto bitcoin expo |
| 18:24:50 | gmaxwell: | tacotime: well its not so simple, I mean if you promote things as secure which aren't or as investments which are sketchy, if you hype the possible beyond its bounds, etc. the result is that you potentially salt the earth and we end up with a cryptocurrency winter. I think its proper to ask for responsible behavior for others working in this space, particularly since none of their ideas exist in isolation. |
| 18:25:36 | Guest70575: | @petertodd I guess since CH is running the show what's your take on him? |
| 18:25:54 | gmaxwell: | I don't think ethereum's marketing has been particularly responsible, though I don't think its yet bad enough to deserve extensive calling out. It's a balance. |
| 18:26:15 | petertodd: | gmaxwell: of course, what makes you think these people actually understand your concerns? for that matter, there's a parallel with merge-mined sidechains... |
| 18:26:22 | sipa: | what do you mean by "CH running the show" ? |
| 18:26:39 | Guest70575: | @sipa tacotime said charles H is running ethereum |
| 18:26:40 | tacotime: | gmaxwell, i suppose that's true. |
| 18:26:50 | petertodd: | Guest70575: I don't think he's technically sophisticated enough to understand where his ideas don't work; I have no reason to think he's being malicious or intentially deceitful |
| 18:26:59 | sipa: | Guest70575: oh loi, i thought by CH you referred to switzerland :) |
| 18:27:09 | Guest70575: | @sipa lol |
| 18:27:42 | gmaxwell: | Vitalik has been really good on the random tech forums of responding honestly to stuff. E.g. their marketing people hype turing complete, I point out on reddit that it isn't really needed, and Vitalik showed up and agreed, pointing out that its mostly interesting for succinctness which I agree with— which was super great and made me feel a bit less concerned by the hype. |
| 18:28:07 | jtimon: | I like "anti-asic" myths much less than the IPO/issuance-into-existence/"premine" thing |
| 18:29:12 | Guest70575: | Well thanks guys for catching me up to speed. I really appreciate it |
| 18:31:01 | Guest70575: | Guest70575 has left #bitcoin-wizards |
| 18:31:07 | tacotime: | gmaxwell, Vitalik is a really nice kid and reasonable to discuss things with. |
| 18:32:03 | petertodd: | jtimon: you gotta pay for development somehow; we're going to see this over and over again |
| 18:32:03 | gmaxwell: | petertodd: I think you're probably to harsh on the mm sidechains— I think its more useful to think of them with the same kinds of security models as some of the bonded banks stuff we'd talked about in the past— they have somewhat orthorgonal features with bitcoin and a different security model, though also I don't expect anything implemented to be so narrow as to only permit merged mining or only derrive its security from merged ... |
| 18:32:09 | gmaxwell: | ... mining. |
| 18:32:13 | michagogo|cloud: | ;;google canary bug |
| 18:32:14 | gribble: | Chrome Release Channels - The Chromium Projects: ; Chrome Canary Bug Hides URLs A Little Too Well - Threatpost: ; Chrome Releases: |
| 18:32:16 | gmaxwell: | petertodd: I fully expect you to add to this list eventually: http://www.reddit.com/r/Bitcoin/comments/22vn4m/why_do_people_think_that_sidechains_are_going_to/cgqy5w6 |
| 18:32:20 | michagogo|cloud: | ;;google canary bug -chrome |
| 18:32:21 | gribble: | Ancient Killer Bug Thrives in Shadow of London's Canary Wharf ...: ; Stack buffer overflow - Wikipedia, the free encyclopedia: ; CANARY: |
| 18:32:28 | michagogo|cloud: | gmaxwell: canary bug? |
| 18:32:53 | michagogo|cloud: | ;;google canary bug software -chrome |
| 18:32:54 | gribble: | CANARY - Open Source Software at Sandia - Sandia National ...: ; Stack buffer overflow - Wikipedia, the free encyclopedia: ; Buffer overflow protection - Wikipedia, the free encyclopedia: |
| 18:33:38 | pigeons: | oh i thought like "stack canary" |
| 18:33:48 | petertodd: | gmaxwell: yes, fine, you think one thing, I think another. point is when I talked to CH about all this stuff in person, I had every reason to believe that he genuinely thought that my criticisms for all these flaws in ethereum were overblown/invalid/etc. MM sidechains is the exact same situation |
| 18:33:49 | gmaxwell: | michagogo|cloud: please don't spam on the channel with google, I'm referring to http://en.wiktionary.org/wiki/canary_in_a_coal_mine ... having a bug that acts as a test to tell if review is adequate. |
| 18:34:09 | gmaxwell: | petertodd: I don't think we think different things. |
| 18:34:50 | jtimon: | although I don't think ethereum's is the best approach to smart contracts, I agree they're innovating on that respect |
| 18:35:05 | gmaxwell: | Maybe you adopt a position that the world is a bit more byzantine than I do, but I generally think everything should error towards assuming more byzantineness simply because it makes you more robust in general. |
| 18:35:45 | jtimon: | if they stopped wasting their time on "anti-aasic" unicorns and used mm SHA256 from the beginning my perception of the project would greatly improve |
| 18:36:51 | gmaxwell: | jtimon: they have some problems in that their contracts stuff could quite reasonably be very expensitive computationally, now considers what happens if much of the difficulty of mining a coin is in the contract validation instead of the POW? |
| 18:38:07 | jtimon: | petertodd you've been invited many times to destroy my example demonstrating why merged mining is more secure than independent mining, and/or to show us your "no cost" attack on namecoin; and as gmaxwell says, 2-way peg and merged mining are completely orthogonal |
| 18:38:51 | sipa: | well the 2-way pegging fork in bitcoin needs to be aware of what kind of mining technology the sidechain uses |
| 18:39:04 | jtimon: | gmaxwell yes, as we've been saying other times, less non-mining full nodes are to be expected |
| 18:39:49 | sipa: | and imho 2-way pegging is mostly an engineering solution: a way to gradually bring up a new chain, that is only actually secure once bitcoin softforks its validation rules |
| 18:39:51 | jtimon: | sipa, sure, yes you need the hash function in the scripting language |
| 18:40:08 | gmaxwell: | sipa: yes, it needs to be able to parse the proofs, but there is no particular need to tie it down to merged mining. |
| 18:40:22 | jtimon: | to me the most interesting use case is still public-private pegs not bitcoin-sidechain pegs |
| 18:40:43 | sipa: | gmaxwell: it could, though, and perhaps with security benefits |
| 18:42:44 | gmaxwell: | Right, I'm generally of the view that merged mining can have security benefits. There are concerns to navigate, and they're real and some have "no closed form answer"— no proof one way or another. So I think its good to be flexible here, and arguments against mm should be reserved for payment systems that actually use it, where you can consider the specific rules and incentives of that system. |
| 18:43:23 | OneFixt_: | OneFixt_ is now known as OneFixt |
| 18:44:57 | petertodd: | jtimon: we have different basic assumptions; we're not going to agree |
| 18:45:14 | sipa: | ftr, by "with security benefits" i meant comparing mm-with-bitcoin-aware-of-it with mm-with-bitcoin-oblivious |
| 18:45:51 | sipa: | mm versus separate mining is a hard questio |
| 18:47:30 | gmaxwell: | petertodd: I dunnot why you'd expect to disagree with jtimon— his big interest there is in auditable offchain banks with some useful features that we'd considered interesting before. |
| 18:48:00 | pigeons: | if most regular bitcoin miners currently are aligned with your side chains goals financialy and philosophically, you will likely gain security from merged mining. if mparent chain miners are not, likely the opposite |
| 18:48:11 | jtimon: | petertodd not on merged mining I don't think we think too differently on other matters |
| 18:48:11 | petertodd: | gmaxwell: I'm talking about the idea that attacking merge mined alt-chains has a non-zero minimum cost |
| 18:48:40 | sipa: | attacking a merge-mined chain has exactly the same cost as protecting it |
| 18:48:42 | jtimon: | well, not on "anti-ASIC" either |
| 18:48:56 | sipa: | this is true for non-merge-mined chains too :) |
| 18:49:31 | gmaxwell: | well, the minimium cost is the effort to do the attack (which we can take as zero for discussion), and the lost oppturnity in participating, which pigeons largely answered... plus the lost value of your bitcoins in not having that transaction option (though there is a bit of a tragedy of the commons there) |
| 18:49:55 | sipa: | right, i'm talking about all systems without subsidy |
| 18:50:00 | gmaxwell: | so then the question really becomes for any proposed use how to achieve enough security through the latter two. |
| 18:50:26 | gmaxwell: | And yes, these issues exist for bitcoin already and especially in the long term with subsidy decline, so there is some symmetry here. |
| 18:50:40 | jtimon: | sipa but merged mined coins like bitcoin actually get more hashing than they pay for, which can only be good: we can bury things on different holes or make only one big hole to bury all our things |
| 18:51:10 | sipa: | jtimon: merge mining just means you give all existing bitcoin mining power a free pass to either protect or attack your chain |
| 18:51:37 | sipa: | with separate mining, it means the pass has the same effect, but isn't free anymore |
| 18:52:23 | jtimon: | first of all, "existing mining power" is not free |
| 18:53:06 | sipa: | marginal cost is free |
| 18:53:11 | jtimon: | and the costs tend to the total reward, so if you don't MM you're at a competitive disadvantage |
| 18:53:37 | sipa: | i don't understand |
| 18:54:13 | sipa: | there is no *additional* cost to either protecting or attacking the sidechain, if you already have bitcoin mining power |
| 18:54:43 | pigeons: | except mainteance, configuration, monitoring |
| 18:54:52 | gmaxwell: | (ignoring the effort of setting things up, which we can do here but it does have some pratical impact! :)) |
| 18:54:53 | jtimon: | yes, but miners protecting the chain get rewarded |
| 18:54:57 | midnightmagic: | and bitcoin mining power has been variously bitcoin-profitable above hardware and electricity. |
| 18:55:08 | sipa: | jtimon: those attacking get rewarded too :P |
| 18:55:27 | gmaxwell: | jtimon: maybe they get rewarded, thats a question of how things are designed. |
| 18:55:32 | sipa: | there are various tradeoffs here |
| 18:55:33 | jtimon: | gmaxwell: that's why the chain's reward must be big enough for miners to bother |
| 18:55:43 | sipa: | i wasn't talking about rewards, and rewards is what it is all about |
| 18:55:54 | gmaxwell: | Right, right. I'm just pulling out the hidden assumptions here. I know you know of them. |
| 18:56:05 | sipa: | but if you talk about costs, mm or non-mm are very similar: both attacking and protecting cost nearly the same |
| 18:56:55 | jtimon: | sipa merged mining is a little bit better as shown in my example |
| 18:57:06 | sipa: | which example? |
| 18:57:33 | jtimon: | on the bitcoin-dev mailing list, wait, I'm trying to find it |
| 18:59:25 | sipa: | i guess the question mm vs non-mm boils down to whether you expect existing bitcoin miners to be more in favor of your sidechain than the rest of the population/economy is |
| 18:59:26 | jtimon: | sipa http://sourceforge.net/p/bitcoin/mailman/message/31806950/ |
| 19:00:23 | jtimon: | I don't see why they wouldn't try to maximize their gains |
| 19:01:33 | gmaxwell: | for example, what if there is no gain. |
| 19:02:02 | jtimon: | if you don't reward miners you're not secure, period |
| 19:02:34 | jtimon: | why would they inccur the costs otherwise? |
| 19:03:29 | gmaxwell: | If you have something like ClosedQuicklyCoin which rips off prerelease bitcoin core code and announceses itself as an innovative replacement for bitcoin. CQC might well reward you handsomly with CQCoins but you can bet there is an non-trivial chance existing bitcoin miners will shut it down. :) |
| 19:04:45 | petertodd: | Zerocoin is the easiest example: there is a non-trivial minority in Bitcoin who genuinely believe that making bitcoin more anonymous will make it less valuable, so they would happily destroy a MM, or worse, 2-way-pegged, Zerocoin |
| 19:05:04 | sipa: | jtimon: i'm not arguing with that |
| 19:05:14 | sipa: | jtimon: as i said, i was talking about costs - not rewards |
| 19:05:46 | jtimon: | sipa they tend to be equal thanks to the difficulty adjustment |
| 19:05:50 | gmaxwell: | petertodd: I think thats very unlikely. |
| 19:06:57 | petertodd: | gmaxwell: who cares about likelyhood? the example shows very clearly that the value of a MM chain is not universal |
| 19:07:48 | jtimon: | petertodd value is never universal |
| 19:09:01 | gmaxwell: | So if I can summaryize jtimon's email: in equlibrium the marginal (and oppturnity) cost of attacking is at best equal to the reward provided by not attacking. In the MM case, the MM may also benefit from generally indifferent miners basically propping up the status quo. |
| 19:09:26 | petertodd: | jtimon: exactly, PoW cost however is to a first approximation, which makes MM more dangerous than straight PoW in many real-world situations |
| 19:10:01 | gmaxwell: | Yea, the starting costs are different, jtimon's argument works only asymptotically. |
| 19:10:14 | gmaxwell: | Though you can also make MM security reflect that. |
| 19:12:00 | gmaxwell: | petertodd: What I'd suggested to matthew and ian a while back, though I don't think they got it was MM plus multisignature signing of blocks, which just turns itself off if the difficulty is ~= the bitcoin difficulty. So then you're only open to those particular attacks if its actually a majority of the bitcoin hashpower out to shut you down. |
| 19:12:01 | jtimon: | gmaxwell a good summary, but rather than "generally indifferent" I would just say "miners acting rationally" |
| 19:12:28 | petertodd: | gmaxwell: which is nuts, because the majority of hashing power is in the control of a tiny number of people |
| 19:12:42 | gmaxwell: | petertodd: yes but then all this stuff is freeking doomed if we can't fix that. |
| 19:13:11 | petertodd: | gmaxwell: no, the MM sidechain case is significantly worse in terms of attacks, because the majority can attack at no cost to themselves, or even a positive return in 2-way-pegs |
| 19:13:12 | gmaxwell: | I mean, sure you can argue this and I can't disagree, but what you're really arguing is that bitcoin is totally insecure but happens to still be working in practice. For the moment. |
| 19:13:20 | Vitalik: | Vitalik is now known as Vitalik_ |
| 19:13:47 | jtimon: | I'm afraid the only solution to that other problem is the ghash.io people to think with their heads |
| 19:14:22 | jtimon: | well, or just a pow changing hardfork |
| 19:14:31 | gmaxwell: | petertodd: it's not no cost: it's always a marginal decision between going this way or that way, if you attack you lose the oppturnity to not attack. jtimon's argument was that the reward you get for mining equals the security. |
| 19:14:44 | gmaxwell: | jtimon: pow changing hardfork just rearranges the deckchairs. :) |
| 19:15:14 | jtimon: | they should know that a pow-change is the next step when mining becomes too centralized |
| 19:15:16 | petertodd: | gmaxwell: yes indeed, but you can make the *cost* to attack and individual chain higher than the reward with embedded systems |
| 19:15:33 | jtimon: | gmaxwell exactly, so what's the problem? |
| 19:15:57 | petertodd: | anyway, I got stuff to do, this conversation is going no different than the last time |
| 19:16:08 | gmaxwell: | jtimon: thats an allusion to an american saying http://en.wiktionary.org/wiki/rearrange_the_deck_chairs_on_the_Titanic |
| 19:16:53 | jtimon: | petertodd, but you're not just defending embedded systems, you're comparing independent pow with mm pow!!! |
| 19:17:42 | gmaxwell: | petertodd: yea, I think everything here I though we were discussing was independant pow and mm pow... other things, well have different arguments. :) |
| 19:18:00 | jtimon: | gmaxwell I got it, but they know they're risking their investment by capturing a too big percentage of the hashrate |
| 19:18:11 | gmaxwell: | jtimon: no they don't. They're stupid. |
| 19:19:21 | petertodd: | gmaxwell: ugh, I should know better to keep replying. :) but like I said above, the idea that reward == security is true, which is why MM is less secure than PoW in many situations because for many miners reward < PoW |
| 19:19:30 | gmaxwell: | I've talked to a bunch of these mining business people, and there are many of them who have had grand plans to have $large_percent hashpower, for values of large which are usually much over 50%. The amusing thing is that there are many of them. Lets just hope that when they go bankrupt they don't make a mess. |
| 19:19:42 | petertodd: | gmaxwell: which gives us MM < PoW < embedded in terms of least secure to most secure for a small system. |
| 19:20:44 | jtimon: | I think dogecoin would be more secure if it was mm with litecoin |
| 19:20:45 | petertodd: | also, s/small/controversal/ |
| 19:21:07 | petertodd: | jtimon: I don't at all, because I've had multiple ltc holders approach me asking for advice on how to kill dogecoin the cheapest possible way |
| 19:21:47 | gmaxwell: | I don't think thats actually counter evidence there! :) but we should talk that out when you have more time. |
| 19:26:04 | jtimon: | well, at least give me that if you're somehow sure that current btc/nmc miners don't have a general aversion to your new chain or think they "need to kill it" you would be more secure with mm because the rational thing for a miner that doesn't hate the chain to do is gladly take the additional income not to have a disadvantage over the other miners |
| 19:26:39 | jtimon: | gmaxwell why are mm miners stupid? |
| 19:27:45 | gmaxwell: | it would be interesting to figure out how many NMC mmers there really are. |
| 19:27:58 | gmaxwell: | There might only be a dozen of them. |
| 19:29:11 | jtimon: | isn't more like 80% of bitcoin's miners? |
| 19:29:57 | gmaxwell: | it's 80% hashrate. |
| 19:30:52 | jtimon: | that's 12 miners? |
| 19:30:56 | gmaxwell: | it could be. |
| 19:31:06 | gmaxwell: | http://blockorigin.pfoe.be/top.php |
| 19:31:17 | sipa: | for namecoin there is little to lose by merged mining |
| 19:31:23 | sipa: | but also little to gain |
| 19:31:48 | jtimon: | but there's many miners per pool, no? |
| 19:31:58 | sipa: | we typically call those hashers, not miners |
| 19:32:11 | sipa: | they're not actually building blocks, just selling their hashpower to the pool |
| 19:32:18 | gmaxwell: | it's somewhat costly to run the software, its not well maintained, has had a number of security issues... uses a lot of resources, and apparently it triggers the FBI automatic child porn detector, since NMC's antispam wasn't adequate to prevent people from shoving whole jpegs in transactions. |
| 19:32:38 | jtimon: | sipa: but they could move to another pool in case of attack |
| 19:32:45 | sipa: | maybe |
| 19:32:52 | gmaxwell: | jtimon: they don't have any say over the content of the blocks, so if you're thinking about who has to get hacked or make a business decision to attack or stop mining the important parties are that dozen. |
| 19:33:21 | gmaxwell: | jtimon: evidence suggests otherwise, generally. e.g. https://bitcointalk.org/index.php?topic=327767.0 (ghash is currently the largest public pool) |
| 19:33:49 | jtimon: | I mean, it's still not ideal that the validation is centralized, I'm saying a pool is not as bad as hosted mining center |
| 19:34:16 | sipa: | agree there |
| 19:34:21 | gmaxwell: | Agreed indeed. |
| 19:34:36 | gmaxwell: | But it seems to me that its also not much better. |
| 19:35:01 | gmaxwell: | (because most people don't move, or care, or know) |
| 19:35:23 | jtimon: | I guess that depends on the miners using the pools and the tools they have to detect fraud or chose between them |
| 19:35:46 | jtimon: | but probably and sadly you're right |
| 19:36:26 | gmaxwell: | right, there is very limited tools to automatically detect and respond to bad behavior today— and they exist exclusively in bfgminer which is the less widely deployed tool. |
| 19:36:41 | gmaxwell: | (well perhaps more widely deployed in terms of users; but less in terms of hashpower) |
| 19:36:57 | gmaxwell: | (just due to all these commercial large integrated miners shipping with cgminer built in) |
| 19:49:36 | gmaxwell: | [OT] ZTEX now has 28nm fpga products. |
| 20:04:50 | stqism: | ;;voiceme |
| 20:04:55 | stqism: | Wrong channel |
| 20:11:06 | adam3us: | adam3us has left #bitcoin-wizards |
| 20:31:23 | warren: | https://securityblog.redhat.com/2014/05/07/defeating-memory-comparison-timing-oracles/ |
| 21:34:36 | andytoshi: | hi, can someone review the Difficulty Calculation section of https://download.wpsoftware.net/bitcoin/alts.pdf (bottom of p6)? |
| 21:36:52 | sipa: | "to weight the each block" ? |
| 21:37:40 | sipa: | i wouldn't say that total work corresponds to known to how many people |
| 21:40:40 | nsh: | * nsh blinks |
| 21:41:12 | andytoshi: | sipa: when i wrote that i was thinking about block witholding attacks |
| 21:41:29 | sipa: | yeah, there is a strong correlation between work and eyes for recent blocks |
| 21:41:38 | sipa: | but as you go further back, it becomes cummulative |
| 21:41:43 | andytoshi: | why is block withholding going to screw you? because you definitely won't create the highest total-work chain without letting others help you |
| 21:42:16 | andytoshi: | (ignoring selfish mining for a second, which is a marginal attack and still requires you to publish your stuff reasonably quickly) |
| 21:42:27 | andytoshi: | by marginal, i mean "at the tip of the chain" |
| 21:42:34 | sipa: | i think my problem with that statement is that PoW in the past (with difficulty possibly different from now) is near meaningless |
| 21:43:28 | sipa: | even if the whole world saw your block in 2010, its PoW is much less than that directly on top of a recent block, even though just 50% of the hashpower may have seen it |
| 21:44:09 | andytoshi: | oh, i see |
| 21:44:19 | andytoshi: | i should add "in the thermodynamic limit" and then link the whole asic paper ;) |
| 21:44:24 | sipa: | lol |
| 21:44:29 | sipa: | ow, that hurt |
| 21:45:00 | andytoshi: | at any given time, you can think of the "recent total work" as giving a proxy for how many eyes there are |
| 21:45:21 | andytoshi: | and the timescales at which that break down are much bigger than the timescales we assume the network is synchronous at |
| 21:45:58 | sipa: | right, agree |
| 21:46:11 | andytoshi: | good catch, i'll clarify that |
| 21:51:59 | mr_burdell: | andytoshi: if you want to see some weird reorgs due to total work, myriad has had up to 9-10 blocks orphaned by a single other block with 10x difficulty |
| 22:00:22 | andytoshi: | sipa: i've added a long footnote to page 6 talking about this. is it ok? |
| 22:04:20 | andytoshi: | mr_burdell: o.O is myriad using SHA256d? |
| 22:04:51 | mr_burdell: | for ~20% of the hashrate, yes |
| 22:05:18 | gmaxwell: | Sounds like yet another Crackpipecurrency. |
| 22:05:45 | mr_burdell: | surprisingly, I haven't seen it exploited yet, but I'm pretty sure at the current hashrates, it could basically be taken over by sha |
| 22:06:22 | mr_burdell: | although there is a difficulty weighting in place... just not sure how effective it is |
| 22:07:04 | mr_burdell: | although, you'd need more than 50% of the sha hashrate to do it |
| 22:08:03 | gmaxwell: | what is its sha256 hashrate? |
| 22:09:12 | mr_burdell: | 112 th |
| 22:09:22 | mr_burdell: | according to one of the pools... hard to tell |