00:29:01	OneFixt_:	OneFixt_ is now known as OneFixt
00:30:41	jtimon:	gmaxwell maaku_ nsh I think it's the chain-hoping algos and not the filters what need to improve most, provided that you have a responsive enough filter
00:31:06	jtimon:	they are really dumb
00:31:19	nsh:	* nsh nods
00:32:14	jtimon:	they believe anything that's in some webs that calculate profitability simply from spot price without any look to market depth, volume or vollatility
00:32:40	jtimon:	http://www.coinwarz.com/cryptocurrency
00:33:31	jtimon:	It's very easy to put a small coin on top of that list with little money
00:35:06	jtimon:	and hop-miners jump into shitcoin just to find out later that they broke the price when dumping their mined coins into the market
00:36:56	jtimon:	a good algorithm just needs to target a time period, the market should make profitability tend to 0%
00:38:10	jtimon:	just not yet
00:40:13	jtimon:	I think the non-merged-mined SHA256 are in the worse position for chain-hoping
00:40:49	jtimon:	so I'm pretty happy with freicoin's filter, things will only get better when MM
00:42:04	jtimon:	and other coins that don't use the block height for demurrage care less about not being always 10 min
00:43:51	jtimon:	even terracoin survives with its random-like filter
00:46:58	gmaxwell:	jtimon: I'm more worred about things like long term behavior with fees being compariable in magnitude to subsidy and miners mining near breakeven in power cost.
00:47:53	gmaxwell:	and then things like filter overshoot making huge chunks of hashpower go unprofitable and shut off automatically. such a system could very likely be quite unstable.
00:48:10	gmaxwell:	e.g. a small overshoot oscilation magnifies until all the hashrate is turning off.
00:48:53	jtimon:	for the filter it's the same, you need to adjust rapidly when big hashing comes and goes
00:49:57	gmaxwell:	"it's the same"?
00:50:16	jtimon:	I'm not saying it's not a difficult problem, I'm saying you can model the filter with against random curves without modeling any mining economics
00:51:02	gmaxwell:	No you can't. A filter with overshoot behaves very differently in a non-linear system than does one which is critically damped.
00:51:11	jtimon:	there could be an earthquake destroying 40% of the hashrate and you should be preapared as well
00:51:37	phantomcircuit:	gmaxwell, is there a cap on how large the change in difficult can be for any one period? (either up or down) ?
00:51:38	gmaxwell:	What I'm pointing out is that some filters can actually cause system failure under some mining economics models.
00:51:47	gmaxwell:	phantomcircuit: yes, 4x.
00:51:54	phantomcircuit:	oh
00:51:55	gmaxwell:	(in both directions)
00:52:03	phantomcircuit:	so that's effectively only relevant for down
00:52:14	jtimon:	gmaxwell I think all filters could fail under certain conditions
00:52:19	gmaxwell:	the box filter is probably unconditionally safe.
00:52:27	jtimon:	you must chose the conditions you're not prepared for
00:52:46	gmaxwell:	jtimon: forget "prepared", I'm pointing out that some designs can fail when nothing changes or goes wrong.
00:54:18	gmaxwell:	In an enviroment where miners turn off when not profitable and turn on when profitable, a design that has overshoot can drive the system into instability. miners turn on, diff goes up, but it goes up too much and then even more miners turn off. then when it goes down it goes down by too much and more miners turn on, and each swing a great portion of the hashrate is being pulled into the oscillation.
00:54:42	jtimon:	I haven't studied any of the filters so I believe a box filter could be better and there's designs that can failt with a constant hashrate
00:54:46	midnightmagic:	keynesian beauty contest to the rescue?
00:54:57	midnightmagic:	:-)
00:54:59	jtimon:	but when's the point in chosing those?
00:55:36	gmaxwell:	jtimon: I think the design in freicoin is one that can fail with constant hashrate!
00:55:42	jtimon:	gmaxwell you can also manually change diff with a hardfork
00:55:50	gmaxwell:	(it has a pretty substantial overshoot)
00:56:05	jtimon:	oh, I see
00:56:10	jtimon:	I didn't know
00:56:11	gmaxwell:	jtimon: which is part of the reason that worrying about black swans is probably a waste of time, esp if the result is something thats riskier.
00:56:47	jtimon:	like most times, it's a tradeoff
01:00:00	jtimon:	in any case, maybe you're right that a less "responsive" filter is better long term, with a mature market without so much subsidy
01:01:22	jtimon:	but in this case (allowing bitcoin asic miners to come and go, but not to mine both at the same time) we desperately needed something more prepared for wild swings
01:03:10	gmaxwell:	my complaint there is not about responsive.
01:05:20	maaku_:	gmaxwell: the overshoot is not that substantial
01:05:30	maaku_:	the prarameters themselves are slightly underdamped
01:05:40	maaku_:	and the overshoot comes from the 144-block window
01:06:10	gmaxwell:	maaku_: Hm. from the FIR filter I saw you using before it could be as high as 20%, IIRC though perhaps it got changed?
01:06:11	maaku_:	so with big square-wave changes, it takes a dozen or more blocks to react
01:06:36	maaku_:	no, it hasn't changed.
01:07:27	maaku_:	i just have a different opinion of those numbers - overshooting by 20% when someone is toggling an order of magnitude more hash power than your entire network is pretty good, imho
01:07:54	maaku_:	we were <1Th/s, and getting hit by 10Th/s chain hoppers
01:10:58	gmaxwell:	thats not what overshoot means, thats called group delay when it takes a long time to react at all.
01:11:17	gmaxwell:	Overshoot is when it does react that it can react more than the change.
01:12:19	maaku_:	yes, well you want a little bit of that
01:12:26	maaku_:	you want it to be underdamped, slightly
03:37:28	justanotheruser1:	How many inputs and how many outputs can be in a transaction? Is there a limit on this other than 1mb?
03:51:28	justanotheruser1:	justanotheruser1 is now known as justanotheruser
04:35:27	jps_:	jps_ is now known as jps
06:31:46	maaku_:	justanotheruser: 18,446,744,073,709,551,615
06:31:55	maaku_:	you hit the 1mb limit long before then, however
08:07:47	adam3us1:	so i think i found a way to (network) efficiently and securely do SPV for single use addresses. now that i thought about it I dont see why i didnt see it before as it an application of NIFS which i described up as a problem statement of in 1996, and found a mechanism for in 1998 (novel use of IBE) and Boneh found a more efficient building block for in 2001 (the weil pairing)
08:08:17	adam3us1:	NIFS http://www.cypherspace.org/adam/nifs/
08:10:36	adam3us1:	it was thought up to provide forward secrecy for email where there is no interactive communication. read that. its basically like a public derivation variant of HD wallet concept but where anyone can be after the fact given a private key
08:17:49	adam3us1:	hmm maybe not ... gotta think more about this (just woke up:) i am thinking weil pairing gives the extra flexibiliy so you can have someone derive a public encryption key for you from a reusable encryption pub key and the previous block number, then do a derivation from the reusable address with a random factor by sender, encrypt factor with the derived pub enc key, and then afterwards you can derive the corresponding private dec key and s
08:18:56	adam3us1:	and therefore the query (the private key) could be unique to the block only, obviously very compact, useless for correlating with other blocks, and non-interactive
08:20:39	gmaxwell:	well, we can do what tor is looking to do with hidden services but its not blind to someone who knows your address.
08:21:59	gmaxwell:	hm. interesting yea okay
08:22:02	adam3us1:	yes ok i think brain woke up, its not NIFS its a diff problem statement a variant without the forward-secrecy as you need random lookup in the tag space, and to be able to safely send people the private key
08:22:40	gmaxwell:	so how about this: take the reusable address scheme, but make the ECDH pubkey be pubkey + H(blocknumber)*G
08:23:02	gmaxwell:	the problem there is that it has the private key unzip attack that BIP32 has.
08:23:04	adam3us1:	gmaxwell: basically each user is their own IBE server, they publish the IBE params as their reusable public address
08:23:30	gmaxwell:	yea, I don't think this is doable without pairing— the EC addition way to do it has the unzip attack.
08:23:58	adam3us1:	gmaxwell: so with IBE your identity is your key, so encrypt with the pub key derived from the previous block hash as "identity"
08:24:51	adam3us1:	gmaxwell: then do the normal sender choose rndom factor, encrypt factor with the derived pub key, ten to delegate a per block decrypt capability, you send the node the corresponding private key that you derive using your IBE private key.
08:24:55	adam3us1:	gmaxwell: agreed
08:25:08	gmaxwell:	then again the pairing is only needed for recognition, so it could be employed here. it would allow you to produce unique per block recognition keys. Someone you gave your reconigition private keys to could only reconize your transactions that used those keys.
08:25:10	adam3us1:	gmaxwell: unfortunately that lets weil-pairing crypto into the tent
08:25:26	gmaxwell:	But its only for privacy, I'm okay with that, but it's an implementation barrier.
08:25:30	adam3us1:	gmaxwell: yes.
08:26:19	gmaxwell:	(IMO thats how we should be using pairing in cryptosystems: for lower value applications, and solving things that can't be solved any other way)
08:26:28	adam3us1:	gmaxwell: well its a start, a proof of concept that its possible. petertodd started to think it maybe provably not, but that seemed wrong to me, and its a good thing he asked the q of can u prove it not, cos it triggered me to think in the other direction :)
08:27:45	adam3us1:	gmaxwell: yeah, if it has a sane failure mode. there maybe ways to contain the failure a bit with normal mechansims eg a few IBE keys or such
08:28:23	adam3us1:	gmaxwell: also i think IBE is technically overkill we dont really need a comm channel, that is a side effect of the previous mechanism. so we may be able to do better.
08:29:13	adam3us1:	gmaxwell: we just want a per block discriminant private key, we dont actually need to allow the node to decrypt something, it can give it to the SPV node and it can decrypt it, itself
08:29:19	gmaxwell:	well really what we want is a BIP32 like derivation which doesn't have the unzip attack.
08:29:30	adam3us1:	gmaxwell: exactly.
08:31:07	adam3us1:	gmaxwell: i dont think u can do it like that tho, because thats what i was trying to do with NIFS and I made and broke a few mechanisms 1996 and concluded you cant do it with DL, hence the IBE connection to NIFS 1998, and then Boneh weil pairing 2001 made it secure/efficient (but esoteric)
08:33:34	gmaxwell:	::nods::
08:34:25	adam3us1:	gmaxwell: but this seems something with lower requirements, more like a new problem statement, so maybe something below IBE can be found. anyway i was excited to have a proof of concept, even weil pairing using... have to think about that next step more :)
08:35:44	gmaxwell:	I'd thought about using the prior block as an identity parmeter but I didn't see how to get away from simulation by anyone who knew the address... the IBE approach indeed would work.
08:39:33	gmaxwell:	petertodd: to decode for you, since you may not be familar with IBE stuff: The idea is that the user has a master private key, which results in a master public key. Anyone can take a prior block hash and combine it with the master public key to get a session pubkey which could be used to encrypt a chaincode included in an OP_RETURN. Using the master private key the user can derrive the session private key, which can then be used to ...
08:39:39	gmaxwell:	... reconize transactions using the same session key.
08:40:07	gmaxwell:	This all sounds a lot like type-2 derrivation, but it doesn't have the unzip problem: having the session private key doesn't help you derrive any other session private keys.
08:41:07	gmaxwell:	(In IBE (identity based encryption) this is all used a bit differently: the master keys are held by a CA, and the session ID is your email address, and now anyone can make a public key for you— but you need the CA's help to get your private key)
08:44:00	gmaxwell:	In fact, if we use this only to encrypt bait, then we can make it more denyable by leaving authentication out of the cryptosystem.
08:45:08	gmaxwell:	E.g. the includes an encryption of a random value with the least significant 8 bits set to zero. Incorrect decryptions will sometimes turn up fake matches.
08:49:26	adam3us1:	gmaxwell: ah nice. its absolute worst case failure mode is what peter was proposing... bloom bait/prefix
08:49:43	gmaxwell:	yea, if you break the cryptosystem you just get bloombait.
08:50:04	adam3us1:	gmaxwell: yes i was thinking also you could send a few dud keys to confuse things, but this is better and could use your like 8 bloom baits, ie one could tune it
08:51:04	gmaxwell:	downside vs bloombait is that its not indexable.
08:51:11	adam3us1:	gmaxwell: i mean you could send the node your block priv key and a few random priv keys. but the extras will never match. by doing bait we get that ability
08:51:42	gmaxwell:	yea, I was thinking about that when I got to the encrypted bait construction... the never matching makes it obvious which ones are real.
08:58:53	gmaxwell:	one interesting thing about the encrypted bait construction is that its attack resistant.
08:59:09	gmaxwell:	a normal bait can be attacked by some high transaction volume jerks choosing the same bait as you.
09:10:06	gmaxwell:	downside is that the it has moderately high overhead, I don't see how to get the overhead under two group elements.
09:10:21	gmaxwell:	but perhaps when I think some more I'll see a way to get it down to one.
09:18:36	adam3us1:	gmaxwell: yes i thnk there maybe scope to go further or to non IBE potentially because the requirements are weaker than what it provides. lets see - having one stepwise clear improvement often helps unlock thinking about the next optimization
10:17:36	BigBitz:	BigBitz has left #bitcoin-wizards
10:37:30	jtimon:	oh dear, http://bitcoin.stackexchange.com/questions/21036/are-namecoins-obsolete-with-the-upcoming-bitcoin-0-9
10:38:00	jtimon:	how do we explain this?
10:38:29	jtimon:	why so many people think "bitcoin 0.9, now with arbitrary data"
10:38:31	jtimon:	?
10:49:37	nOgAnOo:	Probably because of what Gavin said about Ethereum?
10:49:53	nOgAnOo:	"we can adapt anything into bitcoin.
11:00:37	wumpus:	can doesn't mean will, certainly not on such a short timeframe
11:02:08	_ingsoc:	That's just what you say to keep people happy.
11:03:43	_ingsoc:	Innovation can end up hurting value because it's change.
11:04:26	_ingsoc:	So you naturally tend to avoid what you perceive as dramatic change.
11:05:05	_ingsoc:	If Ethereum could do what Ethereum wants to do by contributing code here, there wouldn't be Ethereum, would there?
11:05:17	_ingsoc:	As an example.
16:02:27	tacotime_:	tacotime_ is now known as tt_away_
16:02:42	tt_away_:	Oh whoa, Gavin is here. :)
16:02:52	tt_away_:	Welcome
16:36:53	adam3us1:	can someone explain to me how the batching of an epoch of blocks works in bloom filtering?
16:37:30	adam3us1:	TD said it works via query for 500 blocks in a batch to reduce network round trips.
16:41:39	gmaxwell:	I don't know that it matters, in that since all this would need new network messages you could just also send a list of 500 keys along with the 500 blocks. Though batching makes sense for another reason: since a txn isn't guarenteed to show up in the next block you need to use past keys too, and the matching has O(N*M) complexity.
16:42:36	gmaxwell:	so usinge fewer keys, say one for every 72 blocks, may make sense.
16:43:55	adam3us1:	gmaxwell: i was wondering re the second problem if the sender could identify the block they were thinking of when they derived it.
16:44:23	adam3us1:	gmaxwell: then they could be indexed by sender block and that bit could be deterministic and O(N) instead
16:46:04	adam3us1:	gmaxwell: the other thing is (and i started writing a reply to TD on bct) that i am not sure you gain security by using different keys in a batch because its anyway implicit (*) if all the queries are in the same request that they're yours (or candidates if you smear it a bit with your extended bait idea)
16:46:41	adam3us1:	gmaxwell: (*) the other possibility being to relay queries via a hop encrypted, then queries could be a mix of yours and other peoples
16:47:25	gmaxwell:	the batching doesn't hurt except in so far as it reduces your minimum connection granularity.
16:49:07	adam3us1:	gmaxwell: well if i connect from IP-addr#1 and request query of block 1,2,3 with key k1,k2,k3 chances are those tx are all mine, so the node learns those 3 are probably owned by one person across 3 blocks
16:50:16	adam3us1:	gmaxwell: whereas if i connect from ip-addr#1 and request query of block 1 with k1, then reconnect from ip#2 later, or connect to a diff node and ask for query of block2 with k2, then even if node 1 and 2 collude they dont know if thats one user... (and optional relaying of queries and responses could blur that together)
16:50:27	gmaxwell:	yes, right but say you make your batch 1000 blocks. Then for blocks 0-100 you're connected to one node ... and 200-300 another node .. and so on. If your batch had been smaller you would have leaked less.
16:52:29	adam3us1:	gmaxwell: smaller batch = less leakage, a tradeoff, but here the query data is presumably much smaller than a bloom filter, so it would be nice to aggregate multiple users queries into a block via relaying (maybe).
16:53:02	adam3us1:	gmaxwell: "batching doesn't hurt except in so far as it reduces your minimum connection granularity" i think you mean you optionall ramp it up, but by having epoch size 1 key derivation then you can go down to individual if you want later
16:58:48	adam3us1:	oh i guess another security argument weil pairing is probably stronger than connecting to random internet nodes and delegating query to them re node-capture sybil attack. (ie the privacy security relies on avoiding node capture)
17:41:43	adam3us1:	gmaxwell: you know the weil pairing itself is significantly amenable to multiplicative derivation tricks. you might be able to have each node multiply by its H(IPaddr#) or such querier known guid, or sent over comm channel on other connect time response, and then be able to make different query keys for the same data on different nodes, making it harder to observe redundant checks without needing to use encryption between nodes
17:45:40	gmaxwell:	adam3us1: related, if the bait scheme were similar to the one I suggested, you could intentionally make your bait searching radius half sized and connect to two severs and give each of them half your radius. so some of your transactions would learn via one, some via another... though they'd have the same query key. Probably not worth the complexity.
17:49:28	adam3us1:	gmaxwell: yes. overall seems quite exciting :) we could improve privacy & anon-set for SPV vs bloom, save bandwidth vs bloom query. Abandoning one-use addresses seems risky because of the reliance on weil-pairing for privacy otherwise that would be a nice simplifying assumption and mesh with hard to shake user comprehension problem (or UX issues that dont show that well). Damn pity there so far no way to do it with ECDL
19:06:55	justanotheruser2:	justanotheruser2 is now known as justanotheruser
19:16:02	_ingsoc:	_ingsoc is now known as Guest35297
19:46:28	_ingsoc_:	_ingsoc_ is now known as _ingsoc
22:28:34	comboy:	hey guys, I keep thinking about some p2p web of trust + some pagerank alike algorithm, also I keep wondering if it would be possible to be able to get score for somebody (based on my trust weights), without trust weights being public, maybe you have some random association terms, links or papers to throw at me?
22:29:20	c0rw1n:	random association term : freenet
22:29:43	c0rw1n:	they have a web-of-trust, no idea how public it is
22:31:24	gmaxwell:	comboy: I've thought about this sort of things before, and the best I can come up with is multiparty computation.
22:31:49	gmaxwell:	one problem is that you have information leak attacks if someone can constantly query the system.
22:32:43	comboy:	c0rw1n: thx, good hint, but it seems just to fight spam and quite simplified compared to what I'm thinking of
22:32:47	gmaxwell:	E.g. say I want to know if you trust c0rw1n. Okay, so I make a new sybil account which only trusts you, and then I query the system and find out the sybs trust of c0rw1n. The result is that I know that either you trust him or at least that there is a transitive relationship.
22:34:23	Alanius:	comboy: there is some work being done on reputation in pseudonymous networks
22:34:38	gmaxwell:	with multiparty computation you could have N folks combine in order to answer queries on the transitive trust without disclosing the graph, and if you imposed some cost on queries (e.g. have to pay a fee to the bitcoin network per query) then you could prevent an attacker from constantly querying it to drag out the information. Downsides: multiparty computation isn't pratical today, and the participants would need to be online.
22:34:55	Alanius:	not sure if it's what you're after, but you might want to take a look: http://freehaven.net/doc/cfp02/cfp02.html
22:35:28	comboy:	gmaxwell: yeah, that is a problem, but maybe you could send queries only to nodes who trust you for example.. I'm not even sure it would help... but if you would be not getting full info with some random noise..
22:35:42	gmaxwell:	Personally, I think reputation is nearly worthless in anonymous systems. :P
22:36:04	nsh:	could the graph not exist publicly (or queryably) in some heavily disjoint form that can be recovered using private correspondences (wallet-like identities)
22:36:04	nsh:	?
22:36:06	comboy:	well it is without this kind of system
22:36:31	Alanius:	pseudonymous != anonymous :)
22:36:48	comboy:	yeah identities equivalent to addresses in your wallet would also be some idea
22:36:52	Alanius:	in anonymous systems reputation is indeed worthless
22:37:05	comboy:	yes
22:37:05	gmaxwell:	comboy: well, see for example some of the information theoretic PIR stuff that lets you have a database which can be privately queried and which is secret from the servers if some threshold of the servers do not collude. But I don't know how to create the initial database privately except via MPC, and I don't know how to reliably rate limit access. And trusting servers to not collude is prety lossy.
22:37:33	nsh:	(reputation only becomes worthless asymptotically as the cost of newnym'ing goes to zero)
22:38:05	gmaxwell:	Alanius: even in pseudonymous systems. We see lots of cases in bitcoin-otc (one of few examples ofa pseudonymous wot system where there is actually something at stake) where scammers farm identities until they a trusted then rob people blind.
22:38:39	nsh:	to be fair, that's also a pretty stubborn feature of the non-technological world
22:39:21	comboy:	I mean as far as my quite dumb crypto mind was thinking it would require some p2p client running, I can't imagine it as just a static db somewhere
22:39:51	gmaxwell:	I think it's helpful to think about the benefit of 'reputation' systems in terms of "seperation" e.g. how powerful are they at separating good participants from bad ones. And I think a lot of ideas actually turn out to have _negative_ separation: they actually increase the density of bad people because they impose costs and good people just walk away since what they were going to do wasn't that profitable for them, whereas bad ...
22:39:57	gmaxwell:	... people don't mind the costs because they're a minor cost of doing business (and because the learning how it works part is amortized against many identities)
22:40:12	comboy:	gmaxwell: theoretically pagerank + your connections could prevent farming, once somebody goes rogue, ranks of whoever trusted him goes down
22:40:56	nsh:	well, if you consider it as a separation/classification problem then the system has to be negentropic, which means some resource of order must be consumed
22:41:00	gmaxwell:	comboy: no, it doesn't because obviously your system needs to be welcoming to new people (or it will fail), and so they just simulate new people.
22:41:06	Alanius:	gmaxwell: that's a fine insight
22:41:25	nsh:	(external resource)
22:41:37	comboy:	it could be much more than such kind of separation, because weight could be vectors, this could be coding skills instead of trust, in an istant I know if I want to work on this guys project or find something else
22:41:42	gmaxwell:	nsh: except honest participatants often trade neutrally e.g. their gains are maginal in competition with others. So any resource costs on honest people are much harder than resource costs on dishonest ones.
22:42:12	nsh:	mm
22:42:56	comboy:	gmaxwell: you would have to get trust from somebody in the existing network, it could be partitioned though (but it's quite impossible it would on the large scale), so somebody is risking their trust to accept you
22:43:18	gmaxwell:	I saw this a long time on Wikipedia. Lots of antivandalism measures exclude vandals, sure, but they exclude even more grandmas. ... because grandma is not as eager to contribute as many vandals are. The result is negative separation though the absolute decrease in vandals is more salent.
22:43:36	nsh:	* nsh nods
22:44:10	gmaxwell:	comboy: a while back I tried to float in OTC that we shouldn't be "trusting" each other, we should be insuring each other... that would make it have more meaning.. but I was never able to get traction for that.
22:44:46	nsh:	that makes sense, but it's got higher overhead and trickier
22:44:47	c0rw1n_:	oooh what a good idea
22:45:29	comboy:	yeah, probably insuring is a better term
22:46:36	comboy:	but I really like to hope it could be done with some crypto magic without revealing your weights... at least not to people above some connection degree level
22:47:48	comboy:	Alanius: thx for that link, I also need to read more regarding MPC
22:48:34	Alanius:	I think you could do it with cryptomagic
22:48:50	RoboTeddy:	could we have a combined proof-of-work proof-of-destruction blockchain? the more coins you prove you destroy in the block you're mining, the lower the required bound for your POW
22:48:57	gmaxwell:	well I had some success with the insuring thing, in that a couple times when people I knew from elsewhere showed up in otc wanting to trade but I didn't want to trade I publically offered to personally insure their trade and people rapidly traded with them on good terms too (e.g. not charging them like a risky transaction)
22:49:26	gmaxwell:	RoboTeddy: probably not, because coins destroyed in a non-successful blockchain are free.
22:49:30	Alanius:	imagine this: every node has an accumulator; nodes can increase other nodes' accumulators by an amount equal to how much their own was accumulated - which they keep secret in a zero-knowledge fashion
22:49:44	nsh:	gmaxwell, so could you script a multiparty vouching system using clever transactions?
22:50:02	gmaxwell:	RoboTeddy: e.g. I can make a fork where I destroy allmost all the coins and then it looks very attractive to you, so long as I'm confident it wont be the surviving fork doing this cost me nothing.
22:50:50	nsh:	(so that the more people vouch for someone before a trade, the lower their share of the insurance is it turns sour)
22:50:55	nsh:	*if
22:51:09	RoboTeddy:	gmaxwell: good point, thanks
22:51:38	gmaxwell:	nsh: well the problem you run into invoking transactions is that most fraud is not trustlessly decidable
22:51:45	comboy:	Alanius: yes that's the computation part, but this leaking information with checking your score on people depending on whether you trust somebody or not, example that gmaxwell gave at the beginning
22:51:53	nsh:	right
22:52:39	gmaxwell:	nsh: e.g. I think most of the cost in insuring another trader isn't the actual insurance, its the getting pulled into a dispute should one arise.
22:52:57	comboy:	this insurance thing reminds ripple a bit btw
22:53:25	gmaxwell:	my personal standard in OTC is that that I don't give higher ratings (e.g. greater than +1) unless I'd be willing to help someone collect on a debt that I agreed was real.
22:53:30	gmaxwell:	but I'm weird.
22:53:31	c0rw1n:	comboy well the rippling is a great idea
22:53:35	nsh:	hmm
22:53:45	RoboTeddy:	if one lengthens their fork significantly by destroying lots of their coins in it, they might not be able to safely assume their fork won't survive -- if it's the longest, people will adopt it
22:54:42	gmaxwell:	RoboTeddy: yes, but you weaken other security assumptions, e.g. bitcoin is generally pretty robust against short term network isolation attacks, when you can assume that the attacker doesn't have hashpower (or otherwise they'd prefer to just mine honestly)
22:55:19	RoboTeddy:	gmaxwell: ok, that makes sense, thanks
22:55:21	gmaxwell:	That kind of idea basically undermines the notion in POW that you're buring a scarce resource so you better darn well burn it on the one true successful consensus.
22:55:53	RoboTeddy:	gmaxwell: it makes a lot of sense when you think about it from that perspective
22:56:48	nsh:	hrmm
22:56:50	gmaxwell:	RoboTeddy: I think you can do things like burn resources in one place and use the evidence of the burn in another, and get something working there. E.g. burn bitcoins to mine teddycoins works so long as your bitcoin burn commits to a single unique teddycoin block.
22:57:13	gmaxwell:	it just doesn't obviously work internally. e.g. burn teddycoins to mine teddycoins. :)
22:57:59	RoboTeddy:	interesting; so, you could have a pair of currencies which each burn to prove work on the other
22:58:20	RoboTeddy:	brb mining genesis block for teddycoins
22:58:24	gmaxwell:	I think if the relationship was cyclic like that then you could attack them as a group.
22:58:36	gmaxwell:	e.g. tread it as a single system and attack both.
22:58:42	gmaxwell:	s/tread/treat/
22:58:57	RoboTeddy:	also a good point. so you'd need an acyclic DAG
22:59:23	RoboTeddy:	(along with an "ATM machine" -- I guess all DAGs are acyclic)
22:59:37	gmaxwell:	I think you can do things like have bitcoins mined by burning power, and teddy coins mined by burning bitcoins, and ninja coins mined by burning teddycoins, and that all works out okay.
23:00:12	RoboTeddy:	since the whole system is "grounded" by burning power/cycles
23:00:22	nsh:	as long as the bottom turtle is sitting on a pile of work (hash rounds)
23:00:49	comboy:	gmaxwell, regarding otc, if this would be insurance network, I wonder if disputes could be automated, I mean higher rank always wins, but I guess possibly taking some hit on it's rating (I'm kinda mixing insurance with public WoT here)
23:01:09	gmaxwell:	It doesn't have to be power but that works really well. The necessary criteria is that it burns something and that the burn can commit to the thing you're mining. E.g. you could have a coin burned by getting hashes into court filings (if you assume there existed a court which cryptographically signed its document submissions)
23:01:56	gmaxwell:	You can't have your POW be smashing irreplacable artwork because there is no way to create a cheaply verifable proof that you smashed the artwork in the name of confirming a particular consensus state.
23:02:33	RoboTeddy:	unless you cut the artwork into the shape of particular hashes ;D
23:02:57	RoboTeddy:	(but could fake paintings, so not cheaply verifiable)
23:03:28	gmaxwell:	in particular, it's hard to decide if a painting (real or not) was valuable to begin with. :P
23:03:38	gmaxwell:	power/computation is a bit more objective. :P
23:06:45	gmaxwell:	I think this subject is interesting mostly not for the reason of building more resource-burning-consensus systems— in part because I'm really unsure of how generally applicable resource burning consensus really is— but because I think resource burning anti-spam/anti-dos is interesting and that since bitcoin is a cryptographically provable resource you could use it in those systems.
23:07:05	gmaxwell:	Then again, hashcash has not really been widely adopted. So, ::shrugs::
23:07:35	gmaxwell:	part of this, I suspect is that seperation problem: often attackers are more willing to use resources than honest users.
23:09:42	comboy:	Alanius: got to some nice papers through this link you gave me, thanks a lot
23:12:39	Alanius:	:)