00:04:28maaku: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:07maaku: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:30maaku:it's just there's some major outstanding problems, not least of which is the ability for miner collusion to censor votes
00:07:09Luke-Jr:maaku: so, I can move bitcoins from Mainnet to Freimarkets to Inflationchain back to Mainnet?
00:07:47maaku:Luke-Jr: you have to retreat along a line of credit
00:08:11maaku:maybe someone else had already moved coins from mainnet to inflationchain, in which case yes you could
00:08:25Luke-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:35Luke-Jr:so if I pay 1someone, it knows which side chain to send to
00:10:16maaku: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:14Luke-Jr:even with zk-SNARK proofs?
00:11:48maaku:the overhead comes from quieting periods and such
00:12:03maaku:er, yeah also space overhead which zk-SNARK would help with
00:12:19maaku:but I was thinking about just how long it would take (2-3 days)
00:12:44Luke-Jr:maaku: depends on how it's setup, I guess
00:12:49maaku: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:00Luke-Jr:if you can avoid the quieting period (special merged-mining setup), it could work
00:13:00maaku:*should not think
00:13:25maaku:maybe the coins of type X on othernet are actually "coins from mainnet"
00:13:35maaku:but from the side-chain's perspective they'd be different assets :\
00:14:30maaku: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:37maaku:...they'd look on A like "coins from C"
00:14:48maaku:not native host currency
00:14:59maaku:you'd have to fully unwind the peg to get native host currency
00:15:04maaku:kinda messy :\
00:15:47maaku: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:49justanot1eruser: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:29maaku:justanot1eruser: which pubkey/txout gets to choose the next block depends on the last block, which includes your signature
00:16:35andytoshi:justanot1eruser: it doesn't go into depth because the details of "PoS consensus" schemes vary
00:16:39maaku:so grind signatures until you find one that let's you choose the next block
00:16:41maaku:and repeat
00:16:58justanot1eruser:maaku: well grinding signatures also involves having coins associated with that sig
00:17:36maaku: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:39justanot1eruser:So what, you just send to sig X in block Y and keep changing sig X until you win block Y+100?
00:17:47justanot1eruser:oh okay
00:17:52gmaxwell:justanot1eruser: not necessarily.
00:19:02justanot1eruser:andytoshi: is that page static?
00:19:22BCB:is Andreas M. Antonopoulos a core dev?
00:19:23andytoshi:justanot1eruser: the pdf? yeah, i've just updated it a dozen times today :P
00:19:28andytoshi:BCB: definitely not
00:19:39BCB:Why is he writing "Mastering Bitcoin" for 0'Reily
00:19:42justanot1eruser:andytoshi: can I cite it in ,,(bc,wiki proof of stake)?
00:19:53andytoshi:justanot1eruser: yup, the URL won't ever change
00:20:00gmaxwell:BCB: I don't believe he's developed any Bitcoin software that I'm aware of.
00:20:01maaku:BCB: don't have to be a core dev to write a book
00:20:20BCB:so it's not a technical book?
00:20:33maaku:BCB: i don't think anyone here has read it
00:20:45maaku:but the Mastering series is usually technical
00:20:51BCB:maaku: I don't think its out yet. Just the cover art
00:21:04BCB:just curious. I've never seen him here or the dev channel
00:21:09maaku:BCB: that's rather my point. we have as much to go on as you
00:21:35BCB:gmaxwell: but he has started 3 bitcoin businesses
00:21:45Luke-Jr:BCB: but he's never been involved in development afaik
00:22:12gmaxwell:Does trying to drive me out and demanding that I be "fired" count as involved in development? :P
00:22:23BCB:Luke-Jr: I guess you don't need to be involved in developement to master bitcoin
00:22:35BCB:I thought Peter Todd was the bitcoin master
00:22:46BCB:or Master of bitcoin
00:23:04Luke-Jr:gmaxwell: no? :P
00:23:20antephialtic:BCB: can you take this back to #bitcoin
00:23:25Luke-Jr:gmaxwell: maybe claiming malleability is a DDoS attack is. :P
00:23:31BCB:antephialtic: ok
00:24:39jcorgan:does AA have any commits at all in the repo?
00:24:57Luke-Jr:jcorgan: I don't then he's even written a suggestion for it
00:25:30jcorgan:just remembering something he said in passing, before I learned of the history
00:25:38jcorgan:Andreas Antonopoulos
00:26:11jcorgan:"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:19gmaxwell:Preety sure no. (As I said, I don't think I've seen any bitcoin software development at all)
00:26:45jcorgan:sorry, back to #bitcoin
00:26:46sipa:i hadn't heard that name until recently
00:27:36kanzure: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:36sipa:ah, the good old bitcoin-is-a-hammer-and-everything-looks-like-nails syndrome
00:28:49gmaxwell:yea. hm! point.
00:28:49kanzure:"well clearly the network participants would find value in a proof-of-work blockchain, so therefore it's ..."
00:29:17kanzure: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:41gmaxwell: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:04sipa:well centralized blockchaims are meaningful, just don't have the PoW
00:30:21kanzure:what is the meaning of a "centralized blockchain" anyway :)
00:30:26sipa:the only reason PoW is necessarycin public chaimsmis to rate limit the production of blocks
00:30:27kanzure:is that just a table in a database with transactions?
00:30:34gmaxwell: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:48sipa:kanzure: no, it's a chain of blocks, but prodiced by a single party
00:31:20sipa:instead of PoW, they sign the blocks
00:31:27maaku: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:51kanzure: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:12maaku:kanzure: there are perfectly good reasons to do just that
00:32:15kanzure:maaku: when i hear blockchain i think specifically "a chain of blocks based on mining each block with some coinbase tx header"
00:32:35kanzure:maaku: it's possible that my definition is wrong.
00:32:42sipa:on this channel, that is an unnecessarily specific definition :)
00:32:47kanzure:sipa: okay, yeah, just sign the blocks- sure that's a much better strategy
00:33:26maaku:kanzure: I would leave it at just "a chain of blocks, each a list of transactions"
00:33:53kanzure:hm, okay. and these blocks still get propagated through some p2p network?
00:34:12maaku:kanzure: maybe. not relevant
00:35:12andytoshi: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:15gmaxwell:kanzure: well public auditing can be useful, but no need for POW there.
00:35:25andytoshi:centralized POW blockchains i mean
00:35:36maaku:the block chain is really just an audit log for a transactional server that is maintaining an audit log
00:35:43maaku:andytoshi: they don't reduce to pure centralization
00:35:44gmaxwell: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:48maaku:open-transactions is a case in point
00:35:49sipa:with each block having a hash, derived from their transctions, and their parent block's hash
00:35:54phantomcircuit:BCB, there is no commit in master with "anton" in it
00:36:02maaku:the purely centralized server has no control over user balances
00:36:02kanzure:last i heard is that opentransactions hasn't implemented/defined their audit protocol yet (for server-to-server auditing or w/e)
00:36:11BCB:phantomcircuit: we are in #bitcoin
00:36:13kanzure:(i mean, you could audit the receipts you get, but that's not the whole story)
00:37:07maaku:kanzure: OT has been working fine for years..
00:37:14kanzure:i'm not claiming otherwise?
00:37:21maaku:ok i'm not sure what you're claiming
00:37:33kanzure:yamamashi was recruiting me to work on some zeromq auditing protocol for OT
00:37:40kanzure:because it didn't exist yet
00:37:49kanzure:that is roughly my claim heh
00:38:29kanzure: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:44maaku: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:24maaku: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:52maaku: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:59maaku:and everything is auditable
00:40:01kanzure:i think you end up with weird ddos issues though
00:40:21sipa:ddos.. who is the victim?
00:40:31kanzure:centralized party?
00:40:41sipa:they just need to publish
00:41:42sipa:which may not be trivial
00:41:49kanzure:i'm assuming maaku's scenario literally (bitcoin client)
00:42:02sipa:but it's certainly many times easier a problem than ddos protecting bitcoin
00:49:02kanzure:andytoshi: typo, "In order than all actors can reach consensus," under 3
00:50:29petertodd: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:52andytoshi:thx kanzure, fixed on my end, will appear in next push
00:52:11maaku:sometimes trivially easier - just have a dark fiber connection to the auditors
00:53:30phantomcircuit:petertodd, written up somewhere?
00:54:02maaku:sipa: (you're not in #bitcoin-dev) is there a reason CCoins remembers nVersion?
00:57:18andytoshi: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:08petertodd:phantomcircuit: https://s3.amazonaws.com/peter.todd/tree-chains-preliminary.pdf
00:58:49petertodd:andytoshi: it's not honest to talk about asic mfg centralization without also mentioning how highly centralized chip fab facilities are
00:58:51phantomcircuit: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:57andytoshi:petertodd: i did
00:59:08phantomcircuit:(difficulty of namecoin network should never exceed bitcoin difficulty)
00:59:38andytoshi:petertodd: sure, i'll add a blurb about that
00:59:38maaku:phantomcircuit: strictly speaking there is a loss of generality there. the namecoin headers are not necessarily bitcoin headers
00:59:41phantomcircuit:that way you can fairly safely have a merged coin that only some relatively small % of the bitcoin miners are merging
00:59:55phantomcircuit:maaku, shrug
01:00:15maaku:phantomcircuit: agreed, just be clear you're introducing a new validator rule
01:00:22phantomcircuit:oh for sure
01:00:32antephialtic:are all the asics pretty much manufactured by TSMC?
01:00:37antephialtic:seems pretty centralized to me
01:00:52phantomcircuit:antephialtic, yes and no
01:01:02maaku:it also lets you do interesting things like shut down features of the side-chain when difficulty drops <50% bitcoin's
01:01:04phantomcircuit:i believe everybody is using tsmc simply because they're cheaper
01:01:15andytoshi:can someone say something specific (and true) about chip centralization?
01:01:33petertodd: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:12phantomcircuit:petertodd, except producing chips on the N-1 generation seems to be a better move economically
01:02:23phantomcircuit:and im sure the world can support a number of N-1 fabs
01:02:31petertodd: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:47phantomcircuit:(actually more of the network is N-2/N-3 at the moment)
01:03:01antephialtic:petertodd: would a viable open source design help? then anyone with capital could get a batch fabbed themselves
01:03:19andytoshi:antephialtic: the problem is they'll all go to the same (only) fabber
01:03:21petertodd: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:52kanzure:andytoshi: there's some curious channels on freenode where people do homebrew chip fab.. uh, whatever channel azonenberg is hanging out in.
01:04:00petertodd: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:19petertodd:kanzure: yes, homebrew at a tech level equivalent to about 50 years ago
01:04:25andytoshi:kanzure: homebrew chip fab? o.O certainly you can do homebrew pcb layout (and there are a million pcb fabs everywhere)
01:04:31kanzure:yes, but not just pcb
01:04:48petertodd:andytoshi: yeah, pcb mfg is highly decentralized, even if you're talking about the really high-end stuff
01:04:49kanzure:ah, #homecmos
01:04:52andytoshi:probably half this channel used to mfg pcbs at home. i hadn't heard of chip fab
01:05:04kanzure:i pretended to make pcbs, does that count :|
01:05:37antephialtic:petertodd: seems fairly insurmountable for all hash-based PoW then. just a general consequence of economies of scale. centralization is more efficient
01:05:43petertodd: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:00andytoshi:petertodd: i was friends with EE nerds :)
01:06:31andytoshi: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:32gmaxwell:yea, I've made PCBs at home.. those awful radioshack pcb etching kits...
01:07:09petertodd: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:43gmaxwell:petertodd: you see my pro-social drm discussion from last night?
01:07:52kanzure:there might be trust issues with centralized asic fab
01:07:52petertodd:gmaxwell: don't think so?
01:08:08kanzure:e.g., how do you know that all of the chips are correctly masked
01:08:09phantomcircuit:petertodd, yeah i guess that's true
01:08:16kanzure:or there's no backdoors in the weirdass dopants
01:08:47gmaxwell: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:50petertodd: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:54antephialtic: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:07gmaxwell: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:11petertodd:gmaxwell: right, I saw that - equally the same tech can be used by governments to regulate mining
01:09:26gmaxwell:petertodd: it can, but we couldn't stop that so better to use it for positive uses.
01:09:26kanzure:stealthy dopant-level hardware trojans https://people.umass.edu/gbecker/BeckerChes13.pdf
01:09:44gmaxwell:kanzure: not sure how thats really relevant to mining however. :)
01:10:02phantomcircuit:gmaxwell, nobody doing cloud hashing wants 1:1 with actual hw
01:10:06kanzure:i was implying trust issues with your giant centralized asic fab
01:10:12phantomcircuit:you should hear people complaining about hosted ct hw
01:10:19phantomcircuit:looking at 15 minute averages flipping a shit
01:10:31gmaxwell:phantomcircuit: sure, no reason this has to actually force 1:1. :)
01:10:52gmaxwell:phantomcircuit: also control of the hardware doesn't need to map 1:1 to ownership.
01:11:00kanzure:(the trust problems would be related to hardware design or tampered designs)
01:11:05petertodd: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:11petertodd:... transactions only become more expensive, rather than completely blocked.
01:11:13phantomcircuit:gmaxwell, oh well yeah in that case you could fix it to the pools address
01:11:20gmaxwell: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:22phantomcircuit:makes it kind of hard to sell in the future though :P
01:11:25gmaxwell:or a pool for example.
01:11:41phantomcircuit:it would have to be a setting that could be changed by a signed message
01:11:49gmaxwell: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:53gmaxwell:phantomcircuit: yep.
01:11:58gmaxwell:mentioned all this last night. :)
01:12:00petertodd: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:28petertodd:gmaxwell: that's a very good economic argument to the DRM re: decapping!
01:13:14gmaxwell:petertodd: yea, I think it could also apply to other tokens which are used for ratelimiting.
01:13:15antephialtic: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:18phantomcircuit:petertodd, fyi heat extraction is actually more efficient on a large scale
01:13:36phantomcircuit:as long as you're not trying to reduce the intake temp to below ambient
01:14:35gmaxwell: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:56petertodd:phantomcircuit: on a small scale you can use the heat for something valuable (for some values of "small")
01:15:05gmaxwell: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:50phantomcircuit:gmaxwell, there's a lot of large scale industrial uses for heat :P
01:15:51gmaxwell: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:16:15antephialtic:new idea: bitcoin stove. asic miner you can fry eggs on
01:16:29phantomcircuit:even the largest mining farm isn't going to be using enough power for cogeneration
01:16:32petertodd:phantomcircuit: even with those industrial uses, you still have significantly more decentalization than otherwise
01:16:33antephialtic:or make ... hash browns
01:17:00gmaxwell: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:08phantomcircuit: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:15petertodd: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:41phantomcircuit:petertodd, i assume that's for hvac heating right?
01:17:48gmaxwell: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:03petertodd:phantomcircuit: maintenance? asics are reliable, and more reliable if they're a step back from maximum possible power density
01:18:17petertodd:gmaxwell: the # of people who are running bitcoin miners on zero-cost power...
01:18:38phantomcircuit:petertodd, er believe me i have better numbers on asic reliability than you do
01:18:43phantomcircuit:they're not anywhere near great
01:18:51phantomcircuit:the actual ic never has an issue
01:18:55gmaxwell: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:58phantomcircuit:psus die all the time
01:18:59antephialtic:crappy asic business idea #2: asics targeted toward college students who get free dormroom electricity
01:19:26phantomcircuit:gmaxwell, iirc the only reliable asics are the avalons
01:19:26gmaxwell:yea, 3/4 of my avalon batch 1 units has lost psus.
01:19:39phantomcircuit:and even then psus die
01:19:47petertodd: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:01gmaxwell: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:21gmaxwell:but I think this is all short term nonsense... once the tech matures it will be very reliable.
01:20:41phantomcircuit:gmaxwell, except there will be constant never ending pressure to reduce prices
01:21:12petertodd: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:21gmaxwell: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:52phantomcircuit:gmaxwell, sure... eventually
01:22:10gmaxwell: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:14phantomcircuit:the bitcoin mining market when it was all cpus was pretty much a perfect market
01:22:23phantomcircuit:when it was gpus it was pretty much a perfect market
01:22:33phantomcircuit:currently it is basically the exact opposite of a perfect market
01:22:36gmaxwell:hm?! were you mining in the gpu times it was a mess.
01:22:38phantomcircuit:someday that will change
01:22:56gmaxwell: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:19phantomcircuit:gmaxwell, sure but that was pure supply/demand
01:23:28gmaxwell:so I dunno about 'perfect market'... it was just screwed up in a totally different way than now. :)
01:23:37phantomcircuit:the barrier to entry was relatively small
01:23:54kanzure:were there any bitcoin-specific gpu manufacturers?
01:24:09petertodd:gmaxwell: yup, it's amazingly hard to get a lot of chips these days sadly
01:24:34gmaxwell: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:02gmaxwell:funny now just recently some gpus and motherboards came out being marketed around 'bitcoin mining'. ..
01:26:43sipa:gmaxwell: shows how long their development cycle is!
01:28:02gmaxwell: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:46kanzure:does nvidia have its own fab?
01:30:16gmaxwell:I think nvidia uses TSMC.
01:31:42phantomcircuit:petertodd, you can buy all the chips you want the hard part is getting the boards made correctly
01:33:46petertodd:phantomcircuit: huh? compared to building the chips getting the boards made is easy
01:33:52phantomcircuit:gmaxwell, nvidia actually made modifications to their latest gpus which makes them do scrypt more efficiently
01:34:09phantomcircuit:petertodd, building the chips is hard, buying them from cointerra/hashfast is easy
01:34:19phantomcircuit:they both have literally pallets of them
01:34:34petertodd:phantomcircuit: well sure, but that's not relevant to -wizards discussions about long-term centralization
01:35:09phantomcircuit:petertodd, long term (4+ years) i suspect people with free power will dominate
01:35:19phantomcircuit:(and/or free power arrangements will disappear)
01:35:28petertodd:gmaxwell: at least that does put to rest conspiracy theories that nvidia and amd were pushing alt-coins :P
01:35:46petertodd:phantomcircuit: I'll bet you that's already a significant factor
01:36:12phantomcircuit:petertodd, uhhhh i dont think so
01:36:38petertodd:phantomcircuit: where significant is (low) double-digits of hashing power, yes I think so
01:36:56phantomcircuit:hmm maybe year
01:37:30phantomcircuit:i signed up for a program that allows you to smooth out your electric bill
01:37:46phantomcircuit:they assess how much they think you'll use over the year and set that as a fixed rate for 6 months
01:38:05LarsLarsen:LarsLarsen has left #bitcoin-wizards
01:38:25phantomcircuit:petertodd, now if only they would install a substation for me :P
01:38:42sipa:phantomcircuit: after which you pay the difference?
01:38:59phantomcircuit:sipa, nope after which they reasses the rate for the remaining 6 months
01:39:10phantomcircuit:except you dont have to pay it if you stop buying power from them
01:39:22petertodd: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:27phantomcircuit:it's a deregulated market, so i dont have to buy power from the former gov monopoly
01:39:34phantomcircuit:it's really a very poorly thought out program
01:40:01petertodd:phantomcircuit: did they do deregulated power distribution as well as production?
01:40:08phantomcircuit:in total there is a lot of excess distribution capacity
01:40:20phantomcircuit:but it tends to be in 100-400kW increments
01:40:32phantomcircuit:most places that have a large power use will have a 500kW transformer
01:41:04petertodd:phantomcircuit: yeah, this was in trinidad actually
01:41:09phantomcircuit: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:16phantomcircuit:it's a very american version of privatization
01:41:30phantomcircuit:petertodd, ah so probably more like 50kW patches :P
01:41:52petertodd: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:26phantomcircuit:petertodd, that sounds like a great idea
01:42:40phantomcircuit:until things start to wear out and you're now doing maintenance on equipment in 100 places
01:42:41petertodd:unique situation too because it sounds like trinidad is heavily subsidizing industrial-usage electricity prices too - 3cents/KW/hr or something insane
01:42:52petertodd:phantomcircuit: trinidad isn't known for its high labor prices :)
01:43:11phantomcircuit:petertodd, finding people who can fix gpu issues isn't cheap anywhere...
01:43:56petertodd:well, they'll find out as the business progresses
01:45:30phantomcircuit:petertodd, it seems like trinidad is using nearly all natural gas
01:45:39phantomcircuit:in which case the subsidy is approximately 50%
01:45:52phantomcircuit:on just the marginal cost of the gas
01:46:13petertodd:50% isn't that crazy of a subsidy at least
01:46:14phantomcircuit:ah i see they produce the gas domestically
01:46:45phantomcircuit: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:24petertodd:well... that can easily lead to them underinvesting in export capacity, LNG is a big market now
01:47:55petertodd:equally they might be better off leaving the gas in the ground to use later
01:48:14phantomcircuit:im sure it has
01:48:39phantomcircuit:petertodd, if they dont extract it im sure some enterprising oil company will figure out how to horizontally drill into it :P
01:49:02petertodd:heh, nah, that stuff is pretty tightly regulated in sane countries these days
01:49:51phantomcircuit:petertodd, offshore rig in international waters doing horizontal drilling is prettty hard to regulate
01:52:33petertodd: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:02phantomcircuit:petertodd, 12 miles
01:53:29phantomcircuit:however i would be surprised if there wasn't a vein going out to sea somewhere
01:53:41phantomcircuit:petertodd, either way
01:53:46phantomcircuit:indirect subsidy
01:53:48petertodd: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:48phantomcircuit:petertodd, the whole worlds carved up into fiefdoms :|
01:55:15petertodd: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:23phantomcircuit:gmaxwell, ps apparently there is an nvidia gpu that litecoin mines as efficiently as a gridseen
01:55:25phantomcircuit:which is weird
01:55:46phantomcircuit:(not including the actual computer of course....)
02:03:42warren:some guy on the forum is threatening to hardfork Bitcoin to X11 and taking the community with him
02:03:45petertodd:http://www.vice.com/en_ca/read/bitcoin-could-revolutionize-voting <- ugh
02:03:53petertodd:warren: lol
02:04:04gmaxwell:to X11?
02:04:19petertodd:aside: shittiest name ever
02:04:30gmaxwell:phantomcircuit: I'm afraid we might be overrunning the channel with mining stuff. :)
02:04:44phantomcircuit:gmaxwell, heh
02:04:57sipa:how about we hardfork bitcoin to Qt instead?
02:05:03phantomcircuit:sipa, lol
02:05:04petertodd:sipa: +1
02:05:06sipa:(note: april first here)
02:05:43warren:("X11" is what some scancoins are calling a "CPU-only" hash that combines 11 hashes together ... that was already implemented on GPU.)
02:05:55gmaxwell: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:28petertodd:gmaxwell: that's a charitable description of the article
02:07:28petertodd: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:27kanzure:paperbot: http://www.tandfonline.com/doi/pdf/10.1080/09528130600552888
02:10:30sipa:kanzure: eh?
02:10:41kanzure:andytoshi asked
02:11:06kanzure:paperbot takes a url and gives you a pdf that you might not otherwise be able to get
02:11:40gmaxwell:paperbot: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4926218
02:11:57gmaxwell:it works
02:12:27gmaxwell:now I can read my own publications.
02:12:46kanzure:paperbot uses https://github.com/kanzure/pdfparanoia
02:12:54kanzure:so if you are feeling paranoid, contributions/code review are appreciated
02:13:07andytoshi:kanzure: cool!
02:29:53adam3us: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:08adam3us: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:28gmaxwell: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:05BCB:anyone know how to return the binary representation (not binary number) of a hexadecimal string in bash?
02:34:27phantomcircuit:gmaxwell, the main problem is you have to move a bunch of logic onto the chips
02:34:28maaku:BCB: try #bash
02:34:42phantomcircuit:which is otherwise unnecessary
02:34:43BCB:maaku, thx
02:34:47gmaxwell:BCB: trivial if you use bc.
02:35:41phantomcircuit:oh ffs there's a dead pixel on this display
02:36:39Luke-Jr:gmaxwell: I wonder how much space the NV memory will take though
02:37:07phantomcircuit:and of course 1 dead pixel doesn't qualify for replacement under warranty
02:37:15Luke-Jr:* Luke-Jr wonders what the difference between a "binary representation" and "binary number" is
02:39:35BCB:Luke-Jr, I've been trying to figure that out myself for 2 days!
02:39:48BCB:Luke-Jr, php does it with hex2bin
02:49:58c0rw1n:c0rw1n is now known as c0rw|sleep
02:52:37BCB:gmaxwell, that worked. thx
02:54:49BCB:gmaxwell, I'm trying to has a block header in bash and I can't seem to get the correct has
03:00:36antephialtic:is there some mechanism by which unspendable outputs (say to 1BitcoinEaterDontSend...) can be pruned by miner agreement?
03:00:46antephialtic:goal is to shrink the size of the UTXO set
03:01:15phantomcircuit:antephialtic, for spends toa public key for which nobody has the private key? no
03:01:23phantomcircuit:since you cant prove that nobody has the private key
03:02:12antephialtic:well, I guess the mechanism required would be some function that allowed miners to take coins from people, so that probably wouldn
03:02:14antephialtic:'t fly
03:02:29antephialtic:I guess its just a little concerning that the utxo set growth is forever unbounded
03:11:25jgarzik: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:09jgarzik:There have already been a few proposals about alternate fee-based incentives, and a couple commits along these lines already
03:12:28antephialtic:in terms of radical changes, could you give outputs an expiration date based on the fee?
03:12:45antephialtic:"expired coins" would return to the pool of coins yet to be mined
03:13:45Luke-Jr:what fee?
03:13:56antephialtic:transaction fee
03:14:01Luke-Jr:do all outputs of a transaction expire at the same time then?
03:14:06Luke-Jr:what if some are spent, but others are not?
03:14:21Luke-Jr:what if MtGox's cold wallet expire?
03:14:22antephialtic:any unspend outputs from the tx expire at the date
03:14:29jgarzik: I don't bother with this line of thinking, as a hard fork majority is unlikely to ever approve coin expiration
03:14:43gmaxwell:hard expiration is almost certantly too much of a economic violation.
03:15:01Luke-Jr:you *could* manually mark outputs you believe are unspendable.. but that's risky.
03:15:28gmaxwell: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:01antephialtic:hmm, it might not be plausible for bitcoin, but it would be interesting in an alt
03:16:18antephialtic:though it would make cold storage management quite tricky
03:16:26gmaxwell: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:35gmaxwell: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:37antephialtic:can you represent the UTXO set in constant space with an accumulator?
03:21:10antephialtic:IE keep an accumulator of the TXids of unspent outputs in memory, keep everything else on disk
03:21:28gmaxwell:adam3us: have a commitment to a utxo set in constant space: a single hash.
03:21:31gmaxwell:er antephialtic
03:21:35gmaxwell:(sorry adam)
03:22:48antephialtic: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:24gmaxwell:antephialtic: the suspend part doesn't require anything new, its the bring it back part that requires a number of new things.
03:23:47antephialtic:is there an email thread, or a time in the logs that I can read about the details?
03:25:52gmaxwell: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:01antephialtic:gmaxwell: thanks!
03:27:05justanot1eruser:Why is Antonopoulos trying to get you "fired"?
03:27:34justanot1eruser:Actually, probably respond in #bitcoin if you want
03:35:18Ademan:who is getting "fired" ?
03:35:40Ademan:wtf, are you discussing in #bitcoin?
03:36:30justanot1eruser:Ademan: nothing of significance
03:40:17Ademan:oh dang that is a loonnnggggg thread
03:40:30Ademan:(bitcoin.org pull request 152 discussion)
03:40:48gmaxwell:and offtopic here.
03:59:43adam3us: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:33:33copumpkin:quick, log into his account
05:35:40phantomcircuit:copumpkin, google it
05:36:42copumpkin:pfft, you think I don't know it by heart? I wear one of those daily to work
06:04:44shesek: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:20shesek:attaching it to the private key, and you'd have to keep a combination of both
06:06:45shesek:freeing the network from storing the transaction themselves
06:06:51shesek:could something like that work?
06:07:29Luke-Jr:been on gmaxwell's alt ideas list for a while :P
06:07:43Luke-Jr:IIRC the problem is the proofs get big to relay
06:08:43shesek:how big do they get?
06:12:53kazcw: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:58kazcw:it seems like it might be possible to use ZK proofs to "condense" a history, though......
06:15:29kazcw:actually probably not
06:25:08maaku:shesek: sounds like TXO commitments?
06:25:15maaku:doesn't need an alt coin
06:25:47maaku:it's where things are headed in bitcoin, eventually
07:18:59petertodd: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:57Luke-Jr:petertodd: you should have waited a few more days to announce
07:32:51petertodd:Luke-Jr: I can assure you today was the right day...
07:33:36Luke-Jr:petertodd: no no, you want to wait a little longer.
07:36:34antephialtic:petertodd: maybe you should start #dogecoin-wizards
07:37:06antephialtic:much SNARKs, such side chain. wow
07:46:30petertodd:antephialtic: IRC chat works best when there's more than one person in the channel... :P
07:48:47Luke-Jr:petertodd: there's 2 people in #dogecoin-wizards; 3 if you join
08:04:19antephialtic: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:29antephialtic:see: http://www.gwern.net/docs/2008-nakamoto
10:27:16warren:petertodd: glad to see mastercoin is improving its credibility
10:27:46hearn:it is?
10:31:03warren:hearn: [21:17:28] http://blog.mastercoin.org/2014/04/01/masterdoge-mastercoin-moving-to-dogecoin/
10:31:55hearn:oh, hah
11:06:46kloeri:[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:01jtimon:we made that joke first: https://github.com/maaku/dogemarket.org
14:40:04jtimon:well, it would actually make sense to deploy such a hardfork on dogecoin
14:41:25jtimon: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:57antephialtic:jtimon: #dogecoin-wizards
14:42:08antephialtic:actual channel :)
14:46:53jtimon:joined, but I'll finish my reasoning here
14:46:53jtimon: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:30petertodd: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:40antephialtic:systems that build on bitcoin's chain also benefit from access to bitcoin's userbase
14:51:02petertodd:antephialtic: very good point
15:06:32jtimon:petertodd any advances on validating fees on the client side with those techniques?
15:08:10petertodd: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:45jtimon: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:38jtimon:petertodd how is that validated "client side"? miners are still validating all transactions with tree-chains, right?
15:10:00jtimon:their subset of transactions I mean
15:10:04petertodd:jtimon: potentially no! it could be implemented as a pure proof-of-publication scheme
15:10:33petertodd: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:10jtimon:I understand what you mean there and again my point is fees always depend on miner validation
15:11:55antephialtic: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:05petertodd: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:18jtimon: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:35petertodd: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:01petertodd:jtimon: no, just timestamping is *not* enough because timestamping doesn't prove anythig about the lack of double spends
15:13:09jtimon:"they only need to validate the ones they accept" correction s/only/at least
15:14:07jtimon:yes, sorry, "proof of publication timestamper"
15:14:13petertodd: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:40petertodd:jtimon: yup, speaking of, proof-of-publication doesn't necessarily need to mean timestamping
15:15:02jtimon:I know
15:15:39petertodd:jtimon: good, it'll be on the exam when I get that professorship :P
15:16:15jtimon:ok, so I guess my point is that since miners can ideally receive any asset
15:17:42petertodd:... ?
15:17:55jtimon: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:22jtimon:the rules for asset issuance and transfer must be understood by the miners
15:18:54jtimon:so what's the point of miners not knowing them like in mastercoin?
15:19:02petertodd:flexibility and censorship resistance
15:19:46petertodd: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:25petertodd: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:33petertodd: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:43jtimon:there's other "last hardforks" that would give you the same "everything is a soft-fork" property
15:23:11jtimon:I'm still trying to undesrtand the censorship part
15:23:22petertodd:jtimon: indeed, with respect to some types of decentralized finance applications mastercoin is that "last hardfork" :P
15:24:31jtimon:mastercoin is not a hardfork and neither is "last" unless you're happy with its current efficiency properties
15:24:51maaku:i think "last" here has some broader meaning
15:25:00maaku:mastercoin doesn't do *everything*
15:25:24petertodd: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:52petertodd:maaku: yeah, by "last" I was a) only half-serious, b) really referring to economics/market share
15:27:11jtimon:ok, I see, couldn't you make this more efficient by explicitly defining those channels on the protocol rules?
15:27:43petertodd:depends on what you mean by efficient
15:28:33petertodd: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:29petertodd: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:11petertodd:jtimon: "Store hashes, or a hash root, and soft-fork that blocks are only
15:30:14petertodd:accepted if (a) the data tree is provided, or (b) sufficient work is
15:30:16petertodd:built on it and/or sufficient time has passed"
15:30:27petertodd:jtimon: ^ you're really close to the answere to my 25mBTC challenge...
15:31:40maaku:petertodd: UTXO expiration nullifies many use cases
15:31:58maaku:how do I know a transaction was spent vs expired?
15:33:12petertodd:maaku: age is an obvious way
15:33:55jtimon:petertodd do you have a link with the post including the question? (that thread is big)
15:34:36petertodd:jtimon: https://bitcointalk.org/index.php?topic=395761.msg5985389#msg5985389
16:04:01jtimon:sorry, I don't think I understand the question
16:13:49wallet42:wallet42 is now known as Guest33965
16:13:49wallet421:wallet421 is now known as wallet42
16:28:10BCB:has anyone confirmed the coinbase dump?
16:40:33BCB:nsh there is a "alleged" email dump of coinbase user on pastebin
16:41:04nsh:sounds stupid :)
16:41:57nsh:* nsh reads https://news.ycombinator.com/item?id=7507493 " Hacker Newsnew | comments | ask | jobs | submit login
16:41:57nsh:Coinbase user emails and full names leaked. Bug was dismissed (pastebin.com)"
17:08:05sipa:can we _please_ use coinbase.com when referring to the company?
17:08:09sipa:also, #bitcoin
17:24:47nsh:* nsh nods
17:34:15austinhill:sipa: Check slack for jwilkins's comments on coinbase.com vulnerability
18:17:05super3:tacotime, you there?
18:29:09mr_burde_:mr_burde_ is now known as mr_burdell
19:12:27tacotime:super3, yo, sorry, was out
19:13:31tacotime:super3, you can use ecdh to share a stream/block cipher key and then encrypt data between two peers by that route.
19:13:51tacotime:but you can't use ecdsa private/public keys to directly encrypt a la rsa.
19:14:02tacotime:check out bitmessage's implementation.
19:14:38super3:hmmm, ok that complicates things, but it makes sense
19:20:50gmaxwell:^ please go comment on that proposal. :)
19:26:11tacotime:~2270 AD will be a good time for SHA256d miners.
19:31:29tacotime:Thanks sipa, I lol'd a couple times. X)
19:44:36midnightmagic:* 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:39gmaxwell:* gmaxwell wonders if someone will says that this is an obvious example of why PPC should have been a supported platform.
19:46:54amiller:hahaha that's so cool
19:46:58kazcw:I think #bitcoin is taking it seriously
19:47:04amiller:i convinced myself of it with this codepad: http://codepad.org/wWuVk4Zm
19:47:33gmaxwell:amiller: your codepad is obviously not running on PPC. :P
19:48:30maaku:amiller: well, it is serious. but that doesn't mean we can't have fun in the process :)
19:48:51midnightmagic:kazcw: because as-written it appears it will happen. :)
19:49:06gmaxwell: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:27gmaxwell:the compiler is free to do whatever it wants here.
19:49:30Luke-Jr:gmaxwell: LE MIPS?
19:49:47gmaxwell:Luke-Jr: go test on one? I'd imagine mips would also do the fast thing.
19:50:03Luke-Jr:not sure my MIPS is LE. LE is weird.
19:50:04gmaxwell:but current compilers seem to just do what the underlying arch's shift instruction does.
19:50:15midnightmagic:hey i have a mips laptop. ah crap it's at home.
19:51:18Luke-Jr:midnightmagic: LE?
19:51:33midnightmagic:i don't know, it's one of those loongson lemote thingies.
19:51:42Luke-Jr:I doubt it's LE. MIPS is usually BE.
19:51:59midnightmagic:(sans-aluminum since that wasn't available at the time i ordered it)
19:52:50gmaxwell:LE MIPS is even more rare than ARM running in BE mode these days.
19:52:51midnightmagic:http://en.wikipedia.org/wiki/Loongson says 2e and 2f are both little-endian
19:53:06gmaxwell:hm interesting!
19:53:50midnightmagic:yep I think it's little-endian mips.
20:01:43Luke-Jr:maybe because Loongson targets x86 emulation
20:03:28midnightmagic:you mean like how itanium can operate in big- or little-endian modes?
20:06:08gmaxwell:midnightmagic: ppc and arm can do that too. But I think the mips ones usually aren't runtime selectable.
20:06:56midnightmagic:huh. i thought itanium was boot-time selectable.
20:21:00amiller:i think my favorite part is "42 half-million"
20:23:48sipa:amiller: you ain't seen nothing yet :p
20:24:01amiller:what, there's more?
20:26:50Luke-Jr:amiller: https://gist.github.com/luke-jr/9920788
20:53:22gmaxwell:lol: http://btcplex.com/block/0000000000004c78956f8643262f3622acf22486b120421f893c0553702ba7b5
20:54:49sipa:that's the missed satoshi subsidy?
20:54:54gmaxwell:(see the first transaction: Generation: 50 BTC + 184467440737.09552002 total fees )
20:55:24sipa:uint64_t ftw
21:45:48jrmithdobbs:and functions surrounded by () behave (exactly?) as infxl 0 functions
21:55:23[Tristan]:[Tristan] is now known as Guest86019
21:58:03maaku:that's a lot of fees
22:03:54gmaxwell:I added a link to BIP42 on hacker news.
22:14:15phantomcircuit:playing with fire
22:15:10phantomcircuit:so many people wont get the joke
22:15:26gmaxwell:Thats actually okay.
22:15:51gmaxwell:I think it's good for the community that sometimes crazy shit people dont understand shows up... helps people be skeptical readers.
22:16:03gmaxwell:In this case it's actually completely serious, though written about in a funny way.
22:16:17gmaxwell:Currently the bitcoin software as it is actually running has an infinite supply of coins.
22:16:49phantomcircuit:something tells me we wont be using bitcoin in ~1000 years
22:17:01gmaxwell:sure sure details details.
22:17:23gmaxwell:Are you not a fan of the Clock of the Long Now?
22:17:26sipa:phantomcircuit: heresy!
22:18:36sipa:(i always found that work to seem to sound similar to "hearsay")
22:20:16gmaxwell:petertodd: I bet your python implementation is also inconsistent with the reference when nHeight is negative too!
22:20:55maaku:sipa: i'm a native speaker and honestly I didn't realize until now they were different words
22:21:37gmaxwell:really? Heresay has the advantage of being spelled like what it means.
22:22:42sipa:gmaxwell: heresay or hearsay?
22:23:30gmaxwell:hahah okay, I give up.
22:24:21nsh:* nsh smiles
22:26:45jtimon: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:20Luke-Jr:gmaxwell: I will offer a satoshi!
22:27:54gmaxwell:too late.
22:28:55sipa: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:06sipa:i assumed it would be obvious without it too, but maybe not :)
22:29:24Luke-Jr:well, I think it's fair to say we're all at least decent at PHP
22:30:17sipa:i wrote a (subset of) LaTeX parser in PHP
22:30:25sipa:that's the _only_ thing I ever wrote in it...
22:30:56sipa:well, almost
22:33:00Luke-Jr:ljrbot has a game written in PHP
22:33:08Luke-Jr:(yes, PHP within a Python bot..)
23:01:27sipa:dang, should have made the switch in 2248
23:02:05sipa:that'd make it xkcd 1344 compatible
23:06:38maaku:any thoughts on a safe, transitional way to change the transaction serialization format (in a hard-fork)?
23:07:33nsh:wasn't there some kind of way to do block-depth margin of overlapping standardness?
23:07:53gmaxwell: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:53maaku: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:14nsh:* nsh nods
23:08:27maaku:ok, but that would be what - determine format based on nVersion?
23:08:32gmaxwell:if you were to change that you should really also change the hashing of transactions to make them tree structured.
23:08:40gmaxwell:maaku: yea, I suppose you would.
23:09:36nsh:(the might be some new attacks that would become possible due to the temporary serialization format malleability too)
23:09:41maaku:so (this is context of freicoin/freimarkets) nVersion=1 means bitcoin, nVersion=2 has refheight feild (freicoin), nVersion>=3 is freimarkets formatted
23:09:46nsh:(on other people's software, that is)
23:10:17maaku:so if/when there's yet another hard fork, you restrict freimarkets to just nVersion=3 and new format to >=4?
23:10:24maaku:i guess that works pretty well
23:11:18maaku:gmaxwell: tree-structued inputs and outputs, right?
23:13:08maaku:yeah we're working in that direction
23:14:18gmaxwell: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:55maaku: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:41killerstorm:killerstorm has left #bitcoin-wizards
23:29:00Luke-Jr:sipa: it can sit in draft for that long