| 00:04:28 | maaku: | andytoshi: I need to get a wizards-level summary written, but one of the cool things you can do with proof-of-stake is vote on how the subsidy is distributed, a system I've been calling 'republicoin' |
| 00:05:07 | maaku: | with the right structure it ends up looking somewhat like a parlimentarian democracy, albeit with 1 bitcoin = 1 vote (not unlike lobbying I guess :P) |
| 00:05:30 | maaku: | it's just there's some major outstanding problems, not least of which is the ability for miner collusion to censor votes |
| 00:07:09 | Luke-Jr: | maaku: so, I can move bitcoins from Mainnet to Freimarkets to Inflationchain back to Mainnet? |
| 00:07:47 | maaku: | Luke-Jr: you have to retreat along a line of credit |
| 00:07:52 | Luke-Jr: | :/ |
| 00:08:11 | maaku: | maybe someone else had already moved coins from mainnet to inflationchain, in which case yes you could |
| 00:08:25 | Luke-Jr: | maaku: my thought was to have multiple "day to day" side chains, and people use one of their choice, and encode the side chain id into the address |
| 00:08:35 | Luke-Jr: | so if I pay 1someone, it knows which side chain to send to |
| 00:10:16 | maaku: | well pegging is not something you'd want to use in day-to-day transactions (way too much overhead), but in principle it would work |
| 00:11:14 | Luke-Jr: | even with zk-SNARK proofs? |
| 00:11:48 | maaku: | the overhead comes from quieting periods and such |
| 00:12:03 | maaku: | er, yeah also space overhead which zk-SNARK would help with |
| 00:12:19 | maaku: | but I was thinking about just how long it would take (2-3 days) |
| 00:12:44 | Luke-Jr: | maaku: depends on how it's setup, I guess |
| 00:12:49 | maaku: | in the fully-symmetric case, you should think of having bitcoins on the side chain, you have "coins from mainnet" and "coins of type X from othernet" |
| 00:13:00 | Luke-Jr: | if you can avoid the quieting period (special merged-mining setup), it could work |
| 00:13:00 | maaku: | *should not think |
| 00:13:25 | maaku: | maybe the coins of type X on othernet are actually "coins from mainnet" |
| 00:13:35 | maaku: | but from the side-chain's perspective they'd be different assets :\ |
| 00:14:30 | maaku: | so if I took coins from chian A to chain B, then from there to chain C, and then moved them directly back to A, ... |
| 00:14:37 | maaku: | ...they'd look on A like "coins from C" |
| 00:14:48 | maaku: | not native host currency |
| 00:14:59 | maaku: | you'd have to fully unwind the peg to get native host currency |
| 00:15:04 | maaku: | kinda messy :\ |
| 00:15:47 | maaku: | although someone observing all the chains (or given the necessary proofs) would know they are equivalent to host currency and perhaps treat them as such |
| 00:15:49 | justanot1eruser: | andytoshi: Doesn't really go in depth. Do people just find blocks where their public key is close to winning and form a block that allows them to keep winning? |
| 00:16:29 | maaku: | justanot1eruser: which pubkey/txout gets to choose the next block depends on the last block, which includes your signature |
| 00:16:35 | andytoshi: | justanot1eruser: it doesn't go into depth because the details of "PoS consensus" schemes vary |
| 00:16:39 | maaku: | so grind signatures until you find one that let's you choose the next block |
| 00:16:41 | maaku: | and repeat |
| 00:16:58 | justanot1eruser: | maaku: well grinding signatures also involves having coins associated with that sig |
| 00:17:36 | maaku: | justanot1eruser: you wait until you get randomly selected to chose the next block. then you grind each signature so you never give up that privledge |
| 00:17:39 | justanot1eruser: | So what, you just send to sig X in block Y and keep changing sig X until you win block Y+100? |
| 00:17:47 | justanot1eruser: | oh okay |
| 00:17:52 | gmaxwell: | justanot1eruser: not necessarily. |
| 00:19:02 | justanot1eruser: | andytoshi: is that page static? |
| 00:19:22 | BCB: | is Andreas M. Antonopoulos a core dev? |
| 00:19:23 | andytoshi: | justanot1eruser: the pdf? yeah, i've just updated it a dozen times today :P |
| 00:19:28 | andytoshi: | BCB: definitely not |
| 00:19:39 | BCB: | Why is he writing "Mastering Bitcoin" for 0'Reily |
| 00:19:42 | justanot1eruser: | andytoshi: can I cite it in ,,(bc,wiki proof of stake)? |
| 00:19:53 | andytoshi: | justanot1eruser: yup, the URL won't ever change |
| 00:20:00 | gmaxwell: | BCB: I don't believe he's developed any Bitcoin software that I'm aware of. |
| 00:20:01 | maaku: | BCB: don't have to be a core dev to write a book |
| 00:20:20 | BCB: | so it's not a technical book? |
| 00:20:33 | maaku: | BCB: i don't think anyone here has read it |
| 00:20:45 | maaku: | but the Mastering series is usually technical |
| 00:20:51 | BCB: | maaku: I don't think its out yet. Just the cover art |
| 00:21:04 | BCB: | just curious. I've never seen him here or the dev channel |
| 00:21:09 | maaku: | BCB: that's rather my point. we have as much to go on as you |
| 00:21:35 | BCB: | gmaxwell: but he has started 3 bitcoin businesses |
| 00:21:45 | Luke-Jr: | BCB: but he's never been involved in development afaik |
| 00:22:12 | gmaxwell: | Does trying to drive me out and demanding that I be "fired" count as involved in development? :P |
| 00:22:23 | BCB: | Luke-Jr: I guess you don't need to be involved in developement to master bitcoin |
| 00:22:35 | BCB: | I thought Peter Todd was the bitcoin master |
| 00:22:46 | BCB: | or Master of bitcoin |
| 00:23:04 | Luke-Jr: | gmaxwell: no? :P |
| 00:23:20 | antephialtic: | BCB: can you take this back to #bitcoin |
| 00:23:25 | Luke-Jr: | gmaxwell: maybe claiming malleability is a DDoS attack is. :P |
| 00:23:31 | BCB: | antephialtic: ok |
| 00:24:39 | jcorgan: | does AA have any commits at all in the repo? |
| 00:24:57 | Luke-Jr: | jcorgan: I don't then he's even written a suggestion for it |
| 00:25:21 | sipa: | AA? |
| 00:25:30 | jcorgan: | just remembering something he said in passing, before I learned of the history |
| 00:25:38 | jcorgan: | Andreas Antonopoulos |
| 00:26:11 | jcorgan: | "all you need to be called a core-dev is to have written some code that gets into the repository" or something like that |
| 00:26:19 | gmaxwell: | Preety sure no. (As I said, I don't think I've seen any bitcoin software development at all) |
| 00:26:35 | sipa: | same |
| 00:26:45 | jcorgan: | sorry, back to #bitcoin |
| 00:26:46 | sipa: | i hadn't heard that name until recently |
| 00:26:49 | sipa: | yeah |
| 00:27:36 | kanzure: | gmaxwell: i dunno if you're interested in this, but in asic-faq.pdf it may be helpful to jot down a vague proof about why centralized schemes shouldn't bother with proof-of-work. you mention it's trillions of times more inefficient, which i agree with, but i have trouble explaining to others why it's such a stupid idea. |
| 00:28:36 | sipa: | ah, the good old bitcoin-is-a-hammer-and-everything-looks-like-nails syndrome |
| 00:28:49 | gmaxwell: | yea. hm! point. |
| 00:28:49 | kanzure: | "well clearly the network participants would find value in a proof-of-work blockchain, so therefore it's ..." |
| 00:29:17 | kanzure: | one way i tried is using the "well, mining power can show up and screw up your blockchain, so you should just stick with your conventional database yo" |
| 00:29:41 | gmaxwell: | maybe the way to put that is that PoW replaces the need to have a centeralized system at the expense of costs and weaker security promises against third party attackers? |
| 00:30:04 | sipa: | well centralized blockchaims are meaningful, just don't have the PoW |
| 00:30:21 | kanzure: | what is the meaning of a "centralized blockchain" anyway :) |
| 00:30:26 | sipa: | the only reason PoW is necessarycin public chaimsmis to rate limit the production of blocks |
| 00:30:27 | kanzure: | is that just a table in a database with transactions? |
| 00:30:34 | gmaxwell: | Basically with PoW we replace risks that come from having to trust an enumerated party or set of parties, with the risks of dealing with a vaguely defined computational majority. |
| 00:30:48 | sipa: | kanzure: no, it's a chain of blocks, but prodiced by a single party |
| 00:31:02 | sipa: | *produced |
| 00:31:20 | sipa: | instead of PoW, they sign the blocks |
| 00:31:27 | maaku: | kanzure: a block chain is a data structure. you can think of it as the audit log of a transaction server, like open-transactions |
| 00:31:51 | kanzure: | gmaxwell: on a similar note, i've also encountered someone who was advocating for using a "private blockchain" where the miners are just himself.. sometimes it escapes me how to respond in a meaningful way to that perspective (i have a meaningful response to *me* but not to their perspective) |
| 00:32:12 | maaku: | kanzure: there are perfectly good reasons to do just that |
| 00:32:15 | kanzure: | maaku: when i hear blockchain i think specifically "a chain of blocks based on mining each block with some coinbase tx header" |
| 00:32:35 | kanzure: | maaku: it's possible that my definition is wrong. |
| 00:32:42 | sipa: | on this channel, that is an unnecessarily specific definition :) |
| 00:32:47 | kanzure: | sipa: okay, yeah, just sign the blocks- sure that's a much better strategy |
| 00:33:26 | maaku: | kanzure: I would leave it at just "a chain of blocks, each a list of transactions" |
| 00:33:53 | kanzure: | hm, okay. and these blocks still get propagated through some p2p network? |
| 00:34:12 | maaku: | kanzure: maybe. not relevant |
| 00:35:12 | andytoshi: | kanzure: good call on "centralized blockchains are pointless", people often come up with weird ideas and keep at them after we've shown they reduce to pure centralization |
| 00:35:15 | gmaxwell: | kanzure: well public auditing can be useful, but no need for POW there. |
| 00:35:25 | andytoshi: | centralized POW blockchains i mean |
| 00:35:36 | maaku: | the block chain is really just an audit log for a transactional server that is maintaining an audit log |
| 00:35:43 | maaku: | andytoshi: they don't reduce to pure centralization |
| 00:35:44 | gmaxwell: | e.g. you could take bitcoin replace POW with a signature, and use that to have some kind of public transactional database to facilitate auditing. |
| 00:35:48 | maaku: | open-transactions is a case in point |
| 00:35:49 | sipa: | with each block having a hash, derived from their transctions, and their parent block's hash |
| 00:35:54 | phantomcircuit: | BCB, there is no commit in master with "anton" in it |
| 00:36:02 | maaku: | the purely centralized server has no control over user balances |
| 00:36:02 | kanzure: | last i heard is that opentransactions hasn't implemented/defined their audit protocol yet (for server-to-server auditing or w/e) |
| 00:36:11 | BCB: | phantomcircuit: we are in #bitcoin |
| 00:36:13 | kanzure: | (i mean, you could audit the receipts you get, but that's not the whole story) |
| 00:37:07 | maaku: | kanzure: OT has been working fine for years.. |
| 00:37:14 | kanzure: | i'm not claiming otherwise? |
| 00:37:21 | maaku: | ok i'm not sure what you're claiming |
| 00:37:33 | kanzure: | yamamashi was recruiting me to work on some zeromq auditing protocol for OT |
| 00:37:40 | kanzure: | because it didn't exist yet |
| 00:37:49 | kanzure: | that is roughly my claim heh |
| 00:38:29 | kanzure: | i'm aware that i can audit the receipts that i personally receive from conducting my transactions on an OT server, but that's not the full set of receipts, and they were thinking of some standard way to expose that |
| 00:38:44 | maaku: | yeah they haven't been working on external auditing, although if the server kept logs you could consider that a block chain and replaying those messages would result in the current server state |
| 00:39:24 | maaku: | in principle it's easy to do the same to bitcoin - replace POW with DSA, and stream the chain to auditors as it is made |
| 00:39:52 | maaku: | you get similar properties: users have full control over their accounts, with the worst the server being able to do is censor transactions |
| 00:39:59 | maaku: | and everything is auditable |
| 00:40:01 | kanzure: | i think you end up with weird ddos issues though |
| 00:40:21 | sipa: | ddos.. who is the victim? |
| 00:40:31 | kanzure: | centralized party? |
| 00:40:41 | sipa: | they just need to publish |
| 00:41:42 | sipa: | which may not be trivial |
| 00:41:49 | kanzure: | i'm assuming maaku's scenario literally (bitcoin client) |
| 00:41:53 | kanzure: | (bitcoind) |
| 00:42:02 | sipa: | but it's certainly many times easier a problem than ddos protecting bitcoin |
| 00:49:02 | kanzure: | andytoshi: typo, "In order than all actors can reach consensus," under 3 |
| 00:50:29 | petertodd: | phantomcircuit: "it would be nice if that couldn't be reorganized without the bitcoin block also being reorganized" <- that's exactly what I'm proposing in tree-chains |
| 00:50:52 | andytoshi: | thx kanzure, fixed on my end, will appear in next push |
| 00:52:11 | maaku: | sometimes trivially easier - just have a dark fiber connection to the auditors |
| 00:53:30 | phantomcircuit: | petertodd, written up somewhere? |
| 00:54:02 | maaku: | sipa: (you're not in #bitcoin-dev) is there a reason CCoins remembers nVersion? |
| 00:57:18 | andytoshi: | phantomcircuit: there was a recent writeup about treechains, the conversation got badly sidetracked after the first few posts tho http://sourceforge.net/p/bitcoin/mailman/message/32142133/ |
| 00:58:08 | petertodd: | phantomcircuit: https://s3.amazonaws.com/peter.todd/tree-chains-preliminary.pdf |
| 00:58:09 | phantomcircuit: | oh |
| 00:58:49 | petertodd: | andytoshi: it's not honest to talk about asic mfg centralization without also mentioning how highly centralized chip fab facilities are |
| 00:58:51 | phantomcircuit: | i was just proposing that namecoind keeps the bitcoin block headers since by definition all bitcoin blocks in which namecoin was merged will be valid namecoin blocks |
| 00:58:57 | andytoshi: | petertodd: i did |
| 00:59:00 | andytoshi: | oh |
| 00:59:08 | phantomcircuit: | (difficulty of namecoin network should never exceed bitcoin difficulty) |
| 00:59:38 | andytoshi: | petertodd: sure, i'll add a blurb about that |
| 00:59:38 | maaku: | phantomcircuit: strictly speaking there is a loss of generality there. the namecoin headers are not necessarily bitcoin headers |
| 00:59:41 | phantomcircuit: | that way you can fairly safely have a merged coin that only some relatively small % of the bitcoin miners are merging |
| 00:59:55 | phantomcircuit: | maaku, shrug |
| 01:00:15 | maaku: | phantomcircuit: agreed, just be clear you're introducing a new validator rule |
| 01:00:22 | phantomcircuit: | oh for sure |
| 01:00:32 | antephialtic: | are all the asics pretty much manufactured by TSMC? |
| 01:00:37 | antephialtic: | seems pretty centralized to me |
| 01:00:52 | phantomcircuit: | antephialtic, yes and no |
| 01:01:02 | maaku: | it also lets you do interesting things like shut down features of the side-chain when difficulty drops <50% bitcoin's |
| 01:01:04 | phantomcircuit: | i believe everybody is using tsmc simply because they're cheaper |
| 01:01:15 | andytoshi: | can someone say something specific (and true) about chip centralization? |
| 01:01:33 | petertodd: | antephialtic: yup - the nature of IC mfg seems to be that the # of top-tier fabs is converging towards 1 because every generation requires a more expensive fab plant - at some point the entire worlds economy simply can-not support diversity there |
| 01:02:12 | phantomcircuit: | petertodd, except producing chips on the N-1 generation seems to be a better move economically |
| 01:02:23 | phantomcircuit: | and im sure the world can support a number of N-1 fabs |
| 01:02:31 | petertodd: | andytoshi: basically what's important to be clear about is that the many bitcon mining companies are only designers of asics, the actual asics are built by a tiny number of mfgs |
| 01:02:47 | phantomcircuit: | (actually more of the network is N-2/N-3 at the moment) |
| 01:03:01 | antephialtic: | petertodd: would a viable open source design help? then anyone with capital could get a batch fabbed themselves |
| 01:03:19 | andytoshi: | antephialtic: the problem is they'll all go to the same (only) fabber |
| 01:03:21 | petertodd: | phantomcircuit: doesn't matter, the n-1 generation keeps advancing too, and you end up with the same result. e.g. ten years ago the n-1 generation involved far more mfgs than the n-1 generation now, and the n-1 generation now is way more power efficient than 10 years ago |
| 01:03:52 | kanzure: | andytoshi: there's some curious channels on freenode where people do homebrew chip fab.. uh, whatever channel azonenberg is hanging out in. |
| 01:04:00 | petertodd: | antephialtic: no, the actual design of the hardware with SHA256 isn't expensive to do; you'd still be stuck with the fact that only a half dozen at most companies can build the chips |
| 01:04:19 | petertodd: | kanzure: yes, homebrew at a tech level equivalent to about 50 years ago |
| 01:04:24 | kanzure: | yes |
| 01:04:25 | andytoshi: | kanzure: homebrew chip fab? o.O certainly you can do homebrew pcb layout (and there are a million pcb fabs everywhere) |
| 01:04:31 | kanzure: | yes, but not just pcb |
| 01:04:48 | petertodd: | andytoshi: yeah, pcb mfg is highly decentralized, even if you're talking about the really high-end stuff |
| 01:04:49 | kanzure: | ah, #homecmos |
| 01:04:52 | andytoshi: | probably half this channel used to mfg pcbs at home. i hadn't heard of chip fab |
| 01:05:04 | kanzure: | i pretended to make pcbs, does that count :| |
| 01:05:16 | kanzure: | http://code.google.com/p/homecmos/ |
| 01:05:37 | antephialtic: | petertodd: seems fairly insurmountable for all hash-based PoW then. just a general consequence of economies of scale. centralization is more efficient |
| 01:05:43 | petertodd: | andytoshi: lol, I didn't because contracting it out became so cheap even a decade ago that a poor art student like myself at the time was better off letting someone else do it |
| 01:06:00 | andytoshi: | petertodd: i was friends with EE nerds :) |
| 01:06:31 | andytoshi: | antephialtic: perhaps insurmountable. petertodd's point is simply that i have to mention it for intellectual honesty's sake, i certainly have no intention of doing anything about it |
| 01:06:32 | gmaxwell: | yea, I've made PCBs at home.. those awful radioshack pcb etching kits... |
| 01:07:09 | petertodd: | antephialtic: yes, but remember that's only centralization of the manufacturing of ASICs, actually running them has physics reasons to stay decentralized. Still an existential threat to Bitcoin though, as politically banning/regulating PoW ASIC mfg is easy compared to forcing DRM on everyone, and we've had to fight like hell to keep the latter from happening. |
| 01:07:43 | gmaxwell: | petertodd: you see my pro-social drm discussion from last night? |
| 01:07:52 | kanzure: | there might be trust issues with centralized asic fab |
| 01:07:52 | petertodd: | gmaxwell: don't think so? |
| 01:08:08 | kanzure: | e.g., how do you know that all of the chips are correctly masked |
| 01:08:09 | phantomcircuit: | petertodd, yeah i guess that's true |
| 01:08:16 | kanzure: | or there's no backdoors in the weirdass dopants |
| 01:08:47 | gmaxwell: | petertodd: to make cloud hashing less of an existential risk: make mining chips that know their owners public key... so they only mine like their owner wants them to even if they're housed by a third party. |
| 01:08:50 | petertodd: | kanzure: that's putting it mildly :) basically government would likely just require you to have a license to buy a PoW ASIC, and the conditions of the license include things like only using them to mine transactions following KYC rules |
| 01:08:54 | antephialtic: | petertodd: this is a well-worn path of argument, but I don't see how ASIC/FPGA resistant hashing (assuming such a thing exists) solves the problem of centralization. If mining is profitable with CPUs, miners will get huge datacenters full of servers (or botnets). As long as bitcoin mining is profitable, capital will flow to parties that try to capture a significant percentage of the profits |
| 01:09:07 | gmaxwell: | The nice thing about it is that the security doesn't have to be very strong, it's not like decapping the chips to bypass the protection would be cheaper than just replacing them. |
| 01:09:11 | petertodd: | gmaxwell: right, I saw that - equally the same tech can be used by governments to regulate mining |
| 01:09:26 | gmaxwell: | petertodd: it can, but we couldn't stop that so better to use it for positive uses. |
| 01:09:26 | kanzure: | stealthy dopant-level hardware trojans https://people.umass.edu/gbecker/BeckerChes13.pdf |
| 01:09:44 | gmaxwell: | kanzure: not sure how thats really relevant to mining however. :) |
| 01:10:02 | phantomcircuit: | gmaxwell, nobody doing cloud hashing wants 1:1 with actual hw |
| 01:10:06 | kanzure: | i was implying trust issues with your giant centralized asic fab |
| 01:10:12 | phantomcircuit: | you should hear people complaining about hosted ct hw |
| 01:10:19 | phantomcircuit: | looking at 15 minute averages flipping a shit |
| 01:10:31 | gmaxwell: | phantomcircuit: sure, no reason this has to actually force 1:1. :) |
| 01:10:52 | gmaxwell: | phantomcircuit: also control of the hardware doesn't need to map 1:1 to ownership. |
| 01:11:00 | kanzure: | (the trust problems would be related to hardware design or tampered designs) |
| 01:11:05 | petertodd: | antephialtic: it solves the problem because of physics: getting rid of heat is easier on a unit basis on a small scale than a large scale, so decentralization of mining power is inherently more profitable than not doing that. Secondly, the idea behind a CPU/GPU/FPGA-soft PoW algorithm is to try to reduce the profit ratio between the ASIC implementation and the much harder to control implementation, so hopefully at least the censored ... |
| 01:11:11 | petertodd: | ... transactions only become more expensive, rather than completely blocked. |
| 01:11:13 | phantomcircuit: | gmaxwell, oh well yeah in that case you could fix it to the pools address |
| 01:11:20 | gmaxwell: | phantomcircuit: e.g. you could have hardware who's behavior is controlled by 2 of 3 keys, which are parties independant from both the owner and the operator. |
| 01:11:22 | phantomcircuit: | makes it kind of hard to sell in the future though :P |
| 01:11:25 | gmaxwell: | or a pool for example. |
| 01:11:41 | phantomcircuit: | it would have to be a setting that could be changed by a signed message |
| 01:11:49 | gmaxwell: | phantomcircuit: nah, just have an reassignment procedure. Or even a recovery mode where you have to take the device offline for 24 hours to reassign ownership. |
| 01:11:53 | gmaxwell: | phantomcircuit: yep. |
| 01:11:58 | gmaxwell: | mentioned all this last night. :) |
| 01:12:00 | petertodd: | antephialtic: but, having actually talked to an ASIC designer recently, even a 10x profit ratio would be really, really hard to pull off. We probably just don't know about the problem to attempt it for now while ASIC mfg is still changing. |
| 01:12:28 | petertodd: | gmaxwell: that's a very good economic argument to the DRM re: decapping! |
| 01:13:14 | gmaxwell: | petertodd: yea, I think it could also apply to other tokens which are used for ratelimiting. |
| 01:13:15 | antephialtic: | petertodd: in that case, it might be interesting to wait until an improvement in ASIC mining tech becomes reducible to a general improvement in IC manufacturing. Maybe then you will be able to buy ASICs at bestbuy |
| 01:13:18 | phantomcircuit: | petertodd, fyi heat extraction is actually more efficient on a large scale |
| 01:13:36 | phantomcircuit: | as long as you're not trying to reduce the intake temp to below ambient |
| 01:14:35 | gmaxwell: | phantomcircuit: not so, heat extraction depends on the delta to ambient. ideally you want your heat spread out as much as possible. Sure, if you have to do active pumping at it you get some shared infrastructure benefits, but better to not need that at all. |
| 01:14:56 | petertodd: | phantomcircuit: on a small scale you can use the heat for something valuable (for some values of "small") |
| 01:15:05 | gmaxwell: | e.g. you have cooling costs in your data center, OTOH miners in my house offset heating costs. You pay to remove heat, intead the heat offsets other costs for me. |
| 01:15:50 | phantomcircuit: | gmaxwell, there's a lot of large scale industrial uses for heat :P |
| 01:15:51 | gmaxwell: | If the waste heat is very hot then there are potentially some industrial uses for it (e.g. cogeneration), but thus far no one has invented semiconductors that run hot enough to do that. |
| 01:15:57 | gmaxwell: | ^ |
| 01:16:15 | antephialtic: | new idea: bitcoin stove. asic miner you can fry eggs on |
| 01:16:29 | phantomcircuit: | even the largest mining farm isn't going to be using enough power for cogeneration |
| 01:16:32 | petertodd: | phantomcircuit: even with those industrial uses, you still have significantly more decentalization than otherwise |
| 01:16:33 | antephialtic: | or make ... hash browns |
| 01:17:00 | gmaxwell: | antephialtic: a long time ago I argued that the most powerful computer in your home would be your clothes dryer... turn it on, it bids out a compute job... and it's routing fedex's trucks for tomorrow while drying your linens. :) we're not quite in the world yet. :) |
| 01:17:08 | phantomcircuit: | gmaxwell, the main thing that people fail to account for is maintenance time, if that is your hobby instead of your job that is a massive savings |
| 01:17:15 | petertodd: | phantomcircuit: re: cogeneration, I'm in switzerland right now at the ethereum hackerspace, and there's cogeneration plants attached to individual apartment buildings here |
| 01:17:41 | phantomcircuit: | petertodd, i assume that's for hvac heating right? |
| 01:17:48 | gmaxwell: | phantomcircuit: also space works in your favor there. datacenter square footage is cheap but there are a lot of unused nooks and crannies in the world that can take a miner. |
| 01:18:03 | petertodd: | phantomcircuit: maintenance? asics are reliable, and more reliable if they're a step back from maximum possible power density |
| 01:18:17 | petertodd: | gmaxwell: the # of people who are running bitcoin miners on zero-cost power... |
| 01:18:38 | phantomcircuit: | petertodd, er believe me i have better numbers on asic reliability than you do |
| 01:18:43 | phantomcircuit: | they're not anywhere near great |
| 01:18:51 | phantomcircuit: | the actual ic never has an issue |
| 01:18:55 | gmaxwell: | petertodd: ::cough:: there are a number of recent generation mining devices which are unreliable due to commerical pressures making them too fast to market and pushing devices way out of spec. |
| 01:18:58 | phantomcircuit: | psus die all the time |
| 01:18:59 | antephialtic: | crappy asic business idea #2: asics targeted toward college students who get free dormroom electricity |
| 01:19:26 | phantomcircuit: | gmaxwell, iirc the only reliable asics are the avalons |
| 01:19:26 | gmaxwell: | yea, 3/4 of my avalon batch 1 units has lost psus. |
| 01:19:39 | phantomcircuit: | and even then psus die |
| 01:19:47 | petertodd: | gmaxwell: exatly, while even if you're using waste heat, the attainable ASIC reliability is very, very high, not too dissimilar from a electric furnaces inate reliability |
| 01:20:01 | gmaxwell: | antminers appear pretty reliable. (pretty shocking if you read their schemetics... they're driving their regulators at something like 4x their rated current) |
| 01:20:21 | gmaxwell: | but I think this is all short term nonsense... once the tech matures it will be very reliable. |
| 01:20:41 | phantomcircuit: | gmaxwell, except there will be constant never ending pressure to reduce prices |
| 01:21:12 | petertodd: | gmaxwell: yeah... at my last job I'd routinely design regulators at 1/10th of the calculated capacity for reliability. (well, to be exact, so we could still have the equipment work in the sahara desert) |
| 01:21:21 | gmaxwell: | phantomcircuit: in any case, ultilmately that means that people with worthless time should be able to push that envelope and get cheaper and more efficient power than someone who is paying by the hour to maintain it. :) |
| 01:21:52 | phantomcircuit: | gmaxwell, sure... eventually |
| 01:22:10 | gmaxwell: | petertodd: part of the thing driving hardware out of spec seems to be parts supply. like.. even if you can affort to overspec the power, you can't actually supply enough parts if you do that. |
| 01:22:14 | phantomcircuit: | the bitcoin mining market when it was all cpus was pretty much a perfect market |
| 01:22:23 | phantomcircuit: | when it was gpus it was pretty much a perfect market |
| 01:22:33 | phantomcircuit: | currently it is basically the exact opposite of a perfect market |
| 01:22:36 | gmaxwell: | hm?! were you mining in the gpu times it was a mess. |
| 01:22:38 | phantomcircuit: | someday that will change |
| 01:22:56 | gmaxwell: | I went three months totally unable to get gpus and at one point basically bribed a distributor to go find me a case of gpus. |
| 01:23:19 | phantomcircuit: | gmaxwell, sure but that was pure supply/demand |
| 01:23:28 | gmaxwell: | so I dunno about 'perfect market'... it was just screwed up in a totally different way than now. :) |
| 01:23:37 | phantomcircuit: | the barrier to entry was relatively small |
| 01:23:54 | kanzure: | were there any bitcoin-specific gpu manufacturers? |
| 01:24:03 | gmaxwell: | no. |
| 01:24:09 | petertodd: | gmaxwell: yup, it's amazingly hard to get a lot of chips these days sadly |
| 01:24:34 | gmaxwell: | somehow, even though we were buying like ... all their product, they seemed to have not even noticed the mining market until more than a year later. :) |
| 01:25:02 | gmaxwell: | funny now just recently some gpus and motherboards came out being marketed around 'bitcoin mining'. .. |
| 01:26:43 | sipa: | gmaxwell: shows how long their development cycle is! |
| 01:28:02 | gmaxwell: | probably something like this happened "Sales were skyrocketing since 2011, but recently they've falled off... what happening?!" "Apparently most of our cards were going to something called bitcoin mining, but now they're moving to some alternetive technology." "Arm the marketing machine!" |
| 01:29:46 | kanzure: | does nvidia have its own fab? |
| 01:30:16 | gmaxwell: | I think nvidia uses TSMC. |
| 01:31:42 | phantomcircuit: | petertodd, you can buy all the chips you want the hard part is getting the boards made correctly |
| 01:33:46 | petertodd: | phantomcircuit: huh? compared to building the chips getting the boards made is easy |
| 01:33:52 | phantomcircuit: | gmaxwell, nvidia actually made modifications to their latest gpus which makes them do scrypt more efficiently |
| 01:34:09 | phantomcircuit: | petertodd, building the chips is hard, buying them from cointerra/hashfast is easy |
| 01:34:19 | phantomcircuit: | they both have literally pallets of them |
| 01:34:34 | petertodd: | phantomcircuit: well sure, but that's not relevant to -wizards discussions about long-term centralization |
| 01:35:09 | phantomcircuit: | petertodd, long term (4+ years) i suspect people with free power will dominate |
| 01:35:10 | phantomcircuit: | :P |
| 01:35:19 | phantomcircuit: | (and/or free power arrangements will disappear) |
| 01:35:28 | petertodd: | gmaxwell: at least that does put to rest conspiracy theories that nvidia and amd were pushing alt-coins :P |
| 01:35:46 | petertodd: | phantomcircuit: I'll bet you that's already a significant factor |
| 01:36:12 | phantomcircuit: | petertodd, uhhhh i dont think so |
| 01:36:38 | petertodd: | phantomcircuit: where significant is (low) double-digits of hashing power, yes I think so |
| 01:36:56 | phantomcircuit: | hmm maybe year |
| 01:37:00 | phantomcircuit: | yeah* |
| 01:37:30 | phantomcircuit: | i signed up for a program that allows you to smooth out your electric bill |
| 01:37:46 | phantomcircuit: | they assess how much they think you'll use over the year and set that as a fixed rate for 6 months |
| 01:37:48 | phantomcircuit: | suckers |
| 01:38:05 | LarsLarsen: | LarsLarsen has left #bitcoin-wizards |
| 01:38:13 | petertodd: | lol |
| 01:38:25 | phantomcircuit: | petertodd, now if only they would install a substation for me :P |
| 01:38:42 | sipa: | phantomcircuit: after which you pay the difference? |
| 01:38:59 | phantomcircuit: | sipa, nope after which they reasses the rate for the remaining 6 months |
| 01:39:10 | phantomcircuit: | except you dont have to pay it if you stop buying power from them |
| 01:39:22 | petertodd: | phantomcircuit: one largish miner I was talking to recently said they actually work with the local power company to identify buildings in areas that have excess distribution capacity |
| 01:39:27 | phantomcircuit: | it's a deregulated market, so i dont have to buy power from the former gov monopoly |
| 01:39:34 | phantomcircuit: | it's really a very poorly thought out program |
| 01:39:48 | phantomcircuit: | petertodd, |
| 01:40:01 | petertodd: | phantomcircuit: did they do deregulated power distribution as well as production? |
| 01:40:08 | phantomcircuit: | in total there is a lot of excess distribution capacity |
| 01:40:20 | phantomcircuit: | but it tends to be in 100-400kW increments |
| 01:40:32 | phantomcircuit: | most places that have a large power use will have a 500kW transformer |
| 01:41:04 | petertodd: | phantomcircuit: yeah, this was in trinidad actually |
| 01:41:09 | phantomcircuit: | petertodd, yes and no, the distribution is all done by the same entitiy, except they're required to lease their lines in some bizarre way |
| 01:41:16 | phantomcircuit: | it's a very american version of privatization |
| 01:41:30 | phantomcircuit: | petertodd, ah so probably more like 50kW patches :P |
| 01:41:52 | petertodd: | phantomcircuit: pretty much, IIRC the guy said they don't bother leasing offices, they just go to the existing tenant and lease a closet or something |
| 01:42:26 | phantomcircuit: | petertodd, that sounds like a great idea |
| 01:42:40 | phantomcircuit: | until things start to wear out and you're now doing maintenance on equipment in 100 places |
| 01:42:41 | petertodd: | unique situation too because it sounds like trinidad is heavily subsidizing industrial-usage electricity prices too - 3cents/KW/hr or something insane |
| 01:42:52 | petertodd: | phantomcircuit: trinidad isn't known for its high labor prices :) |
| 01:43:11 | phantomcircuit: | petertodd, finding people who can fix gpu issues isn't cheap anywhere... |
| 01:43:56 | petertodd: | well, they'll find out as the business progresses |
| 01:45:30 | phantomcircuit: | petertodd, it seems like trinidad is using nearly all natural gas |
| 01:45:39 | phantomcircuit: | in which case the subsidy is approximately 50% |
| 01:45:52 | phantomcircuit: | on just the marginal cost of the gas |
| 01:46:13 | petertodd: | 50% isn't that crazy of a subsidy at least |
| 01:46:14 | phantomcircuit: | ah i see they produce the gas domestically |
| 01:46:45 | phantomcircuit: | it's plausible it isn't a subsidy in a direct sense but rather just that they dont sell the gas on the international market |
| 01:47:24 | petertodd: | well... that can easily lead to them underinvesting in export capacity, LNG is a big market now |
| 01:47:55 | petertodd: | equally they might be better off leaving the gas in the ground to use later |
| 01:48:14 | phantomcircuit: | im sure it has |
| 01:48:39 | phantomcircuit: | petertodd, if they dont extract it im sure some enterprising oil company will figure out how to horizontally drill into it :P |
| 01:49:02 | petertodd: | heh, nah, that stuff is pretty tightly regulated in sane countries these days |
| 01:49:51 | phantomcircuit: | petertodd, offshore rig in international waters doing horizontal drilling is prettty hard to regulate |
| 01:52:33 | petertodd: | phantomcircuit: I would be highly surprised if doing that was worth it except in extremely rare gases - horizontal drilling is not cheap and international waters are generally pretty far away |
| 01:53:02 | phantomcircuit: | petertodd, 12 miles |
| 01:53:29 | phantomcircuit: | however i would be surprised if there wasn't a vein going out to sea somewhere |
| 01:53:41 | phantomcircuit: | petertodd, either way |
| 01:53:46 | phantomcircuit: | indirect subsidy |
| 01:53:48 | petertodd: | phantomcircuit: which is already a damn expensive horizontal drill, and also many countries have succesfully petitioned the UN to have that 12 mile limit greatly extended when natural resources are at play (e.g. oil and gas!) |
| 01:54:48 | phantomcircuit: | petertodd, the whole worlds carved up into fiefdoms :| |
| 01:55:15 | petertodd: | phantomcircuit: also, what you actually want to talk about, is the "Exclusive Economic Zone", which defaults to 370km, specifically to cover oil/gas reserves |
| 01:55:23 | phantomcircuit: | gmaxwell, ps apparently there is an nvidia gpu that litecoin mines as efficiently as a gridseen |
| 01:55:25 | phantomcircuit: | which is weird |
| 01:55:46 | phantomcircuit: | (not including the actual computer of course....) |
| 02:03:42 | warren: | some guy on the forum is threatening to hardfork Bitcoin to X11 and taking the community with him |
| 02:03:45 | petertodd: | http://www.vice.com/en_ca/read/bitcoin-could-revolutionize-voting <- ugh |
| 02:03:51 | warren: | oooh.... |
| 02:03:53 | petertodd: | warren: lol |
| 02:04:04 | gmaxwell: | to X11? |
| 02:04:19 | petertodd: | aside: shittiest name ever |
| 02:04:30 | gmaxwell: | phantomcircuit: I'm afraid we might be overrunning the channel with mining stuff. :) |
| 02:04:44 | phantomcircuit: | gmaxwell, heh |
| 02:04:57 | sipa: | how about we hardfork bitcoin to Qt instead? |
| 02:05:03 | phantomcircuit: | sipa, lol |
| 02:05:04 | petertodd: | sipa: +1 |
| 02:05:06 | sipa: | (note: april first here) |
| 02:05:43 | warren: | ("X11" is what some scancoins are calling a "CPU-only" hash that combines 11 hashes together ... that was already implemented on GPU.) |
| 02:05:55 | gmaxwell: | petertodd: page isn't loading for me, I assume it's yet another thing thats mistaken bitcoin for a general jamming free network? |
| 02:06:28 | petertodd: | gmaxwell: that's a charitable description of the article |
| 02:07:28 | petertodd: | gmaxwell: you know, it's kinda unfortunate that blockchain voting does make perfectly good sense for the highly specialized case of digital assests - that's going to confuse a lot of people |
| 02:09:27 | kanzure: | paperbot: http://www.tandfonline.com/doi/pdf/10.1080/09528130600552888 |
| 02:09:36 | paperbot: | http://diyhpl.us/~bryan/papers2/paperbot/3407742a4d5d94cab2d719e80953870a.pdf |
| 02:09:37 | kanzure: | |
| 02:10:30 | sipa: | kanzure: eh? |
| 02:10:41 | kanzure: | andytoshi asked |
| 02:10:46 | sipa: | k |
| 02:11:06 | kanzure: | paperbot takes a url and gives you a pdf that you might not otherwise be able to get |
| 02:11:40 | gmaxwell: | paperbot: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4926218 |
| 02:11:44 | paperbot: | http://libgen.org/scimag/get.php?doi=10.1109%2FTASL.2009.2023186 |
| 02:11:55 | gmaxwell: | ooohhh |
| 02:11:57 | gmaxwell: | it works |
| 02:12:27 | gmaxwell: | now I can read my own publications. |
| 02:12:35 | phantomcircuit: | lold |
| 02:12:46 | kanzure: | paperbot uses https://github.com/kanzure/pdfparanoia |
| 02:12:54 | kanzure: | so if you are feeling paranoid, contributions/code review are appreciated |
| 02:13:07 | andytoshi: | kanzure: cool! |
| 02:29:53 | adam3us: | gmaxwell: "make mining chips that know their owners public key... so they only mine like their owner wants them to even if they're housed by a third party" interesting |
| 02:31:08 | adam3us: | gmaxwell: wonder how simple one could make the circuit to verify ownership. bignums, ecc etc maybe non-simple relative to sha256 x 10,000 |
| 02:32:28 | gmaxwell: | fortunately it doesn't have to be fast. it should be possible to implement a microcontroller from off the shelf hdl in fewer gates than an unrolled sha256 core. |
| 02:34:05 | BCB: | anyone know how to return the binary representation (not binary number) of a hexadecimal string in bash? |
| 02:34:27 | phantomcircuit: | gmaxwell, the main problem is you have to move a bunch of logic onto the chips |
| 02:34:28 | maaku: | BCB: try #bash |
| 02:34:42 | phantomcircuit: | which is otherwise unnecessary |
| 02:34:43 | BCB: | maaku, thx |
| 02:34:47 | gmaxwell: | BCB: trivial if you use bc. |
| 02:35:41 | phantomcircuit: | oh ffs there's a dead pixel on this display |
| 02:36:39 | Luke-Jr: | gmaxwell: I wonder how much space the NV memory will take though |
| 02:37:07 | phantomcircuit: | and of course 1 dead pixel doesn't qualify for replacement under warranty |
| 02:37:08 | phantomcircuit: | >.> |
| 02:37:15 | Luke-Jr: | * Luke-Jr wonders what the difference between a "binary representation" and "binary number" is |
| 02:39:35 | BCB: | Luke-Jr, I've been trying to figure that out myself for 2 days! |
| 02:39:48 | BCB: | Luke-Jr, php does it with hex2bin |
| 02:49:58 | c0rw1n: | c0rw1n is now known as c0rw|sleep |
| 02:52:37 | BCB: | gmaxwell, that worked. thx |
| 02:54:49 | BCB: | gmaxwell, I'm trying to has a block header in bash and I can't seem to get the correct has |
| 02:54:52 | BCB: | *hash |
| 03:00:36 | antephialtic: | is there some mechanism by which unspendable outputs (say to 1BitcoinEaterDontSend...) can be pruned by miner agreement? |
| 03:00:46 | antephialtic: | goal is to shrink the size of the UTXO set |
| 03:01:15 | phantomcircuit: | antephialtic, for spends toa public key for which nobody has the private key? no |
| 03:01:23 | phantomcircuit: | since you cant prove that nobody has the private key |
| 03:02:12 | antephialtic: | well, I guess the mechanism required would be some function that allowed miners to take coins from people, so that probably wouldn |
| 03:02:14 | antephialtic: | 't fly |
| 03:02:29 | antephialtic: | I guess its just a little concerning that the utxo set growth is forever unbounded |
| 03:11:25 | jgarzik: | antephialtic, IMO the best avenue to pursue is always economic and game theory incentives. How to incentivize optimal UTXO management? How to tilt the incentives to encourage UTXO healthy by default? |
| 03:12:09 | jgarzik: | There have already been a few proposals about alternate fee-based incentives, and a couple commits along these lines already |
| 03:12:28 | antephialtic: | in terms of radical changes, could you give outputs an expiration date based on the fee? |
| 03:12:45 | antephialtic: | "expired coins" would return to the pool of coins yet to be mined |
| 03:13:45 | Luke-Jr: | what fee? |
| 03:13:56 | antephialtic: | transaction fee |
| 03:14:01 | Luke-Jr: | do all outputs of a transaction expire at the same time then? |
| 03:14:06 | Luke-Jr: | what if some are spent, but others are not? |
| 03:14:21 | Luke-Jr: | what if MtGox's cold wallet expire? |
| 03:14:22 | antephialtic: | any unspend outputs from the tx expire at the date |
| 03:14:29 | jgarzik: | I don't bother with this line of thinking, as a hard fork majority is unlikely to ever approve coin expiration |
| 03:14:43 | gmaxwell: | hard expiration is almost certantly too much of a economic violation. |
| 03:15:01 | Luke-Jr: | you *could* manually mark outputs you believe are unspendable.. but that's risky. |
| 03:15:28 | gmaxwell: | and talk of that stuff— even just in the context of what I think will inevitably happen due to the prospect of crypto breaks— has gotten me violent threats in the past. |
| 03:16:01 | antephialtic: | hmm, it might not be plausible for bitcoin, but it would be interesting in an alt |
| 03:16:12 | Luke-Jr: | s/alt/side |
| 03:16:18 | antephialtic: | though it would make cold storage management quite tricky |
| 03:16:26 | gmaxwell: | I think petertodd had an idea which is probably fruitful here... which is that you could 'soft expire' utxo into a pruned tree and then require someone to go create a proof that their utxo was a member. |
| 03:17:35 | gmaxwell: | so then not everyone would need to go store that data, blocks would come along with a membership proof... going and getting the data needed to form the membership proof is the spenders problem, and _that_ is probably not too much of a change, if the utxo load were really burdensom. |
| 03:20:37 | antephialtic: | can you represent the UTXO set in constant space with an accumulator? |
| 03:21:10 | antephialtic: | IE keep an accumulator of the TXids of unspent outputs in memory, keep everything else on disk |
| 03:21:28 | gmaxwell: | adam3us: have a commitment to a utxo set in constant space: a single hash. |
| 03:21:31 | gmaxwell: | er antephialtic |
| 03:21:35 | gmaxwell: | (sorry adam) |
| 03:22:48 | antephialtic: | I'm a little behind on the 2-way pinning stuff, but what would be needed to be added to script to "suspend" the coins on the BTC chain? |
| 03:23:24 | gmaxwell: | antephialtic: the suspend part doesn't require anything new, its the bring it back part that requires a number of new things. |
| 03:23:47 | antephialtic: | is there an email thread, or a time in the logs that I can read about the details? |
| 03:25:52 | gmaxwell: | antephialtic: the log here http://download.wpsoftware.net/bitcoin/wizards/2013-12-18.txt describes the high level stuff that needs to be done, the script details haven't made it to a handy place online yet. |
| 03:26:01 | antephialtic: | gmaxwell: thanks! |
| 03:27:05 | justanot1eruser: | Why is Antonopoulos trying to get you "fired"? |
| 03:27:34 | justanot1eruser: | Actually, probably respond in #bitcoin if you want |
| 03:29:26 | jgarzik: | ? |
| 03:35:18 | Ademan: | who is getting "fired" ? |
| 03:35:23 | jgarzik: | me |
| 03:35:40 | Ademan: | wtf, are you discussing in #bitcoin? |
| 03:36:30 | justanot1eruser: | Ademan: nothing of significance |
| 03:40:17 | Ademan: | oh dang that is a loonnnggggg thread |
| 03:40:30 | Ademan: | (bitcoin.org pull request 152 discussion) |
| 03:40:48 | gmaxwell: | and offtopic here. |
| 03:59:43 | adam3us: | gmaxwell: i thought you'd thought of a novel way to verify sigs via consensus rather than asic ecdsa verifier "have a commitment to a utxo set in constant space: a single hash." :) it even sort of made sense. force the block to contain a tx with given txo or it wont be mined. if it is mined but the sender doesnt have the private key, the sig will be invalid, and hence the block - maybe it even works :) |
| 05:25:20 | phantomcircuit: | 08787337 |
| 05:33:33 | copumpkin: | quick, log into his account |
| 05:35:40 | phantomcircuit: | copumpkin, google it |
| 05:36:17 | Luke-Jr: | http://eandata.com/lookup/0087800000737/ |
| 05:36:18 | Luke-Jr: | wat? |
| 05:36:42 | copumpkin: | pfft, you think I don't know it by heart? I wear one of those daily to work |
| 06:04:44 | shesek: | it could be interesting to create an altcoin where the the coin owner is responsible for keeping an SPV-like proof that his input transactions were included in a previous block |
| 06:05:20 | shesek: | attaching it to the private key, and you'd have to keep a combination of both |
| 06:06:45 | shesek: | freeing the network from storing the transaction themselves |
| 06:06:51 | shesek: | could something like that work? |
| 06:07:29 | Luke-Jr: | been on gmaxwell's alt ideas list for a while :P |
| 06:07:43 | Luke-Jr: | IIRC the problem is the proofs get big to relay |
| 06:08:43 | shesek: | how big do they get? |
| 06:12:53 | kazcw: | well you'd need a tree of transactions with the one to validate as the root and all the coinbases whose output-descendants are being spent as the leaves, right? that scales the same as human ancestors (starting out exponential, becoming less extreme as multiplicity increases -- sort of "exponential with memoization") |
| 06:14:58 | kazcw: | it seems like it might be possible to use ZK proofs to "condense" a history, though...... |
| 06:15:29 | kazcw: | actually probably not |
| 06:25:08 | maaku: | shesek: sounds like TXO commitments? |
| 06:25:15 | maaku: | doesn't need an alt coin |
| 06:25:47 | maaku: | it's where things are headed in bitcoin, eventually |
| 07:17:28 | petertodd: | http://blog.mastercoin.org/2014/04/01/masterdoge-mastercoin-moving-to-dogecoin/ |
| 07:18:59 | petertodd: | kazcw: I'm looking into stuff like that w/ tree-chains: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04388.html |
| 07:22:57 | Luke-Jr: | petertodd: you should have waited a few more days to announce |
| 07:32:51 | petertodd: | Luke-Jr: I can assure you today was the right day... |
| 07:33:36 | Luke-Jr: | petertodd: no no, you want to wait a little longer. |
| 07:36:34 | antephialtic: | petertodd: maybe you should start #dogecoin-wizards |
| 07:37:06 | antephialtic: | much SNARKs, such side chain. wow |
| 07:46:30 | petertodd: | antephialtic: IRC chat works best when there's more than one person in the channel... :P |
| 07:48:47 | Luke-Jr: | petertodd: there's 2 people in #dogecoin-wizards; 3 if you join |
| 07:52:48 | midnightmagic: | :-D |
| 07:56:14 | petertodd: | hilarious |
| 08:04:19 | antephialtic: | anyway, a question for anyone who was around in the early days of bitcoin - does anyone have a copy of the draft version of the bitcoin paper? The original title was "Electronic Cash Without a Trusted Third Party " |
| 08:04:29 | antephialtic: | see: http://www.gwern.net/docs/2008-nakamoto |
| 10:27:16 | warren: | petertodd: glad to see mastercoin is improving its credibility |
| 10:27:24 | warren: | =P |
| 10:27:46 | hearn: | it is? |
| 10:31:03 | warren: | hearn: [21:17:28] http://blog.mastercoin.org/2014/04/01/masterdoge-mastercoin-moving-to-dogecoin/ |
| 10:31:55 | hearn: | oh, hah |
| 11:06:46 | kloeri: | [Global Notice] For purely non-profit reasons, all your nickserv accounts have been converted into freenode+ accounts; details at http://blog.freenode.net/2014/04/googleplusfreenode/. Thank you for using freenode. |
| 14:38:01 | jtimon: | we made that joke first: https://github.com/maaku/dogemarket.org |
| 14:40:04 | jtimon: | well, it would actually make sense to deploy such a hardfork on dogecoin |
| 14:41:25 | jtimon: | inefficient embeded systems only fit in bitcoin's main chain because "anything else would be too insecure", that's their reason to exist (much like colored coins) |
| 14:41:57 | antephialtic: | jtimon: #dogecoin-wizards |
| 14:42:08 | antephialtic: | actual channel :) |
| 14:46:53 | jtimon: | joined, but I'll finish my reasoning here |
| 14:46:53 | jtimon: | embedded systems assume their features won't be able to justify a hardfork with explicit validation, and then implement those without the hardfork consent in less efficient ways |
| 14:48:30 | petertodd: | jtimon: keep in mind many of the techniques that could allow bitcoin to scale up also push validation client-side; I'm increasingly less convinced that miner validation is such a big advantage |
| 14:50:40 | antephialtic: | systems that build on bitcoin's chain also benefit from access to bitcoin's userbase |
| 14:51:02 | petertodd: | antephialtic: very good point |
| 15:06:32 | jtimon: | petertodd any advances on validating fees on the client side with those techniques? |
| 15:08:10 | petertodd: | jtimon: well, one approach is to pay for fees with coins whose history is constrained to just the one chain (IE in the tree-chains model) |
| 15:08:45 | jtimon: | antephialtic how is the bitcoin user base more inclined to use mastercoin than namecoin for being accounted on the bitcoin chain? It seems to me like it's irrelevant from the user perspective |
| 15:09:38 | jtimon: | petertodd how is that validated "client side"? miners are still validating all transactions with tree-chains, right? |
| 15:10:00 | jtimon: | their subset of transactions I mean |
| 15:10:04 | petertodd: | jtimon: potentially no! it could be implemented as a pure proof-of-publication scheme |
| 15:10:33 | petertodd: | but yeah, if you pay for fees with coins whose history only includes the subset of blocks the miners are mining on, then there's no validation problem for miners |
| 15:11:10 | jtimon: | I understand what you mean there and again my point is fees always depend on miner validation |
| 15:11:55 | antephialtic: | jtimon: useful services built on the 1TB (one true blockchain :) ), add utility to it, and thus increase demand for the tokens needed to manipulate it |
| 15:12:05 | petertodd: | ah, but, so look at it this way: you could build multiple proof-of-publication-using systems on top of this, and thus have different people paying different assets to miners - the only need to validate the ones they accept |
| 15:12:18 | jtimon: | if you didn't care about proof of work, you could just have a giant dumb timestamping and validate everything on the client, I get that point |
| 15:12:35 | petertodd: | Mastercoin's actually been talking about that, e.g. by defining Mastercoin denominated fees as being credited to the scriptPubKeys of coinbase transactions |
| 15:13:01 | petertodd: | jtimon: no, just timestamping is *not* enough because timestamping doesn't prove anythig about the lack of double spends |
| 15:13:09 | jtimon: | "they only need to validate the ones they accept" correction s/only/at least |
| 15:14:07 | jtimon: | yes, sorry, "proof of publication timestamper" |
| 15:14:13 | petertodd: | no, that's an "only" if you're using the system in the proof-of-publication/client-side-validation model - basically with regard to fees the client is the validation |
| 15:14:40 | petertodd: | jtimon: yup, speaking of, proof-of-publication doesn't necessarily need to mean timestamping |
| 15:15:02 | jtimon: | I know |
| 15:15:39 | petertodd: | jtimon: good, it'll be on the exam when I get that professorship :P |
| 15:16:15 | jtimon: | ok, so I guess my point is that since miners can ideally receive any asset |
| 15:17:42 | petertodd: | ... ? |
| 15:17:55 | jtimon: | and to validate what they receive the whole custody chain (and that's the best save of commited txo/utxo's over dumb hashing)... |
| 15:18:22 | jtimon: | the rules for asset issuance and transfer must be understood by the miners |
| 15:18:54 | jtimon: | so what's the point of miners not knowing them like in mastercoin? |
| 15:19:02 | petertodd: | flexibility and censorship resistance |
| 15:19:46 | petertodd: | the former in that now everything is a soft-fork, and it's a soft-fork where the usefullness is perportional to the hashing power/economic power that has adopted the new rules |
| 15:20:25 | petertodd: | censorship resistance in that multiple systems are using the same chain, so to try to attack any one of them results in a lot of collatteral damage and wasted hashing power/other resources |
| 15:21:33 | petertodd: | one of the things I'm working on is figuring out what kind of models make sense - do you do prefix-filtering and pick some fixed prefix for your niche system? do you change the prefix regularly by some method? not totally clear what's the best solution here |
| 15:22:43 | jtimon: | there's other "last hardforks" that would give you the same "everything is a soft-fork" property |
| 15:23:11 | jtimon: | I'm still trying to undesrtand the censorship part |
| 15:23:22 | petertodd: | jtimon: indeed, with respect to some types of decentralized finance applications mastercoin is that "last hardfork" :P |
| 15:24:31 | jtimon: | mastercoin is not a hardfork and neither is "last" unless you're happy with its current efficiency properties |
| 15:24:51 | maaku: | i think "last" here has some broader meaning |
| 15:25:00 | maaku: | mastercoin doesn't do *everything* |
| 15:25:24 | petertodd: | jtimon: so, proof-of-publication security is such that to 51% attack some publication domain you need $x, if your transactions are worth $y <<< $x, but are published in the same place that n other embedded consensus systems are published, then the cost to attack your system is the sum of the cost to attack all the systems at once |
| 15:25:52 | petertodd: | maaku: yeah, by "last" I was a) only half-serious, b) really referring to economics/market share |
| 15:27:11 | jtimon: | ok, I see, couldn't you make this more efficient by explicitly defining those channels on the protocol rules? |
| 15:27:43 | petertodd: | depends on what you mean by efficient |
| 15:28:33 | petertodd: | e.g. mastercoin already does this in a very primitive way in that mastercoin tx's are easy to find - they all pay a dust amount to the exodus address - so full clients with respect to MSC only need to be SPV with respect to BTC |
| 15:29:29 | petertodd: | incidentally, this is why I'm really worried that committed UTXO sets will encourage UTXO growth if we don't do UTXO expiration (with a TXO commitment fallback so we're not changing the economics much) |
| 15:30:11 | petertodd: | jtimon: "Store hashes, or a hash root, and soft-fork that blocks are only |
| 15:30:14 | petertodd: | accepted if (a) the data tree is provided, or (b) sufficient work is |
| 15:30:16 | petertodd: | built on it and/or sufficient time has passed" |
| 15:30:27 | petertodd: | jtimon: ^ you're really close to the answere to my 25mBTC challenge... |
| 15:31:40 | maaku: | petertodd: UTXO expiration nullifies many use cases |
| 15:31:58 | maaku: | how do I know a transaction was spent vs expired? |
| 15:33:12 | petertodd: | maaku: age is an obvious way |
| 15:33:55 | jtimon: | petertodd do you have a link with the post including the question? (that thread is big) |
| 15:34:36 | petertodd: | jtimon: https://bitcointalk.org/index.php?topic=395761.msg5985389#msg5985389 |
| 15:34:46 | jtimon: | thanks |
| 16:04:01 | jtimon: | sorry, I don't think I understand the question |
| 16:13:49 | wallet42: | wallet42 is now known as Guest33965 |
| 16:13:49 | wallet421: | wallet421 is now known as wallet42 |
| 16:28:10 | BCB: | has anyone confirmed the coinbase dump? |
| 16:38:15 | nsh: | dump? |
| 16:40:33 | BCB: | nsh there is a "alleged" email dump of coinbase user on pastebin |
| 16:41:04 | nsh: | sounds stupid :) |
| 16:41:57 | nsh: | * nsh reads https://news.ycombinator.com/item?id=7507493 " Hacker Newsnew | comments | ask | jobs | submit login |
| 16:41:57 | nsh: | Coinbase user emails and full names leaked. Bug was dismissed (pastebin.com)" |
| 17:08:05 | sipa: | can we _please_ use coinbase.com when referring to the company? |
| 17:08:09 | sipa: | also, #bitcoin |
| 17:24:47 | nsh: | * nsh nods |
| 17:34:15 | austinhill: | sipa: Check slack for jwilkins's comments on coinbase.com vulnerability |
| 18:17:05 | super3: | tacotime, you there? |
| 18:29:09 | mr_burde_: | mr_burde_ is now known as mr_burdell |
| 19:12:27 | tacotime: | super3, yo, sorry, was out |
| 19:13:31 | tacotime: | super3, you can use ecdh to share a stream/block cipher key and then encrypt data between two peers by that route. |
| 19:13:51 | tacotime: | but you can't use ecdsa private/public keys to directly encrypt a la rsa. |
| 19:14:02 | tacotime: | check out bitmessage's implementation. |
| 19:14:38 | super3: | hmmm, ok that complicates things, but it makes sense |
| 19:15:08 | gmaxwell: | http://sourceforge.net/p/bitcoin/mailman/message/32174171/ |
| 19:20:50 | gmaxwell: | ^ please go comment on that proposal. :) |
| 19:26:11 | tacotime: | ~2270 AD will be a good time for SHA256d miners. |
| 19:31:29 | tacotime: | Thanks sipa, I lol'd a couple times. X) |
| 19:44:36 | midnightmagic: | * midnightmagic wishes not for the first time that there was an easy way to post to mailing lists from arbitrary locations just by signing the message with something. |
| 19:46:39 | gmaxwell: | * gmaxwell wonders if someone will says that this is an obvious example of why PPC should have been a supported platform. |
| 19:46:54 | amiller: | hahaha that's so cool |
| 19:46:58 | kazcw: | I think #bitcoin is taking it seriously |
| 19:47:04 | amiller: | i convinced myself of it with this codepad: http://codepad.org/wWuVk4Zm |
| 19:47:33 | gmaxwell: | amiller: your codepad is obviously not running on PPC. :P |
| 19:48:30 | maaku: | amiller: well, it is serious. but that doesn't mean we can't have fun in the process :) |
| 19:48:51 | midnightmagic: | kazcw: because as-written it appears it will happen. :) |
| 19:49:06 | gmaxwell: | arm and x86 implement the shift instructions as if the shift amount were masked by the target size. (results in a lower delay hardware implementation, since you don't need an additional step to deal with the too large value) but PPC and some other things behave more sanely. |
| 19:49:15 | maaku: | *kazcw |
| 19:49:27 | gmaxwell: | the compiler is free to do whatever it wants here. |
| 19:49:30 | Luke-Jr: | gmaxwell: LE MIPS? |
| 19:49:47 | gmaxwell: | Luke-Jr: go test on one? I'd imagine mips would also do the fast thing. |
| 19:50:03 | Luke-Jr: | not sure my MIPS is LE. LE is weird. |
| 19:50:04 | gmaxwell: | but current compilers seem to just do what the underlying arch's shift instruction does. |
| 19:50:15 | midnightmagic: | hey i have a mips laptop. ah crap it's at home. |
| 19:51:18 | Luke-Jr: | midnightmagic: LE? |
| 19:51:33 | midnightmagic: | i don't know, it's one of those loongson lemote thingies. |
| 19:51:42 | Luke-Jr: | I doubt it's LE. MIPS is usually BE. |
| 19:51:59 | midnightmagic: | (sans-aluminum since that wasn't available at the time i ordered it) |
| 19:52:50 | gmaxwell: | LE MIPS is even more rare than ARM running in BE mode these days. |
| 19:52:51 | midnightmagic: | http://en.wikipedia.org/wiki/Loongson says 2e and 2f are both little-endian |
| 19:53:06 | gmaxwell: | hm interesting! |
| 19:53:50 | midnightmagic: | yep I think it's little-endian mips. |
| 20:01:43 | Luke-Jr: | maybe because Loongson targets x86 emulation |
| 20:03:28 | midnightmagic: | you mean like how itanium can operate in big- or little-endian modes? |
| 20:06:08 | gmaxwell: | midnightmagic: ppc and arm can do that too. But I think the mips ones usually aren't runtime selectable. |
| 20:06:56 | midnightmagic: | huh. i thought itanium was boot-time selectable. |
| 20:21:00 | amiller: | i think my favorite part is "42 half-million" |
| 20:22:40 | Luke-Jr: | :P |
| 20:23:48 | sipa: | amiller: you ain't seen nothing yet :p |
| 20:24:01 | amiller: | what, there's more? |
| 20:26:50 | Luke-Jr: | amiller: https://gist.github.com/luke-jr/9920788 |
| 20:53:22 | gmaxwell: | lol: http://btcplex.com/block/0000000000004c78956f8643262f3622acf22486b120421f893c0553702ba7b5 |
| 20:54:49 | sipa: | that's the missed satoshi subsidy? |
| 20:54:53 | gmaxwell: | yes. |
| 20:54:54 | gmaxwell: | (see the first transaction: Generation: 50 BTC + 184467440737.09552002 total fees ) |
| 20:55:24 | sipa: | uint64_t ftw |
| 21:45:48 | jrmithdobbs: | and functions surrounded by () behave (exactly?) as infxl 0 functions |
| 21:45:52 | jrmithdobbs: | bah |
| 21:55:23 | [Tristan]: | [Tristan] is now known as Guest86019 |
| 21:58:03 | maaku: | that's a lot of fees |
| 22:03:54 | gmaxwell: | I added a link to BIP42 on hacker news. |
| 22:04:32 | sipa: | reddit? |
| 22:06:44 | maaku: | upvoted! |
| 22:08:43 | gmaxwell: | http://www.reddit.com/r/Bitcoin/comments/21ynmv/bitcoin_should_adopt_a_noninfinite_coin_supply/ |
| 22:14:15 | phantomcircuit: | playing with fire |
| 22:14:31 | sipa: | hmm? |
| 22:15:10 | phantomcircuit: | so many people wont get the joke |
| 22:15:21 | sipa: | yup |
| 22:15:26 | gmaxwell: | Thats actually okay. |
| 22:15:38 | phantomcircuit: | lol |
| 22:15:51 | gmaxwell: | I think it's good for the community that sometimes crazy shit people dont understand shows up... helps people be skeptical readers. |
| 22:16:03 | gmaxwell: | In this case it's actually completely serious, though written about in a funny way. |
| 22:16:17 | gmaxwell: | Currently the bitcoin software as it is actually running has an infinite supply of coins. |
| 22:16:49 | phantomcircuit: | something tells me we wont be using bitcoin in ~1000 years |
| 22:17:01 | gmaxwell: | sure sure details details. |
| 22:17:11 | phantomcircuit: | :P |
| 22:17:23 | gmaxwell: | Are you not a fan of the Clock of the Long Now? |
| 22:17:26 | sipa: | phantomcircuit: heresy! |
| 22:18:36 | sipa: | (i always found that work to seem to sound similar to "hearsay") |
| 22:20:16 | gmaxwell: | petertodd: I bet your python implementation is also inconsistent with the reference when nHeight is negative too! |
| 22:20:55 | maaku: | sipa: i'm a native speaker and honestly I didn't realize until now they were different words |
| 22:21:37 | gmaxwell: | really? Heresay has the advantage of being spelled like what it means. |
| 22:22:42 | sipa: | gmaxwell: heresay or hearsay? |
| 22:23:30 | gmaxwell: | hahah okay, I give up. |
| 22:24:21 | nsh: | * nsh smiles |
| 22:26:45 | jtimon: | hehe "Gregory Maxwell wrote: But owing to a rather large bribe (or at least not less large than any other offered by competing parties)" |
| 22:27:20 | Luke-Jr: | gmaxwell: I will offer a satoshi! |
| 22:27:54 | gmaxwell: | too late. |
| 22:28:37 | Luke-Jr: | :< |
| 22:28:55 | sipa: | we shouldn't have put in the PHP part: http://www.reddit.com/r/Bitcoin/comments/21y5nn/bitcoindev_finite_money_supply_for_bitcoin/ |
| 22:29:06 | sipa: | i assumed it would be obvious without it too, but maybe not :) |
| 22:29:24 | Luke-Jr: | well, I think it's fair to say we're all at least decent at PHP |
| 22:30:17 | sipa: | i wrote a (subset of) LaTeX parser in PHP |
| 22:30:25 | sipa: | that's the _only_ thing I ever wrote in it... |
| 22:30:56 | sipa: | well, almost |
| 22:33:00 | Luke-Jr: | ljrbot has a game written in PHP |
| 22:33:08 | Luke-Jr: | (yes, PHP within a Python bot..) |
| 23:01:27 | sipa: | dang, should have made the switch in 2248 |
| 23:02:05 | sipa: | that'd make it xkcd 1344 compatible |
| 23:06:38 | maaku: | any thoughts on a safe, transitional way to change the transaction serialization format (in a hard-fork)? |
| 23:07:33 | nsh: | wasn't there some kind of way to do block-depth margin of overlapping standardness? |
| 23:07:53 | gmaxwell: | it's really hard to do that without blowing up a lot of software. It's really obnoxious. The best you could do, I think as nsh notes, is to support both. |
| 23:07:53 | maaku: | I've thought about adding the block height to the serialization routines for CTransaction, but that makes the transition messy, especially with regards to zero-conf transactions |
| 23:08:14 | nsh: | * nsh nods |
| 23:08:27 | maaku: | ok, but that would be what - determine format based on nVersion? |
| 23:08:32 | gmaxwell: | if you were to change that you should really also change the hashing of transactions to make them tree structured. |
| 23:08:40 | gmaxwell: | maaku: yea, I suppose you would. |
| 23:09:36 | nsh: | (the might be some new attacks that would become possible due to the temporary serialization format malleability too) |
| 23:09:41 | maaku: | so (this is context of freicoin/freimarkets) nVersion=1 means bitcoin, nVersion=2 has refheight feild (freicoin), nVersion>=3 is freimarkets formatted |
| 23:09:46 | nsh: | (on other people's software, that is) |
| 23:10:17 | maaku: | so if/when there's yet another hard fork, you restrict freimarkets to just nVersion=3 and new format to >=4? |
| 23:10:24 | maaku: | i guess that works pretty well |
| 23:11:18 | maaku: | gmaxwell: tree-structued inputs and outputs, right? |
| 23:13:08 | maaku: | yeah we're working in that direction |
| 23:14:18 | gmaxwell: | yes, I think I would actually structure it with 4 parts "common header", "input identifiers", "signatures", "txouts". and probably make the tree [[txouts],[[inputs],[signatures]]] and maybe put the common header in the position of the last txout or something like that.. Not quite sure. |
| 23:15:55 | maaku: | hrm.. freimarkets adds quite a bit of complexity to that -- you also have sub-transactions, validation scripts, list of tokens, and probably other things... I need to whiteboard this |
| 23:16:41 | killerstorm: | killerstorm has left #bitcoin-wizards |
| 23:29:00 | Luke-Jr: | sipa: it can sit in draft for that long |