01:34:30	qwertyoruiop:	qwertyoruiop is now known as Guest92930
02:44:58	Guest92930:	Guest92930 is now known as qwertyoruiop
03:48:05	Guest6680:	Guest6680 is now known as qwertyoruiop
10:17:58	cr3pe:	cr3pe has left #bitcoin-wizards
10:20:46	airbreather_1:	airbreather_1 is now known as airbreather
12:45:20	nsh_:	nsh_ is now known as nsh
15:58:31	gmaxwell:	The stupid, it burns: https://bitcointalk.org/index.php?topic=581635.0
16:02:12	sipa:	gmaxwell: /ignore is your friend
16:02:35	gmaxwell:	I'm sure not responding.
16:04:04	gmaxwell:	But it's concerning and sad that there isn't anyone with a sensible response (like Bitcoin can't just be changed like that by a bunch of people running alternative software; or PoS appears to be non-viable) in the first page.
16:08:26	jgarzik:	gmaxwell, nobody clueful has the energy to respond to the 1,000,000th unoriginal, stupid proposal in a calm, education-laden manner :)
16:09:56	gmaxwell:	sure, but why didn't someone half-clueful respond pointing people to some of the N other times this sort of thing has been discussed?
16:16:41	sipa:	gmaxwell: because half cluefull people either don't visit the forums, or think the same as you :)
16:18:10	gmaxwell:	I would have responded if it wasn't on page 11 by the time I saw it. :P
16:18:22	gmaxwell:	At this point it would be pointless.
16:18:57	sipa:	make a new post :p
16:19:50	gmaxwell:	I think I'll ask 'cbeast' or 'itod' to edit their front page post to include some useful points.
17:28:32	reipr:	Anyone have experience using https://github.com/ConceptPending/proveit ?
17:28:42	reipr:	The numbers are not adding up for me in my tests.
17:31:54	reipr:	I've followed the instructions on the site, generated the string for my users to verify it. The root node sum does not equal the sum of all the other nodes
17:32:19	reipr:	Im summing it myself using decimal.Decimal
17:33:54	reipr:	nvm, sorry to bother I got it
17:35:11	gmaxwell:	reipr: what was it?
17:36:54	reipr:	I wasnt summing the nodinfo node as well.
17:37:02	reipr:	Its still not verifying, but thats not the reason
17:37:16	reipr:	Im not sure why at this point why its not validating
18:00:06	reipr:	nope, doesnt verify.
18:00:16	reipr:	Validates on the backend, but not the frontend
18:03:11	reipr:	Hopefully its something that I am doing. I wanted to use the static-verify.html in the exact form from github and tell my users that they can see its the same, or if they are more comfortable they can use the static-verify.html from the guthub page
18:03:37	reipr:	github*
18:05:46	Dizzle:	Dizzle is now known as Guest90072
18:18:33	BCB:	problem is when a reader seems someone mention "proof of work" or "proof of stake" they just assume the poster knows wtf they are talking about (because most of the readers don't have any idea what that means) and the FUD begins.
18:20:00	tacotime:	Proof of stake really refers to a collection of complicated systems, some of which are implemented and some of which are theoretical.
18:20:13	tacotime:	Whereas proof of work is just a simple concept.
18:24:40	hearn:	i sometimes ponder whether you could build a bitcoin-like consensus system on a stream of digital signature votes
18:25:07	hearn:	that is, handwave and assume some central authority maps people to keys 1:1. now how do you build a p2p consensus method on top of that
18:25:08	gmaxwell:	hearn: depending on what you mean by bitcoin like, sure— trivially.
18:26:29	hearn:	i guess i mean, with a block chain. i.e. the same, except that people vote by signing with their key instead of hashing
18:26:57	gmaxwell:	hearn: you require that every block be signed by half the keys. If you try to have one signature one block you run into the problems that the POS coins have (but that implementation works for that)
18:27:21	hearn:	i’d like to assume an open world. no pre-registration of keys. miners come and go as they please.
18:27:59	hearn:	or at least, within limits, i.e. you can assume there is no extremely sudden spike or fall in miners, as bitcoin assumes some kind of smoothness in the mining power curve
18:28:13	hearn:	also: scalability, etc.
18:28:55	hearn:	i was wondering if you could potentially have lots of signatures on recent blocks, and then use SCIP to compact the signatures down, i.e. run sig checking under zkp and attach the proof
18:31:46	gmaxwell:	Most of the POS problems go away if you can afford quorum signing (e.g. using some compression of the signatures) and can prohibit parties from signing a parallel fork (e.g. by invalidating their keys if they do).
18:35:04	hearn:	i’d think there’s still the conceptual issue that the set of rich people and set of people who wish to run full nodes might not overlap that much
18:35:49	gmaxwell:	Sure, but I don't think from a consensus algorithim perspective that matters much, I just meant you could get one from the other by changing how you manage that set of keys.
18:36:50	hearn:	to invalidate someone’s keys because they signed two parallel forks, i guess you’d need to be able to embed a proof that they did it into the chain itself, so that key blacklisting is permanent and recorded
18:36:52	amiller:	the timing element is important too
18:37:16	zooko:	* zooko reads with interest.
18:37:42	gmaxwell:	POS in its simples forms runs into problems where nothing discourages you from mining multiple forks, in fact you're rather encouraged, since doing so increases the odds that your blocks will have a high density in the chain (e.g. keep trying histories until you find one where you are the selected keyholder for all the blocks). So most of the proposals in that space are around fixing that.
18:38:24	jgarzik:	heh, in office we just talked about event chains, targeting applications that need to coordinate near-real-time events like gaming environments. Spawned by that mailing list quick-block thing from Sergio.
18:38:25	tacotime:	that'd be an interesting way to do it. i'd just been using PoW to prevent forks for my implementation; without very strong PoW it doesn't work.
18:38:29	amiller:	lets say you had a perfect form of that countermeasure, where if anyone gets a whiff of two signatures then you're signature is no good, is there any obscatle left?
18:38:56	jgarzik:	It was interesting to consider incentivizing miners to choose chains based on variable difficulty
18:39:06	gmaxwell:	PPC 'addresses' this by requiring POW blocks, and having the developer sign them, and only basing the stake selection on the POW. (otherwise the security just reduces to POW but with no promise the POW is strong)
18:39:08	jgarzik:	Higher PoW target implies higher fees, etc.
18:39:50	hearn:	i must admit i never studied proof of stake much
18:40:01	tacotime:	It's amusing to see that BlackCoin hasn't trainwrecked yet.
18:40:11	gmaxwell:	As far as I can tell NXT is protected by the code not being completely open. 0_o
18:40:17	hearn:	does it not lead to people who already own a lot of coins being able to mine more blocks, and thus become even wealthier?
18:40:24	tacotime:	As it's using PPC PoS but no PoW.
18:40:34	gmaxwell:	hearn: the PoS reward is very small.
18:40:58	tacotime:	hearn: yes, that's why on my fork I always made PoW reward 2x PoS reward. But yeah, in PPC it's only 1% per year.
18:41:17	gmaxwell:	tacotime: funny, PPC originally didn't have the behavior I just described. and it was attacked, with the PoS-nothing-at-stakeg-grinder solving all the blocks, but it surived because the developer block signing mechenism.
18:42:34	tacotime:	gmaxwell, Right. BlackCoin tried to get around this by reducing search space for timestamps in the future to 10 minutes, but I suspect that within a reasonable timespan someone will attempt a doublespend and throw the network into catastrophe.
18:42:36	hearn:	you can create a proof of double-chain signing by taking two blocks and then presenting a chain of headers from both blocks back to a single parent block. perhaps even using the smartspv proofs
18:42:58	nsh_:	nsh_ is now known as nsh
18:42:58	hearn:	such a proof should be small enough to embed into the block chain itself, leading to invalidation of that signer. *if* you have some kind of stable/expensive miner identity, of course
18:43:14	tacotime:	hearn: I'm not sure if you read vitalik's proposal, it was something along those lines
18:43:29	hearn:	not sure which proposal you mean, so i guess i didn’t read it.
18:43:36	tacotime:	hearn, http://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/
18:46:13	gmaxwell:	tacotime: in the original ppc the search window was limited too, (though I don't recall how limited, I think part of the point of the checkpoints was to be able to advance the clock if it got stuck), but the attack didn't limit itself to replacing the tip, if it couldn't mine on the tip it would cut further back and just try to find two blocks and so on.
18:46:51	amiller:	note that in vbuterin's proposal, the point is to eliminate PoW, yet the security relies on timing 2000 blocks is hard to get, yet only proof of work is able to ensure that
18:47:15	hearn:	yeah. it’s sort of circular.
18:47:17	tacotime:	gmaxwell, right, the "stake modifier" thing. they included that as well, but i'm not sure how much security that really affords.
18:47:34	amiller:	also it's absolutely invalid reasoning to say that you use "stake" to mine blocks, but that stake is somehow outside the value of a coin
18:47:39	amiller:	you might as well burn bitcoins directly.
18:47:49	amiller:	if "stake" is useful, then you can sell your stake and it's part of your wealth
18:47:57	gmaxwell:	hearn: a lot of these things are. The problem is that there is no strong impossibility proof so people go keep throwing hurestic solutions at it which are increasingly hard to analyize .. but ultimately it seems most have non-trivial weaknesses.
18:48:09	amiller:	you can't say for one context it's a valuable resource, and yet argue for another context it's outside the value
18:48:55	gmaxwell:	tacotime: well ultimately these developer-signs things are as secure as control of that key is.. which means that they can have rather great security esp if the coin is (nearly) worthless or completely junk security, and you can't really tell which.
18:50:15	gmaxwell:	(I think it's somewhat horrifying that none of them even use threshold signatures, personally I'd be worried about my safety if the value took off and I held the one key to rule them all.)
18:50:29	hearn:	going back to a theoretical world where people have keys and certs, and those keys/certs have some tangible value. let’s ignore how that’s achieved for the sake of thought experiment. i wonder, is it possible to use something like difficulty adjustment where the more signatures that are gathered per block, the more signatures become required to create a block. so there’s no requirement that everyone be known at the start b
18:50:30	hearn:	system grows, creating alternative chains requires a larger number of bad actors
18:50:59	hearn:	assuming that keys can be banned if they double mine
18:51:35	amiller:	there are a lot of kinds of bad behavior that you can't detect
18:51:49	amiller:	especially anything that looks like "omitting" data, because you might not have been told about that data to begin with
18:51:58	amiller:	that's what it looks like when you try to mine on history rather than on the most recent block
18:52:08	hearn:	i meant bad actor in the strict block chain sense - an attacker who is trying to rewrite the chain
18:52:22	amiller:	yes trying to rewrite the chain is one of those
18:52:38	amiller:	unless the same key is used to sign blocks in both chains
18:53:16	gmaxwell:	hearn: and total work is just the number of signatures?
18:53:18	hearn:	well eventually you have to be able to sign in both chains, otherwise natural forks would result in miners dropping out forever. but i guess as long as you don’t sign in sections of the chain that are actually much parallel
18:53:29	hearn:	gmaxwell: i guess. not sure. thinking out loud
18:53:49	gmaxwell:	hearn: sounds reasonable-ish to me, though since it's always ramming right against the limit it might become impossible to produce the next block (e.g. if some signers go offline)
18:54:14	gmaxwell:	though perhaps you could have a local clock that let you sign with fewer after a while.
18:54:31	gmaxwell:	might be unstable around the tip though.
18:54:40	hearn:	assuming all possible signers take part all the time, yes
18:54:57	hearn:	otherwise if say, 10% of possible signers mine, then if some drop out, it just takes longer to make a block as the others have to notice things have slowed down and decide to step up
18:55:52	hearn:	i wonder if an equilibrium can be designed where of all possible miners, some mine and some don’t, but the system is self adjusting so there’s always some percentage that are active
18:56:26	gmaxwell:	I suppose you could be rewarded for inactivity by somekind of weighing since your last usage.
18:58:21	zooko:	Joe Bonneau presented some nascent new research along these lines at the Princeton workshop, which he called "Agile Tokens".
18:59:46	gmaxwell:	Hm. I hadn't noticed the link there. I suppose, though IIRC the agile tokens the coin owners picked which sequencing servers they used.
19:00:14	zooko:	Yeah I think that's the main idea of Agile Tokens.
19:05:44	hearn:	zooko: is there anything i can read on that topic?
19:07:17	zooko:	hearn: I'll ask Joe Bonneau if he/I can share a draft with you.
19:11:41	zzyzx:	zzyzx is now known as roidster
19:12:11	roidster:	roidster is now known as Guest34559
19:16:48	reipr:	yay. If anyone is interested, the hash creation functions bewtween the js and the python do not match, that is the problem
19:16:50	hearn:	zooko: thanks.
19:17:04	reipr:	the python uses the pipe delimeter to seperate fields, the javascript does not
19:17:17	hearn:	zooko: could you give me a quick summary, maybe? there are sequencing servers?
19:17:44	zooko:	The basic idea is: there are any number of servers, a la Certificate Transparency and Sovereign Keys and other such ideas.
19:18:06	zooko:	And, the additional idea from this research is: the token comes with a list of which of those servers are authoritative for the next hop of this token.
19:18:46	hearn:	each token can have more than one? resolved through simple majority voting, or … ?
19:19:04	zooko:	Yes. Don't recall.
19:19:16	hearn:	right. so the idea is it’s sort of like with a bank, except each time the coins change hands, the “banks” also change?
19:19:38	zooko:	Like Certificate Transparency, a notary can only a) fail, b) notarize correctly, or c) double-notarize,
19:19:43	zooko:	and c) is instant death penalty.
19:19:50	zooko:	hearn: yeah!
19:20:11	hearn:	right. lots of academic e-cash works have some kind of assumption that double spending can be punished after the fact, in them
19:20:30	zooko:	* zooko nods.
19:20:40	zooko:	I don't think this one assumes anything very strong along those lines.
19:20:56	zooko:	"Death penalty" means people won't include that notary in their notary-sets ever again.
19:21:10	hearn:	right
19:21:14	jgarzik:	* jgarzik is just not as worried about the current double-spending brouhaha
19:21:15	hearn:	assuming they know about it
19:21:27	jgarzik:	Merchant business incentives handle a lot of it.
19:21:29	hearn:	so you need an unjammable broadcast channel anyway i guess, to distribute proofs of double signing
19:21:40	hearn:	jgarzik: how so?
19:22:06	jgarzik:	hearn, e.g. pointless to double-spend on a physically shipped good
19:22:20	jgarzik:	hearn, or an account or subscription
19:22:32	jgarzik:	hearn, basically anything except instant digital goodness
19:22:48	hearn:	or anything in person
19:23:08	hearn:	that may not represent a big chunk of bitpay’s business today, but what about tomorrow?
19:23:11	zooko:	Good points, jgarzik.
19:23:41	jgarzik:	double-spends tend to apply largely for hit-and-run, never-see-you-again customer scenarios
19:23:52	jgarzik:	s/for/to/
19:24:29	jgarzik:	hearn, double spends definitely happen today, without any need for miner collusion. Just network racing is plenty sufficient.
19:24:42	jgarzik:	hearn, They are resolved on a case-by-case basis, and the activity always stops immediately.
19:24:47	hearn:	zooko: i quite like the simplicity of the agile tokens idea. i wonder if the other servers could be turned into the unjammable channel, as they have an incentive to inform you if their competitors were cheating
19:25:08	zooko:	hearn: nice thought. Why the hell isn't Joe Bonneau in this channel.
19:25:36	jgarzik:	Long term double spending never happens.
19:25:37	hearn:	i wonder what quantity of servers you need to avoid your coins getting stuck due to servers naturally going offline
19:25:50	zzyzx_:	zzyzx_ is now known as zzyzx
19:27:33	hearn:	zooko: though it is in effect just the no-double-spends-as-a-service idea, with sets of anti-double-spenders.
19:27:50	hearn:	zooko: but trying to maximally decentralise them to take their own reputation out of the equation. which seems hard.
19:27:52	jgarzik:	The higher level point is that you don't always need a purely technical solutions, when economic & game theory incentives exist for certain avenues of attack.
19:27:57	jgarzik:	*solution
19:27:58	hearn:	actually maybe i like the idea less now i’m thinking about it more :)
19:27:59	andytoshi:	gmaxwell: re that stupid PoS thread, the person who started it (who also posted on bitcoin-development) contacted me privately to ask what the problems with PoS are. he seemed open-minded enough (or maybe he's just a good politician). he offered to buy me lunch at some point. i gave him a quick overview of PoS problems and linked to asic-faq.pdf, we'll see how that goes
19:28:19	hearn:	right. it’s just the same, actually
19:28:49	hearn:	zooko: the issue is - how do I know the notaries are not in collusion with (or actually are sybils of) the spender? you need some kind of long term stable identity for that. same thing as having authenticated miners, in effect
19:29:34	nsh:	where's this agile tokens written up--- oh, not anywhere publically yet...
19:30:42	zooko:	hearn: right, I think that means that you don't accept that currency.
19:30:53	zooko:	The currency which is notarized by a bunch of sketchy outfits that you don't like the look of.
19:31:30	hearn:	then we end up back at banking. pretty much what i said on the bitcoin-development thread: if you need lots and lots of people all to agree on a set of parties who are trustworthy and uncorruptible, you probably don’t have lots of them
19:31:39	gmaxwell:	andytoshi: I'm not shocked, though the problems with his post go beyond POS, like thinking you can change how bitcoin works in that respect just by convincing a bunch (but decidely not everyone) to run some software.
19:31:40	hearn:	it’s sort of like the CA problem
19:31:59	hearn:	i mean, there are quite a lot of CA’s given the cost of running them actually. but it’s not like becoming a CA is as easy as becoming a miner
19:32:37	phantomcircuit:	jgarzik, there's very few digital goods which actually cost something to delivery and cannot be retracted after the transaction is confirmed as double spent
19:32:44	phantomcircuit:	indeed i am yet to find a single example
19:33:17	nsh:	any remotely revocable authorization to use a service
19:33:43	hearn:	phantomcircuit: huh? software? music? movies?
19:34:02	phantomcircuit:	hearn, none of those things have any significant cost to deliver
19:34:03	nsh:	well, you can't take those back, unless they rely on third party to be usable
19:34:18	zooko:	hearn: do you still want me to ask J Bonneau to send you a draft? ☺
19:34:52	hearn:	akamai would disagree with you. but it’s not delivery cost that matters, it’s just “cost”. these goods have a price. if someone doesn’t pay them, that’s accounted as a loss of that much money. please don’t start a stupid “piracy is harmless” argument - the people _selling the items_ would perceive losses due to double spending as theft, and those are the people who matter.
19:35:02	hearn:	zooko: maybe :) he may have thought of these things
19:36:16	phantomcircuit:	hearn, it costs very close to nothing to deliver things via akamai if you're doing it in any bulk
19:36:30	jgarzik:	hearn, no so, as _on-going_ double spending is unlikely
19:36:44	jgarzik:	hearn, as soon as a pattern emerges, you're sunk
19:36:48	jgarzik:	*not so
19:36:51	hearn:	jgarzik: who is sunk?
19:36:57	jgarzik:	the attacker
19:37:11	hearn:	who is ….. ?
19:37:16	hearn:	i mean, are you ID verifying every bitpay customer?
19:37:23	phantomcircuit:	you can get 20TB/month on a 10gbps line for ~$400/month
19:37:25	hearn:	s/customer/end user/ ?
19:37:32	phantomcircuit:	(that's level3 connectivity)
19:37:51	jgarzik:	hearn, huh? Not sure how that avenue of thought emerged.
19:38:03	jgarzik:	hearn, "sunk" -- your attack stops making money, and LEAs are probably notified
19:38:04	phantomcircuit:	that's 0.02$ per GB
19:38:05	hearn:	phantomcircuit: bandwidth costs vary a _lot_ around the world. i used to manage an akamai setup for google maps in australia and new zealand. it was extremely expensive. but anyway, see above - it’s not delivery costs
19:38:33	hearn:	jgarzik: and what info do you give to LE? my point is, you’re saying double spending is not an issue because double spenders can be punished. but how do you know who is doing it? bitcoin tx doesn’t tell you that
19:38:56	phantomcircuit:	hearn, if you're seriously worried about people double spending to steal digital goods which they can already trivially pirate, then im going to have to call your concern absolutely fucking insane
19:39:34	hearn:	phantomcircuit: yes that is normally how conversations with you end :) never mind. i don’t care what you think about that. i care what sellers think, and they would not agree with you. by definition. otherwise they wouldn’t be sellers, they’d give their software away for free.
19:39:59	zooko:	zooko has left #bitcoin-wizards
19:40:35	midnightmagic:	* midnightmagic hugs the strong-worded people.
19:40:36	jgarzik:	hearn, the identity of the attacker is irrelevant. the point being made is that an attack will not be continual. people will take a look at server logs and block the attack or do whatever needs to be done. It is a standard griefer attack, not a critical business attack.
19:40:57	jgarzik:	hearn, there is clear economic incentive to stop asshole customers
19:42:09	jgarzik:	hearn, For BitPay specifically, it is up to the merchant to determine their level of risk RE confirmations and to take action if any funny business occurs.
19:42:25	hearn:	ah. well, this is technically right but practically not very useful. i’ve seen what it takes to control carding fraud at google (i.e. double spending). it’s ugly as hell and is sort of sticking fingers in the dyke. quite high losses are written off as an unavoidable cost of doing business. part of why bitcoin is attractive to merchants is they _don’t_ need crazy machine learning models trying to analyze browser fingerprints
19:42:25	hearn:	javascripts ,etc
19:42:26	jgarzik:	hearn, the local Chinese shop will just stop delivering to the asshole that tried to double-spend a dinner.
19:42:40	jgarzik:	Any large amount will be subject to confirmations by standard practice.
19:42:47	phantomcircuit:	shrug
19:43:07	phantomcircuit:	hearn, you're wrong, im not going to censor myself because you disagreew
19:43:09	phantomcircuit:	disagree*
19:43:16	jgarzik:	Therefore the double-spending impact is limited to (a) small amounts and (b) situations of instant digital delivery, and usually (c) where delivery is anonymous and customer info is lacking at the merchant.
19:43:45	hearn:	yes requiring merchants to ID verify all their customers is one solution, but it’s hardly pleasant for the user or merchant
19:44:08	hearn:	the ideal payment system would allow anonymous purchasers to purchase, with no double spending risk.
19:44:14	phantomcircuit:	that is not what he's suggesting
19:44:17	hearn:	bitcoin is a lot closer to this ideal than credit cards, but still isn’t ideal
19:44:26	jgarzik:	* jgarzik never presented nor proposed a solution, nor recommended ID checks. You are reading way too much into the words.
19:44:42	stephenreed:	andytoshi: I lurk here now thanks to your tip
19:44:46	hearn:	yeah, you did, you said “the chinese shop will not deliver to the asshole again” i.e. the customers are being ID verified by street address
19:44:47	jgarzik:	These incentives exist today. These are statements of fact, not suggestions.
19:44:55	phantomcircuit:	jgarzik, afaict there is no problem
19:45:02	jgarzik:	phantomcircuit, pretty much
19:45:04	hearn:	which is great if you’re delivering to someone’s street address and not so great if the asshole just picks the pizza up
19:45:35	andytoshi:	stephenreed: oh, hey steven
19:45:42	jgarzik:	hearn, That's a one time attack. Will the business go under due to that? No, they will just stop serving that customer.
19:46:11	jgarzik:	hearn, not cost effective to attack that way
19:46:20	andytoshi:	stephenreed: normally this channel is much quieter and much wonkier :)
19:47:21	jgarzik:	hearn, It is easy to think up a one-time double-spend attack. But those will necessarily be very low reward and not cost effective.
19:47:29	jgarzik:	to make money, you need a stream of double spends
19:47:47	jgarzik:	otherwise, congratulations, you just stole $5 worth of goods, and cannot ever pull off that attack at that site again.
19:49:00	hearn:	well, this is true sometimes, but the existence of professional carders rather implies that a lot of them can do it again and again
19:49:05	hearn:	and they’re not all buying stuff mail order either
19:49:45	hearn:	i’ve seen cases where carders were buying things like flight tickets, believe it or not
19:50:07	hearn:	so, pretty expensive.
19:50:08	jgarzik:	flight tickets won't get double-spent
19:50:16	jgarzik:	that's a revocable
19:50:51	iddo:	jgarzik: what if you double-spend on a physical item that's worth a lot of money, then the merchant (who has your id / street address) goes to the judge with the losing chain that has your other signature, and you tell the judge that someone stole your privkey and signed it (or whatever, there's plausible deniability, no?)
19:50:53	jgarzik:	People who sell tickets for BTC already covered that angle, long ago.
19:51:13	jgarzik:	iddo, "worth a lot of money" -> logic failed there
19:51:27	jgarzik:	iddo, standard practice is to wait for confirmation, for any non-small amount of money
19:51:52	iddo:	you mean, if you buy a car with bitcoins, wait for more than 6 confirmations?
19:51:58	jgarzik:	iddo, yes
19:52:21	iddo:	ok, assuming that merchants are prudent...
19:52:32	nsh:	prudence is economically self-correcting
19:53:00	hearn:	only if you’re a professional car seller who can tolerate the loss of some cars ….. consider someone who just wants to sell theirs second hand
19:53:30	hearn:	having to hang around for hours with buyer and seller stuck in place, sucks. i was thinking of smart property to solve that but it’s hardly practical in the short term
19:53:46	iddo:	there can be competition among merchants, i.e. one merchant can say "i'm only waiting for 6 confirmations" for this (high-value) item, etc.
19:53:58	hearn:	so i bet in practice people will take the risk and get burned
19:54:20	nsh:	(some people) getting burned is part of the systemic process of discovering acceptible levels of risk
19:54:21	hearn:	though cars may be a special case
19:55:38	iddo:	i suppose that it isn't really the case right now that merchants evaluate how many confirmations to wait for, based on the value of the item...?
19:56:21	iddo:	for example, fiat/BTC exchanges always wait for no more than 6 confirms, even if you deposit a large amoung of BTC, right?
19:58:06	jgarzik:	Practically speaking, if I was selling my car for BTC, I would just wait for one confirm, maybe two at most.
19:58:42	jgarzik:	"hang around for hours" is quite exaggerated, for the needed level of security for such a TX
19:59:26	amiller:	cars have lots of tracking details, they're a bad example anyway
19:59:50	iddo:	what if the buyer tries to bribe large pools, and share profit from the double-spending with the pools?
19:59:57	hearn:	jgarzik: it’s not so uncommon to have a single block take nearly an hour though, right
20:00:03	hearn:	it’s not exactly 10 mins each time
20:00:15	hearn:	so sometimes people will say, let’s wait for a block, and then it’s unusually slow and they just give up
20:00:24	hearn:	though that maybe useless for a double spender as they can’t predict it eithe
20:00:40	gmaxwell:	;;tslb 3600
20:00:41	gribble:	(tslb takes no arguments) -- Shows time elapsed since latest generated block. This uses the block timestamp, so may be slightly off clock-time.
20:00:47	gmaxwell:	;;tblb 3600
20:00:48	gribble:	The expected time between blocks taking 1 hour and 0 seconds to generate is 5 days, 10 hours, 17 minutes, and 41 seconds
20:01:19	iddo:	amiller: but there's plausible deniability, no? you can say that transferred the BTC to buy the car, and someone else stole your privkey and double-spent?
20:01:25	gmaxwell:	so an hour should be a weekly thing, assuming hashrate isn't growing; less often if it is more often if its shrinking.
20:01:31	andytoshi:	..and yet somehow it will always take an hour exactly when you're trying to sell your damn car :)
20:01:46	jgarzik:	gives new meaning to the term "weekly swap meet"
20:02:50	andytoshi:	my feeling is that when ordinary people are using bitcoin, we will probably have banks involved. so if you wanna buy a car, you go get a money order the day before
20:03:11	iddo:	jgarzik: so if you wait for 1 or 2 confirms, and buyer of the car tries to bribe large pools to double-spend and share profits with them, it might be a plausible attack?
20:03:29	andytoshi:	then it's on the bank to wait for confirmations before honouring the money order
20:03:35	jgarzik:	iddo, still implausible
20:03:58	iddo:	because of pool's reputation?
20:04:08	jgarzik:	iddo, doing that once is difficult. doing it multiple times nearly impossible.
20:05:05	iddo:	yes, just once... you want to buy the car for less money by carrying out a double-spending attack
20:06:41	jgarzik:	iddo, the payoff for a one-time attack is too small, versus consequences for the pool participating
20:07:23	iddo:	payoff for the pool, right? i.e. it will hurt the long-term reputation of the pool?
20:07:30	jgarzik:	Any in-person meeting + stolen good gives the police a lot to work with
20:08:13	jgarzik:	The pool has to gain something, otherwise it will not bother to help with an attack.
20:09:05	iddo:	yes, part of the double-spent BTC will be then sent to the pool operator
20:09:36	iddo:	it's true that if there's collusion with the pool then it gives the police something to work with
20:10:15	hearn:	well, assuming non-anonymous miners. but really they’re meant to be anonymous
20:10:21	hearn:	gosh double spending is a fun problem to think about isnt it :)
20:10:29	iddo:	but unless you have evidence of human communication, i.e. it's just BTC transfers, there's plausible deniability i guess
20:11:49	hearn:	not very plausible
20:14:56	iddo:	also it's possible to try bribe attack without human communication (and even if everyone were using p2pool), by offering large miner fees in the hostile chain
20:17:58	iddo:	if you only wait for 1 or 2 confirmations, then maybe miners will assess that mining the hostile chain is worth the risk (i.e. doing PoW work on a chain that has 1 or 2 blocks deficit relative to the main chain)
20:19:17	iddo:	(there's old bitcointalk on that, title is "double double spend")
20:19:31	iddo:	s/bitcointalk/bitcointalk thread
20:37:48	stqism:	stqism is now known as stqism`
20:37:54	stqism`:	stqism` is now known as stqism
20:42:45	stqism:	stqism is now known as gribble`
20:42:58	gribble`:	gribble` is now known as stqism
21:11:36	shinybro__:	shinybro__ is now known as shinybro_