00:46:26	andytoshi:	BlueMatt: you are "everything that is wrong with cryptos" :)
01:03:52	gmaxwell:	* gmaxwell claws his eyes out at "cryptos"
01:06:00	gmaxwell:	if someone has ethical concerns on BM's tool, BM could just add a warning that says "poor selection of the parameters here can result in a trivially insecure coin, the site makes no promises that the settings are good"
01:06:47	gmaxwell:	"make heavily demanded features are believed by experts in the Bitcoin world to be terrible for security in subtle or even vulgar ways, sometimes thats why Bitcoin doesn't do them. Buyer Beware."
01:06:50	andytoshi:	the ethical concern from earlier is that i suggested 'secretly' adding wizarding experiments
01:07:19	gmaxwell:	oh well I don't think there is anything secret needed. You can just add them and make people _pay_ for them.
01:07:37	sipa:	indeed, just make them extra features
01:08:01	gmaxwell:	or make turning them off an extra (pay for) feature if you like.
01:09:41	Luke-Jr:	maybe BlueMatt would donate the site to -wizards ;)
01:10:03	Luke-Jr:	it'd be neat to make it list all mergable pull requests as options..
01:11:14	Luke-Jr:	perhaps unmergable ones too, and give a warning about "There is an additional charge for this feature which cannot be calculated automatically. You will receive a quote within 3 business days if you choose it."
01:11:16	Luke-Jr:	:D
01:11:30	Luke-Jr:	and then let anyone competent bid on it
01:11:41	sipa:	it probably needs some deterministic seed
01:11:55	sipa:	so that new versions of existing coins created with it can be generated
01:12:00	sipa:	if the upstream source is updated
01:12:09	sipa:	(which determines magic bytes etc)
01:13:03	Luke-Jr:	sipa: that would break the merging features a bit
01:14:16	Luke-Jr:	"I have a magic node which keeps track of peers for each coin and forwards them on in addr messages, but if no one else is running a node, youre sol."
01:14:20	Luke-Jr:	wow, that probably took some effort
01:15:17	gmaxwell:	nah, if you get an inbound connection you're silent, the connector sends the network version
01:15:37	gmaxwell:	so then its just like one of those 100 line python "node" implenmentations with a dict of addresses per network.
01:16:20	Luke-Jr:	<.<
01:24:00	Luke-Jr:	wow, BlueMatt's thing has made over $500 already :P
01:25:21	warren:	it has no disclaimer of warranty
01:27:31	Luke-Jr:	I suppose sipa's auto-upgrader could bill you
01:28:08	sipa:	why what?
01:28:11	sipa:	my what?
01:32:00	Luke-Jr:	sipa: the idea to let people come back for upgraded builds of the same coin
01:32:36	Luke-Jr:	sipa: my objection was that it would break merges - but it could work if you get billed for any conflicts ;)
01:33:06	warren:	Luke-Jr: why do you care about the maintainability of scam coins?
01:33:29	sipa:	well, my concern about them is pretty much irrelevant, as i have no interest in using the tool
01:33:50	sipa:	but if the users were serious to any extent about the coins they are creating, they should demand it
01:33:51	Luke-Jr:	warren: I'm just thinking financing development and testing this way, ignoring how the end products are used ;)
01:34:38	warren:	Luke-Jr: I think this current tool renames everything to make merges impossible
01:40:08	Luke-Jr:	warren: maybe.
01:40:26	Luke-Jr:	warren: I was thinking more of merging before s&r
01:40:53	Luke-Jr:	ie, rebuild the scamcoin from scratch
01:41:24	warren:	Luke-Jr: you would have done well as a litecoin dev =)
01:42:06	Luke-Jr:	well, arguably litecoin *is* using my code.. :P
03:14:25	Luke-Jr:	too bad Script is neutered
03:14:39	Luke-Jr:	could make a transaction-fee-for-only-future-blocks..
03:14:50	Luke-Jr:	sPK: "" OP_SWAP OP_CAT OP_HASH256 OP_DEPTH 1 OP_SUBTRACT OP_FOR OP_CAT OP_HASH256 OP_ENDFOR OP_SWAP OP_CAT OP_CAT OP_HASH256 OP_LE
03:14:59	Luke-Jr:	sS: "" "" ""
03:15:12	Luke-Jr:	petertodd: ^
03:16:39	gmaxwell:	looping in scrypt is yuck though. e.g. while(true)OP_HASH256.
03:17:02	gmaxwell:	if you just want to burn coins OP_RETURN them, poof gone and trivially provable they were burned.
03:25:57	Luke-Jr:	but then they're "too" burned :P
03:26:07	Luke-Jr:	OP_FOR isn't the same as OP_WHILE :p
03:26:18	Luke-Jr:	OP_FOR would inherently be non-forever
03:38:13	andytoshi:	in an alt where fees were tied to runtime, you could do cool things like this
03:38:31	andytoshi:	it seems to me that even "non-forever" is not sufficient to prevent DoS attacks
03:39:00	andytoshi:	if you can loop for tens of thousands of iterations, that can cause bad problems .. if you can nest loops, etc
03:39:07	andytoshi:	otoh, if you -can't- do those things then that sucks
03:43:58	gmaxwell:	Luke-Jr: yea, 4 billion SHA256 ... big improvement over forever.
03:44:10	Luke-Jr:	[03:38:09] in an alt where fees were tied to runtime, you could do cool things like this <-- there is no reason this would be an alt
03:44:20	gmaxwell:	tying things to runtime is really really likely to cause hardforking bugs.
03:44:30	Luke-Jr:	gmaxwell: only if they are hard rules
03:44:33	gmaxwell:	since you need a precise instruction counter.
03:44:42	gmaxwell:	Luke-Jr: they must, because non-miners must evaluate script too
03:45:13	gmaxwell:	otherwise you have mining pools incentivized to put in fast hardware script execution engines and no one else can keep up validating the coin
03:45:35	Luke-Jr:	gmaxwell: I'm okay with letting miners decide on the upper runtime limits, within reason.
03:47:11	gmaxwell:	within reason is the problem there == hardforks. :P
03:48:48	Luke-Jr:	nah, within reason is vague enough to use opcode counters
03:48:49	andytoshi:	gmaxwell: sorry, i meant 'instruction count' which could be defined very precisely in a forth-like script
03:50:32	gmaxwell:	andytoshi: yes, it can be. What OP_CHECKMULTISIG does is also very precisely defined and that didn't stop several alt implementers from getting it wrong.
03:50:50	andytoshi:	ah, this is true
03:51:53	gmaxwell:	this may ultimately be an argument for replacing script with verficiation for some proof of execution, since it may actually be easier to get it right.
03:52:13	gmaxwell:	or at least alt implementors are less likely to try to reinvent crypto constructs.
03:53:27	gmaxwell:	it's nuts. SCRIPT is actually a public key signature system itself. People writing their own ECDSA code as a my-first-project would be super frowned on, and yet they re-write script. though somewhat annoying in that at least there are libraries for ecdsa.
03:55:43	andytoshi:	i think i will start pushing the meme on #bitcoin that cryptography is serious business and that only morons try to roll their own or work with it without understanding it
03:55:56	andytoshi:	...which appeared to be common knowledge until altcoins became a thing
03:55:56	gmaxwell:	Okay, I think I'm going to give up on bitcoin, jesus christ: http://blockchain-link.com/#future
03:57:15	andytoshi:	gmaxwell: agreed on "this is an argument for snarks", aside from the usual novel crypto warnings it seems to me they'd be way easier from a blockchain engineering perspective
03:57:49	andytoshi:	and i'd be really jacked to see a turing complete script (and maybe one which could do things like read the past blockchain)
03:58:42	andytoshi:	gmaxwell: where did you get that URL?
03:59:06	gmaxwell:	#bitcoin
03:59:13	gmaxwell:	oh thank god those are fethercoin amounts
03:59:24	gmaxwell:	I was thinking this person had recieved over 600 btc in donations
03:59:25	andytoshi:	ahhh wtf
03:59:48	gmaxwell:	I think if that was true I would probably just never do anything with bitcoin again. I'm getting seriously depressed about all the money flowing into fucking things up.
04:00:37	gmaxwell:	I am not a very coin operated guy myself, but the funds flowing specifically to _bad_ things is especially demotivating.
04:01:30	andytoshi:	gmaxwell: as personal advice i'd say you do way too much to correct misinformation and engage with these idiots ... but otoh it does a massive amount of good for the bitcoin communitiy, so i dunno what to say
04:02:20	gmaxwell:	well I certantly know that I have the option of ignoring everything I don't like.
04:02:42	gmaxwell:	And I actually consciously ignore enormous swaths of stuff (though I know it doesn't seem like it)
04:03:32	andytoshi:	maybe i will write a "why alts are retarded" FAQ which discusses cryptography and the horrors of using it blindly or stupidly ... and reminding people that crypcocurrencies are a novel cryptographic concept and these lessons apply -even more so- because of that, and then -even more so- because there is monetary value involved
04:04:23	andytoshi:	because it appears that people think this shit is magic, people talk as though "cryptos" are a thing , a collection of magical systems that are all on equal footing
04:05:34	gmaxwell:	you can probably pull up some of the old sci.crypt faqs
04:05:44	gmaxwell:	things like "anyone can make a cryptosystem that they themselves can't break"
04:06:16	gmaxwell:	it all applies to the _entire_ altcoin. The whole thing— minus some frills around the edges, but everything that actually makes it an alt— is a cryptosystem
04:06:37	gmaxwell:	e.g. the decision to go with 10 minutes vs 5 minute block times is a cryptographic decision, and one that isn't very completely understood!
04:06:48	gmaxwell:	(though more understood than some other things)
04:07:01	andytoshi:	good call on sci.crypt -- i was a young child when it crossed into mostly-insanity so i forgot all about it :P
04:07:30	andytoshi:	i'll hack something up this week and post it here, maybe just github the latex and give you all push access
04:07:33	gmaxwell:	it was pretty much always insanity, but the boundary of sane and not is what produced some of the arguments you need.
04:07:55	andytoshi:	or rather, git.wpsoftware.net it ... i don't think github likes direct pushing
04:08:33	gmaxwell:	I think making a concrete argument the whole of the interior rules are a cryptosystem is important. It's a bit sad that OP_CAT is off and that we don't havea OP_PUSH_TXN_HASH as you could implement lamport signatures in script with that.
04:09:30	gmaxwell:	bluematt's think will help, in a couple of months you'll be able to claim that many alts are created by people who can't use a compiler.
04:09:48	gmaxwell:	so there will be no illusion that there is some latent stock of cryptographic genuises putting out these things.
04:09:50	andytoshi:	yeah, that's excellent
04:11:11	andytoshi:	i might even describe this as a "social experiment which Matt Corallo proposed to the bitcoin developers to illustrate this point"
04:11:30	andytoshi:	because people on the btct thread seem to think he is some random guy..
04:12:25	andytoshi:	though i really don't want to give the impression that the bitcoin developers are holy people directing the currency somehow
04:12:42	andytoshi:	because that kind of thinking causes alts with convergence issues
04:12:45	Luke-Jr:	Matt Corallo is a bitcoin developer O.o
04:12:52	gmaxwell:	well, also, while not a secret emphasizing that the tool is intentionally cynical may lower matts income from it.
04:13:18	andytoshi:	Luke-Jr: i know, i guess i phrased that badly
04:13:23	gmaxwell:	andytoshi: and fwiw, I do think I was the first person to suggest it. :P (though perhaps matt had been thinking about it independantly)
04:13:44	andytoshi:	oh, sorry :}
04:13:49	gmaxwell:	(I spent a while in #bitcoin-mining trying to convince Luke-Jr and/or petertodd to do it. (luke has the nice ability to tie in merged mining))
04:13:57	gmaxwell:	like ... N months ago.
04:14:24	andytoshi:	my intention in saying that was exactly to claim it is cynical .. but you are right that i'd be just taking money from Matt
04:15:47	gmaxwell:	well I think its cyncism is not secret, but emphasizing it now might reduce his income from it, and given the two choices I'd rather have the latter.
04:16:01	gmaxwell:	the cynical aspect of it is super obvious (it even was one of the first comments in the altcoin thread about it)
04:16:40	andytoshi:	okay, that's good then .. one of my concerns was that having Matt involved publically might make alts seem legitimate
04:19:27	grau:	I assume you talk about coingen.io: I think it greatly damages alts, showing how pointless they are, unless there is a network of people supporting one.
04:22:08	gmaxwell:	grau: thats the idea.
04:22:37	gmaxwell:	Were you in the #bitcoin-mining discussion where it was proposed eons ago? for some reason I had the impresion you were. :P
04:23:08	grau:	I never joined #bitcoin-mining
04:23:13	gmaxwell:	hm! okay!
04:23:28	gmaxwell:	well as I just said: super obvious.
04:23:31	gmaxwell:	:P
04:23:56	gmaxwell:	Part of it is a network effect thing, dillution hurts smaller coins more than bigger ones.
04:24:07	grau:	but is it good in your opinion, or should we rather embrace alts?
04:24:48	gmaxwell:	I think it's good to dillute "worthless" alts. I don't think coingen.io does anything harmful at all to ones that have a solid reason for existing (which currently is .. not very many)
04:26:14	gmaxwell:	it highlights the worthlessness of things that are clearly worthless, and somewhat undermines the efforts of people who use the internet version of boilerroom techniques to promote worthless things trying to get a quick buck.
04:26:40	justanotheruser:	I think altcoins are an interesting phenomenon. Normally people wouldn't flock to a new version of software with a new logo and a few variables changed. For example, if I made altfirefox where the scroll bar was half the size and the logo was a dog, it wouldn't get any downloads let alone a thread with hundreds of replies.
04:26:44	gmaxwell:	though I still have no real answer to altcoins which have good _sounding_ reasons to exist but which are without substance when you pull back the technical covers.
04:27:13	gmaxwell:	justanotheruser: yea, you're not promoting the altfirefox with an investment ... scheme.
04:27:50	warren:	protoshares!
04:27:53	justanotheruser:	exactly, people buy into a purposeless piece of software because they think they will make money off it
04:28:26	gmaxwell:	right and coingen.io probably dashes those hopes for "YAAC" (yet another altcoin) though not for something with an elaborate vaporware story.
04:28:51	gmaxwell:	obviously then next thing to do is a coingen2.io that makes whitepapers for non-existing altcoins using a hidden-markov-model
04:29:02	grau:	those get rich schemes depend on being able to convert to BTC (since direct to fiat is absent) and this keeps me wondering why someone is selling BTC for some alt.
04:29:10	andytoshi:	gmaxwell: my hope is that i can write a faq which talks about smart-sounding alts
04:29:50	justanotheruser:	andytoshi: You should. There are only a handful you would have to cover
04:29:52	grau:	assuming there is no get rich, then motivation might really be the need for cheap tokens
04:29:58	andytoshi:	e.g. litecrypt and it's goofy scrypt implementation, feathercoin and its super fast alts
04:30:04	andytoshi:	blocks*
04:30:16	grau:	there could be applications for near worthless tokesns e.g. for games.
04:30:19	justanotheruser:	grau: if you want a cheap token, you should buy uBTC
04:30:40	andytoshi:	realsolid's difficulty algo
04:30:43	gmaxwell:	grau: my guesses include things like (1) people with large amounts of illicitly gained btc which can't easily be spent other ways, (2) exchanges buying them with fake BTC to pump prices for their own profits, (3) ... just people trying to repeat bitcoins rise in value a second time
04:30:47	justanotheruser:	I suppose you are talking about small transaction fees though
04:31:09	gmaxwell:	grau: sure, but we've got plenty of altcoins already, we don't need public exchanges for cheap tokens either.
04:31:26	andytoshi:	for that matter, solidcoin's seemingly solid reputation, and the character who turned out to be behind it
04:32:23	justanotheruser:	Is there going to be a point where most of the transactions are off-chain? I mean if we keep the block size at 1mb, people will eventually be competing with higher transaction fees to get their transaction into a block.
04:34:19	andytoshi:	my feeling is that some sort of {snark+agressive pruning}coin will be released before bitcoin is seriously strained by the tx load
04:34:20	petertodd:	justanotheruser: nah, hopefully we'll just uncap the blocksize and gmaxwell and I will get the smug satisfaction of being proven right
04:34:47	petertodd:	andytoshi: snark's don't help with scalability the way I think you think they do
04:35:11	justanotheruser:	petertodd: how do we deal with the massive blockchain and bandwidth?
04:35:20	andytoshi:	petertodd: i'm not suggesting they can be used for pruning, but for quicker transaction validation
04:35:24	grau:	gmaxwell: (4) maybe a also scheme of anonymizing with recourse to BTC
04:35:30	andytoshi:	(and i'm aware that in 2014 even that is not true)
04:35:48	gmaxwell:	andytoshi: they're not quicker than trivial txn today. even the fastest stuff is .. well see that tinyram paper you linked to.
04:36:01	petertodd:	justanotheruser: by sharding the blockchain so that no individual node has to deal with all of it, but that's very tricky
04:36:19	gmaxwell:	But to the extent that they allow binding offchain systems they do improve scaling.
04:36:44	andytoshi:	could petertodd's MMR stuff be implemented in an alt today and enable massive block pruning?
04:37:02	petertodd:	andytoshi: yes, but not in the way you think so :P
04:37:20	justanotheruser:	petertodd: Is that in development at all? Is there anywhere I can read about that?
04:37:22	andytoshi:	petertodd: ok, this time you're right that i believe unjustified things :)
04:37:25	petertodd:	andytoshi: MMR TXO commitments actually make scalability a lot worse
04:37:29	andytoshi:	really?
04:38:04	petertodd:	andytoshi: yes, the bandwidth required to prove txin existence is about an order of magnitude more than what it is now
04:38:08	gmaxwell:	they make the blocks really big, but they allow a bandwidth/storage tradeoff if you can optionally send them when a node already has the data.
04:38:30	BlueMatt:	andytoshi: yea, I love that comment
04:38:35	andytoshi:	i thought with TXO commitments we could get away with only storing the last $small_time of actual blocks
04:38:41	gmaxwell:	bandwidth does tend to be more scarce than storage. though the ratio is kinda hard to reason about
04:38:42	petertodd:	andytoshi: where they can make things better is in conjunction with sharding techniques that allow that much worse bandwidth to be spread out over multiple nodes
04:38:57	BlueMatt:	Luke-Jr: I'm not a "bitcoin developer"?
04:39:03	Luke-Jr:	BlueMatt: you're not?
04:39:05	BlueMatt:	not a core dev sure, but I think everyone here is...
04:39:09	gmaxwell:	andytoshi: you can but you made the blocks much bigger because they're carring around kilobyte proofs per txin instead of 32 byte hashes.
04:39:29	andytoshi:	gmaxwell: ah, i see, that's what i was missing
04:39:36	petertodd:	BlueMatt: heh, people are starting to call even me a core dev, which you have a much better claim to :)
04:39:40	gmaxwell:	of course if you have the txo set you don't need the proof, so it could be made optional.
04:39:44	andytoshi:	i thought this MMR business was basically a smart version of "add a hash of chainstate/ to the blocks"
04:40:16	gmaxwell:	andytoshi: sure but when a tx spends coins committed in that state the tx has to include a proof that its inputs are in it.
04:40:16	andytoshi:	and you'd request a copy of the chainstate dir instead of IBD'ing
04:40:36	andytoshi:	gmaxwell: oh, okay, so my understanding was not wildly far off
04:40:46	gmaxwell:	andytoshi: oh no, that just SPV security for full nodes you're talking about. sort of orthorgonal
04:40:52	petertodd:	andytoshi: that's completely right, but bandwidth, esp. anonymous bandwidth is the importatn thing
04:41:11	petertodd:	andytoshi: also the real importance of chainstate is being able to product compact proofs that rules were violated
04:42:03	gmaxwell:	andytoshi: if the chainstate is commited then you could have a full validating node without even storing the chainstate, but at the cost of txns having to carry chainstate proofs. (just hashtree fragments)
04:42:51	andytoshi:	ok, i see, did not realize that bandwidth would be hit so hard -- i was looking at "download 20gb of old transactions and validate them" as being much more overwhelming
04:43:06	gmaxwell:	and its orthorgonal to if you hot-started or not. If you hotstart without something like a snark proving chainstate faithfulness you reduce full nodes to SPV security— e.g. miners could potentially inflate the coin.
04:43:48	andytoshi:	well, you might keep the last few weeks of actual blocks so that miners would need to outcompute the network for a long time to do that
04:43:59	gmaxwell:	and using a snark to prove a full chainstate fidelity isn't technically feasable yet, I think. though perhaps we're close if you skip the script evaluation.
04:45:07	gmaxwell:	andytoshi: but keep in mind in doing that you change the incentives completely. so the analysis isn't simple. E.g. if non-miner full nodes didn't check the generated amount, would miners just all set their generated coins to 100 and leave them there?
04:45:09	grau:	checkpoints skip script evaluation
04:45:46	gmaxwell:	grau: we're going to remove that in bitcoin-qt almost certantly after headers first, and even there there is a commandline switch to reenable.
04:46:05	gmaxwell:	and miners don't set checkpoints.
04:46:48	andytoshi:	gmaxwell: presumably at all times non-miner full nodes have the past ten days or so of blocks (and they'd be dropping them), so there'd never be a window when people weren't validating the latest blocks
04:46:54	gmaxwell:	Basically the point there is that if miners can get themselves a blank cheque its a very different set of incentives than we currently have.
04:48:07	grau:	I think it will be miner keeping check on each other not user
04:48:27	gmaxwell:	andytoshi: sure, you just have eluria and ghash.io and slush (>>50% of the network) agree to do a 10 day reorg that harms nothing but gives them 10x the coins. Why not? it's tricky. And then why would people keep 10 days? 0 days is enough until the attack actually happens. Let someone _else_ take the cost of preventing the attack.
04:48:32	gmaxwell:	BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Ping timeout: 260 seconds]
04:48:33	grau:	user will move to SPV, even merchants may
04:48:35	gmaxwell:	oops missate there.
04:48:41	andytoshi:	grau: then there's an incentive to conspire/collaborate and this leads to pool centralization
04:49:04	andytoshi:	ah, now i see the incentive problem with what i suggested
04:49:05	gmaxwell:	grau: there are only two or three people in the world required to achieve >50% control of hashrate.
04:49:34	gmaxwell:	(and one of them (the cex.io guy) has physical control of most of his hashrate directly)
04:50:05	andytoshi:	ugh, this is so frustrating, i had this massive blind spot in my analysis of pruning schemes
04:50:14	andytoshi:	if only i could convey that feeling to the alt-chasers..
04:50:50	gmaxwell:	grau: trusting miners is a pretty terrible idea, far worse than trusting the fed— at least the fed has a sea of regulations and public identity regulating its behavior. Miners are anonymousish, fully self selecting, unregulated, etc.
04:50:50	grau:	gmaxwell: assuming 2-3 would and use it to inflate coins. This could be surfaced by anyone and would destroy trust in the currency and that possibility would keep them from doing that.
04:51:05	gmaxwell:	and if you regulate them, the you just undermine the system in a differnet way.
04:51:24	gmaxwell:	Instead they can be regulated _naturally_ by the system how it was designed: but not trusting them any more than the absolute minimum needed.
04:51:31	gmaxwell:	(by having full nodes that impose the rules)
04:51:35	Luke-Jr:	BlueMatt: anyhow, maybe you misread what I said. I said you *are* a bitcoin dev..
04:51:44	BlueMatt:	ahh, ok
04:53:34	grau:	collaborating between miner to change rules is the same dilemma as in "selfish mining", whort term incentives against long
04:54:02	grau:	*short
04:54:31	petertodd:	grau: relying on incentives of a small number of quite-possibly non-rational people is crazy
04:54:49	grau:	if you have an other choice
04:55:10	gmaxwell:	* gmaxwell out
04:55:35	petertodd:	grau: well we do: design crypto-currencies where pools aren't possible, and be ready to deploy them if it becomes an issue (as an example)
04:56:20	Luke-Jr:	petertodd: if pools aren't possible, then you get worse alternatives (hosted mining)
04:56:26	grau:	design a migration policy of welth also if you are that
04:56:47	petertodd:	grau: that's the easy part actually
04:56:54	gmaxwell:	Luke-Jr: hosted mining is made insecure by the same things that break pools (though perhaps no one cares, which was the argument I gave before: easier to break pools than hosted mining)
04:57:08	petertodd:	Luke-Jr: basic physics fortunately encourages decentralization of hashing power
04:57:25	gmaxwell:	oh yea I'm not here
04:57:29	Luke-Jr:	that's why it's better to make decentralised pooling as cheap as possible, cheaper than hosted mining
04:57:56	grau:	petertodd: why that? bigger plants should have better ratios of energy/hash
04:58:25	Luke-Jr:	^ + bulk orders of hardware get better prices
04:59:04	petertodd:	grau: nope, the basic unit of production is the chip + power supply, and for that your economy of scale is making them. otoh your costs to run the hardware has a huge component of getting rid of waste heat, which incentivizes decentralization
04:59:25	petertodd:	grau: e.g. "a bitcoin miner in every water heater"
05:02:02	grau:	petertodd: thereby you would raise production cost of e.g. water heater. Competition in water heater would eliminate that.
05:02:50	petertodd:	grau: if crypto-coin mining has a value, and heating water has a value, then you're cost for doing both at once is less than separating the two activities
05:04:58	grau:	You assume that water-heater mining is profitable to the extent that it ever amortizes the added production cost. That is not given.
05:06:24	petertodd:	grau: my point is if bitcoin mining is profitable, it'll be more profitable if you can use the waste heat for something useful. using waste heat for something useful is easier with more decentralization than less
05:08:51	grau:	There are places where getting rid of heat is not a big issue. I think you engage a bit in wishful thinking. We should rather think hard of how to deal with centralized mining.
05:09:56	petertodd:	grau: yes, and those places are always decentralized! it's just the basic physics of heat: surface area scales by x^2 and volume x^3
05:10:13	grau:	iceland
05:10:24	petertodd:	grau: obviously bitcoin mining will tend towards more northern places, but there's a whole lot of those around
05:11:13	gmaxwell:	21:07 < NomZ> You all will love this one. The dogecoin blockchain split after someone submittted a 500M transaction.
05:11:35	petertodd:	grau: my parents live in a place significantly colder than iceland...
05:12:13	grau:	petertodd: wow, send them some boxes to mine :)
05:13:18	petertodd:	grau: yeah, I've done the math on that, it actually makes quite a lot of sense. furthermore in communities north of them the high cost of electricity is *not* a factor because the electricity generation is all diesel anyway, and diesel's more expensive (slightly) than fuel oil
05:13:29	grau:	gmaxwell: tomorrow you'll have lots of journalists asking if this could happen to BTC
05:15:10	brisque:	grau: not having scrollback to refer to, can you give me a one line summery of what you're referencing?
05:15:18	gmaxwell:	http://www.reddit.com/r/dogecoin/comments/1ufl1e/much_concern_dogecoin_block_chain_has_split/cehm0yw
05:16:34	brisque:	gmaxwell: ouch. I suppose that's what you get when you have inexperienced developers managing a bitcoin clone.
05:16:46	petertodd:	gmaxwell: heh, yeah warren noticed that awhile back
05:17:11	andytoshi:	petertodd, warren: oh? what is special about this 500m tx?
05:17:37	Luke-Jr:	lolwut @ font
05:17:38	petertodd:	andytoshi: it triggers some sanity limits that they recently removed
05:17:39	brisque:	andytoshi: the title of the thread has the details. some clients accept larger amounts in blocks than others.
05:17:41	warren:	andytoshi: competence
05:18:08	brisque:	"Ten days ago, the developers made a change to the Dogecoin client that raised the limit of coins in a block from 500 million to 10 billion. So now some folks are running Dogecoin clients without that change, because they are older, and some folks are running newer clients. In block 42279, a transaction that broke the rule -- containing more than 500 million DOGE -- has prevented these older clients from advancin
05:18:30	warren:	did the pools upgrade?
05:18:43	gmaxwell:	.... wtf they didn't stage the change?!@#
05:18:51	andytoshi:	holy shit, this is so incompetent i can't believe it, even from doge
05:19:02	brisque:	presumably one pool updated, then the big TX made it into a block and the chain forked
05:19:07	gmaxwell:	well we learned nothing then, as we've succesfully made a number of changes that would have been forking if not staged.
05:20:16	brisque:	warren: from looking, there's some on one fork and some on another. presumably anybody on the old client has been left behind and that's the majority at this point.
05:20:21	andytoshi:	it appears they just pushed a forking change in a routine update? what the fuck?
05:20:47	nsh:	my hilarity sense is tingling...
05:20:48	warren:	three forks exist?
05:20:49	warren:	not sure how
05:20:54	warren:	but it's hilarious
05:21:06	nsh:	oldyellercoin....
05:21:17	justanotheruser1:	justanotheruser1 is now known as justanotheruser
05:21:20	brisque:	they might have changed the TX limit previously without making it a staged change.
05:21:23	andytoshi:	well, i'm going to move to #bitcoin..
05:21:48	warren:	andytoshi: that update was to stop a massive dust attack. they had a mintxfee of 0.0001 when coins were very plentiful ... much hilarity
05:22:04	gmaxwell:	andytoshi: yea, it'll keep creating more forks if the non-acceptable-to-all-nodes chain has a majority hashpower.
05:22:28	andytoshi:	oh man, such wow
05:22:30	gmaxwell:	er "acceptable-to-all-nodes"
05:22:32	gmaxwell:	not non-.
05:22:48	gmaxwell:	if the non-acceptable has a majority then you'll get exactly two.
05:23:00	warren:	how do I format a mocking doge message to post in litecoin dev news
05:23:05	petertodd:	warren: heh, I wish I had the time to add really easy multi-currency support to python-bitcoinlib to make writing attacks for non-btc crypto-coins easier...
05:23:07	grau:	gmaxwell: there could be a lesson for us in this. Let's see how the worst case unwinds.
05:23:08	gmaxwell:	if the acceptable to a majority has a majority you'll get constant reorgs and more forks but most will be short.
05:23:24	Luke-Jr:	gmaxwell: I thought you left? :P
05:23:48	warren:	petertodd: you're sitting on a lot of unearned funding...
05:23:49	gmaxwell:	grau: things like this have happened with smaller alts before, they just release another version and tell everyone to hurry up and upgrade. And because there is no major economic activity no one cares and its forgotten.
05:24:13	brisque:	presumably they aren't using the alerts system to notify clients because they didn't change the key from Litecoins.
05:24:54	petertodd:	warren: one of the reasons I'm not working on python-bitcoinlib...
05:25:13	petertodd:	warren: and for that matter, why I quit the day job (mastercoin was just good luck)
05:25:14	andytoshi:	i like how this happened less than a hour after i decided to write an alt faq
05:25:22	andytoshi:	brisque: classic
05:25:29	warren:	I need a doge speak primer to format the mocking message properly.
05:26:35	grau:	I regularly write doge, without intent :)
05:27:08	petertodd:	warren: verb noun, verb noun, verb noun etc. (all lowercase) make the layout alternate sides, but not symmetrical.
05:27:09	brisque:	https://github.com/dogecoin/dogecoin/commit/2ee5cb3396df66c10fef34480a183d00e3bec635
05:27:18	brisque:	^ that's the forking change, if anybody was curious
05:27:55	petertodd:	specifically the change to the definition of MAX_MONEY
05:28:04	brisque:	https://github.com/dogecoin/dogecoin/blob/94b99f5cc7d997d9c656b9d08ce5f74caa6a3ec3/release/dogecoin.conf
05:28:08	gmaxwell:	wtf they totally did just change max_money, halarious.
05:28:12	brisque:	what's with the hardcoded RPC password?
05:28:28	warren:	prior to making that change they e-mailed me asking for help
05:28:29	brisque:	default rather, not hardcoded.
05:28:35	gmaxwell:	worse than I guessed, initially I thought perhaps not all instances of max money were made into the define and they only got one right.
05:28:54	gmaxwell:	"Fix dust issue" misleading commit message too
05:28:57	warren:	I didn't intentionally not respond, I was sleeping the entire time including that commit.
05:29:19	petertodd:	lol "
05:29:19	petertodd:	wallet_bgcoin.png should not be modified on every release, as it would increase the size of the repository time by time...
05:29:37	gmaxwell:	and the commit was by " dogecoin " no actual attribution.
05:30:03	warren:	I didn't verify this, I was told one of the dogecoin devs is an engineer at IBM.
05:30:47	brisque:	oh, so Dogecoin is a fork of "Linkcoin" rather than Litecoin?
05:30:51	petertodd:	ha, and dogecoin doesn't sign their commits
05:30:56	petertodd:	or even tags
05:31:43	petertodd:	warren: they do have an android client on the front page though
05:32:10	brisque:	petertodd: and a web wallet.
05:32:40	warren:	brisque: not all that different from most coins. people mine directly into an exchange wallet.
05:32:42	petertodd:	brisque: with twitter bootstrap like the big boys!
05:35:11	grau:	Alt holdings could wash to BTC now en masse.
05:37:30	warren:	https://plus.google.com/+LitecoinOrg/posts/3iVBu7bC1h6 <--- this is the best I could do
05:37:53	petertodd:	warren: lol
05:37:57	grau:	:)
05:38:13	pigeons:	pigeons is now known as Guest41495
05:41:47	brisque:	there's a comment in that reddit thread asking the developer to use the alerts system to notify people, the response is "in good time"- they definitely can't because they don't have litecoin's alert private key.
05:42:48	warren:	they actually copied our alert key?
05:43:12	andytoshi:	i bet "in good time" means "when a litecoin dev names his price to sign an alert for us"
05:43:22	brisque:	warren: https://github.com/dogecoin/dogecoin/blob/2ee5cb3396df66c10fef34480a183d00e3bec635/src/main.h#L1589
05:43:28	warren:	andytoshi: can't do that. that alert would be on our network too.
05:43:53	brisque:	andytoshi: http://www.reddit.com/r/dogecoin/comments/1ufl1e/much_concern_dogecoin_block_chain_has_split/cehkh91?context=1 (I misremembered, that quote wasn't verbatim)
05:44:00	warren:	andytoshi: litecoin's alerts already jumped onto 20+ clone networks
05:44:01	petertodd:	warren: isn't dogecoin on 0.6? could limit display to just 0.6
05:44:07	andytoshi:	warren: oh, i thought because the nodes won't talk to each other litecoin would be isolated
05:44:39	brisque:	andytoshi: they would be isolated until someone just manually transported the alert to litecoin and made a mess.
05:45:16	andytoshi:	brisque: yeah, i realized that as soon as i typed that
05:45:33	brisque:	andytoshi: if I've read right, some people on bitcointalk have designed their systems to go into a safe mode when they see an alert on the network too
05:46:36	warren:	litecoin does regular alerts for color changes, so they shouldn't be surprised.
05:46:44	warren:	* warren is exaggerating, a little.
05:48:29	petertodd:	I like how in the reddit thread about the dogecoin split, specifically warning people not to send dogecoin during the split, people are tipping each other like crazy...
05:50:05	brisque:	petertodd: it's fairly obvious that the community has no clue what they're doing. the "co-founder" is saying everything is fine and they had 10 days to update (not realising that as soon as they made the commit the network could have been split {if anybody actually builds from master and runs it behind something})
05:51:15	petertodd:	brisque: and with their fast block rate and fast diff adjustment we can see first-hand what forks look like when coinbase payouts are destroyed!
05:51:17	andytoshi:	brisque: where are these claims being made?
05:52:04	brisque:	andytoshi: http://www.reddit.com/r/dogecoin/comments/1ufl1e/much_concern_dogecoin_block_chain_has_split/cehkbm8 and there's other bits scattered about the thread
05:53:29	andytoshi:	i love the talk in that thread about the "real chain" and "bad chains"
05:53:53	andytoshi:	apparently they have a reddit-based consensus system now..
05:54:30	petertodd:	BlueMatt: ^ there's an option for the coingen!
05:54:59	petertodd:	"So, now what do we do? Is there someone who is in charge of maintaining the blockchain?" <- lol
05:55:59	brisque:	petertodd: I would absolutely love to have a real time visualisation. connect to multiple nodes on different forks and watch them race. the short block time for make for an incredibly interesting display.
05:56:41	petertodd:	brisque: it'd be extra fun if someone decided to DoS attack the network right now
05:58:17	warren:	petertodd: coingen.io is for sale
05:58:20	brisque:	petertodd: I doubt they need it really. the network is so fragmented and so little actually relies on Dogecoin that the entire system will likely just collapse.
05:59:13	petertodd:	brisque: I sure hope so, but good luck on that...
05:59:43	petertodd:	brisque: communities of people around a technology that doesn't actually need to work for the community to exist can be surprisingly durable
06:01:00	brisque:	petertodd: I suppose, if they don't understand as a whole how bad this situation is then it won't collapse. strange situation. it's a bit like NXT supporters still being optimistic when their closed source currency posted it's source.
06:02:22	petertodd:	brisque: well remember the "situation" is they have a fun meme and a community built around that meme. if anything the problem is just as likely to get *more* people interested in dogecoin
06:04:51	andytoshi:	well, as fun as this is to watch, i've got an early flight tomorrow
06:04:56	andytoshi:	have a good night guys
06:05:03	brisque:	petertodd: like all "memes" the velocity will die off (if it isn't already).
06:05:13	andytoshi:	petertodd: i'm going back to austin, vancouver is freezing !!
06:05:27	petertodd:	brisque: sure, but that die-off may have little to do with tech
06:05:40	petertodd:	andytoshi: ha
06:05:46	petertodd:	andytoshi: pretty though :)
06:06:50	andytoshi:	that's true, i'll miss it
06:06:52	brisque:	petertodd: the meme is already losing staying power, it could just be that massive incompetence and forks is enough to destroy the coin as well. http://www.google.com/trends/explore#q=doge%2Cdogecoin
06:07:55	brisque:	http://www.google.com/trends/explore#q=doge%2C%20dogecoin&date=today%2012-m&cmpt=q
06:08:02	brisque:	that's a much better graph.
06:16:27	warren:	this fork didn't seem to affect its exchange rate
06:17:28	brisque:	logically exchanges would have closed their doors temporarily when they saw the network wide alert about the chain fork (haha). they risk double spends if they don't.
06:18:03	warren:	I'm just pointing out that networks being reliable has nothing to do with alt value.
06:19:14	brisque:	alright, I agree.
06:27:14	nessence:	it is near ~midnight throughout most of US on a saturday
06:46:21	justanotheruser1:	justanotheruser1 is now known as justanotheruser
08:04:05	Sangheil-:	Sangheil- is now known as Sangheili_afk
08:06:18	warren:	petertodd: ooh... with the dust spam attack, I wonder if their massive reorg triggered the BIP50
08:19:33	brisque:	brisque is now known as Guest75151
09:47:17	Sangheili_afk:	Sangheili_afk is now known as Sangheili
10:08:10	brisque:	looks like dogecoin released another update that adds check pointing to try and get around their hardforks issue.
10:08:31	brisque:	confusingly in two commits "checkpoint" and "checkpoints".
10:09:47	gmaxwell:	brisque: oh boy, did they back out the change?
10:10:18	brisque:	they did not.
10:10:31	gmaxwell:	if not they may be for a helluva ride as the hashrate majority when I looked _appeared_ to be on the acceptable-to-all fork
10:11:26	gmaxwell:	who the heck knows what happens if you upgrade to code that imposes a checkpoint you've long since violated and you don't reindex.
10:12:08	brisque:	the commit only checkpoints two very late blocks, but I'm not really sure how the behaviour works
10:12:11	brisque:	https://github.com/dogecoin/dogecoin/commit/dab72582b657395a25e25f4ea367b8b8990db460
10:13:00	brisque:	in the first commit they only checkpoint the later block *after* the fork, but wisely added a checkpoint for the forking block later on.
10:13:59	gmaxwell:	this sounds like a bad idea, if the hashrate majority is on the old stuff, they'll keep on trucking. If its on the new stuff, they didn't need the checkpoint at all.
10:15:34	brisque:	from their IRC (signal to noise was off the chart, it was hard to tell) the older branch had the majority and was overtaking the newer clients with the forking change. as the original instructions from the developer were to upgrade at all costs, I guess they just went with it.
10:15:41	gmaxwell:	also if you upgrade a node already past the checkpoint on the non-checkpointed chain, it's not going to reorg on its own unless you do a reindex.
10:16:08	gmaxwell:	seems like a really bad plan to me, since they won't know for sure if they'll actually get the majority to switch fast.
10:16:17	gmaxwell:	so it might make a huge reorg days later...
10:19:33	brisque:	I'm not sure it was thought through that much, from talking to the developer before he was certainly trying to grapple with what was going on, but doesn't have that much experience with the finer points.
10:20:47	gmaxwell:	my strategy would have been to revert the change, set the change to trigger in the future, checkpoint the chain everyone can accept. release and nag everyone to upgrade to that.
10:21:18	brisque:	sounds familiar.
10:21:22	gmaxwell:	that would avoid any (further) reorgs assuming the hashpower majority was already on the generally acceptable chain.
10:21:41	gmaxwell:	it's even _better_ than when we did it in bitcoin, if the hashpower majority is on the generally acceptable chain most of the time.
10:22:09	gmaxwell:	(bitcoin was screwed because there was a decisive hashpower majority on a chain the majority of nodes would reject)
10:24:59	brisque:	handled with relative grace given the circumstances. it would have been harder with a majority p2pool, but significantly easier now that we have two pools with a majority hashrate.
10:26:39	gmaxwell:	well it wouldn't have happened at all really with p2pool. majority of nodes were not on the fork creating version we would have just gotten a _single_ orphan block out of it and probably not noticed the event. :( (if thats good or bad it's unclear!)
10:27:53	gmaxwell:	it's actually an interesting question if the BIP50 fork actually happened earlier and we missed it because the old chain got ahead fast enough.
10:28:51	brisque:	the 0.8 chain was from a single pool wasn't it?
10:29:10	brisque:	wouldn't they have notice the sudden increase in orphaned blocks?
10:29:16	gmaxwell:	no, its was from two primarily.
10:29:35	brisque:	BTCGuild and Slush, got it.
10:29:42	gmaxwell:	brisque: I mean in a hypothetical world where hashpower wasn't consoldated at a big pool...
10:30:05	gmaxwell:	the trigger was pretty hard to hit, we went for months before triggering it again after the large blocks were allowed again.
10:30:37	gmaxwell:	I think we've triggered large numbers of unpatched 0.7 nodes to misbehave only twice since.
10:30:39	brisque:	so 0.7 clients without a modified database configuration are permanently orphaned now?
10:30:48	gmaxwell:	no because its non-determinstic.
10:30:58	gmaxwell:	the last time apparently got a lot of them though.
10:31:14	gmaxwell:	I'd bet you could sync a new one from start successfully now though.
10:32:39	gmaxwell:	if instead the <0.8 nodes solved two blocks before the 0.8 only chain got a second, it would have just been orphaned and probably no one would have noticed, since that orphan producing 0.8 node would likely have not triggered it again with its next block.
10:32:55	gmaxwell:	(as some portion of its txn would have been included on the <0.8 chain.)
10:33:15	brisque:	I've a few 0.7.99 clients at the current highest block, so you're likely right with that.
10:34:52	gmaxwell:	0.7.99 = 0.8 for this purpose.
10:35:59	michagogo|cloud:	12:26:40 well it wouldn't have happened at all really with p2pool. majority of nodes were not on the fork creating version we would have just gotten a _single_ orphan block out of it and probably not noticed the event. :( (if thats good or bad it's unclear!)
10:36:44	michagogo|cloud:	Bוא 'םוךגמ,א איק ארדשמדשבאןםמד ישהק קמגקג ופ ןמ איק צקצפםםךד םכ איק ופערשגקג מםגקדת עקאאןמע רקצןמקג שעשןמ שא קשבי נךםבל אישא שמ ופערשגקג מםגק צןמקג?
10:37:00	michagogo|cloud:	Gah, I hate when that happens
10:39:53	michagogo|cloud:	But wouldn't the transactions have ended up in the mempools of the upgraded nodes, getting remined again at each block that an upgraded node mined?
10:41:42	gmaxwell:	michagogo|cloud: yes, creating single height forks which wouldn't continue (far) if they were in the minority, and would stop if they restarted, and would stop if they switched to the latest build. and since they were already running the latest code, there is a prior probablity that they're likely to upgrade.
10:45:54	michagogo|cloud:	gmaxwell: Sure, but it wouldn't just be a single block, it would be a bunch of 1-deep forks, and I think "oh, I stopped getting doges for my mining" would have lead to it being noticed
10:50:31	gmaxwell:	michagogo|cloud: I think you're splicing two discussion now.
10:50:41	gmaxwell:	not being noticed was a comment on the bitcoin pre-0.8 vs 0.8 hardfork
10:50:47	michagogo|cloud:	oh
10:50:47	gmaxwell:	which wouldn't have likely retriggered.
10:50:52	michagogo|cloud:	...right, sorry
10:51:01	michagogo|cloud:	* michagogo|cloud rereads
10:51:22	michagogo|cloud:	* michagogo|cloud goes back into his corner
11:08:09	nsh_:	nsh_ is now known as nsh
12:47:50	adam3us:	i liked jtimon's use of the word scamcoin to cover param-tweaks. i do think we need a clear tone setting term for param-tweaks vs actual alts, the scam coins are unduly dirtying even the concept of alts; alts with actual innovation could be useful things; as we've discussed btc pegged side-chains are good for some types of things, but actualy experiments in proof of work, economics may not be possible fit into that model
12:49:09	brisque:	adam3us: what do you call things like Primecoin and NXT? they're not parameter tweaks, but still not sane things to be promoting. as soon as you create differentiation you end up encouraging one over the other.
12:49:15	adam3us:	(and btc pegged side-chains have some technical and game-theory open questions, though its' an idea I find interesting and perhaps of great value to bitcoin ecosystem so eg we can run bitcoin 0.x and bitcoin 1.x in parallel, or competing bitcoin 1a.x and bitcoin 1b.x
12:50:54	adam3us:	brisque: yes i do wonder about that. as i said on a private chat prime coin is pretty close to another scam coin. the paper talking about the scientific method is not credible. it doesnt benefit the world to search for pairs of mid-sized priimes any more thn searching for hashcash stamps for the bitcoin stamp-collection
12:51:43	sipa:	i also believe not all "silly" altcoins are intended as scams
12:51:49	brisque:	I'd have to check, but I'm sceptical that their prime searching thing is reliable as a hash too.
12:52:40	adam3us:	you know i think momentum PoW might actual have some utility, the paper describing it is undefined/ambiguous on most of the critical issues; but i think reverse engineering it it might actually be an interestingly step towards a memory hard pow that doesnt require memory to verify (despite failing multiple other features he set himself)
12:53:27	brisque:	sipa: it might not be intended that way, but anybody looking at the Alternate Cryptocurrencies subforum should certainly be able to work out what's going on.
12:53:32	adam3us:	sipa: yeah scam might be the wrong word. i just think we owe like jtimon & maaku credit for having a non scamcoin, and just ranting against alts unfairly taints their freicoin economic experiement
12:54:48	sipa:	there are really many cases
12:55:12	sipa:	of coutse, a ton of silly alts (just tweaking some parameters)
12:55:14	adam3us:	brisque: there can be a difference between ooh make-money-fast, missed the bitcoin bubble, maybe i too can get some small early-adopter mining/premine mentality which isnt exactly a scam (otehr than egregious premine) but an attempt to get rich now that the proof has been given over 3 years of high uncertaint with bitcoin bootstrap that crypto currencies can bootstrap
12:55:32	sipa:	there are some that try to address a different problem (namecoin, datacoin)
12:56:01	sipa:	some are failed experiments on their own (litecoin as gpu-resistant pow perhaps)
12:56:17	sipa:	ppcoin was interesting, but flawed imho
12:56:36	adam3us:	and it can be somewhat hard to untangle. like if coingen succeeds in squelching param tweak,s maybe the people who can use a compiler enough to not need a hosted compiler will then just try harder to make a story
12:56:48	brisque:	adam3us: yes, but that said you don't want to be promoting NXT. it isn't a parameter swap but it's ridiculously insecure.
12:56:53	adam3us:	sipa: that probably becomes the new min-bar for "innovation"
12:57:10	adam3us:	brisque: very true.
12:57:37	sipa:	i've long been thinking about creating my own altcoin
12:57:45	adam3us:	see we have like "moron coins" and "good coder but crypto/distrbitued system incompetent" coins and usually a lot of greed and a bit of scam mixed in
12:57:50	sipa:	to fix all things that are wtong in bitcoin :)
12:58:03	sipa:	but time...
12:58:10	adam3us:	sipa: yep, everyone thinks about it, i thought about it also
12:58:13	brisque:	I take the primecoin comment back, it seems to be semi-sane but the "work" it's producing is just as useless as anything else.
12:58:21	sipa:	yeah
12:58:55	adam3us:	brisque: no there is something wrong with primecoin, algorithmically; its not exactly progress free and the probability distribution is slightly wrong i think
12:58:57	sipa:	adam3us: i'd probably implement most of it from scratch, though
12:59:42	brisque:	adam3us: on my first read I thought the work was based on a 32bit hash, but it's not. I haven't looked any further than that.
13:00:09	brisque:	sipa: why wouldn't you? there's lots of little niggles in Bitcoin that could be fixed with a complete rewrite.
13:00:41	adam3us:	sipa: yes that is actually what got me to thinking about 1-way pegged side-chain and i presume BlueMatt/gmaxwell about 2-way peg was that it makes more sense to respect the initial bootstrap as a one-off event, the it becomes possible to do significant innovation, overhauls, re-writes without having the barrier to actual adoption of a new digital scarcity
13:01:38	sipa:	brisque: not following, i'm saying i prefer to total rewrite over patching
13:01:48	brisque:	sipa: I'm agreeing with you.
13:01:52	sipa:	ok
13:02:24	adam3us:	the only other people i saw who even tried to tone down the "make money fast" motivation (which is actually a smart thing to tone down for adoption) were jtimon & maaku, there was like a charitable donation, and a temporary but modest (i think?) development fund, plus the new economic bit about demurrage
13:03:01	sipa:	maybe ironically, i just don't care about economics much
13:03:04	adam3us:	sipa: yeah the thing that i find awesome about 1-way or 2-way pegged side-chain (if we can figure out the details) is that it fully allows major feature experiments, securely
13:03:20	sipa:	adam3us: link?
13:04:09	adam3us:	ohh i am not sure there was a 1-way peg write up on bitcoin-dev, one sec for link; 2-way was a thread on here, been meaning to update the email thread with that discussion
13:04:45	sipa:	one way pegging through burning bitcoins to create coins in another system seems simple enough
13:04:55	sipa:	being able to go back... i don't see how
13:05:42	adam3us:	https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02945.html
13:05:46	adam3us:	thats the 1-way
13:06:48	adam3us:	sipa: so the 2-way works if you make changes to bitcoin 0.9x to honor transfers back. but only once for previous transfers out. in that way the security is limited to damange ONLY the current holders of transferred out bitcoins (if security issues appear on bitcoin 1a.x)
13:07:52	brisque:	adam3us: so you would have coinbase TXs without a block, sorta?
13:08:34	sipa:	i don't understand
13:08:52	sipa:	you send a coin to a dead address to instantiate it in betacoin
13:09:02	sipa:	how do you turn it back into a bitcoin coin?
13:14:43	adam3us:	sipa: sorry about that free airport wifi expired… onto the next laptop
13:15:24	adam3us:	sipa: the reason i thought 1-way peg is interesting is i was frustrated about adoption rate of simple (but soft/hard-forking) clear improvements to bitcoin (of which i think there are many)
13:15:59	adam3us:	sipa: so i though 1-way peg servers as a security insulator and doesnt require bitcoin 0.9x changes (which was the bottleneck i was trying to think of a way to unblock)
13:16:41	sipa:	i'm not following what you're talking about now
13:17:39	adam3us:	brisque: "coinbase tx without a block" no the pegged side-chain would have no reward mining (that would be done via transfer/destruction on bitcoin main) but it would have tx reward (denominated in btc)
13:18:11	adam3us:	sipa: did u skim the url about bitcoin-staging? which bit of the above?
13:18:24	sipa:	adam3us: sorry, your mails are too long :)
13:18:44	adam3us:	sipa: yeah i tend to write tldr stuff oops.
13:19:29	adam3us:	sipa: so i guess we agree that there are a number of things that could be simply fixed, but arent worth the security/value risk of soft/hard forks, and interesting features to enable
13:20:15	sipa:	it depends whether it's about things that could reasonably once be enabled in bitcoin itself
13:20:17	adam3us:	sipa: (eg enable some more scripting, or change it so the value is signed - which bites trezor & offline armory)
13:20:25	sipa:	yeah
13:20:33	sipa:	that stuff is fine
13:21:26	sipa:	but things like utxo-walking pow, or transactions committing to a particular chain, or tx fees that are spread over multiple blocks
13:21:38	sipa:	i doubt those can be considered "bitcoin"
13:21:58	adam3us:	sipa: so its not exclusive right, there can be a bitcoin 1a.x bitcoin 1b.x etc which are competing pegged side-chains … if maaku & jtimon want to go implement the freimarket script extensions on one thats cool. another one can focus on shorter term fixes like the above. maybe bitcoin might merge some of them later or switch over bitcoin to 1c.x if users demand it and move everything to 2.x
13:23:19	adam3us:	sipa: well i think the interesting thing to preserve if people are genuine about wanting to move the tech forward is the digital scarcity definition. eg one can preserve bitcoin 0.9x as the only reward miner, that way it respects the 21 mil coin limit, and people can innovate on an existing currency base (which i do not think its reasonable to attempt to restart)
13:23:51	sipa:	i don't want 1-way pegging, as it means you have to burn (valuable) bitcoin to obtain a potentially worthless successor coin
13:24:05	sipa:	if you kbow a way to do actual two way pegging, i like to hear it
13:24:09	adam3us:	sipa: so whether its a rewrite or just enabling queued simple/nice things or some script/market experiment… that can all be done on competing pegged side-chains. they can interoperate if you can move coins back (via main)
13:25:18	sipa:	(in a way that doesn't force the side chain to be very compatible with bitcoin, as that would limit the degree of innovation there)
13:25:18	adam3us:	sipa: i think the main limitation is you have to enforce security so that security/value bugs in the side-chains can not leak back into bitcoin main. for more adventurous things (utxo walking pow)) you'd probably have to make do with a 1-way peg
13:25:36	sipa:	right, of course
13:26:08	adam3us:	sipa: yes. 2-way peg is far nicer as nothing is destroyed, just moved. just pointing out the limits with 2-way tieing back to the more adventurous changes that cant easily say preserve a security/value firewall because the value definition is too redefined
13:26:21	sipa:	right
13:27:26	sipa:	there is of course the centralized approach using an exodus address which has an actual private key known to some people
13:27:35	sipa:	but that already smells way too scammy
13:28:27	brisque:	smells like mastercoin to me.
13:28:31	adam3us:	sipa: so gmaxwell & BlueMatt were exploring using SPV security from the merge mined 1:1 pegged side-chain (with a long conf time like 100blocks) . even that is pretty complex. i guess we'd have to explore that first before figuring out if you can go further and two-way peg something with quite different value semantics
13:30:41	adam3us:	sipa: maybe you can do something, the main point being that nothign must be possible to move back from the side-chain twice. ie it must be tied back to the demonstrable ownership (in SPV model say) of a previous bitcoin that was destroyed, and then allowed (once) to be recreated (though the cycle could repeat, it must be allowed once in each cycle)
13:31:01	gmaxwell:	the key observation in that discussion that I came to was that it doesn't really matter if the value transfer mechenism is very slow (e.g. taking many blocks), because you could just do regular atomic coinswaps so long as the liquidity on each side was reasonably balanced, you only need the direct chain moves to move funds without a counterparty.
13:32:00	adam3us:	gmaxwell: yes i agree with that. its the expectation of later fairly certain settlment, market can do the rest (pay day loan for the impatient)
13:33:10	adam3us:	gmaxwell: sipa was wondering if more esoteric/bigger value definition/ownership changes could be two-way pegged "sipa: if you kbow a way to do actual two way pegging, i like to hear it
13:33:11	adam3us:	(in a way that doesn't force the side chain to be very compatible with bitcoin, as that would limit the degree of innovation there)"
13:34:32	adam3us:	sipa: even if it were not (significantly) possible, just a two-way peg could allow quite a lot of new parallel development flexibility and innovation on existing value base. that alone is a big project.
13:35:08	brisque:	if a two way peg were possible namecoin would be a lot more interesting.
13:36:44	gmaxwell:	brisque: no thats not possible.
13:36:54	sipa:	souns like that requires every utxo in the beta currency to be backed by a bitcoin utxo
13:36:55	gmaxwell:	namecoin already exist.
13:36:56	adam3us:	sipa: (another change would be like the tagging of additional meanings directly on the side chain rather than coloring; freimarkets proposes tagging, and its better than coloring as coloring is i think inherently SPV incompatible, and tends to spam the bitcoin network)
13:37:18	gmaxwell:	sipa: not quite, perhaps someone should go extract that conversation from logs.
13:37:25	brisque:	gmaxwell: well yes, unfortunately.
13:38:02	brisque:	gmaxwell: not sure anybody would argue that the project isn't stale though.
13:38:17	sipa:	well if you can create a bitcoin output script that requires a proof of transfer through betacoin and back... ok
13:38:24	gmaxwell:	sipa: in any case, basically you add a softforking change to bitcoin that lets you write txouts which can be spent according to terms that come with SPV-like proofs from the other chain.
13:38:28	gmaxwell:	right.
13:38:56	sipa:	but SPV proofs cannot prevent double spending
13:39:36	sipa:	and it is limiting in the sense that it requires encoding some basic form of betacoin's transfer rules in bitcoin
13:39:43	gmaxwell:	no no,
13:40:05	adam3us:	for my part i think 1-way (and more practically 2-way) pegged side-chain is the best new bitcoin idea of 2013. i hope its possible.
13:41:48	gmaxwell:	sipa: the script is a proof "Betacoin say 2 btc can come back to bitcoin to scriptpubkey 1234 + a bunch of betacoin headers". I'd also come up with an idea that required the txout scriptpubkey in such a transaction could be such that it had a minimum time it could be spent from, and before that the transfer canceled with a longer chain of headers.
13:42:27	gmaxwell:	so then bitcoin is totally blind to betacoin's rules, except for how betacoin headers works, how how betacoin communicates moves back to bitcoin.
13:42:58	gmaxwell:	from the betacoin side the transfer from bitcoin could be similar or betacoin could watch the bitcoin chain, the latter is probably better.
13:43:53	gmaxwell:	if the whole transfer is slow and cumbersome and requires a 8 kbyte transaction it doesn't really matter, since if you have two parties you can just to an atomic coin swap.
13:44:16	gmaxwell:	the cross chain teleports are only needed to balance liquidity.
13:44:59	gmaxwell:	(so if there are more coins wanted on the betacoin chain than exist there there is a way to satisify the demand)
13:45:58	gmaxwell:	also means that if you can fake out the teleport method e.g. with a huge betacoin reorg, you can make betacoin fractional reserve, but you never inflate bitcoin.
13:47:41	gmaxwell:	presumably this could be stronger in practice than in theory because if bitcoin miners were all betacoin miners they could generally refuse to mine suspect betacoin proofs, or themselves be prompt about providing contradiction-proofs that aborted the trasnfer in a soft-security fashion.
13:48:33	gmaxwell:	"no no, there is a compeating betacoin fork as good/better than this one, abort this transfer until someone can show an even better betacoin proof"
13:49:36	adam3us:	sipa: the 1-way peg also could consider a longer term version of the market providing liquidity based on later settlement, eg if the network bootstraps to become credible, or if multiple sensible people and orgs make an approximate indication that they plan to switch over with in 18-mo - 2yrs to a hyopthetical sipa-led rewrite
13:50:07	adam3us:	sipa: as after the switch over the rest of the bitcoins are moved over to the new network and the liquidity providers can earn the arbitrage profit they were aiming for
13:50:29	adam3us:	sipa: (wrote about somewhere on the tldr 1-way peg thread)
13:51:27	adam3us:	(what a choice… pay gbp 5 to extend free airport wifi or type a password into a *windows* machine. yup i paid)
13:51:35	gmaxwell:	plus imagine all the great drama we'll get in two way pegs. people creating altcoins that can two-way-peg with bitcoin (because why not make the facility completely generic so anyone can hook up a new chain to it?) just with the intention of leaving it insecure so they can steal all the coins that move over.
13:52:02	gmaxwell:	LHR 45 minute wifi is robbery.
13:52:15	brisque:	adam3us: just spoof your MAC.
13:52:25	adam3us:	gmaxwell: i could tumble the mac i guess, but too late
13:53:05	adam3us:	gmaxwell: i was thinking really should ptu a script to tumble th emac on network connect anyway - privacy principle. probably nsa is tracking mac s somewhere in utah
13:54:14	brisque:	adam3us: changing your MAC doesn't stop that, you can just look for wifi cards announcing what networks they're looking for and then compare that to the google skyhook database to find their home address.
13:54:18	adam3us:	gmaxwell: also it a rather nice argument against scamcoins (still need a better word to describe param-tweak/get-rich-quick from genuine innovation) … and why did you start a new digital scarcity race? we were discussing that above in relation to coingen.
13:55:08	adam3us:	gmaxwell: and it seems likely the min-bar will just go up slightly to things like primecoin, or other artificial uninteresting or stupid changes that are just above the param-tweak and come with a semi-plausible to novice argument and white paper. (Like NXT … that is nuts)
13:55:25	brisque:	adam3us: out of my own curiosity I set up a wifi dongle looking out onto the street that did something like that. incredibly effective when people walk around with phones in their pockets.
13:56:27	adam3us:	brisque: i think bitcoin has a problem. once a competent grey-hate gets too tempted the base band phone p0wning will harvest $ms of coins in automated attacks. we need hardware fast.
13:57:07	adam3us:	someone who shall remain nameless to protect their own stupidity showed me a phone with 500btc on it ('doh!)
13:57:45	adam3us:	(an otherwise i guess reasonably competent CS degree programmer type of person)
13:58:02	brisque:	adam3us: I was more talking about privacy violations by phones announcing people's home addresses every few seconds. I'd really like to see sensible hardware too though, the Trezor looks quite nice.
13:59:32	brisque:	adam3us: I personally predict a piece of commodity hardware will be hacked to create a secure but cheap USB based wallet. there's quite a number of children's toys that have been turned into RF analysers and other tools.
13:59:35	adam3us:	brisque: not sure if 2014 will be the year, but a year RSN we will surely see baseband and targetted DSL IP# hacks from bitcoin big change identified IP# from bitcoin users who dont use tor to spend from large coins; the only hope is air-gaps IMO, or TPM (arm trustzone, intel TPM etc)
14:00:02	gmaxwell:	adam3us: someone with a typo squat on a popular bitcoin service domain and a java exploit for IE that I was seeing get investigated recently had stolen several hundred btcs in a few days time.
14:00:26	gmaxwell:	so the bar is still pretty low
14:01:09	brisque:	adam3us: doesn't really have to be a specifically designed hardware. anything would do. I saw photos of a childrens toy that would make an excellent Trezor type device with a lot more features (full keyboard) than the real thing.
14:01:17	adam3us:	gmaxwell: the stupidity factor never ceases to amaze. its scarcy that people are not being hacked way more.
14:01:36	brisque:	adam3us: there's some constraints, but the hardware doesn't have to be complex. you don't even need to have a hardware RNG on board.
14:02:26	adam3us:	brisque: you said about wifi network advertising networks it wants. it works that way? no waiting for announce, requesting ssid ? the client broadcasts all the wifi ssid it knows??
14:03:07	brisque:	adam3us: a wifi client announces sequentially every wifi network it knows, every 10 seconds it ruins "hidden" SSID by sending out the name and MAC of the routers it knows.
14:03:32	adam3us:	sipa: so are you getting the 2-way peg bug yet? ;)
14:03:51	sipa:	adam3us: let's call them "silly alts", "delusional alts" and "flawed alts" :)
14:03:54	brisque:	adam3us: this is the childrens toy I was talking about. you could certainly port a hardware wallet to this. http://d4c027c89b30561298bd-484902fe60e1615dc83faa972a248000.r12.cf3.rackcdn.com/imagepicker/4494/thumbs/IM.jpg
14:04:16	adam3us:	brisque: on noes! i guess the mac-tumbler script i need to write needs to flush the ssid cache also
14:05:03	adam3us:	brisque: i like the QR code as optical isolation connection that "visual btc" setup
14:05:51	adam3us:	brisque: of course it helps if the value could be signed so the input tx history doesnt need to be sent to work around that bug
14:06:21	brisque:	the IM-me is missing a camera so a QR code is out of the question. the sticking point is that you can't use sound because of the must-see-every-input issue of transactions.
14:06:51	brisque:	a device like this with more IO (a camera mainly) would be able to replace trezor with cheap commodity hardware.
14:07:48	brisque:	if the must-see-every-input bug was fixed in 0.9, you could almost push a TX via sound, it's just too heavy as it stands.
14:07:59	adam3us:	sipa: i guess someone could do a zoo-ology catalog of them. the variety of stupidity and greed in involved is hilarious. some of them even bootstrapped to semi-respectability by first-mover advantage. i think one test maybe zero real-transactions (non speculator), lack of clients, lack of any development, lack of any plan to obtain real-tx
14:09:25	gmaxwell:	people would never believe the zooology wasn't all made up
14:09:31	adam3us:	brisque: as i recall gmaxwell guestimated 2 years to fix the sig malleability bug; not sure what the guestimate would be on the no signed values bug. depressing. hence enthusiasm for 2-way peg. in the old thread on 2-way peg gmaxwell said (in relation to my question if this itself could get implemented given the other bugs) was that yes but this (2-way peg) is the one change to rule them all
14:10:04	adam3us:	gmaxwell: crypto-zoology :)
14:10:52	gmaxwell:	adam3us: also— why bother with baseband hacks and zero days, when you can just ask people to give you their money: https://bitcointalk.org/index.php?topic=393593.msg4274997#msg4274997
14:11:49	gmaxwell:	adam3us: yea, a two way pegging facility is fully general. I mean its a way you could completely replace the protocol in a totally consentual way, start up mergemined two-way-peg and move all the funds to the new chain over time.
14:11:50	brisque:	adam3us: if dogecoin can do a hard fork in 10 days, I'm sure gmaxwell can come up with some crypto-magic to get bitcoin's done in 20.
14:12:12	gmaxwell:	having a hard fork is not a problem, avoiding one is.
14:12:45	gmaxwell:	suggested two way peg stuff doesn't actually need a hardfork, might not even be any easier with one.. it's just new scriptpubkey features, at least if it stays at the quasi spv security level.
14:12:45	adam3us:	the other annoying thing about airport wifi is i have a pay as you go 3g sim with 3GB/month data allowance for gbp 2/day for UK on any day used, but the wretched thing never works, and i think i grabbed the wrong replacement sim when i was leaving.
14:13:20	brisque:	gmaxwell: that story is terrible.
14:16:12	adam3us:	is there anyway to get above SPV security i wonder in a sensible level of bitcoin main changes that doesnt just have both protocols in the client (or a link to a beta validator running in parallel)
14:17:12	gmaxwell:	well spv security can mean multiple things there is communicationless spv which is what you get when someone hands you a proof and you're happy, and normal spv when you can go out and seek more evidence.
14:17:21	gmaxwell:	I think we can get it the latter of those two.
14:17:26	gmaxwell:	More than that implies validating the rules
14:17:33	gmaxwell:	which implies embeding the rules in bitcoin
14:17:46	gmaxwell:	and all of the data needed to check the rules
14:18:04	gmaxwell:	and short of snarks or something, I think thats probably not realistic. (well and not realistic with snarks today regardless but maybe in a few years)
14:19:25	adam3us:	brb
14:28:24	Guest41495:	Guest41495 is now known as pigeons
14:30:06	adam3us:	gmaxwell: well say hypothetically a client that speaks both bitcoin v1 and bticoin v2 protocol with a pegged side-chain connecting them
14:31:22	adam3us:	gmaxwell: eg less of a general competition between 2a, 2b 2c etc side-chains but more the next version of bitcoin with fork requiring bug fixes on it, running in parallel with real-value transferred via the 1:1 peg by those who need the 2.x features, eg 1.x for value storage and 2.x for anything other than basic tx (say)
14:36:38	adam3us:	adding insult to injury this gbp 5/hr wifi is failing I think because of the web injection urls timing out. grr
15:21:35	brisque:	regarding hardware wallets.
15:22:14	brisque:	I was looking into various bits of hackable hardware, looking at the specs and everything. realised it's a little pointless when you can get a 6" laptop from Alibaba for 30 pounds or so.
15:23:19	brisque:	that's all you'd need for a super effective offline device really, and it's cheaper than the Trezor ever was.
15:25:47	gmaxwell:	brisque: but bulky.
15:26:07	brisque:	gmaxwell: one of these would work too http://en.qi-hardware.com/wiki/Ben_NanoNote
15:26:10	gmaxwell:	(also: thats why I didn't order a trezor)
15:26:15	gmaxwell:	yea, but stupidly expensive.
15:26:24	gmaxwell:	I actually looked at getting a nanonote for wallet use.
15:26:46	gmaxwell:	it's not true of trezor but in theory a hardware wallet could be tamper resistant too.
15:27:00	gmaxwell:	your cheap laptop will suck when the evil made pops the keyboard and adds a keylogger chip.
15:27:07	gmaxwell:	s/made/maid/
15:28:38	brisque:	that's why I was thinking of consumer hardware that can be hacked. the childrens toy I mentioned has almost everything you need, including a wireless pink USB dongle. the issue is that you have to open it to get to the serial ports to flash it. not something you can convince everybody to do. http://d4c027c89b30561298bd-484902fe60e1615dc83faa972a248000.r12.cf3.rackcdn.com/imagepicker/4494/thumbs/IM.jpg
15:29:05	gmaxwell:	wow neat
15:29:07	gmaxwell:	what cpu?
15:29:33	brisque:	that's the other sticking point, it's CPU is a little short on memory.
15:29:43	gmaxwell:	though wireless usb dongle may mean a rather large attack surface area.
15:30:31	brisque:	the low memory is ultimately what makes it useless sadly.
15:30:54	brisque:	works as a RF spectrum analyser though.
15:31:25	gmaxwell:	why would it make it useless as a signing device?
15:31:29	gmaxwell:	surely it has enough for that.
15:31:49	brisque:	http://www.ti.com/product/cc1110f32
15:32:06	brisque:	32kB flash, 4kb of RAM
15:32:59	gmaxwell:	could be used as a signer no problemo.
15:33:12	gmaxwell:	though uh, perhaps not with wireless.
15:34:19	brisque:	yeah. my thinking is that there's got to be another dirt cheap childrens toy with an LCD, keyboard and some decent IO that can be hacked into a deterministic wallet.
15:34:51	gmaxwell:	but, of course, that also makes it easier to tamper with
15:34:57	brisque:	camera for QR codes, or audio, or even USB pretending to be a HID would work perfectly for this.
15:35:10	brisque:	isn't the assumption that with a hardware token, your coins are compromised anyway?
15:35:51	gmaxwell:	hm?
15:36:07	brisque:	any KDF on an embedded device would make it useless, and no matter what you do the seed is going to be extracted.
15:36:30	brisque:	I've seen hardware that's meant to destroy keys before, it's not all it's cracked up to be.
15:36:36	gmaxwell:	nah, you can make successful extraction of the seed pretty hard and make it be destructive.
15:37:05	gmaxwell:	(be destrutive meaning an intruder couldn't tamper and put it back)
15:37:42	gmaxwell:	and yea, sure concerted 'offline' effort by an expert you can't be safe from, but certantly it's better if your curious teenager couldn't extract the keys easily.
15:38:00	gmaxwell:	not saying mandatory: trezor fails this too as I understand it, but it would be preferrable.
15:38:26	brisque:	there was a game console that did something like that. had a chip with the ROM, and a battery backed RAM chip with a secret key. on boot it XORed the two to get the executable. any screwup meant you lost the RAM chip and had to pay a pile of money for a new one.
15:39:21	gmaxwell:	yea there are all kinds of interesting things you can do, and then also embed the stuff in epoxy with embeded tripwires that cut power to the ram if cut.
15:40:14	brisque:	that's all doable, but that wasn't my aim with this concept. a dirt cheap hardware device holding a seed is preferable to a computer running windows and java.
15:40:54	gmaxwell:	fair enough. probably more interesting to reduce the interface exposure.
15:41:59	brisque:	QR codes would be ideal, then audio, then you're back to pretending to be a USB HID. are there any other "airgapped" ways of getting TX data to a device?
15:43:18	gmaxwell:	hid doesn't get you bidirecitional, does it?
15:43:41	brisque:	it does. the device can pretend to type, and the host can flash the caps lock key.
15:43:49	gmaxwell:	lol!
15:43:57	gmaxwell:	thats going to be rather slow
15:44:00	brisque:	doesn't the trezor pretend to be HID?
15:44:07	gmaxwell:	no clue
15:44:13	gmaxwell:	you need to transfer several kb.
15:44:23	brisque:	yes, the Trezor pretends to be HID too.
15:44:37	gmaxwell:	man the things you need to do to make windows happy
15:44:49	gmaxwell:	I would have just made it a usb serial device, but I guess those need drivers in window
15:44:51	brisque:	being driverless was probably the aim.
15:45:38	brisque:	10kB/s using the caps lock light..
15:46:12	gmaxwell:	crazy, still a bit slow
15:46:34	gmaxwell:	how about usb storage... plug unplug plug. :P
15:46:48	gmaxwell:	and sign and enter your pin on the device itself while unplugged.
15:46:55	jgarzik:	caps lock light - ha, creative!
15:47:17	brisque:	well for me wanting to hack something, that's probably going to let the host flash the device which is undesirable. I'm really just throwing ideas around.
15:47:20	jgarzik:	jumping airgaps is all the rage, these days. NSA or private community alike.
15:49:02	brisque:	doing it usefully is the issue though. I don't want to have to listen to my CPU buzz with a parabolic microphone to get Bitcoin TX data to an embedded device.
15:49:04	gmaxwell:	obviously why having a device with a minimized surface area matters.
15:49:41	gmaxwell:	* gmaxwell looks at gox and hurrays
15:50:28	brisque:	gmaxwell: I wanted a Ben NanoNote just to play with, doesn't look like anybody sells them anymore.
15:51:19	brisque:	by the looks of things, the easiest and cheapest airgap transmission is audio. if people hated dialup modems they're going to hate me screaching 200kB of previous outputs at them.
15:51:37	gmaxwell:	brisque: harder to setup bidirectional.
15:52:08	gmaxwell:	how about a usb device immitating a sound device?
15:52:41	brisque:	USB sound cards are cheap as chips, you can get one that works on any linux device for a few dollars.
15:52:54	gmaxwell:	and then you can easily just get 192kbit/sec in each direction using two bits per sample, and it would be completely inaudable if addressed to the wrong device.
15:52:57	brisque:	bonus, you can do transfer over audio to a phone.
15:54:08	brisque:	imitating a USB sound device would be doable though. matching a generic driver on the host would mean no attack surface.
15:54:43	brisque:	could also have audio output, then connecting to a cellphone would work.
15:55:10	brisque:	bonus mode, make adaptors so that transactions can be signed over phones, 56k style
15:57:26	jgarzik:	I continue to be stunned that mtgoxUSD receives the trading action that it does
18:33:07	justonegy:	hello
18:33:17	justonegy:	anywhere here who can help with ubuntu build?
18:33:50	justonegy:	or rather wants to..
18:39:46	michagogo|cloud:	justonegy: What about it?
18:39:58	michagogo|cloud:	(though this is most likely off-topic for this channel...)
18:40:17	justonegy:	I'm trying to build and its difficult to find information
18:40:20	justonegy:	EXCEPTION: N5boost12interprocess22interprocess_exceptionE
18:40:32	sipa:	#bitcoin or perhaps maybe #bitcoin-dev
18:41:01	justonegy:	checking for Berkeley DB C++ headers... default
19:06:56	justonegy:	no one want to help?
19:07:15	justonegy:	trying to fix this issue and there is just no information and the debug info is non existent
19:08:07	sipa:	please, not here
19:08:26	jcorgan:	#bitcoin-dev is better, and, you need to provide a bit more info
19:09:08	justonegy:	justonegy has left #bitcoin-wizards
19:19:21	Sangheili:	Sangheili is now known as Sangheili_afk
19:25:11	midnightmagic:	lol, one more reason why having a maid is crazy.
19:25:33	midnightmagic:	if yer in a house and can't vacuum your own floors, you're in the wrong damn house.
20:06:53	7CBAANUJO:	7CBAANUJO is now known as kinlo
20:22:30	mist:	[Global Notice] Sorry about the network split noise, folk. Unfortunately, yet another bunch of idiots has decided to DOS us. Yes, very funny guys. I guess your mummy and daddy bought you a botnet for christmas. Anyway, hopefully they'll get bored soon, until then, sorry again for the network noise, and thanks to all our sponsors who generously provide the bandwidth that this idiots fill with garbage.
22:22:01	EasyAt_:	EasyAt_ is now known as EasyAt
23:37:40	petertodd:	1CounterpartyXXXXXXXXXXXXXXXUWLpVr <- crazy, 107BTC sacrificed for some "protocol for the creation and use of decentralised financial instruments such as asset exchanges, contracts for difference and dividend payments"
23:37:49	petertodd:	https://bitcointalk.org/index.php?topic=395761.0;all
23:38:43	petertodd:	hilariously the scheme seems to be using OP_RETURN "CNTRPRTY
23:39:50	petertodd:	though that's not very surprising when you consider the psychology of it: a standard address for the burn lets people easily see how much has been invested, fueling additional investment...
23:41:32	nsh:	* nsh blinks
23:42:41	nsh:	* nsh reads harder
23:43:23	nsh:	nope. can you explain in more simple terms, petertodd?
23:43:33	nsh:	* nsh looks at the thread
23:45:04	petertodd:	nsh: OGG CAVEMAN BURN TASTY MEAT IN FIRE BECAUSE NOG CAVEMAN SAID MUCH MORE MEAT IN FUTURE IF OGG BURN MEAT NOW
23:45:18	petertodd:	nsh: OGG STUPID CAVEMAN, NOG CAVEMAN HAVE NO PLAN FOR MORE MEAT
23:45:24	nsh:	right, i'm basically at that stage
23:45:39	nsh:	but the bit where it actually makes sense to someone (and how) is beyond me
23:46:14	petertodd:	nsh: well I'm basically saying the intelligence of the people who throw away six figures is similar to that of a caveman
23:46:25	nsh:	sure
23:46:42	sipa:	what does 'OGG' refer t?
23:46:44	sipa:	to?
23:47:03	nsh:	but pretending this guy is actually some satoshi-level genius. what are people gaining by burning these coins? stake in some future system
23:47:04	nsh:	but how?
23:47:05	petertodd:	sipa: ogg is a standard caveman name in western english culture
23:47:29	petertodd:	nsh: basically, by the definition of the system, much like mastercoin was done, only with (arguably) even less chance of future success
23:47:55	sipa:	at least it sounds less scammy, as the exodus address is an actual burn here...
23:48:34	petertodd:	sipa: indeed, OTOH that can also mean less chance of success, as who'se paying for development?
23:48:44	sipa:	agree
23:48:57	nsh:	you'd want to be really really confident of everything working out to actually boot-strap the thing with real sacrifice from early-adopters...
23:49:37	petertodd:	nsh: yup, in this case actually it doesn't look like the creator of the scheme has any ill-intent, more that the investment community around it are idiots and will jump to throw money at anything
23:50:12	nsh:	well, i suppose you can take an ecological view: at the worst, something nontrivial will have been tried and lessons can be learnt, and those people who threw money in probably could afford it
23:51:01	nsh:	(and everyone who has btc gets slightly richer from the deflation)
23:52:10	petertodd:	nsh: quite likely true, although I'm going to let someone else pay to learn those lessons for me :P
23:52:20	nsh:	* nsh smiles