| 00:00:01 | gmaxwell: | andytoshi: trying to have an anti-double-spending bond? |
| 00:00:28 | andytoshi: | gmaxwell: yeah, but it's not working out :P |
| 00:00:29 | gmaxwell: | one problem with those is then how do you prevent the bond from being multiple subscribed? |
| 00:00:54 | gmaxwell: | e.g. I make one 1 btc bond. Then I make 1000 0.5 BTC spends secured against it… |
| 00:00:54 | phantomcircuit: | andytoshi, bond for what? |
| 00:02:07 | justanotheruser: | petertodd: Are there any posts or technical details on how sharding the blockchain would work? Would it involve removed anonymity? |
| 00:02:19 | petertodd: | gmaxwell: well, what if we had some kind of global consensus on who was making use of the bond? |
| 00:02:22 | petertodd: | * petertodd ducks |
| 00:02:24 | andytoshi: | phantomcircuit: the idea is, i send you some money -- they rather than having you wait for a confirm, i construct an output (which i own) such that you can just take it if you can prove that i've double-spent you |
| 00:02:52 | gmaxwell: | petertodd: but then you have to wait for that consensus to settle, defeats the purpose. |
| 00:03:28 | justanotheruser: | * justanotheruser frowns |
| 00:03:51 | petertodd: | gmaxwell: that was the joke :) |
| 00:04:22 | petertodd: | justanotheruser: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03307.html is the best writeup I have |
| 00:04:33 | gmaxwell: | I'd say you could trust a broadcast network to tell you about compeating bond usage, except the theif could redeem his own bond. |
| 00:04:39 | petertodd: | justanotheruser: and it's not strictly about sharding, but you can easily see how it could be |
| 00:04:52 | andytoshi: | gmaxwell: that's the problem that just occured to me when i said "it's not working out :P" |
| 00:04:55 | gmaxwell: | (and he's not obligated to tell the broadcast network) |
| 00:05:09 | petertodd: | gmaxwell: hence it needs to be partial redeem, partial destroy |
| 00:05:31 | justanotheruser: | petertodd: thanks |
| 00:05:44 | gmaxwell: | andytoshi: this isn't to say that such bonds might not be useful. E.g. large ones which mostly destroy their funds. (they only pay at all as a reward for making the cheating public) |
| 00:05:50 | petertodd: | justanotheruser: I had another post on bitcointalk somewhere from a few months back |
| 00:06:21 | gmaxwell: | but there needs to be a way to transfer ownership of such bonds. |
| 00:07:33 | petertodd: | gmaxwell: which I solved, but soon realized then you also need a way to prove that proof-of-fraud isn't waiting to be released, which means you need consensus about all such fraud, which means proving fraud needs to be proof-of-publication-based. Fortunately this txout scheme I think works here. |
| 00:07:56 | petertodd: | gmaxwell: e.g. the proof is the txout bond hasn't been spent via fraud proof |
| 00:09:37 | gmaxwell: | right, but how do you allow transfer and not create a race between a transfer and a fraud? |
| 00:10:06 | petertodd: | gmaxwell: you create an intermediate "cooling off" period before a transfer can actually go through |
| 00:10:23 | gmaxwell: | I guess by having two outputs, one for transfer, one for fraud, and fraud can still be published for some time after the transfer before it settles? |
| 00:10:38 | gmaxwell: | yea, makes sense the resulting protocol has a number of steps though, which is unfortunate. |
| 00:12:05 | petertodd: | Yeah, or some multisig scheme with some kind of mutually agreed on cooling off tx - lots ofpossibilities. |
| 00:12:38 | petertodd: | Well, I think the cooling off thing is unavoidable to be fair to people potentially relying on the bond. |
| 00:12:44 | gmaxwell: | anyone honoring the bond needs to know the ... right |
| 00:13:09 | petertodd: | Which also means the bond txout really needs to be able to constrain the txout of the tx spending it. :( |
| 00:13:19 | gmaxwell: | esp if you want to allow the bond to be honored by 'offline' devices. |
| 00:13:24 | petertodd: | yup |
| 00:13:52 | andytoshi: | petertodd: right, and that means that you have to precommit to your output and you lose the 'spend without waiting for confirmations' benefit :( |
| 00:14:14 | gmaxwell: | andytoshi: only if you expect people to get paid from the bond. |
| 00:14:52 | gmaxwell: | andytoshi: the alternative is you give up on that and just set it up so that misbehavior costs the misbehaving party their valuable bond... you don't get paid back but they don't get to keep using the bond. |
| 00:15:52 | petertodd: | gmaxwell: no, you just make some of the reward of proving fraud be paid out, and some destroyed, and make the destroyed amount larger than the payout amount |
| 00:16:46 | gmaxwell: | petertodd: you still can't promise the defrauded person get paid no matter how much the bond pays out |
| 00:16:49 | andytoshi: | sure, but how does this make it possible to use the bond without commiting to the output? |
| 00:17:05 | andytoshi: | ah, because 'overcommitting' is not a thing |
| 00:17:06 | petertodd: | gmaxwell: ah, right |
| 00:17:08 | gmaxwell: | andytoshi: because you're not promising that any particular victim can get paid. |
| 00:17:11 | gmaxwell: | right. |
| 00:17:25 | gmaxwell: | The payment the victim gets is just for the trouble of actually announcing to the world that they got ripped off. |
| 00:17:40 | petertodd: | gah, I should have written this up back when I was thinking about this stuff for fidelity bonded banks... |
| 00:18:16 | petertodd: | gmaxwell: yeah, they're not guaranteed to be made whole, and it's tricky to guarantee the fraudster has a net loss |
| 00:21:22 | petertodd: | unrelated: took a look at the twister twitter blockchain thing, and it's difficulty is 0.002... a single GPU scrypt miner could 51% attack the thing |
| 00:21:28 | gmaxwell: | haha one of my coworkers just asked me about his ntp daemon at home using lots of bandwidth |
| 00:21:36 | petertodd: | whut? |
| 00:21:49 | gmaxwell: | "Uh. maybe there is a NTP reflection DDOS attack" "oh look, one was recently found and is being exploited" |
| 00:21:56 | petertodd: | lol |
| 00:23:12 | andytoshi: | petertodd: suppose that you've got like a 1btc bond, and it's only considered valid by fast food restaurants and groceries (who want the bond value to be some large multiple of the product value) |
| 00:23:28 | andytoshi: | then to get a net win a scammer would have to get to a whole ton of physical stores within a blocktime or two |
| 00:23:57 | andytoshi: | (and any more than a blocktime would require some sort of mining-based attack) |
| 00:24:00 | petertodd: | andytoshi: sure, but that just goes to say you have to take countermeasures against that kind of thing or it's easy to rip off |
| 00:24:06 | phantomcircuit: | andytoshi, or coordinate with lots of other scammers |
| 00:24:12 | gmaxwell: | andytoshi: really these things make more sense in the context of an anti-doublespending signer service rather than personally, as the signer service could afford a bond a huge multiple of the typical transaction prices. |
| 00:24:24 | phantomcircuit: | (organized russian crime groups do this fairly regularly with atm heists) |
| 00:24:38 | gmaxwell: | (and could also be secured by hardware remote attest) |
| 00:24:53 | petertodd: | gmaxwell: esp if the signing service provides some kind of proof of how many uncommitted btc they've signed for |
| 00:25:12 | andytoshi: | phantomcircuit: right, derp |
| 00:25:34 | andytoshi: | gmaxwell: neat, then you've got a traditional debit-card system but with a bit less trust |
| 00:26:11 | gmaxwell: | petertodd: if only someone recently described how to run a cryptographically private accumulator... |
| 00:26:33 | petertodd: | gmaxwell: I know 'eh? |
| 00:26:49 | andytoshi: | * andytoshi has one last exam tomorrow, better get off -wizards before somebody posts a link |
| 00:26:49 | phantomcircuit: | lol |
| 00:27:13 | andytoshi: | andytoshi is now known as andytoshi-away |
| 00:39:31 | maaku: | petertodd gmaxwell: I had a "duh" moment, but if prefixed proofs become *required* for transaction and block propagation, then it doesn't matter how the (U)TXO index is keyed, right? or the size of the UTXO set? |
| 00:40:06 | petertodd: | maaku: it's impossible to require them effectively |
| 00:40:18 | maaku: | well, setting that aside... |
| 00:40:56 | maaku: | spherical cow analysis, if you could get every node to upgrade, etc. |
| 00:41:53 | petertodd: | then you'd get collusion between miners who greatly reduce their bandwidth to each other by leaving out proofs they don't need because they have parts of the utxo set cached |
| 00:42:39 | maaku: | i'm not sure that's a problem, except as it applies to decentralization |
| 00:43:07 | petertodd: | well if it's not a problem, then why did you want to require them? |
| 00:43:08 | gmaxwell: | perhaps I'm missing some context, as I don't see what maaku is talking about (maybe it was something too obvious?) |
| 00:43:29 | petertodd: | I assume for fairness, otherwise you might as well just only provide proofs when needed |
| 00:44:08 | justanotheruser: | justanotheruser is now known as justanotheruser1 |
| 00:44:11 | maaku: | well it's very obvious now that i think about it, but the trigger was that I as assuming you need to store the UTXO twice to support scriptPubKey-indexing |
| 00:44:19 | gmaxwell: | the whole idea of the MMR-structured data was that it let you make a storage/bandwidth tradeoff if you could always demand a peer give you proofs with their transactions. |
| 00:44:33 | justanotheruser1: | justanotheruser1 is now known as justanotheruser |
| 00:45:12 | gmaxwell: | oh no, you wouldn't though you should note that scriptPubKey-indexing isn't naturally computationally balanced— so its a poor index. |
| 00:45:14 | justanotheruser: | petertodd: do you think blockchain sharding will be implemented some time soon? |
| 00:45:25 | petertodd: | justanotheruser: heck no |
| 00:45:29 | gmaxwell: | (also making address reuse cheaper is unfortunate) |
| 00:45:33 | maaku: | but if a proof comes with a transaction, you could just mandate that proofs contain the paths to the inputs in the scriptPubKey index, and a mapping of txid:n -> scriptPubKey |
| 00:46:13 | justanotheruser: | petertodd: what is the number of full nodes drops below 2k? |
| 00:46:31 | gmaxwell: | yea, sure. Doesn't mean that indexing by scriptPubKey is actually desirable, but if you change how transactions look up their inputs, then indeed, you don't need two indexes. |
| 00:46:40 | maaku: | " (also making address reuse cheaper is unfortunate)" <-- yes i'm onboard with that. this is more of a -wizards hypothetical |
| 00:47:00 | gmaxwell: | ::nods:: |
| 00:47:04 | maaku: | yeah ok i was stupid for not realizing that earlier |
| 00:47:11 | petertodd: | justanotheruser: sharding requires miner co-operation and a soft-fork |
| 00:47:55 | justanotheruser: | petertodd: yes, wouldn't it be necessary because the number of full nodes is dropping? |
| 00:48:19 | sipa: | well, if we can create a currency from scratch, with outputs being (value, merkle-ast-root) and inputs being (merkle-script, script inputs), you can easily (except for potential unbalancing) have your UTXO tree indexed by (merkle-ast-root, txid) |
| 00:48:58 | maaku: | justanotheruser: re "blockchain sharding" sortof, that will come soon |
| 00:49:11 | maaku: | if, that is, you mean pruning where some nodes only store ranges of blocks |
| 00:49:20 | maaku: | not tomorrow though, but soon |
| 00:49:49 | justanotheruser: | maaku: I mean blockchain sharding as in https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03307.html |
| 00:50:03 | sipa: | so you only need a single UTXO data structure for both validation lookups and lightweight node balance checking |
| 00:50:38 | gmaxwell: | The unbalancing could be avoided by just prohibiting reuse. You end up with a design close to an anonymous coin then. E.g. where outputs do blinded inserts into a existing coin list, and where inputs unblind coins, prove the coins exist, and they are added to a spent coin list. |
| 00:51:48 | petertodd: | justanotheruser: necessary doesn't make stuff actually happen you know, more likely lack of full nodes just pushes people to use web-wallet stuff |
| 00:52:26 | petertodd: | justanotheruser: with so few pools the politics of the situation are unknown and may not be what we want... |
| 00:52:26 | justanotheruser: | gmaxwell: btcguru in #bitcoin is linking to a sketchy website. No results on google |
| 00:53:16 | justanotheruser: | petertodd: why would the number of pools effect that? |
| 00:53:26 | petertodd: | sipa: ugh, I really think we're best off avoiding that kind of single-scriptPubKey balance checking stuff |
| 00:53:48 | petertodd: | justanotheruser: because they're large enough that more centralization and fewer nodes out there may be in their interests |
| 00:54:25 | maaku: | sipa: yeah that was more my line of thinking. indexing by txid or by insertion order isn't really useful, other than that's how bitcoin is structured (scriptPubKey isn't available in the input) |
| 00:54:42 | maaku: | and, i guess, useful in that it doesn't encourage bad, bad things like dumping data on the block chain |
| 00:55:13 | petertodd: | maaku: or address re-use |
| 00:55:23 | sipa: | petertodd: maybe - i don't like the privacy implications of that either |
| 00:56:23 | maaku: | petertodd: yeah, although I don't know how to support looking up bip 32 or keypool addresses without also encouraging address reuse :( |
| 00:57:07 | petertodd: | maaku: use fixed prefixes so all you're reusing is the prefix, which still gets you a decent anonymity set (see my recent post on blockchain data) |
| 00:58:13 | petertodd: | maaku: for change I think we can get away with totally random change addresses as the set of *unspent* change txouts doesn't have to grow |
| 01:03:06 | gmaxwell: | Man, people are going to love anonymous coins where efficient lookups for payments to you is impossible. |
| 01:04:09 | petertodd: | gmaxwell: ? |
| 01:06:24 | gmaxwell: | petertodd: if you have an truly anonymous cryptocurrency, e.g. one that worked by committing to blinded coin values in an insertion ordered tree.. there is no way to tell someone paid you from just inspecting the currency. |
| 01:07:33 | gmaxwell: | They'd have to tell you out of band, or you'd have to have a seperate channel e.g. for storing ECDH keyed encrypted messages "hey, I paid you, the blinded coin has value X" |
| 01:07:40 | petertodd: | gmaxwell: oh sure - all this business about stealth addresses is just a way of relaxing that anonymity a bit so you can recover the payment. even a fully anon cryptocurrency can always bolt on a messaging layer to provide that channel |
| 01:08:08 | gmaxwell: | yea, but interestingly the messaging layer could easily break the privacy. |
| 01:08:10 | petertodd: | gmaxwell: if bitmessage was reliable, you'd just use it, but it's not for non-interactive use |
| 01:08:22 | gmaxwell: | e.g. if the messages have a visible to it likely removes it completely. |
| 01:08:42 | petertodd: | gmaxwell: well, if you re-use something like bitmessage, at least your anonymity set also includes random messages unrelated to payments |
| 01:09:02 | gmaxwell: | an interesting point. |
| 01:09:46 | justanotheruser: | Are you referring to zerocoin? |
| 01:09:55 | petertodd: | Anyway, figuring out how to make the user-experience of "must send this packet of data for foo to get their coin at all" to be acceptable might come in handy for other crypto-currency schemes like txin commitments where the network doesn't have the data at all. |
| 01:10:28 | gmaxwell: | petertodd: well in general seperating the accumulator operation from notice is interesting. Esp since there are different durability requirements. |
| 01:10:46 | gmaxwell: | e.g. losing old notices, ::meh:: |
| 01:11:30 | petertodd: | gmaxwell: yup |
| 01:11:34 | gmaxwell: | justanotheruser: no. |
| 01:20:38 | phantomcircuit: | Morici v Hashfast Technologies |
| 01:20:40 | phantomcircuit: | and so it begins |
| 01:20:42 | phantomcircuit: | Case5:14-cv-00087 |
| 01:26:47 | gmaxwell: | phantomcircuit: do you have some data feed of bitcoin relevant docket entries? |
| 01:27:58 | phantomcircuit: | gmaxwell, yes |
| 01:28:22 | phantomcircuit: | fun with lexus nexus |
| 01:28:25 | gmaxwell: | Is anyone aware of any fully homorphic encryption schemes can have a plaintext output? e.g. the code inside the FHE decides to write to a plaintext output |
| 01:28:31 | gmaxwell: | phantomcircuit: any details on it? |
| 01:28:43 | phantomcircuit: | gmaxwell, i'll upload the complaint in a minute |
| 01:31:02 | phantomcircuit: | gmaxwell, also it should be on RECAP now |
| 01:34:03 | phantomcircuit: | huh not working |
| 01:36:40 | gmaxwell: | and of course, pacer's password recovery takes like ... days |
| 01:38:03 | warren: | you folks manage to get it? I have westlaw and lexis access right now |
| 01:40:40 | phantomcircuit: | warren, i have it but scribd doesn't like me |
| 01:43:02 | phantomcircuit: | gmaxwell, http://198.27.67.106/hashfast.pdf |
| 01:43:55 | gmaxwell: | phantomcircuit: Can I post that URL on the forum? |
| 01:44:25 | warren: | from PACER? |
| 01:44:34 | phantomcircuit: | gmaxwell, sure |
| 01:44:37 | gmaxwell: | Thanks. |
| 01:45:14 | phantomcircuit: | warren, yes |
| 01:45:55 | warren: | well, good luck to them on getting their BTC back... USD value seems more likely |
| 01:47:05 | phantomcircuit: | warren, sure, but at what day? |
| 01:47:19 | phantomcircuit: | warren, did you notice the spike to 1000 on mtgox? |
| 01:47:23 | phantomcircuit: | i wonder if that's a coincidence |
| 01:47:28 | phantomcircuit: | or you know... not |
| 01:49:49 | jgarzik: | michagogo|cloud, yes, it is time to update bootstrap torrent. Past time, even. |
| 01:50:46 | phantomcircuit: | http://ia600407.us.archive.org/25/items/gov.uscourts.cand.273355/gov.uscourts.cand.273355.docket.html |
| 01:52:24 | phantomcircuit: | i wonder if pacer has broken recap on purpose |
| 02:10:25 | phantomcircuit: | http://www.archive.org/download/gov.uscourts.cand.273355/gov.uscourts.cand.273355.1.0.pdf |
| 02:10:28 | phantomcircuit: | there we go |
| 02:10:41 | phantomcircuit: | that cost me like $10 |
| 02:10:44 | phantomcircuit: | stupid pacer |
| 02:57:45 | fagmuffinz_: | +1 on updating the bootstrap torrent |
| 02:58:07 | fagmuffinz_: | I'm currently catching up my laptop and it's > 10 weeks behind |
| 02:58:25 | fagmuffinz_: | Been several hours now and I'm just 7 weeks behind now |
| 03:01:39 | gmaxwell: | the torrent is just papering over the lack of the headers first patches. |
| 03:06:18 | justanotheruser: | justanotheruser has left #bitcoin-wizards |
| 03:16:09 | maaku: | fagmuffinz_: it will take just as long to verify via the bootstrap download |
| 03:16:23 | maaku: | unless you manually set a checkpoint or something |
| 03:18:04 | phantomcircuit: | maaku, actually it's much faster |
| 03:18:29 | gmaxwell: | maaku: fetch is seriously fuxored now.. |
| 03:19:11 | maaku: | well i guess it depends on your internet speed :P |
| 03:19:23 | maaku: | i'm behind an ADSL.1 here :( |
| 03:19:35 | maaku: | rural speeds |
| 03:24:28 | gmaxwell: | maaku: right you now you can expect to fetch the same blocks over and over again during sync, doesn't help when you're on adsl. :( |
| 04:43:25 | jgarzik: | jgarzik is now known as home_jg |
| 05:21:34 | michagogo|cloud: | jgarzik: do you know which block you'll extend it to? |
| 05:22:47 | michagogo|cloud: | (If so, I can generate the file myself, and be ready to seed when it goes live) |
| 05:26:05 | maaku: | maaku is now known as Guest58374 |
| 05:33:40 | gmaxwell: | warren: http://peercoin.net/index.php < click Myth 2. |
| 05:51:54 | michagogo|cloud: | gmaxwell: o_O |
| 05:52:35 | michagogo|cloud: | They were the ones that allow the dev to add new checkpoints at any time without an update to the software, right? |
| 05:52:45 | BlueMatt: | gmaxwell: though that looks ridiculous, it does say they dont enforce checkpoints by default.... |
| 05:52:50 | BlueMatt: | michagogo|cloud: yes |
| 05:54:11 | gmaxwell: | BlueMatt: it's not true. |
| 05:54:20 | BlueMatt: | ahh |
| 05:54:22 | gmaxwell: | BlueMatt: the text they're quoting there is about XPM not PPC. |
| 05:54:29 | BlueMatt: | well...thats just ridiculous |
| 05:54:33 | gmaxwell: | BlueMatt: it also says that Bitcoin and Litecoin has "checkpoints" too. |
| 05:54:42 | BlueMatt: | yea |
| 05:54:44 | BlueMatt: | I liked that bit |
| 05:55:06 | michagogo|cloud: | And even if it were true, if part of the network enforced them DNA another part didn't, that means a hardfork |
| 05:55:14 | michagogo|cloud: | and* |
| 05:55:50 | gmaxwell: | The PPC consensus model _requires_ them, not just for fuzzy security reasons, but because you cannot validate PoS without a transaction index containing the stake thats being used on the block... so they only allow coins which have been immobile for >30 days to be used for PoS and then use the checkpoints to make damn sure the network agrees about the state in the past. |
| 05:56:23 | gmaxwell: | I also checked the PPC codebase, they're on, and there appears to be no way to turn them off. |
| 05:57:04 | warren: | gmaxwell: and of course it doesn't matter if it isn't enabled by default, if pools do then the users don't have a choice. |
| 05:58:01 | michagogo|cloud: | Erm, maybe not hard |
| 06:40:54 | gmaxwell: | I wish people would ask better questions: http://www.reddit.com/r/Bitcoin/comments/1uoq6e/what_do_you_guys_think_of_proof_of_stake_mining/cek9fhq |
| 06:42:36 | home_jg: | I wish reddit would not suck so much |
| 06:43:09 | home_jg: | Cardinal example of upvoting/downvoting systems producing herds of fast-moving idiots |
| 06:43:51 | home_jg: | I say this as a near-daily reddit user, of course |
| 06:45:12 | home_jg: | well-informed cautionary answers on brainwallets routinely get downvoted |
| 06:53:25 | Guest58374: | herding idiots |
| 06:53:31 | Guest58374: | i'm going to remember that :) |
| 06:54:28 | Guest58374: | Guest58374 is now known as maaku |
| 06:58:07 | gmaxwell: | the upvoted downvotey stuff overweighs superficial opinions. It's fine for cat pictures. |
| 06:58:13 | gmaxwell: | (which is mostly why I browse reddit) |
| 06:58:28 | gmaxwell: | I hardly read any bitcoin or technology things at all, mostly just funny pictures of animals. |
| 07:00:18 | Taek42: | I'm not sure that it's a symptom of upvotes and downvotes so much as Reddit being a general audience |
| 07:01:04 | maaku: | people are stupid |
| 07:01:09 | gmaxwell: | Taek42: nah, normally the general audience doesn't have their hands firmly placed on the steering wheel. |
| 07:01:20 | maaku: | it boggles my mind that when you have a crowd of them, wisdom is supposed to emerge |
| 07:01:42 | gmaxwell: | lol |
| 07:01:55 | Taek42: | democracy! |
| 07:02:00 | gmaxwell: | to be fair even the crappy "Wisdom of the crowds" book said that wasn't actually so. |
| 07:04:38 | Taek42: | I've often wondered what would happen if voting had a cost to it, and you could pick the power of your vote by adjusting the cost |
| 07:04:39 | maaku: | never actually read it. was the thesis that you need proper incentives? |
| 07:07:46 | michagogo|cloud: | Taek42: a monetary cost, you mean? |
| 07:08:08 | Taek42: | well, some sort of currency that could be swapped for real currency |
| 07:08:11 | maaku: | citizen cost a la starship troopers? |
| 07:08:11 | Taek42: | dogecoin, perhaps |
| 07:08:18 | gmaxwell: | voting already has a substantial cost in terms of time/trouble. |
| 07:08:33 | Taek42: | on reddit, the first vote is pretty costly |
| 07:08:42 | Taek42: | seeing as you have to log in, and maybe create an account |
| 07:08:46 | Taek42: | but the rest are painless |
| 07:09:39 | michagogo|cloud: | Or creddits |
| 07:09:48 | Taek42: | I imagine though that it wouldn't actually be that different even if there were a monetary cost to each vote (or a karma cost) |
| 07:10:23 | Taek42: | The problem being that the average person could have as much authority/power as the expert |
| 07:10:27 | michagogo|cloud: | I seem to recall there was some site like that |
| 07:10:39 | michagogo|cloud: | Where you spend reputation points to vote |
| 07:11:22 | phantomcircuit: | gmaxwell, is there still a penalty for p2pool? |
| 07:11:32 | phantomcircuit: | iirc there used to be a substantial orphan rate |
| 07:11:57 | phantomcircuit: | also @anybodyelse |
| 07:12:20 | gmaxwell: | phantomcircuit: it has the lowest orphan rate of any pool as far as I can tell. |
| 07:12:38 | phantomcircuit: | what's it's current orphan rate? |
| 07:13:02 | gmaxwell: | there has been two this year. |
| 07:14:01 | gmaxwell: | 0.12% in my data. (eligius, by comparison, has been ~1%) |
| 07:14:25 | phantomcircuit: | that's interesting |
| 07:14:52 | gmaxwell: | phantomcircuit: p2pool changed a couple years ago to a model where nodes pre-forwarded transaction data to their peers. So when one finds a block it just has to send the list of transactions that were actually in it. |
| 07:15:38 | Taek42: | theoretical problem: suppose every miner picks the maximum-payout pool. Wouldn't every miner end up picking the same pool? |
| 07:15:43 | gmaxwell: | it will also mine a transactionless block in brief windows when the local bitcoind is lagging but p2pool peers have produced shares against a further along chain. |
| 07:15:48 | phantomcircuit: | any idea why the orphan rate would be lower than eligius? |
| 07:16:11 | gmaxwell: | phantomcircuit: because it has an enormous network connectivity advantage. |
| 07:16:49 | phantomcircuit: | it might also have to do with what kind of hardware is connected to p2pool |
| 07:16:54 | phantomcircuit: | some of them have uh |
| 07:17:00 | phantomcircuit: | interesting ideas of what stale means |
| 07:17:04 | gmaxwell: | p2pool blocks end up being concurrently announced by a dozen peers in the first 30ms after finding a block... hundreds within 400ms. |
| 07:18:21 | gmaxwell: | phantomcircuit: maybe, p2pool direct miners to return "stale" shares. |
| 07:18:42 | gmaxwell: | in any case, if some miner is overly agressive in what its discarding, its not getting paid for that portion of its work. |
| 08:18:52 | fagmuffinz: | fagmuffinz has left #bitcoin-wizards |
| 08:51:51 | gmaxwell: | I think bitcoin is becoming the new DHT. :( |
| 08:52:49 | wumpus: | yo, slap a blockchain on it |
| 08:53:32 | roidster: | COULUD STAND FOR HEMROID |
| 08:53:57 | roidster: | could* pardon the caps |
| 08:55:10 | BlueMatt: | gmaxwell: I think we've known that was gonna happen for a while |
| 08:55:33 | BlueMatt: | /has been happening for a while |
| 08:55:43 | wumpus: | well yes bitcoin is the new idea of the day, so now we're in the [try_with_new_idea(x) for x in old ideas] phase |
| 08:56:47 | wumpus: | and you get nonsensical ideas, like in the internet boom.... just like your old pet shop, but online! |
| 09:06:48 | gmaxwell: | a miracle happened on reddit today |
| 09:07:02 | gmaxwell: | someone mentioned my name in a ppc thread, which is what brought my attention to those claims on that website. |
| 09:07:09 | gmaxwell: | I refuted them with citations to source code. |
| 09:07:29 | warren: | URL? |
| 09:07:34 | warren: | (reddit thread) |
| 09:08:02 | gmaxwell: | http://www.reddit.com/r/Bitcoin/comments/1uoq6e/what_do_you_guys_think_of_proof_of_stake_mining/cek7vbc |
| 09:08:30 | gmaxwell: | and someone argued with me... and then actually accepted my counter arguments. and I'm not being voted down! |
| 09:14:23 | sipa: | i've been explaining the problem with PoS a few times now at the zurich bitcoin meetups |
| 09:14:35 | sipa: | people do seem to understand it |
| 09:18:11 | gmaxwell: | it makes me sad, I really wish it worked. |
| 09:19:37 | justanotheruser: | What are the potential problems of associating namecoin registration price with transaction fee sum? |
| 09:19:53 | gmaxwell: | what is a "transaction fee sum"? |
| 09:20:46 | gmaxwell: | if you mean some function of recent transaction fees … the problem is miners padding up transaction fees with payments to themselves to manipulate prices (might as well just let miners set them) |
| 09:20:58 | justanotheruser: | gmaxwell: you could look at how much was paid in tx fee since the last difficulty adjustment (or some other arbitrary period of time) |
| 09:21:36 | justanotheruser: | gmaxwell: yeah, that is a problem |
| 09:22:18 | justanotheruser: | There's not really a way to evaluate how many namecoin users there are... |
| 09:22:39 | gmaxwell: | you can look at the registrations however. |
| 09:23:00 | gmaxwell: | (and also, it's easy to see it not being used anywhere, and even easy to see the lack of people asking how to use it) |
| 09:23:02 | justanotheruser: | gmaxwell: but you can't set the registration rate based on the number of registrations |
| 09:23:31 | gmaxwell: | yea oh sorry I thought you were back to suggesting that namecoin isn't currently a failure. :P |
| 09:23:51 | justanotheruser: | If there were only 500 domains offered per day, people would have to compete in price for registering. |
| 09:24:17 | justanotheruser: | Unfortunately namecoin isn't going to ever be stable, so you can't say "$10 for a registration" |
| 09:24:27 | gmaxwell: | yea, I've got no freeking idea. yes, one possible way would be to make the database fixed in size or something like that. |
| 09:25:18 | justanotheruser: | if people compete in price it would have to be in mining fees, so the miners would be able to register however many domains they wanted... |
| 09:25:25 | gmaxwell: | well with 2 way-peg you could transfer bitcoins into the namecoin chain to pay for names, thus giving them to miners, who can remove them from the namecoin chain. (I mean, if we're talking about things which decidely aren't namecoin as it is today) so then the instability of namecoin as a tradable asset can be removed. |
| 09:25:44 | justanotheruser: | but I guess for every domain they buy, they lose one domain sale that day |
| 09:25:45 | gmaxwell: | justanotheruser: unless the system just limits it via a protocol rule. |
| 09:26:26 | justanotheruser: | gmaxwell: is there a way to have a decentralized 2 way peg? |
| 09:26:58 | gmaxwell: | I guess you missed those discussions. I believe it's possible, there are some security limitations. |
| 09:27:30 | justanotheruser: | also I don't think pegging something to bitcoin makes it stable. It makes it more stable relative to all other cryptocurrencies, but relative to almost every other asset/commodity bitcoin is incredibly unstable |
| 09:28:11 | gmaxwell: | basically I suggested a relatively minor softforking addition that would allow you to assign coins to another chain, and then carry a proof back from the other chain to bitcoin to allow you to very slowly teleport coins back and forth. |
| 09:28:20 | gmaxwell: | (slowly meaning like 100 blocks) |
| 09:28:50 | justanotheruser: | gmaxwell: would this allow for offchain transactions if the bitcoin chain was too big making transaction fees high? |
| 09:29:20 | justanotheruser: | well not "if", but for that reason would it be useful |
| 09:29:31 | gmaxwell: | it would. or more interesting it would allow altcoins to expirement with new ideas without also creating new currencies. (at least when the idea is just new payment network ideas) |
| 09:30:17 | gmaxwell: | e.g. you could have namecoin but without having a seperate namecoin currency. or you could have some 10 second blockchain thing (0_o) or something with more powerful script. |
| 09:30:29 | gmaxwell: | (turing complete script, whoppie!) |
| 09:30:38 | justanotheruser: | gmaxwell: is the peg discussion in #bitcoin-dev logs? |
| 09:30:43 | gmaxwell: | it's in the logs here. |
| 09:30:58 | justanotheruser: | any public logs for this channel? |
| 09:31:07 | gmaxwell: | andytoshi-away: makes logs, dunno where they are. |
| 09:31:14 | michagogo|cloud: | (The logs should really be mentioned in the topic...) |
| 09:32:03 | justanotheruser: | I'll make a note to ask him for the logs |
| 09:32:07 | gmaxwell: | it's not a serious proposal at this time... but perhaps it will become one. The belief that it could work two ways is relatively new. (it's not that complicated an idea though, I'm sure I would have said it was obvious in 2011 if it had been suggested to me then) |
| 09:32:55 | justanotheruser: | gmaxwell: so would this pretty much remove the need for Open Transactions? |
| 09:33:42 | gmaxwell: | but in any case the idea is that you make a payment to a special scriptpubkey which basically says "these coins are now controlled by foocoin" and then it's possible to spend from txouts to that scriptpubkey by showing up with an SPV proof "foocoin says you should give me X of those coins to scriptpubkeys Y and Z", plus some extra details. |
| 09:34:21 | gmaxwell: | justanotheruser: well it would allow the same kind of "binding" that open transactions could do already using multisig ... but allow it for other blockchain cryptocurrencies. |
| 09:34:38 | justanotheruser: | gmaxwell: isn't the only way for that SPV proof to exist by embedding all those block headers in the bitcoin blockchain? |
| 09:35:35 | justanotheruser: | Or is there some way that the miner can be proved that their blockchain says something without actually looking at anything other than the transaction |
| 09:35:36 | gmaxwell: | justanotheruser: sure, but 100 blocks is 8kb. whopptie do. These transfers would generally be infrequent because they'd be used for bulk liquidity, normally if you want coins on the other chain you find someone who wants bitcoin and you do an atomic coinswap. |
| 09:35:59 | gmaxwell: | But the coinswaps alone cant get you a 2-way peg because they can't provide long term liquidity. |
| 09:37:13 | gmaxwell: | justanotheruser: the proofs could also be structured so that they can be pruned. e.g. perhaps the only thing that gets stored in the blockchain directly is a summary of the proof. After all the proof only has SPV security, once it's thousands of blocks deep in bitcoin why keep it? (and if that were done the proof wouldn't need to count against the block size limit, or wouldn't need to count against it fully) |
| 09:38:22 | gmaxwell: | (also a single proof could actually be batching dozens of transfers, e.g. foocoin tells bitcoin a whole list of scriptpubkeys to pay, at least you can get batching in the foo->bitcoin direction) |
| 09:39:05 | justanotheruser: | gmaxwell: Seem expensive still. The blockchain could end up storing a dozen other blockchain headers in it |
| 09:39:33 | gmaxwell: | e.g. the foo->bitcoin instructions are generated by foocoin miners, summarizing actions commanded by transactions and validated according to the foocoin rules. |
| 09:40:06 | gmaxwell: | justanotheruser: well snarks can compress that kind of thing down to 384 bytes for 128 bit security, but I'd prefer to show it viable without any cutting edge cryptography. |
| 09:40:41 | justanotheruser: | I wonder if there's some crypto that could be used to do that proof in a size significantly smaller than the actual altchain |
| 09:40:44 | gmaxwell: | justanotheruser: and each of those dozens of other chains could have an infinity of transactions, seems like a good tradeoff to me. |
| 09:41:08 | justanotheruser: | gmaxwell: do you think that's more viable than sharding the blockchain? |
| 09:41:47 | gmaxwell: | justanotheruser: zk-SNARKs can have size only proportional to the security level. The size of the rule being proven or the data it accesses is irrelevant to them. |
| 09:43:30 | gmaxwell: | but the really small ones have some uncomfortable security tradeoffs (CRS assumption) the ROM ones are somewhat larger (eg 20kb, though I did invent a novel compression scheme which may help, so they may not be good for compressing header proofs, but then again they'd allow full security not just spv, potentially.. but this is all really cutting edge and not yet totally pratical stuff.) |
| 09:44:02 | justanotheruser: | hmm |
| 09:44:48 | justanotheruser: | gmaxwell: do you have some cryptography PhD or something? |
| 09:45:14 | gmaxwell: | in any case, I don't think an 8kb signature intermittently per bound chain is a bad tradeoff. Especially knowing that application of sufficient magic could make it smaller in the future. |
| 09:45:31 | gmaxwell: | justanotheruser: No. I'm just some guy who enjoys math. |
| 09:45:41 | justanotheruser: | I see |
| 09:45:57 | justanotheruser: | This idea seems to have a lot of potential |
| 09:46:44 | justanotheruser: | Would this not require disabled opcodes to determine whether the transactions belonged to someone else on this other chain? |
| 09:47:05 | justanotheruser: | I guess you said it was a softfork, so my real question is why wouldn't it |
| 09:47:21 | gmaxwell: | I think it does too. well, and it also may solve a problem thats been bothering me— which is that its hard to do novel cryptocoin expirementation. We can't mess around with it in bitcoin because its too important. Alt systems generally get little love because they're worthless, unless you make a big thing about pumping their value and then that speculation becomes all encompassing. |
| 09:48:03 | gmaxwell: | justanotheruser: we'd add a new opcode in place of a no-op today "the thing on the stack is a chain binding proof, this transaction is only valid if the proof is valid" |
| 09:48:41 | gmaxwell: | old nodes would just see a no-op transaction and permit it. |
| 09:49:00 | gmaxwell: | It would be safe to use once a super majority of hashpower agreed to enforce it as a rule in the chain— same way p2sh was deployed. |
| 09:49:47 | Taek42: | gmaxwell, what's your opinion of XRP? |
| 09:50:39 | gmaxwell: | Taek42: https://bitcointalk.org/index.php?topic=144471.0 the whole thread is informative, I answer my own question and then get into a discussion with one of the ripple developers. |
| 09:50:54 | Taek42: | thanks |
| 09:53:08 | TD_: | TD_ is now known as TD |
| 09:53:51 | justanotheruser: | Any known weaknesses to the pegging system? |
| 09:53:55 | gmaxwell: | ohh "Crony Consensus" I'll have to remember that. |
| 09:54:51 | gmaxwell: | justanotheruser: at least as I was describing above it only has SPV-like security. meaning that if you can outpace the second chain you can steal all the bitcoins assigned to it and leave it fractional reserve. |
| 09:55:08 | gmaxwell: | (which would be part of the reason it would need to be fairly slow) |
| 09:55:21 | gmaxwell: | (I mean the teleport operation would need to be slow) |
| 09:56:15 | BlueMatt: | gmaxwell: implementation detail: do you require the side-chain be merged-mined? |
| 09:56:31 | justanotheruser: | BlueMatt: seems like that would be ideal |
| 09:56:39 | TD: | good evening guys |
| 09:56:50 | gmaxwell: | BlueMatt: I don't think bitcoin should require that, though it would probably be pretty darn prudent. |
| 09:57:02 | BlueMatt: | hi TD |
| 09:57:21 | gmaxwell: | BlueMatt: at least my thought is really "just add enough so that bitcoin can verify a sutiable proof, and then you can build anything out of that which you can make fit" |
| 09:57:24 | gmaxwell: | HI |
| 09:57:32 | sipa: | TD: timezone deficiency? |
| 09:57:58 | TD: | evening for them. morning for us :) |
| 09:58:08 | gmaxwell: | BlueMatt: so while it might be _wise_ to merge mine it, and perhaps there are some optional strenghtening things that could be done, I don't think it would make sense to require it. |
| 09:58:08 | sipa: | ah, right |
| 09:58:19 | BlueMatt: | gmaxwell: makes sense |
| 09:58:33 | TD: | lol |
| 09:58:34 | TD: | "Since we're generating the points randomly, I'm going to ignore the first condition because it happens far less frequently than malfunctions in the CPU instructions that I might use to detect it." |
| 09:58:43 | TD: | i think i'm going to remember this excuse for ignoring edge cases, for the future :) |
| 09:58:52 | sipa: | link? |
| 09:58:57 | TD: | https://www.imperialviolet.org/ |
| 09:59:03 | TD: | agl talking about implementing elligator for curve25519 |
| 09:59:23 | gmaxwell: | e.g. ideally the pubkey could specify the proof geometry required with enough flexibility that you could merge in something rather throughly unlike bitcoin. |
| 09:59:33 | justanotheruser: | sipa: seem into producing acronyms... |
| 10:00:21 | gmaxwell: | BlueMatt: though annoyingly some of the already existing altcoins can't have compact spv-like proofs. :( |
| 10:00:48 | justanotheruser: | gmaxwell: scryptcoins? |
| 10:00:50 | TD: | how did they manage that? |
| 10:01:22 | TD: | justanotheruser: no, scrypt based coins still use sha256 for the merkle tree |
| 10:01:36 | BlueMatt: | gmaxwell: meh, I dont care about current altcoins that do dumb things, I want to enable actual innovation, not knob twiddling |
| 10:01:49 | TD: | says the guy behind coingen.io :) |
| 10:01:53 | justanotheruser: | TD: but how do you verify the PoW without including scrypt into bitcoin or implementing scrypt in a bitcoin script? |
| 10:02:11 | BlueMatt: | TD: yes, hopefully it will saturate the market with knob twiddling and people will get bored of it |
| 10:02:31 | gmaxwell: | TD: well PPC's proof of stake stuff appears to need a (mostly) unpruned blockchain history to validate. And a primecoin headers look like they're a couple kilobytes and need primality testing?! |
| 10:03:35 | TD: | gmaxwell: surely even in proof of stake, transactions are in blocks and arranged into a merkle tree though? |
| 10:03:54 | TD: | or you mean you can't just download headers at all |
| 10:03:56 | gmaxwell: | TD: you need to prove it hasn't been spent. |
| 10:04:09 | gmaxwell: | well they have no getheaders p2p messages either, but thats an aside. :P |
| 10:05:22 | gmaxwell: | basically at least as PPC is now, I don't think you can extract a compact proof that a header is valid. maybe you can get close enough by extracting the transactions and assuming they weren't subsiquently spent, but I dunno, since there is no POW on those blocks attacking is cheap. I honestly haven't thought about it much. |
| 10:06:32 | gmaxwell: | at a minimum it's complicated. |
| 10:07:36 | sipa: | maybe we should write a "if you're going to create an altcoin, think about:" document |
| 10:08:10 | BlueMatt: | sipa: yea, think about: "2-way pegged value" |
| 10:08:34 | sipa: | listing some of the easy-if-we-knew-it-at-the-start ideas like p2sh only, or simplifying script, or having amounts in the signature hash |
| 10:08:50 | sipa: | and concerns like compact proofs |
| 10:09:08 | sipa: | oh and maybe explain the reason for block times being slow |
| 10:10:53 | gmaxwell: | sipa: dunno that it would help, couldn't hurt. I say I don't know because of how they've responded when encountering problems. |
| 10:11:48 | BlueMatt: | for current-gen alts, its sure to make no difference |
| 10:12:35 | gmaxwell: | (e.g. the general response has been to do something even dumber) |
| 10:12:43 | BlueMatt: | for people making real alts (maybe, though I'm very unconfident) coingen will help |
| 10:14:15 | gmaxwell: | e.g. feathercoin had instability and attacks in due to some of their parameter choices, their response was to pay the ppcoin person to license "advanced checkpointing" from ppc (developer broadcast "checkpoints"). |
| 10:15:25 | Taek42: | are people licensing cryptocurrency ideas now? |
| 10:16:21 | _ingsoc_: | BlueMatt: Lol. |
| 10:16:29 | _ingsoc_: | _ingsoc_ is now known as _ingsoc |
| 10:16:46 | gmaxwell: | thats the only incident of it that I'm aware of. |
| 10:16:55 | TD: | i never liked p2sh only as an idea. |
| 10:16:58 | gmaxwell: | unless you count coingen.io |
| 10:17:38 | gmaxwell: | It's certantly something I'd do when starting from scratch. Opinions may differ. |
| 10:17:38 | TD: | ethereum might evolve into an interesting alt |
| 10:17:56 | TD: | gmaxwell: well, it'd rule out things like OP_RETURN tagged outputs and the like, which people have found uses for. |
| 10:18:15 | gmaxwell: | TD: yea, the ethereum warez site agent is totally going to be popular. :P |
| 10:18:58 | TD: | is that actually on their website? |
| 10:19:18 | gmaxwell: | TD: no reason that it would preclude having a no index flag (or really just a seperate field in transactions for aux data). |
| 10:19:34 | gmaxwell: | TD: no, I was kidding, but it seemed to follow naturally from the description of it I read. :P |
| 10:19:46 | TD: | you saw payfile, right? :) |
| 10:19:46 | sipa: | what is ethereum? |
| 10:19:47 | gmaxwell: | TD: you couldn't tell for sure though… |
| 10:20:13 | TD: | gmaxwell: that's true. you could extend the tx format at the same time. |
| 10:20:25 | gmaxwell: | sipa: vitalik altcoin based on turing complete script. |
| 10:20:35 | gmaxwell: | doesn't exist yet as far as I know. |
| 10:20:54 | sipa: | ah |
| 10:20:57 | gmaxwell: | a bunch of the design decisions wouldn't be ones I would have made but. ::shrugs:: |
| 10:21:31 | gmaxwell: | sipa: in particular it's supposted to support being able to upload code into the network which the network runs triggered by events e.g. independantly of transactions, which can do things like create transactions. |
| 10:21:47 | sipa: | ewww |
| 10:21:56 | TD: | hah |
| 10:21:59 | gmaxwell: | and a handwave at fees to pay for it, without any consideration of the incentives around that. |
| 10:22:06 | gmaxwell: | Yea, my response too. But at least its different. |
| 10:22:20 | TD: | right. hence me thinking it's the most interesting alt, even if i also think it's unlikely to work |
| 10:22:23 | TD: | but we'll see |
| 10:22:24 | gmaxwell: | be nice or I'll suggest they name one of their currency units after you. |
| 10:22:46 | nsh: | nobody talks about Dr Frankenstein advanced the field of medicine |
| 10:22:48 | nsh: | +how |
| 10:23:30 | gmaxwell: | http://demotivators.despair.com/demotivational/mistakesdemotivator.jpg |
| 10:23:39 | TD: | the guardian did a nice article on alt coins. i banged the drum about how they demonstrate the fundamentally democratic nature of crytocurrencies |
| 10:24:03 | TD: | so coingen and other joke alts are not entirely useless. they educate people about the tech and more importantly, make BlueMatt a lot of money |
| 10:24:14 | nsh: | * nsh smiles |
| 10:24:32 | gmaxwell: | Sadly alt's don't work too well as education on what not to do, just like invent your own blockcipher usually doesn't— because they usually don't reach the point where they justify a serious attack, but oh well. |
| 10:24:57 | TD: | well, that's education of developers. i'm thinking of education of users. showing how bitcoin developers are not simply the new central bankers |
| 10:25:12 | TD: | http://www.theguardian.com/technology/2014/jan/07/bitcoin-me-how-to-make-your-own-digital-currency |
| 10:25:32 | gmaxwell: | TD: hey, I strongly promoted that idea. I'm all for it. I also suggested it to people who wanted to "fight" altcoins as the fair and ethical way to do so... "we think these things are pointless, well it's not fair to stop them, but lets reduce the friction that makes making a pointless altcoin profitable." |
| 10:26:19 | gmaxwell: | TD: did you see the fallout from the launch of the 'conya' coin? (or however its spelled?) |
| 10:26:38 | gmaxwell: | coinye |
| 10:27:35 | warren: | gmaxwell: I'm guessing ICANN procedure to get the domain taken away will be tried next |
| 10:27:49 | gmaxwell: | yea probably. |
| 10:27:55 | gmaxwell: | did you see they were having zillion block reorgs? |
| 10:28:08 | sipa: | who? |
| 10:29:16 | TD: | i saw that kanye's lawyer was trademark-whacking them. lol. |
| 10:29:28 | gmaxwell: | coinye coin. another purpusfully dumb coin, but it started out with about 1/1000th of the initial difficulty it should have had. |
| 10:29:35 | TD: | and the anonymous authors response was basically to wave two fingers at them and say they'll bump up the release date |
| 10:29:44 | gmaxwell: | (they basically released a password to unlock the software at some time with enormous hype) |
| 10:30:17 | sipa: | eh? |
| 10:31:10 | warren: | if they were anonymous devs, with people unable to examine the software before the launch of mining, they could have included a trojan to steal |
| 10:31:22 | warren: | lots of idiots would rush in |
| 10:31:28 | gmaxwell: | and now pools that lost the reorg wars have shuttered and people are angry that they're not getting paid. |
| 10:31:34 | warren: | and they would cash out in an unexpected way |
| 10:31:50 | Taek42: | warren sounds like something worth trying |
| 10:32:02 | BlueMatt: | warren: I'm honestly surprised we haven't seen more of that |
| 10:32:08 | gmaxwell: | it was only released a couple hours ago and has like 5000 blocks. |
| 10:32:24 | gmaxwell: | BlueMatt: esp now that some of these exchanges will happly add brand new coins. |
| 10:35:12 | gmaxwell: | is it just me or is bc.i switching to USD every time other people follow a link to it? |
| 10:36:46 | sipa: | experienced that as well |
| 10:40:38 | michagogo|cloud: | gmaxwell: not just you |
| 10:54:09 | warren: | BlueMatt: to avoid that someone could release all the code except for the genesis |
| 10:54:50 | gmaxwell: | I believe thats how ltc was launched. |
| 10:55:25 | gmaxwell: | https://bitcointalk.org/index.php?topic=404888.0 < fwiw, I posted asking about bc.i's switching |
| 11:06:47 | TD: | sigh. we need to beat some rationality into the fees market |
| 11:19:44 | warren: | TD: the way we rolled out 20x lower fees might be feasible (albeit very dumb) |
| 12:54:52 | adam3us: | TD, gmaxwell: i admit some fault with coingen.io also (I was stting opposite mappum when he registered the domain), not a new idea apparently, but I yacked about how cool it would be a bunch with BlueMatt and put him up to it. maybe it'll back fire in interesting ways, but the intent is humorous clearly and genuine: to deflate param tweaks |
| 12:56:15 | adam3us: | TD, gmaxwell: and its actually serious. it seems to me that alts are stifling actual innovation. if u think about it inmany ways bitcoin innovation has virtually stalled since 2009. thats why i want to kill param-tweaks, and think pegged side-chains are the bet new idea since 2009 in bitcoin period. |
| 13:02:51 | adam3us: | about ethereum i talked to vitalik about it, not sure i mentioned this part or not, that while fees is a solution to the halting problem in a Turing Complete complete script language; however the history of java byte code interpreter sandbox escapes could give it a massive, repeating, binary failure, where each sandbox escape results in theft of all coins (and maybe bitcoins) |
| 13:15:26 | adam3us: | aka there is a reason bitcoin script is functional, no iterators/recursion, and most of even the stylized/simplified/cut-down script language is itself disabled. ripple dont seem to appreciate this risk and their draft script language looks turing complete. in open transactions, chris showed me he has pluggable script language interpreter hooks and jscript, lua etc but thats just code because he likes generalized clean code. |
| 13:54:37 | andytoshi-away: | justanotheruser: logs are at http://download.wpsoftware.net/bitcoin/wizards/ ... if you msg andytoshi-logbot with 'help' i think it'll tell you |
| 13:55:06 | andytoshi-away: | sipa: re 'someone should write a "what to think about before making an alt" document', i'm planning to write something like that this weekend |
| 13:58:22 | TD: | adam3us: you wouldn't try to steal all coins simultaneously, that'd be dumb |
| 13:59:24 | TD: | adam3us: it'd just be treated as an outage |
| 13:59:47 | TD: | you'd want to steal 1% or something like that ... |
| 14:00:26 | adam3us: | TD: if these coins are pegged bitcoins, you'd want to steal as many as possible. it depends on the reaction mode to stemming the loss. if its like the many exchange/processor thefts like say sheep market place (the largest?) because of the irrevocability maybe you may not even care if u empty the alt chain in one go on the way |
| 14:01:21 | adam3us: | TD: what re people going to do? issue and deploy an emergency bitcoin patch to reject this specific side chains re-conversion? that sounds centralized and fed policy like |
| 14:01:43 | TD: | we were talking about ethereum i thought? |
| 14:01:51 | adam3us: | TD: but you may well be right for detail reasons that the optimal exfiltration |
| 14:02:11 | adam3us: | TD: oh yeah sorry :D |
| 14:03:14 | adam3us: | TD: i guess that depends on the market cap and the liquidity and intent of the sabateur. why are they killing the alt. to make money or because they want to do a 'scorched earth' to borrow a petertodd'ism to prove a point |
| 14:04:00 | adam3us: | TD: lot of people might be quite upset and litigious about it if the market cap was like non-trivial at the time. dangerous thing to do possibly even via Tor. |
| 14:04:30 | adam3us: | (sorry i was still in pegged side-chain mode so misinterpreted your observation) |
| 14:04:34 | TD: | anyway, most of the java sandbox escapes especially these days are not issues with the bytecode verifier but rather with the huge libraries or native code that they call out to |
| 14:04:51 | TD: | presumably ethereum would not have anything in the way of libraries or big surface area APIs |
| 14:07:05 | adam3us: | TD: interesting point, yes i never went looking at the root cause of the repeated sandbox failures, but if thts accurate the risk might be a bit lower. but anyway i guess you can say its a brittle failure mode and more risky than bitcoin as a value store as a result. not only could a big bug collapse value like, but some worse things i think, like taking control simultaneously of all online nodes. |
| 14:07:32 | TD: | sure |
| 14:07:38 | TD: | code execution is always tricky |
| 14:08:04 | TD: | ironically, i suspect the JVM may end up being one of the safest sandboxes around. given how massively and repeatedly it's been attacked by hardened hackers compared to most sandboxes |
| 14:08:14 | adam3us: | (could happen to btc also, but higher risk as their code is basically an abstract interpreted asm with memory and iteration, pointers. very flexible. more like executing x86 interpreter) |
| 14:08:24 | TD: | if they keep plugging away at it for enough time, and if you restrict the API surface area, it could end up being kind of robust |
| 14:10:14 | adam3us: | TD: yes. but it seems in some ways that btc is surfacing whole new levels of code assurance. if there's a $1bil reward sitting on the table for entire system value exfiltration, more resources nd resourceful people get in, or lose their ethical behavior $ limit filter, seemingly empirically many otherwise trustworthy people have such limits) |
| 14:11:14 | adam3us: | just to say maybe its more interesting to sandbox escape ethereum (if btc was using that model right now) than sandbox vm escapes. it only takes one. |
| 14:11:16 | TD: | yeah. it makes me wonder if one day it'll simply become impossible to make any changes to the code at all because the legal/financial risk of making a mistake is so high |
| 14:11:25 | TD: | either that or every bitcoin developer will be anonymous and work from behind Tor |
| 14:11:28 | adam3us: | TD: yes i think so |
| 14:11:38 | TD: | neither outcome seems desirable |
| 14:11:42 | TD: | still i guess banks manage, sorta, somehow |
| 14:12:53 | adam3us: | TD: the Tor thing is interesting. i think people who get into exchanges and btc biz dont realize the risk they are putting themselves, their family etc at. if they get enough value inside a server, they have become like a bank. at the high end what do we need like thebunker.net or fortress with servers in it. seems like banks or physcal security need to be part of the picture with multsig eventually |
| 14:14:14 | adam3us: | TD: yes, that seems part of the genuine value of banks, they have structured governance (cross checks) physical security, personnel vetting, alarms, perhaps monitored security at managers houses. they had to think about it all and manage it. that is actual value. |
| 14:14:15 | TD: | probably. one reason why i'd never run an exchange or bitbank. however, exchanges are needed, so .... someone has to take that risk. w.r.t the rest of it, well, it's MIT licensed and disclaims all responsibility for everything |
| 14:14:28 | TD: | though i imagine some people will eventually ignore that and try their luck in courts anyway |
| 14:14:51 | adam3us: | TD: what u mean sue for losses due to code bugs? |
| 14:15:09 | TD: | well, or for any other kind of excuse. or patent lawsuits or whatever. |
| 14:15:17 | TD: | i mean as the amount of value goes up, anything could happen |
| 14:16:38 | adam3us: | TD: was vaguely wondering if one could retain unseizability property while protecting your self or your exchange or your processor (some server or equipment or paper under the service operators and employees control) from physical duress, by multisig the whole thing with a physical security provider of one part of the multisig. the RA aspect of the bank multisig is typically weak also. tho they do a lot of risk management |
| 14:17:54 | WOODMAN: | morning warriors |
| 14:17:59 | TD: | they're also insured |
| 14:18:15 | adam3us: | TD: like cheque sigs are not verified under £30k i hear. but if u wire £20k you can do that with some lame, malware attackable security. exactly insurance and risk management. |
| 14:18:25 | WOODMAN: | anybody been around on this technology since early days, i have a decent question if its ok? |
| 14:18:37 | WOODMAN: | brb |
| 14:19:04 | andytoshi-away: | WOODMAN: usually, try #bitcoin-dev first |
| 14:19:23 | adam3us: | TD: but i think what backs it all up is the revocability, usually when things go wrong they can undo the tx, they have ID, so they can recover even withdrawn funds, and insurance covers the rest |
| 14:20:28 | adam3us: | TD: btc lacks that. and if we introduce it (certainly can do revocable, easy using irrevocable + multisig escrow) then the disput resolution costs come back in and btc tx costs same as credit card. so we cant win. the remaining new avenue is to some smart contract magic |
| 14:20:29 | WOODMAN: | what is this site? |
| 14:20:29 | TD: | yep. it might turn out in the long run that irreversible transactions are simply something humanity can't handle, when the amounts of value being handled get too high |
| 14:20:44 | WOODMAN: | https://bitcointalk.org/index.php?topic=11606.0 |
| 14:20:46 | TD: | (too hard to build secure software systems) |
| 14:20:56 | adam3us: | TD: was ever thus. ecash (irrevocable fast settlement) and slow cash just dont interface together well |
| 14:21:02 | WOODMAN: | i believe i bought bitcoin in 09 |
| 14:21:35 | adam3us: | TD: yes. maybe that is an answer. large payments typically can tolerate being slow, and the parties having recourse enough to tolerate the revocability. |
| 14:21:37 | WOODMAN: | i never set up a client....bought from someone who put it on a USB and sent it to me....me never wanting to store on computer cause of hacking and never planned on selling, as there was no market at that time |
| 14:21:54 | andytoshi-away: | WOODMAN: #bitcoin please |
| 14:21:56 | WOODMAN: | i found this link and it discusses that you can put bitcoins on a USB |
| 14:22:01 | WOODMAN: | ah come on andy |
| 14:22:05 | andytoshi-away: | though i did enjoy the second post saying 'screw that, just use mybitcoin' :) |
| 14:22:06 | WOODMAN: | be a sport |
| 14:22:11 | sipa: | WOODMAN: #bitcoin, now |
| 14:22:24 | WOODMAN: | ahora! |
| 14:22:38 | WOODMAN: | im banned from there |
| 14:22:48 | sipa: | (you're very welcome to follow the discussion here, or contribute, but basic questions are completely off topic) |
| 14:22:54 | TD: | or post to bitcointalk |
| 14:23:10 | WOODMAN: | too many indians , not enough chiefs |
| 14:23:36 | WOODMAN: | this could be problem with open source |
| 14:24:19 | WOODMAN: | got another bitcoin IRC where they respect free speech? |
| 14:24:30 | WOODMAN: | or is this all funded by soros? |
| 14:25:00 | adam3us: | TD: "TD: (too hard to build secure software systems)" i worry about this. baseband hacking smart phones, targetted sophisticated malware, code base targetted tampering, human error over time. |
| 14:25:05 | sipa: | /ignore WOODMAN |
| 14:25:29 | TD: | adam3us: best "solution" such that it is, is to avoid large pileups of value in one place |
| 14:25:48 | adam3us: | TD: it doesnt seem like security has even warmed up yet. even the trezor & armory wallet are not safe from address substitution and payment protocol still leaves a gap in the merchant server |
| 14:25:49 | TD: | however, wealth inequality will not go away anytime soon. so .... not sure how far that takes you |
| 14:26:45 | adam3us: | TD: i think u could operate quite a bit of bitcoin ecosystem with airgap security protecting funds and airgap level of assurance of ownership of addresses |
| 14:26:58 | adam3us: | TD: even an exchange. |
| 14:28:31 | adam3us: | TD: (using color coin or better labelled /tagged coins on a pegged side chain and an offline issuer key issuing USD against a client funds issuer account. with a high reputation issuer) |
| 14:31:32 | adam3us: | TD: i think the airgap could save it as the exchange then has no btc funds or usdcoin funds at stake. all cash funds are held in offline airgapped wallets at all times. physical security for a merchant is like any supermarket... an armored truck deals with emptying. but even better than can sweep electronically to a vault with armed guards at company HQ. |
| 14:31:40 | TD: | * TD -> away |
| 14:35:43 | adam3us: | hmm so maybe a solution is a different property coins circulating though. optionally intentionally (time-limited) revocable coins for large tx by companies to derisk their storage from physical assault. and you can convert from revocable to irrevocable simply by waiting for the escrow smart-contract clause to expire |
| 14:37:39 | adam3us: | and similarly irrevocable become revocable by adding the escrow agent smart-contract. actually for storage the revocability needs to be permanent. the way you remove it is to spend it to an irrevocable address with the cooperation of the escrow agent. |
| 14:46:48 | Graet: | Graet is now known as Guest5939 |
| 15:40:39 | adam3us: | TD: btw something else on the topic of software security and not daring to make changes to btc anymore, it seems to me there maybe scope to simplify high value storage & tx and perhaps layer the assurance. eg full node only model requires less validation, less code, less assumptions, and high value can afford full node reliance. not sure how to layer that upwards to SPV separately, but it seems like a desirable property |
| 15:41:37 | CodeShark: | adam3us: what about high values formed by aggregating lots of small ones? |
| 15:41:39 | adam3us: | TD: also apropos of the new discovery of a 23-year old remote root in all intervening? versions of X11. how would that look for btc as a world currency. |
| 15:42:21 | adam3us: | CodeShark: doesnt change the picture, we're talking systemic risk of value bug |
| 15:47:10 | michagogo|cloud: | ;;later tell shesek Looks like the magic bytes appear 250,010 times in the first 250,000 blocks on disk (bootstrap.dat) |
| 15:47:10 | gribble: | The operation succeeded. |
| 15:54:11 | sipa: | michagogo|cloud: they could be occurring a few times just randomly as part of other data |
| 15:54:20 | sipa: | though 10 times is a lot |
| 15:54:21 | michagogo|cloud: | sipa: Yeah, I know that |
| 15:54:43 | michagogo|cloud: | (we had this discussion earlier (today or last night)) |
| 15:55:32 | jgarzik: | adam3us, RE X11... url? |
| 16:36:54 | adam3us: | jgarzik: http://lists.x.org/archives/xorg-announce/2014-January/002389.html |
| 16:38:26 | adam3us: | jgarzik: "checked in on 1991/05/10, and is thus believed to be present in every X11 release starting with X11R5 up to the current libXfont 1.4.6" |
| 16:38:47 | not-andytoshi: | not-andytoshi is now known as andytoshi_ |
| 16:39:03 | andytoshi_: | adam3us: that bug is older than i am! |
| 16:39:13 | sipa: | andytoshi_: wow :o |
| 16:39:25 | sipa: | * sipa suddenly feels old |
| 16:39:37 | andytoshi_: | well, only by 3 months :) |
| 16:39:52 | sipa: | well, I was in my first year at school in 1991... |
| 16:42:21 | adam3us: | * adam3us *is* old :) was starting CS PhD degree then |
| 16:42:49 | sipa: | haha |
| 16:42:52 | sipa: | * sipa feels young |
| 17:00:34 | WOODMAN: | sipa take it somewhere else |
| 17:00:36 | WOODMAN: | sipa now |
| 17:00:45 | WOODMAN: | take it to lethargic IRC chat |
| 17:00:47 | WOODMAN: | now |
| 17:00:54 | WOODMAN: | go |
| 17:00:57 | WOODMAN: | run |
| 17:01:13 | helo: | :/ |
| 17:07:00 | WOODMAN: | you kids are funny |
| 17:07:05 | WOODMAN: | B) |
| 17:39:46 | justanotheruser: | andytoshi_ |
| 17:40:27 | justanotheruser: | do you have logs from the 2 way pegging discussion? |
| 17:41:13 | nsh: | justanotheruser, it's still in my buffer. can pastebin it |
| 17:41:32 | nsh: | (was meaning to give it another read later anyway) |
| 17:43:42 | justanotheruser: | nsh: please do |
| 17:43:46 | nsh: | moment |
| 17:44:10 | justanotheruser: | nsh: you mean the discussing I wasn't involved in right? |
| 17:44:43 | nsh: | oh, i meant from earlier today. i missed the discussion when gmaxwell mooted it |
| 17:44:53 | andytoshi_: | justanotheruser: one sec, i'm pretty sure i do.. |
| 17:45:00 | nsh: | * nsh defers to andytoshi |
| 17:45:34 | nsh: | (here's today, in any case (unlisted on pastebin): http://pastebin.com/Aefaxfew ) |
| 17:47:30 | justanotheruser: | thanks nsh |
| 17:48:41 | nsh: | np |
| 17:54:52 | andytoshi_: | justanotheruser: sorry, i can't find it on my server's logs, will check my laptop's logs when i get home |
| 17:55:07 | andytoshi_: | there are memories in my brain of it, so i'm pretty sure i was present |
| 17:55:18 | justanotheruser: | andytoshi_: ok please PM me them, thank |
| 17:55:20 | justanotheruser: | s |
| 18:53:26 | gmaxwell: | andytoshi_: I made a kind of boring comment about the vntinyram paper: https://groups.google.com/forum/#!topic/scipr-discuss/1psbALDMkAI (mostly I just wanted an excuse to post to the list and see if anyone was reading it, since there were no posts ever) |
| 19:46:01 | nsh: | gmaxwell, is that what you were referring to in this: "but the really small ones have some uncomfortable security tradeoffs (CRS assumption) the ROM ones are somewhat larger (eg 20kb, though I did invent a novel compression scheme which may help, so they may not be good for compressing header proofs" from earlier? |
| 19:49:26 | gmaxwell: | nsh: no. |
| 19:49:32 | nsh: | k |
| 20:08:45 | jgarzik: | adam3us, sounds like the root hole is in BDF font installation |
| 20:09:01 | jgarzik: | adam3us, thankfully, not really an actively used or triggered area |
| 20:10:01 | adam3us: | jgarzik: yes. i was well is the coe in the bdf or the code is in a malicious font no? the latter is bad as someone can send u a font file. did u know fedora 18 dvd wont install without network and downloads amongst other things fonts? (they are crazy) |
| 20:10:45 | adam3us: | jgarzik: or is bdf font an optional font system? so no risk if u havent installed that component? |
| 20:11:02 | jgarzik: | adam3us, well, (1) F18 installs fine without network and (2) any download exists inside a GPG-signed universe |
| 20:12:36 | adam3us: | jgarzik: hmm it depends which image u download, i tried 3 of them until i found one that installs without network cable. their new installer is a bit of a mess, but i was pretty determined to get an all offline install and trid 7 isos from ubunu an fedora over pretty much 2 ays |
| 20:12:43 | spinza_: | spinza_ is now known as spinza |
| 20:13:41 | jgarzik: | adam3us, at which step did you get stuck? I might have had to do some magic to get my F18 going in its network-free VM |
| 20:14:02 | jgarzik: | adam3us, I keep several network-free VMs as virtual condoms for various things |
| 20:16:32 | adam3us: | jgarzik: about the gpg-sig. the problem is 2-fold: one the WoT is sparse, secondly it doesnt define a merkle tree, so the content can be tailored to u and there is no rpm sig equivalent of certificate transparency |
| 20:18:19 | adam3us: | jgarzik: i finally gave up as i recall an used ethernet briefly i was very annoyed by that point, 2 days burnt on fedora & ubuntu i was astounded that it would fail for network on a DVD iso. 4GB and they want to fetch a font on the network or the install aborts. actually it was probably fc 19. i even tried ubuntu server install. |
| 20:18:34 | jgarzik: | adam3us, well each package comes from signed metadata package repo summary |
| 20:18:44 | jgarzik: | adam3us, I agree this does not solve 'tailored to u' problem |
| 20:18:50 | adam3us: | jgarzik: yes my point is say NSA has a copy ... ok right u get it |
| 20:19:29 | adam3us: | jgarzik: there is a solution.. merkle tree of snapshot of packages at iso release time, then your entire install is hardwired to the merkle root. |
| 20:19:56 | jgarzik: | adam3us, nobody wants packages of an era circa iso release time ;p |
| 20:20:35 | jgarzik: | adam3us, familiar problem as with routers: the moment you open the box and turn on the computer, it is out of date and missing security and other critical bug fixes |
| 20:21:54 | adam3us: | jgarzik: actually i would happily take an out of the box for this app, which is admittedly completely atypical (i was testing armory prebuilt stuff and source stuff.) that the DVD wouldnt install therefore was just the opposite. |
| 20:24:42 | helo: | hmmm... ubuntu without network has worked fine for me (via iso-on-usb) |
| 20:27:15 | adam3us: | jgarzik: also i guess we're going to need sooner or later the SSL / cert transparency, for rpm signatures, or something. its pretty much spelled out in like schneier and applebaum research in teh docs and articles from that that NSA has well placed TCP hi-jack infrastructure with selective payload delivery. u could imagine they might hve hacked some important signing keys via physical intrusion, black bag, NSL etc. |
| 20:29:25 | adam3us: | helo: i am not in a hurry to repeat that experiment it was the least fun i've had with a computer in quite a while. this was ubuntu 10 and ubuntu 12 (whatever armory claimed to be prebuilt for, or latest stable for source) and fedora 18. tried lots of isos. i dont think i was dreaming. been using linux since slackware 0.9 so i am not unusually fat fingered about linux installs |
| 20:30:06 | helo: | yeah, sounds pretty terrible |
| 20:31:03 | gmaxwell: | the fedora stuff kinda shuffles users torwards the crappy live image based installers, which I think do have to be online. |
| 20:31:11 | _ingsoc: | _ingsoc has left #bitcoin-wizards |
| 20:50:06 | michagogo|cloud: | adam3us: 10 and 12? |
| 20:50:09 | michagogo|cloud: | Which ones? |
| 20:50:29 | michagogo|cloud: | (.04 or .10?) |
| 20:51:22 | adam3us: | michagogo|cloud: it was a month ago, i tried 10, 12 as main advertised iso on ubuntu.co and i think 10 server at suggestion of a hacker friend of mine that server maybe less chatty |
| 20:51:29 | adam3us: | .04 |
| 21:50:39 | andytoshi-away: | gmaxwell: cool, glad to see (a) that the list is active and (b) we're not crazy to think we can be throwing hash circuits everywhere |
| 21:50:41 | andytoshi-away: | andytoshi-away is now known as andytoshi |
| 21:51:10 | andytoshi: | i have another concern, which i haven't mentioned since i haven't read the whole paper, about verifying input.. |
| 21:51:35 | andytoshi: | presumably to make a snark-based blockchain we would want VERIFY (old chain state, new chain state, transactions) |
| 21:51:43 | gmaxwell: | someone needs to find a bored grad student to go generate circuits for sha256 and all the sha3 finalists and see which results in the fastest proofs. |
| 21:51:58 | andytoshi: | and we'd want the old and new chainstate to be public, but the transactions to be zero knowledge |
| 21:52:18 | andytoshi: | the impression i get from the paper is that if we want inputs to be public and provably there, we'd need them to appear in the preprocessing stage |
| 21:52:21 | andytoshi: | is this right? |
| 21:54:15 | gmaxwell: | andytoshi: no, the preprocessing stage just takes in the description of vntinyram itself, the time limit bound, and the _number_ of public inputs. |
| 21:54:41 | andytoshi: | are the public inputs what they call 'auxilliary inputs'? |
| 21:55:10 | gmaxwell: | no, public inputs are "program inputs", while "auxilliary inputs" are the ZK inputs. |
| 21:55:42 | andytoshi: | ok, thanks, great |
| 21:55:48 | gmaxwell: | (also non-determinsim used to simplify the tinyram circuit, e.g. like magical answers that tinyram divide by only having a circuit to check the answer) |
| 21:56:00 | andytoshi: | yeah, i noticed that, that was really clever |
| 21:57:49 | gmaxwell: | andytoshi: also, in your description above there is an extra thing that needs to be provided.. full nodes would also demand a set of updates to change from the old state to the new state. |
| 21:58:15 | andytoshi: | the proof would not be enough for them? |
| 21:58:17 | gmaxwell: | E.g. the transactions are ZK but you do actually need to know the final state (not intermediate states) in order to make the next proof yourself. |
| 21:58:40 | andytoshi: | right, that's what i mean by 'new chain state', they can just use that as 'old chain state' in their next proof |
| 21:58:59 | gmaxwell: | oh okay, I read what you were saying as a commitment to the state. |
| 22:00:33 | gmaxwell: | A non-miner in that model doesn't actually need to pay attention to the state much of the time... so commitments are good enough.. then they could just get fragments of the state from filtering nodes to prove they were paid. |
| 22:01:28 | andytoshi: | right |
| 22:02:32 | andytoshi: | and full/filtering nodes would have to figure out some way to efficiently store the series of chainstates |
| 22:03:10 | andytoshi: | perhaps snark-proving chainstate diffs would be more efficient, i dunno, these are just details at this point :) |
| 22:03:11 | gmaxwell: | its useful to commit to the diff as well, since then you can get it from someplace else. |
| 22:03:52 | andytoshi: | oh, good point, doing both gives the best of both worlds |
| 22:05:50 | andytoshi: | full nodes would use the diffs, non-full user nodes would use the full state to verify what the full nodes are telling them |
| 22:08:54 | gmaxwell: | if you want to be really snazzy, you have a hiearachy of backpointers to old blocks, and at each backpointer level you keep a state snapshot and periodically commit big gap proofs. |
| 22:09:25 | gmaxwell: | then hotstarting a full node just involves evaluating log2(blocks)+ε proofs, and pulling down a full state. |
| 22:09:42 | gmaxwell: | but since the proofs are so fast, I goes O(N) proofs isn't so bad. |
| 22:10:05 | andytoshi: | we'll see what hardware looks like wherever this becomes feasible :P |
| 22:10:30 | andytoshi: | though my money's on "before 2020", and then things will look pretty-much the same |
| 22:14:35 | andytoshi: | justanotheruser: the 1-1 peg discussion starts (i think) at http://download.wpsoftware.net/bitcoin/wizards/2013-12-18.txt |
| 22:14:56 | andytoshi: | (for some reason my logs from 12-17 to 12-27 were not on the website, that's why i couldn't find them earlier) |
| 22:16:38 | michagogo|cloud: | 2014-01-08 22:11:18 REORGANIZE: Disconnect 7880 blocks; 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f.. |
| 22:16:39 | michagogo|cloud: | * michagogo|cloud 2014-01-08 22:11:18 REORGANIZE: Connect 31489 blocks; ..00000000ce13e2d877387db6a418974481fdcd946bcc72c3a52f1ed7ad34f2a5 |
| 22:17:03 | gmaxwell: | michagogo|cloud: is that testnet? |
| 22:17:12 | michagogo|cloud: | It's Jesuscoin |
| 22:17:17 | andytoshi: | phew |
| 22:17:20 | gmaxwell: | ... Jesus coin?! |
| 22:17:31 | gmaxwell: | (I did a reorg on testnet that big) |
| 22:17:57 | michagogo|cloud: | gmaxwell: coingen |
| 22:18:11 | michagogo|cloud: | second coin on http://coingen.io/status.html |
| 22:18:19 | gmaxwell: | ohhh you blew up a coingen coin?! |
| 22:18:30 | gmaxwell: | hah |
| 22:18:34 | michagogo|cloud: | Well, my script is breaking |
| 22:18:55 | michagogo|cloud: | since the reorg lags jesuscoin-qt |
| 22:19:17 | gmaxwell: | hah |
| 22:19:29 | gmaxwell: | * gmaxwell titters at "jesuscoin-qt" |
| 22:19:43 | gmaxwell: | does it have an icon where a coin outline forms a halo around jesus? |
| 22:21:47 | helo: | it proclaims to _be_ the second coming |
| 22:21:55 | michagogo|cloud: | gmaxwell: http://imgur.com/Wldyc7t |
| 22:22:26 | gmaxwell: | aww |
| 22:23:35 | michagogo|cloud: | Okay, added begin,rescue,retry,end lines |
| 22:23:40 | phantomcircuit: | opportunity missed |
| 22:23:44 | michagogo|cloud: | that should make it stop crashing |
| 22:24:41 | michagogo|cloud: | If you're interested, here's my script: http://0bin.net/paste/OFWqJ7Lj0k0GO0o4#Rd6uP8VFxwv3SEO4HQAwtF+Vy5M3ZtaUrrKC9m3qI+w= |
| 22:25:31 | michagogo|cloud: | Anyone happen to know when Bitcoin's first difficulty increase was? |
| 22:25:46 | gmaxwell: | block 80k? |
| 22:26:00 | michagogo|cloud: | thanks |
| 22:26:42 | michagogo|cloud: | Heh, looks like the real chain is fighting with my replay of the bitcoin chain |
| 22:27:03 | michagogo|cloud: | Reorging back and forth |
| 22:27:39 | andytoshi: | ah, this is from before BlueMatt fixed the 'same genesis' 'bug' |
| 22:27:59 | shesek: | oh, it was fixed eventually? when? |
| 22:28:06 | shesek: | we were talking about it just yesterday |
| 22:28:24 | gmaxwell: | michagogo|cloud: oh I'm wrong about the height |
| 22:28:28 | BlueMatt: | no, it was fixed a long time ago |
| 22:28:40 | gmaxwell: | michagogo|cloud: 32256 |
| 22:28:57 | michagogo|cloud: | Hmm, what did it rise to? |
| 22:29:04 | gmaxwell: | 1.18289953 |
| 22:29:06 | shesek: | oh, I was under the impression it was still like that yesterday... someone said it was |
| 22:30:12 | michagogo|cloud: | If anyone feels like watching jesuscoin get killed, https://secure.join.me/671-648-265 |
| 22:30:34 | michagogo|cloud: | (tailf of jesuscoin's debug.log) |
| 22:32:31 | michagogo|cloud: | Hey, I think I might have just pulled ahead |
| 22:33:29 | michagogo|cloud: | BlueMatt: How many coingen coins used Bitcoin's genesis block? |
| 22:33:41 | gmaxwell: | michagogo|cloud: too bad there aren't any huge tx fees until fairly late. |
| 22:34:01 | michagogo|cloud: | gmaxwell: Why? |
| 22:34:22 | gmaxwell: | otherwise I'd say it would be fun top play it up to right before the point where there was a block with huge tx fees. Then mine that txn yourself. |
| 22:34:30 | BlueMatt: | michagogo|cloud: no idea |
| 22:34:33 | gmaxwell: | Then continue on.. and you get the huge tx fees. |
| 22:34:36 | michagogo|cloud: | gmaxwell: heh |
| 22:37:45 | helo: | where's the boom? |
| 22:37:56 | michagogo|cloud: | helo: https://secure.join.me/671-648-265 |
| 22:39:04 | michagogo|cloud: | shh, nobody tell Luke-Jr that I killed Jesus(coin) |
| 22:39:14 | helo: | interesting date |
| 22:39:46 | michagogo|cloud: | helo: hmm? |
| 22:40:32 | helo: | jesuscoin has blocks as far back as 2010? |
| 22:40:42 | michagogo|cloud: | helo: It's the Bitcoin blockchain |
| 22:41:33 | michagogo|cloud: | I'm just using http://0bin.net/paste/OFWqJ7Lj0k0GO0o4#Rd6uP8VFxwv3SEO4HQAwtF+Vy5M3ZtaUrrKC9m3qI+w= to replay the bitcoin blockchain onto Jesuscoin |
| 22:42:20 | helo: | wouldn't the hard coded genesis block make that not work? |
| 22:42:38 | shesek: | they share the same genesis block |
| 22:42:54 | helo: | bad move :/ |
| 22:42:56 | shesek: | coingen used to give the altcoins it created the same genesis block as bitcoin's |
| 23:20:51 | gmaxwell: | andytoshi: the proving process for QAP snarks is ludicrously parallel, I wonder if it would make sense to have distributed generation of the proofs? ... I think the problem is that they need communcation similar to the prover key in size. |
| 23:23:30 | maaku: | adam3us: I've done multiple ubuntu installs without network connection ... i know it works for 12.04 |
| 23:26:23 | andytoshi: | gmaxwell: hmm, a high communication requirement is going to incentivize centralization |
| 23:26:38 | andytoshi: | and in general, if you break the proof up it is hard to decide what part any individual miner should work on |
| 23:27:01 | andytoshi: | which i think also encourages centralization since it is easy to organize a single mining farm to not step on its own toes |
| 23:30:00 | andytoshi: | i think "ludicrously parallel" will just mean that we don't have a gpu-hard mining algorithm here |
| 23:30:49 | maaku: | * maaku downloads jesuscoin-qt and goes to make some popcorn |
| 23:32:34 | michagogo|cloud: | maaku: not much to see |
| 23:32:52 | sipa: | i expect jesuscoin to be able to fork, and keep both instances alive... |
| 23:32:53 | michagogo|cloud: | It'll just look like Bitcoin-Qt syncing |
| 23:32:56 | maaku: | is it off of git-head, or 0.8? |
| 23:33:02 | michagogo|cloud: | 0.8.6 |
| 23:33:04 | sipa: | 0.8.6 iirc |
| 23:33:08 | maaku: | oh :\ |
| 23:33:18 | michagogo|cloud: | Why? |
| 23:33:33 | michagogo|cloud: | Which git feature were you hoping to use? |
| 23:33:38 | maaku: | i was hoping for some fine grained timestamps on the log messages to get a good idea of how the reorg was spreading through the network |
| 23:33:59 | maaku: | vs. the "honest" miners |
| 23:34:01 | michagogo|cloud: | maaku: you can roll your own |
| 23:34:24 | michagogo|cloud: | Just built git head and change the pchMessageStart |
| 23:34:27 | maaku: | yeah true. i suppose I just need the port & msg bytes |
| 23:34:36 | michagogo|cloud: | port 9336 |
| 23:34:55 | michagogo|cloud: | Don't know the magic, though |
| 23:34:57 | michagogo|cloud: | Sorry |
| 23:35:08 | maaku: | np. thanks |
| 23:35:19 | maaku: | i'll read the first 4 bytes of blk*.dat |
| 23:35:38 | michagogo|cloud: | (Not at my computer anymore, I'm writing this from my bedroom) |
| 23:37:28 | shesek: | so I guess Satoshi is now heavily invested in Jesuscoin? :) |
| 23:37:33 | shesek: | he should own a pretty large chunk of it |
| 23:39:34 | shesek: | given his large ownership in the early bitcoin blocks |
| 23:39:58 | sipa: | ...? |
| 23:40:08 | maaku: | shesek: yes, but unfortunately he Ascended into heaven in 2010 without leaving any of his public keys to his disciples :\ |
| 23:40:13 | maaku: | /public/private/ |
| 23:40:55 | sipa: | someone should create a Nakamotocoin - dedicated to The Ascended One |
| 23:41:01 | sipa: | by mocking his Creation |