00:02:06	shesek:	jcb1, your previous sentence ended at "of notaries who'd need to notarize the ne"
00:06:06	nsh:	(the full name of the knights who say ne!)
00:07:18	sipa:	ni?
00:07:59	nsh:	aye, originally. i had to bend the truth a bit for that weak joke :)
00:08:16	nsh:	in my defence, the 'ne' in 'need' is phonetically identical
00:09:12	kazcw:	and fish could be spelled ghoti
00:10:38	jcb1:	last sentence should have been: You can then prove you're the current owner by showing that a majority of notaries who'd need to notarize the next transfer haven't put this transaction into their spent transactions tree yet
00:14:26	jaekwon:	jcb1: I don't understand why you must provide the history, if you can just show one transaction where the output is to you, & have the notaries tell you that that output hasn't been spent yet.
00:16:04	jcb1:	jaekwon: the history is how you link your token to whatever means was used to issue it. If somebody trusts your most recent notaries fully they can accept their notarization and not re-check the history back to issuance
00:16:43	jcb1:	showing all the history is a major impracticality, but I can't think of a way to remove that requirement without adding trusted parties
00:18:01	jaekwon:	presumably the other party needs to trust some notary in order to know that the output hasn't been spent. then that party might as well also trust that the provenance is good.
00:26:39	licnep_:	licnep_ is now known as licnep
01:28:18	nsh_:	nsh_ is now known as nsh
03:17:43	andytoshi:	Elriel: have you considered relativity of simultaneity when thinking about your timestamping scheme? it is not clear to me that you can have distributed timestamp consensus without massive enforced delays since time ordering is physically ill-defined for far-away events
03:18:37	andytoshi:	jcb1: how is this "majority of provers in the tx history" scheme sybil-resistent?
03:30:22	jcb1:	andytoshi: token owner chooses the notaries in the transaction history, which are a finite set
03:36:09	andytoshi:	jcb1: but the token owner is the one with incentive to double spend...she can transact with herself to create a forked history then your consensus is broken
03:40:47	jcb1:	andytoshi: that's discussed in the doc. if a token has passed through dodgy/unknown notaries at one step, people can spot this and refuse to accept it as payment. but that's definitely the ugliest part of this
03:42:46	andytoshi:	if "dodgy/unknown notaries" are a problem then you have a trust-based system, you can make it way simpler by just requiring every tx to be signed by the trusted parties
03:46:10	roidster:	roidster is now known as Guest40061
03:52:31	jcb1:	andytoshi: my goal wasn't that you don't have to trust the notaries at all, but that you (and the community) have a good way to change this set over time
03:56:15	andytoshi:	here you are trusting the notaries completely, so you can shortcut this by directly signing txes. and you can't change the set over time because you need consensus on what the trusted set is, otherwise it is easy to double-spend by finding two people with different trust sets. and if histories are signed inconsistently then you have destroyed fungibility as well
03:58:10	andytoshi:	eg if you want to double-spend to and reddit, give me a tx signed by midnightmagic and give reddit one signed by andreas anantopolous. i'd expect they won't talk to each other and nobody trusts them both
04:16:48	jcb1:	a double-spend wouldn't work like that. My previous tx would have to specify which of those two is the next notary (or more likely a set). At least one notary would have to sign the transaction twice.
05:08:13	pigeons:	pigeons is now known as Guest27974
05:39:19	Guest40061:	Guest40061 is now known as ridster
05:40:33	ridster:	ridster is now known as roidster
06:55:39	gmaxwell:	So... a thought on how cloud mining could be less of an existential risk for bitcoin: Of course you can have cloud providers allow hashrate owners to pick their own policy/pooling sources (e.g. run their own nodes or use publically available sources of consensus)... but at any moment the guy with physical control of the hardware could redirect it for an attack.
06:56:03	gmaxwell:	What if mining asics had some functionality where you needed to periodically sign the work being given to them, and if you didn't for too long, they'd stop mining.
06:56:53	gmaxwell:	So you'd just transfer keys to the hardware to someone and the device is a brick if they stop mining. Maybe you even have a recovery mode where they have to mine fruitlessly for a day to forget their prior owner.
06:57:33	gmaxwell:	this would be fairly 'easy' to implement on existing hardware's microcontrollers; though to be actually strong it would need to be in the asics directly.
06:57:34	lnovy:	how could that help as attacker would have access to keys also, when he had access to hw?
06:58:09	gmaxwell:	hm? he'd never have access to the keys.
06:58:16	gmaxwell:	(hurray for public key cryptography)
06:58:26	lnovy:	i need to read that again
06:58:38	copumpkin:	the owner of the hardware would have the private key and wouldn't store it in the cloud, but would supply it periodically?
06:59:02	copumpkin:	just cross your fingers you don't lose that key or someone has a lot of scrap metal to dispose of
06:59:09	gmaxwell:	copumpkin: he'd sign a message periodically and send it off (or ask another third party to do it for him, perhaps several third parties)
06:59:15	copumpkin:	yeah
06:59:17	gmaxwell:	copumpkin: I did mention a recovery mode for a reason!
06:59:22	copumpkin:	:)
06:59:25	gmaxwell:	but you could do N of M threshold signing.
06:59:37	copumpkin:	sure
07:01:11	gmaxwell:	But then you could be reasonably sure your hardware would stay mining as you intend and not get redirected off onto something that is mining a nasty fork or censoring transactions or doing things you don't agree with. Even if ninjas show up and threaten the operators.
07:01:49	gmaxwell:	(e.g. as a cloud host operator you'd probably want this so that you could turn away demands from ninjas)
07:01:52	lnovy:	well... I can imagine that working on some types of (current) asic hws, but not on anothers... Vendors would have to make it pretty hard for the firmare to be tamper resistant. But besides that, it's a very sound concept.
07:02:29	gmaxwell:	to be maximally strong it wouldn't be a firmware thing, it would be implemented entirely on the die... if it was well designed there would be no _economical_ way to bypass it.
07:02:51	gmaxwell:	e.g. you could bypass it by decapping the die and making some microscopic modifcation but that would cost more than replacing it.
07:05:22	gmaxwell:	or more realistically by abusing a recovery mode ... which I'd think would best be done by having to enable some pin that can't be enabled while normally mining and which good hardware doesn't wire to anything but a jumper.. and then mining uselessly for some sufficiently long span of time. ... though maybe you wouldn't even do that if you really want to include local dictators in your threat model.
07:06:01	Luke-Jr:	gmaxwell: do you think it would be practical to require the signature for every job?
07:06:15	lnovy:	Luke-Jr: +1
07:06:28	lnovy:	if you leak 1 % of power, nobody could know
07:06:57	gmaxwell:	1% is not likely that interesting. So it could be made pratical with every job but it would be slighltly more complex.
07:07:03	lnovy:	you would need to integrade things like stratum/getblocktemplate directly to firmware otherwise
07:07:38	gmaxwell:	What you'd do for that is that you generate a random mac key, and then encrypt the mac key to the asic.. and then use the mac key to authenticate all the work... and thats actually something that would let you easily auth every job.
07:08:00	gmaxwell:	though we might want to expand nonce space for improve how well that works.
07:08:13	lnovy:	hw can fluctuate up to 10 % afaik... and 5 % of every piece you have there starts to be interesting anyway
07:08:41	gmaxwell:	well I think 5% is _WAY_ better than 100% but I do think that this could potentially prevent leaks entirely.
07:09:06	gmaxwell:	(you don't want to sign and verify all work, but running a mac on all work is trivial)
07:09:22	copumpkin:	steve jobs would be proud
07:09:25	copumpkin:	* copumpkin runs
07:09:37	gmaxwell:	message authentication code... you know, a keyed hash. :P
07:09:42	copumpkin:	yeah yeah
07:09:49	copumpkin:	admit it, you're a fanboy
07:09:51	lnovy:	hmm... what about just ssl connection with strict counterparty verification?
07:10:03	gmaxwell:	you're not going to run SSL into an asic. :P
07:10:25	gmaxwell:	doing the protection only at the firmware level is probably too easily bypassed.. though the nice thing there is that we could deploy it today.
07:10:34	gmaxwell:	e.g. do it firmware level first to prove out the idea.
07:11:26	gmaxwell:	then later hardware moves the functionality onto the chips where it is economically tamperproof. Geesh this might be the first example of tamper resistant hardware that would actually be sound.
07:15:02	gmaxwell:	In any case, I think some really careful thought is required. It will have to be quite clever to balance the need for reliablity.
07:15:14	gmaxwell:	Otherwise people won't use it because they don't want to risk downtime.
07:15:28	gmaxwell:	the fact that it would prevent theft is nice though.
07:15:53	gmaxwell:	as lnovy notes, hardware varries and a cloud provider could be stealing several percent from you without you really being able to tell.
07:16:00	lnovy:	can a safe transfer of authenticity be done on a stratum<=>getwork proxy which is mostly running in the firmware next to the asic?
07:16:25	gmaxwell:	lnovy: thats why I mentioned increasing the nonce space.
07:16:49	gmaxwell:	though there is hardware increasingly doing stratum like work closer to the metal.
07:16:55	gmaxwell:	(e.g. avalon2 chips)
07:17:31	gmaxwell:	and you could potentially not authenticate the left rung of the stratum tree, but the right rung and prev block.
07:17:52	gmaxwell:	though that would still enable theft so better to have a scheme that can authenticate everything.
07:18:18	gmaxwell:	one fun thing is that you could require rekeying the mac periodically, so you could temporarily delegate the mac key to the firmware.
07:18:37	gmaxwell:	and it reports work back to you, and if it stops reporting back good looking work you just let the mac key expire.
07:19:09	gmaxwell:	though, again, that doesn't get you the good theft protection, since compromised firmware could swap out a small percentage of the work.
07:19:09	lnovy:	if you have firmware part to pair itself with asic whatever the vendor consider way, it would require to secure only the firmware part and this part can run ssl stuff...
07:19:25	gmaxwell:	thats really hard to secure in a way that can't be cheaply compromised.
07:20:16	gmaxwell:	basically anything on the firrmware can be compromised just by swapping out the controller boards, and then having a stack of controller boards you root with a SPI bus probe.
07:20:20	gmaxwell:	better than nothing
07:20:29	gmaxwell:	and something that could be implemented on basically all existing high end mining devices.
07:21:01	lnovy:	efuses, or just STM32F205xx can be paired and locked down pretty hard for keys to be economically unextractable
07:21:09	gmaxwell:	but not really what I'd consider a good end game, plus that doesn't stop the theft of small amounts of hashpower. (since you just root the controller and replace with one that steals 5%)
07:21:22	lnovy:	gmaxwell: you would pair asic with controller
07:21:42	lnovy:	no swapping of controller would be possible
07:22:10	gmaxwell:	maybe! yea, as I noted before the economics of this mean you just have to make it cheaper to replace the asic.
07:25:08	Luke-Jr:	gmaxwell: unfortunately, I don't think we could convince any ASIC manuf to do this.
07:25:55	gmaxwell:	I'm pretty sure we could get firmware-only level. ASIC level is another matter.
07:26:09	gmaxwell:	I'm less convinced than you are though.
07:26:25	gmaxwell:	I mean, if I went and found someone to outright pay them to do it, of course they'd do it.
07:26:38	gmaxwell:	I think a lot of people are concerned about mining consolidation.
07:26:49	Luke-Jr:	well sure, but they'd probably make a run for themselves without the limit too? :P
07:27:06	lnovy:	pretty much every vendor is trying hard to have his firmware/controller unhackable and failing... If we tell them how to do this right... it's a double edged sword..
07:27:11	gmaxwell:	why bother? I mean, if you control it, you have the keys, and it does you no harm.
07:27:39	gmaxwell:	hm? I don't know of any mining hardware vendor who is trying to lock down much of anything at all.
07:27:48	gmaxwell:	(hell, they all run gpl mining software…)
07:28:40	Luke-Jr:	[07:27:06] pretty much every vendor is trying hard to have his firmware/controller unhackable and failing… <-- really? what vendor is trying that? O.o
07:29:07	lnovy:	Ok, I overestimated... but afaik some BFL are only flashable with jtag no?
07:29:31	gmaxwell:	Luke-Jr: I guess they could make runs that claimed to have this functionality but didn't really... but I think really that no one would want such a thing. It's a liability that someone might attack you in some way to redirect your mining power. Better that it not be easily possible.
07:30:06	Luke-Jr:	lnovy: that's laziness.
07:30:21	lnovy:	* lnovy stands corrected
07:30:26	Luke-Jr:	gmaxwell: backdoor
07:30:57	Luke-Jr:	lnovy: in fact, they *intended* to make it PC-flashable originally..
07:31:03	Luke-Jr:	* Luke-Jr sighs
07:31:14	gmaxwell:	Luke-Jr: sure, but I'm doubtful that anyone would spend extra money and effort to do such a thing.
07:31:36	Luke-Jr:	gmaxwell: actually, something like this (minus the backdoor, I mean) *has* been done before..
07:31:39	lnovy:	another point of view: if the vendor offers a functionaly for your hardware to be "unredirectable", they can be made liable if this fails...
07:31:43	gmaxwell:	I know, the tricone miner.
07:32:11	gmaxwell:	This is applying that kind of idea for public good.
07:32:19	Luke-Jr:	lnovy: err, I don't think that's likely at all
07:32:32	Luke-Jr:	lnovy: the harmed party wouldn't be the miner, in most cases
07:32:55	gmaxwell:	I think if I owned a big mining farm I'd even be inclined to setup my control key as some threshold signing thing and delegate it off to other people.
07:34:00	lnovy:	Luke-Jr: if facility owner is smart... if he is dump and just redirects all power for couple of days and than run away...
07:34:21	Luke-Jr:	lnovy: you're assuming the facility owner is the attacker
07:34:43	lnovy:	which would be the truth in most cases
07:34:56	Luke-Jr:	least likely party in this case
07:35:06	gmaxwell:	I'd actually assume someone coercing the facility owner would be the attacker, except when you're talking about stealing a small percentage, in which case I'd expect it to be a staff person.
07:35:08	Luke-Jr:	more likely: 1) cracker; 2) government; 3) chip backdoor
07:35:22	gmaxwell:	or a cracker, indeed.
07:36:09	Luke-Jr:	I'll group physical-coercion in with cracker ;)
07:37:07	lnovy:	anyway some proposed "best-practice" cannot do any harm
07:37:09	gmaxwell:	government has a lot of possible submeanings. e.g. could be some tin-hat dictator in a funny place with cheap power, or a really misguided court order where it would be in the public interest to be possible to respond that you are technically unable.
07:38:21	gmaxwell:	in any case, I've had people involved with varrious cloud operations ask me how they can be 'safe' with some (usually insane) percent of the hash power. Mostly these questions have depressed me... but now I think I have an answer.
07:39:02	gmaxwell:	(they get asked because all these folks have insane business projections that make them have 9001% of the haspower by $future or whatever)
07:40:37	gmaxwell:	too fancy for an asic implementation... but in firmware you could make mining rigs themselves smart property.
07:40:52	gmaxwell:	and if they did gbt they'd even be seeing the network and would witness transactions changing their ownership. :P
07:41:26	gmaxwell:	would actually be kinda neat to implement smart property firmware... like ... you install a miner and enable smart property mode and set a maintance fee....
07:41:36	gmaxwell:	and then tada people start buying and selling the hardware you're running. 0_o
07:41:52	lnovy:	dat future!
07:42:06	gmaxwell:	I suppose it's logical that the first smart property should be miners.
07:42:51	lnovy:	well at least they would finally care for transactions :))
07:43:18	gmaxwell:	you could even have a nice hardware-vendor-can't-screw people scheme this way, though you'd never get a hardware vendor to buy in
07:43:44	gmaxwell:	where you only pay some cogs level cost upfront and you get a miner which is only willing to mine on chains where you've paid the rest of the miner's price to its maker.
07:44:12	gmaxwell:	probaby a bit too cryptowank there. :)
07:45:16	lnovy:	you still need to trust the vendor with this... so it's not entirely screw-proof, but very close
07:47:04	gmaxwell:	I think a lot of this stuff is a question about trust durability. I can trust you _now_ ... but later something changes and your behavior is suddenly untrustworthy.
07:47:31	lnovy:	OT: if you have some supermicro servers with ipmi, don't disable usb support in EFI setup, you won't be able to reach it again. Also when this happens, don't disable timeout in grub :D
07:47:35	lnovy:	#FML
07:48:42	gmaxwell:	you have some cash flow problem, you lose you mind, someone steals your identity or coerces you. I'm pretty sure most of the tremendous bitcoin failures started out honest. ... you can look at these tools as ways to pre-commit to not being evil in the future, even if you later decide you really really want to be evil.
07:49:09	lnovy:	yep, I don't trust myself in this :)
08:02:24	Emcy:	I neef btc
08:02:25	Emcy:	Btc want to exchange
08:02:25	Emcy:	#bitcoin-otc
08:02:25	Emcy:	Okk
08:02:25	Emcy:	How much you have?
08:02:25	Emcy:	How much btc do you have?
08:02:45	Emcy:	this guy has messaged me immediately like 3 times on joining
08:02:53	Luke-Jr:	here?
08:03:01	lnovy:	/ver rex5454
08:03:02	Emcy:	pm on this server
08:03:04	lnovy:	fsck
08:03:14	Luke-Jr:	he's in #bitcoin
08:03:20	Emcy:	i assume hes doing it to everyone
08:03:46	Emcy:	how do you tell what chan theyre on
08:04:07	Luke-Jr:	/whois
08:04:09	lnovy:	doesn't look like a bot
08:05:15	midnightmagic:	booted
08:05:40	Emcy:	thanks mm
08:14:32	gmaxwell:	http://www.smbc-comics.com/?id=3310#comic good thin #bitcoin-wizards doesn't write books on dating advice.
08:16:06	midnightmagic:	np
08:17:43	Snowleaksange:	ive been so busy gamedeving paid 0 attn to bitcoin
08:20:40	Emcy:	ha
08:57:11	lnovy:	http://youtu.be/3i3Mc66Au8s "rubber bullets"
08:59:01	lnovy:	fsck... sorry wrong window again
08:59:06	lnovy:	i'm trully sorry
08:59:09	lnovy:	completly off topic
09:43:40	Elriel:	andytoshi: the scheme I'm thinking of is not based on majority vote. It's based on entangled chains of signed blocks that form a network through their internal links.
09:45:08	Elriel:	since there is no consensus required in the system itself, it's pretty difficult to attack. even one honest node in the mix could make the attack detectable.
10:30:01	nsh:	hmm
10:33:55	Elriel:	the biggest problem is figuring out what is a good structure for how to entangle the chains. Otherwise it could be rather bandwidth intensive to use.
10:37:53	sl01:	Elriel: like block at each level with the highest "pagerank" is the block people use?
10:38:39	Elriel:	sl01: each node makes their own blocks. No consensus even attempted.
10:39:03	Elriel:	when you want some hash recorded in the system, only one node needs to include it in their block.
10:39:28	Elriel:	when verifying that, every node needs a bit different data to verify it's time.
10:39:37	Elriel:	depending on their location on then network
10:39:58	Elriel:	basically, they need a path through the entangled chains that leads to it from the timestamp server they trust
10:41:03	Elriel:	(also, it probably is not strictly necessary to trust any server at all, I just haven't figured out for certain yet)
10:41:19	Elriel:	it could well be enough to trust that there is one trustworthy server in the mix
11:11:33	nsh_:	nsh_ is now known as nsh
11:42:12	Guest2675:	Guest2675 is now known as maaku
11:42:41	maaku:	maaku is now known as Guest95405
11:44:22	Guest95405:	Guest95405 is now known as maaku
12:48:06	andytoshi:	Elriel: detecting attacks doesn't help you if you can't even determine which side of a fork is "the real one". and the type of trust you need here is impossible to get because of relativity of simultaneity. you are being way too vague, you need to write it down precisely enough that you can see exactly how a sybil/isolation/censorship/double-spend attacker is prevented from acting.
12:50:56	Elriel:	I'm not that far with this idea.
12:51:49	Elriel:	This could well be a bit more than I can handle by myself.
12:54:00	Elriel:	double-spend is not an issue on this layer, since there's only timestamping hashes. censorship resistance is obvious as there is no consensus. any node can include any hashes it wants in their blocks.
12:56:00	andytoshi:	a double-spend here would be if you can get A < B as well as B < A encoded in your network.
12:56:02	Elriel:	isolating uncooperating nodes would be the only way to do censorship
12:58:38	Elriel:	in most cases, it'll be clear as to whether A < B or B < A. When it's not, that'll be clear too. In other words, you can't prevent it, but you can detect it.
12:58:55	Elriel:	I think that's enough
12:59:37	Elriel:	in the layers above you can then decide what to do in such a case. probably best to go with "neither A nor B is valid" option in such a case.
13:00:23	Elriel:	alternatively, decide on some rule that resolves the conflict deterministically.
13:05:24	andytoshi:	how do you deal with the fact that two hashes A and B can exist in your merkle graph but neither has a path to the other?
13:05:32	andytoshi:	ie you have a poset but not a totally ordered set
13:07:05	andytoshi:	if A and B are not comparable, then i can add A to a path from B and B to a path from A -- now A
13:07:17	andytoshi:	then anyone depending on A actually being timestamped is screwed
13:37:57	Elriel:	andytoshi: ah, merkle graph, that's a good term for what the structure is. Thank you :) There is no way to completely avoid the problem you describe. You can only minimize the time window during which it's possible to have an unclear situation like that in general. Also, in case of complete network splits, the situation needs to be detected and if the portion of network you remain connected to is smaller than some limit, consid
13:38:19	Elriel:	this time window would then be the confirmation time.
13:39:26	Elriel:	every node has an identity, so it's possible to detect if nodes change or drop out.
13:42:36	Elriel:	also, about sybil attack, it'd at most allow the attackers to isolate your node, which is detectable.
14:20:16	zooko`:	zooko` is now known as zooko
14:26:58	andytoshi:	Elriel: i don't see how a sybil attack is detectabe, nor how there are any time windows, let alone 'minimized' ones, nor how network size can be estimated, nor how identity changes are detected, nor why you say "at most" allow attackers to isolate your scheme allows attackers to feed an arbitrary graph to an isolated node
14:37:18	Elriel:	andytoshi: every node signs their blocks with their own key. Network size can be estimated from the block headers + signatures that your node sees.
14:38:21	Elriel:	the time window I'm talking about is until the whole network has created a path to a particular transaction.
14:38:56	gmaxwell:	"created a path"??
14:39:24	Elriel:	merkle path through blocks of many nodes.
14:39:56	Elriel:	the path will of course differ depending on the node's "location" in the network.
14:41:40	Elriel:	ah, I mean particular has, this layer doesn't know about transactions.
14:41:44	Elriel:	*hash
15:11:34	zzyzx:	zzyzx is now known as roidster
15:12:04	roidster:	roidster is now known as Guest41109
16:03:44	killerstorm:	killerstorm has left #bitcoin-wizards
16:57:25	tippan:	tippan is now known as typex
18:09:43	rastapopuloto:	rastapopuloto has left #bitcoin-wizards
18:35:04	Burrito:	Burrito has left #bitcoin-wizards
18:56:40	gmaxwell:	Looks like another altcoin broken by difficulty rules that made dropping the difficulty low easy: https://bitcointalk.org/index.php?topic=546338.0
18:59:29	copumpkin:	lol, consensus was that Luke-Jr did it
19:00:31	sipa:	how was this consensus obtained?
19:00:40	sipa:	through the whodiditcoin blockchaim?
19:02:40	gmaxwell:	nah, I really doubt that.
19:03:04	copumpkin:	:)
19:03:29	copumpkin:	Luke-Jr: the ultimate altcoin bogeyman
19:06:01	andytoshi:	"The Bitcoin mafia will never let any altcoin succeed."
19:06:31	lnovy:	andytoshi: I was just about to post that here! :D
19:08:36	andytoshi:	y'know, i thought it was funny at the texas conference when Luke got all menacing "keep talking about SNARKs austin-boy and i might have to send phantomcircuit to pay you a visit"....
19:08:53	andytoshi:	damn mafia always keeping the good ideas down
19:11:39	sipa:	"that's a nice proof you have there. would be a... pity if it were to fall into that pool full of snarks over there..."
19:12:07	Luke-Jr:	andytoshi: O.o?
19:12:54	andytoshi:	Luke-Jr: i was making a joke about "the bitcoin mafia"
19:13:19	andytoshi:	which is referenced at gmaxwell's "auroracoin forked" link
19:16:39	lnovy:	"That would explain the poor luck on Eligius then... if the pools hashing power was directed at Aurora instead of BTC. If this is verifiably true, this will destroy Eligius too."
19:16:39	Emcy:	you know a snark is a type of alien bug used as a weapon in half life from 1998
19:16:43	lnovy:	:D
19:17:46	nsh_:	i wonder how infuriating it would be to the world mathematics community if you presented a zero-knowledge proof of some longstanding conjecture
19:17:47	andytoshi:	lnovy: >.< does somebody actually need to go do misinformation-clearing in that thread?
19:17:58	Emcy:	luke unilaterally annihalated a complete altcoin once and they wont let him live it down
19:18:31	lnovy:	andytoshi: he was corrected right away: "Does eligius work with scrypt? I thought it was bitcoin only." This is just hillarious to read
19:19:57	Emcy:	im pretty sure the alitcoin forum is bitcointalks ball pit
19:20:44	gmaxwell:	Emcy: hardly eradicated either, just mined it with an overwhelming majority of hashpower and charged insane transaction fees— and it was a really shitty alt, one that the p2sh code out of bitcoin and tried beating bitcoin to market with its own code— complete with an exchange within an hour of the coin being announced... but people are hyper nutzo about it.
19:20:46	Emcy:	every online community needs a ball pit, somewhere you can put the silly people to argue with each other while the rest get on with it
19:21:40	Emcy:	no doubt it was a scamcoin
19:21:51	lnovy:	every alt is
19:21:54	Emcy:	just saying people will never forget
19:22:51	Emcy:	vast majority of alts are premine or day 1 echanger scams or whatever
19:26:58	Emcy:	was something like auracoin really trading for >$1 per?
19:27:10	Emcy:	how many of these alts are over a dollar
19:27:22	Emcy:	wtf
19:30:49	gmaxwell:	well last trade is a noisy measure. At one point doge had a 'market cap' of 7 trillion or something because someone bought a small amount at an insane price.
19:31:27	Emcy:	lol
19:32:35	Emcy:	i think someone is going to do doecoin with a scrypt asic next for the lols
19:32:40	lnovy:	besides that, market cap is just pretty crappy metric anyway
19:33:35	Emcy:	mkt cap for anything is always a fantasy number imo
19:34:26	Emcy:	you want me to believe apple contains a value of 250 billion or whatever. They essentially sell toys
19:39:28	sipa:	* sipa will make an altcoin that has an impkicit coin assigned to every address
19:39:35	sipa:	infinite markrt cap!
19:41:20	kazcw:	for the market cap to be infinite, you'd need addresses of arbitrary length... and that would require innovating in an alt coin
19:41:41	lnovy:	just allow double spending :) ta-daa
19:42:17	kazcw:	you could do what infinitecoin does, and have a high enough coin limit that it's possible to overflow TxOutCompressor
19:42:26	lnovy:	or more like... require one of the input to be already spend to trasaction to be valid :D
19:43:01	gmaxwell:	I wonder if an altcoin broke the coinbase checks and allowed any txn to spend the all zeros txid how long it would take people to notice.
19:44:14	Luke-Jr:	gmaxwell: let's find out! :P
19:44:54	lnovy:	where can I mine^Wobstain that coin? =)
19:51:45	sipa:	kazcw: pretty sure i'm capable of doing that :)
19:58:25	kazcw:	sipa: I wasn't questioning your abilities, but the limitations of alt coins =P. There seems to be a law of nature that they don't do anything new
20:00:14	kazcw:	a core developer adding new features to an alt coin would be the unstoppable-force-meets-immovable-object of cryptocurrency
20:00:28	kazcw:	undefined behavior would result
20:02:03	gmaxwell:	well you take the number of new features created by said developer and divide it by the amount of innovation in the altcoin previously
20:02:06	gmaxwell:	oh crap.
20:06:05	jcorgan:	is there an altcoin graveyard/museum where you can take your grandchildren to warn them about the bad things that will happen to them if they don't study their crypto and don't do well in economics?
20:07:15	gmaxwell:	there really isn't, most people have never even heard of the earliest altcoins.
20:07:25	gmaxwell:	there are some lists but they're incomplete.
20:35:37	nsh_:	nsh_ is now known as nsh
20:44:55	amiller:	an altcoin graveyard would be nice.
20:45:07	maaku:	geistgeld is one with remembering
20:45:11	maaku:	7.5s rounds
20:46:23	jcorgan:	you could add an option to coingen.io to pay in advance for a plot/exhibit
21:11:51	andytoshi:	jcorgan my alts.pdf is supposed to be such a graveyard, every time i think about specific alts i lose my motivation to write tho :(
21:23:10	topynate:	the first zero knowledge proof currency should make for some interesting alts, actually. retain the initialization key and create as many coins as you want without anyone being able to prove you did it
21:26:43	nsh:	i doubt there's such a thing as undetectable inflation in practice
21:27:54	nsh:	and the suspect list is pretty short. dunno if it would be a game-changer in the scamcoin department
21:35:38	maaku:	nsh: there is in zerocash
21:36:20	maaku:	undetectable inflation that is
21:36:31	nsh:	well, until people realize the depreciation. wealth still can't be magicked out of cryptography :)
21:37:15	maaku:	nsh: with zerocash the person holding the CRS can print money in a way that looks like a normal payment
21:37:22	nsh:	sure
21:37:31	maaku:	only if everyone reveals their balances and adds it up can you tell there's inflation going on
21:37:40	nsh:	but there's a natural limit to how much you can do that before there is a noticeable effect on the economy
21:37:50	nsh:	even the federal reserve exercises moderation
21:37:59	gmaxwell:	yea, but that limit is likely enormous before its clearly detectable
21:38:06	maaku:	eh, you could go pretty darn far before people know for sure that's what is going on
21:38:08	gmaxwell:	like multiples of the money supply depending on the money velocity.
21:38:18	nsh:	mm
21:38:25	gmaxwell:	I dunno about you but I'd sure like an extra half of all existing bitcoins in my pocket...
21:38:35	nsh:	* nsh smiles
21:38:47	maaku:	if mtgox coins were stolen, that's 6% of the monetary base, and we're still debating what went on there
21:39:24	nsh:	it's an interesting game-theoretic value proposition: let's say only matt green can do it, his likely profit is pretty damn large before he can be outed, but if it's detected he's lynched for sure...
21:40:08	nsh:	(but obviously it would be vastly preferable for it to be impossible)
21:42:39	maaku:	well you only run into these issues when you have a single proving key that everyone has to use
21:44:22	nsh:	more proving keys wouldn't help though, would they? as far as i understand it, there's no trust-free zero-knowledge accumulator cryptosystem yet that doesn't involve the trusted destruction of some information during initialization
21:44:36	nsh:	(or verified destruction)
21:44:44	nsh:	(whatever that means)
21:45:57	gmaxwell:	well, for example, you could carry multiple proofs.
21:46:44	gmaxwell:	at the limit every user who cares about the result could have an initilization state and you could prove under all of them. :P
21:47:05	gmaxwell:	which sounds nuts if you're thinking about zerocash, but is perfectly reasonable for many contract applications.
21:47:56	nsh:	hmm, interesting
21:48:15	shesek:	someone should make http://xkcd.com/303/ with "confirming!"
21:48:40	shesek:	I'm wasting so much time waiting for transactions to get mined... I should really setup testnet in a box for that
21:49:32	gmaxwell:	regtest <3 ... block on demand.
21:50:05	gmaxwell:	we probably should have made the testnet rule 10 second blocks or something... its not like it matters if it reorgs like crazy.
21:50:14	gmaxwell:	remind me I said this next time we reboot testnet.
21:50:20	shesek:	yeah, that would've been smart
21:50:36	gmaxwell:	it would have been less different than the 20min rule too.
21:50:43	shesek:	blocks take forever in testnet - seems like blocks are only ever mined when the difficulty drops after 20 minutes
21:51:14	nsh:	bitcoinmafia will never let testnet succeed
21:51:18	Luke-Jr:	depends
21:51:25	shesek:	its almost exactly every 20 minutes, no one seems to be mining them with the regular difficulty
21:51:26	gmaxwell:	the difficulty is high enough from people testing in bursts that the 1.6GH/s I keep on testnet almost never gets a block.
21:52:00	gmaxwell:	I'd put more on it but I'm out of power. :(
21:52:18	shesek:	someone should do an testnet-as-a-service
21:52:33	gmaxwell:	in any case regtest lets you get a block instantly.
21:52:37	shesek:	with an api that allows you to just force blocks/transactions in, disregarding the regualr PoW and all that
21:53:13	shesek:	yeah, I should look into regtest
22:13:40	warren:	gmaxwell: is there scripts somewhere to replicate the tests that are in the first 500 something blocks?
22:14:53	gmaxwell:	mostly they're the tests that are in the unit tests. though the set is somewhat incomplete and has been improved by random later blocks.
22:19:54	maaku:	gmaxwell: the trouble is there's a lot of useful test cases in the current testnet
22:22:39	gmaxwell:	I don't think thats really much of a trouble.
22:22:43	gmaxwell:	it's easy to go find them
22:27:51	warren:	all the "tests" that break bitcoin-ruby, for example
22:31:44	gmaxwell:	sure, and they're all easily found e.g. just go extract every script that isn't one of the few common patterns.
22:37:15	Elriel:	if I ever create an altcoin, it'll most likely be 100% premined. The catch? The premine will be for addresses grabbed from the biggest established coins.
22:37:38	Elriel:	in proportion to their amount of the total coins
22:38:12	kazcw:	you have a creative approach to impracticality
22:40:43	Elriel:	this approach would work well with an altcoin based on cunicula's PoW/PoS combination. It has the demurrage for coins that don't participate in mining.
22:42:36	nsh:	how do coins participate in mining?
22:46:46	topynate:	just thinking out loud: for real PoS you would have to have blocks contain a proof of the form "the miner that found the hash for this block can spend this set of transaction outputs", right?
22:47:21	topynate:	so no mining pools, and no pubkey hashes - all the public keys would be visible as part of the proof
22:52:24	kanzure:	shesek: there's a docker container for testnet-in-a-box that can be very easily modified to be regtest-in-a-box. then you're at least somewhat partway done with 'as a service'.
22:52:29	Elriel:	nsh: https://en.bitcoin.it/wiki/Proof_of_Stake#Cunicula.27s_Implementation_of_Mixed_Proof-of-Work_and_Proof-of-Stake
22:53:09	kanzure:	shesek: eg https://index.docker.io/u/freewil/bitcoin-testnet-box/ (i've only ever used this in regtest mode. i didn't see a reason to try testnet.)
22:53:32	nsh:	Elriel, ty
22:58:16	mike4:	mike4 is now known as money