00:16:27	HostFat_:	again :) https://www.reddit.com/r/Bitcoin/comments/38aqt6/nodes_should_prefer_smaller_blocks/
00:18:39	gmaxwell:	HostFat_: if you know you'll win a race even with a later announcement you should withhold your block, this makes it so the strategic ('selfish') mining has substantial returns starting at 25% hashpower.
00:18:58	gmaxwell:	(this is a well known problem with any block preference scheme except smaller)
00:20:03	HostFat_:	wait, tt depends, if you wait longer, all nodes will still receive the bigger block first
00:20:07	HostFat_:	it*
00:20:55	HostFat_:	I don't see it as a win strategy
00:24:08	HostFat_:	the smaller blocks only win on the downloading phase, so this is the way to avoid a dos attack from bigger blocks
00:25:13	gmaxwell:	HostFat_: also, I think you've still failed to grasp a point made the other day... that it doesn't matter if j-random-node does this or that, assuming they don't outright reject them, miners don't care if it takes minutes for a j-random-node to get them.
00:26:25	HostFat_:	they care if they know that if a smaller block will come after their block, nodes will prefer to download the later one
00:27:40	HostFat_:	one miner can make a 1 GB block if he wants, and nodes will start do download it ... but if after few seconds it arrives a new block of 1 MB (example), nodes will pause the download of the one of 1 GB, and will give all the bandwitch to download the smaller one
00:27:47	HostFat_:	the block of 1 GB will be orphan
00:28:09	gmaxwell:	HostFat_: Again (1) it doesn't matter what random non-mining nodes do. has no influence on miner income unless nodes outright reject the blocks, and (2) if you can construct a block that you _know_ will be prefered even if accepted later, you should do that and selfish mine and win every 'race'; having an advantage on everyone else by the amount of time you keep the 'best' chain secret.
00:28:48	gmaxwell:	I'm sorry if I'm failing to make these concepts clear enough; they're well understood by many people.-- I have too much else to do right now, perhaps someone else will explain (though #bitcoin might be a better venue).
00:29:25	dgenr8:	HostFat: to be clear, you DL the smaller one preferentially until you have the samebuffer of both, then download equally, is that what you propose?
00:29:36	HostFat_:	I mean all the nodes should have these rules, and if a miner wait longer, he will lose the race, even with a smaller block, because all the nodes will have already dowloaded another one
00:35:11	HostFat_:	no, all nodes will download the smaller first, if they receive more than one block
00:36:04	HostFat_:	it's really risky to wait to release your block, to do selfish mine, because you can lose the race if all the nodes will have already downloaded other blocks
00:36:57	gmaxwell:	gmaxwell has left #bitcoin-wizards
00:37:02	dgenr8:	some problems with that. nodes don't know what the size is until they download it. And, the later one isn't smaller, once it's become bigger ;)
00:40:05	HostFat_:	maybe this can be arranged by asking the block size first, and then block the IP of the possible liar
00:52:10	justanotheruser:	HostFat_: blocks don't have IP addresses
00:53:20	HostFat_:	but the sender yes, and the sender is the only one that maybe has malicious intent
00:54:15	HostFat_:	to fake size to give more priority to the block that it is sending
00:54:39	sipa:	sipa has left #bitcoin-wizards
00:59:21	c0rw1n:	c0rw1n is now known as c0rw|zZz
01:00:29	justanotheruser:	oh, well sending an invalid block already bans you
01:00:31	justanotheruser:	iirc
01:00:42	justanotheruser:	at the very least, it increases your ban score
01:02:00	justanotheruser:	but if you aren't making the blocks invalid, just "unideal" or whatever, it doesn't help
01:43:02	Guest81362:	Guest81362 is now known as DanielBTC
02:05:30	frankenm_:	frankenm_ is now known as frankenmint
03:09:13	Jaamg:	tx fees currently seem to accumulate around 20 BTC / day. if we assume that one day there will be 1000x more blockchain transactions, is there a reason to believe that tx fees will not increase to 20,000 BTC / day?
03:12:34	justanot1eruser:	yes, we don't know what fees will be in the future
03:24:45	Jaamg:	justanot1eruser: do you perhaps refer to bitcoin value rising which might give downwards pressure to tx fees? if yes, i repeat my question by adding "20,000 BTC / day, measured in today's btc price"
03:25:13	Jaamg:	or do you refer to something else?
03:26:25	justanot1eruser:	I think 1000x more blockchain transactions either will never happen or is too far off to predict
03:27:02	Jaamg:	justanot1eruser: that was an assumption
04:05:08	NewLiberty__:	NewLiberty__ is now known as NewLiberty
05:10:29	jcorgan:	jcorgan has left #bitcoin-wizards
05:50:58	bramc:	Jaamg, The blockchain as it stands currently just plain can't handle 100x as many transactions. It's disallowed as an anti-ddos measure. There's a hard limit on the maximum size of a block. Hence all the discussion about raising that. But in answer to your question, transaction fees are fairly close to zero today because the demand is less than the supply (or rather, parties who have considered writing applications which
05:50:58	bramc:	would have dramatically increased the demand have kindly refrained from doing so). If demand goes up to exceed supply transaction fees will jump dramatically. How dramatically depends on how much people care about doing those transactions
05:51:18	Jaamg:	bramc: "if we assume that one day"
05:51:46	bramc:	Jaamg, I didn't use that turn of phrase
05:52:28	bramc:	Jaamg, You can't assume that the transaction rate goes up by 100x. It isn't allowed
05:53:11	Jaamg:	bramc: i know
05:55:15	Jaamg:	my assumption obviously includes the condition "Blocksize is more than 1MB OR size of an average tx is significantly smaller than today
05:55:26	NewLiberty:	or rather tx rate can go up 100x but they won't be incl in blocks
05:56:26	Jaamg:	likely the former
05:58:12	Jaamg:	but i would still like to hear an answer to original question
05:59:10	bramc:	Jaamg, If you assume that a 100x transaction rate is achieved by raising the block size to large enough that it has more than enough capacity for that, then no, transaction fees won't have gone up
05:59:58	bramc:	Jaamg, If you assume that a 100x transaction rate is achieved by raising the block size to 50x what it is now, thus allowing 100x as many transactions as there are currently, but capacity is being met, then transaction fees are likely to be vastly larger.
06:01:31	Jaamg:	bramc: i'm not talking about fee/tx going up, i'm talking about the sum of all fees going up, because of increased blockchain traffic
06:01:59	bramc:	Jaamg, My previous comments were about the aggregate fees, not the individual fees
06:03:08	bramc:	The fees right now are so close to zero that they're more social convention than economic mechanism.
06:05:40	Jaamg:	bramc: fees are close to zero, but they still accumulate around 20 BTC / day. is there a reason to believe that 1000x blockchain traffic would not increase that number to 20,000 BTC / day?
06:07:15	Jaamg:	or if that feels to far in the future, we can also talk about 10x traffic and number increasing to 200 BTC / day
06:07:27	bramc:	Jaamg, If the capacity is continuously increased to stay ahead of demand, there's no reason to expect the per-transaction fee to stay the same as the number of transactions goes up
06:11:16	bramc:	Current mining rewards, if I recall correctly, are 1800 BTC/day, so transaction fees are around 1%
06:11:17	Jaamg:	bramc: if we assume that one day blockchain security is provided by scarcity-induced high tx fees, what will happen to network security if blockchain traffic for whatever reason drops?
06:11:45	Jaamg:	it's 3600 currently
06:13:02	bramc:	Jaamg, As long as demand exceeds the limit, then the amount of blockchain traffic will remain fixed at the limit, and the fees will fluctuate with demand.
06:13:43	bramc:	The security parameter of the block chain will vary in linear proportion to the transaction fees (and time, you can always wait longer to have greater security)
06:16:26	phantomcircuit:	bramc, i think you'll find this interesting http://rusty.ozlabs.org/?p=500
06:16:37	phantomcircuit:	bramc, 3600 btc/day
06:16:41	phantomcircuit:	fyi
06:17:00	Jaamg:	bramc: with security i'm referring to the network hash rate and not to the confirms (if that's what you meant)
06:17:56	bramc:	Jaamg, It's a bit smoothed out because the costs of buying asics are amortized over time, but to a first approximation the network hash rate is linearly proportional to the mining rewards.
06:18:54	bramc:	When is the hash rate halving again? I thought it was supposed to earlier this year, but maybe I'm misremembering and it's early next year.
06:19:05	bramc:	I mean the mining rewards, pardon my freudian typo.
06:19:39	Jaamg:	http://bitcoinclock.com/
06:20:03	bramc:	Rusty is working on lightning networks? Are the lightning networks guys employed at blockstream as well?
06:20:17	moa:	block #420k
06:20:42	phantomcircuit:	bramc, they're not
06:22:20	bramc:	When the mining rewards halve again, I'm going to get the local environmentalist groups to organize a celebration
06:22:50	phantomcircuit:	lol
06:24:12	moa:	block #420k should have numerous groups partying
06:24:16	bramc:	Are things in motion to get a relative timelock opcode added to bitcoin?
06:24:33	moa:	bramc: appears to be
06:28:26	phantomcircuit:	bramc, yes
06:28:47	phantomcircuit:	lots of review effort is required which realistically translates to lots of time
06:32:12	gmaxwell:	bramc: there is a proposal for a potential first step in a relative checklocktime verify on the bitcoin-development list (if you can find it amid all the non-development political traffic :) )
06:32:39	gmaxwell:	in related news, BIP66 is about to activate: http://bitcoin.sipa.be/ver-2k.png
06:32:58	gmaxwell:	looks like it may activiate in ~1 week.
06:33:35	gmaxwell:	Overall progress chart: http://bitcoin.sipa.be/ver-50k.png
06:47:00	petertodd:	gmaxwell: all the big pools have transitioned; smaller pools lagging
06:47:16	petertodd:	gmaxwell: mostly that's because I asked those big pools, directly or indirectly :)
06:54:19	bramc:	What is the 'block version'? Is that what's used for voting? How are you supposed to do voting on a new feature if an old one failed?
06:54:52	bramc:	gmaxwell, Is it a proposal for relative based on relative block height?
06:57:14	petertodd:	bramc: it's not a vote; see https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki and look at how it's implemented
06:59:20	bramc:	petertodd, Question still applies. If nVersion failed to get the appropriate threshold to make 3 required, what's the mechanism for giving up? And how would you distinguish acceptance of a new thing from attempted acceptance of the old thing?
07:00:00	bramc:	Does BIP66 succeed in making signatures fully canonical?
07:00:17	petertodd:	bramc: in the existing scheme there isn't a mechanism; sipa aims to fix that problem with his new scheme
07:00:26	petertodd:	bramc: remember that it is *not* a vote
07:00:47	bramc:	Okay that's a dumb question, obviously it doesn't. Does it succeed in making the simplest types of signatures fully canonical?
07:01:10	petertodd:	bramc: there's very specific reasons for BIP66 and they aren't rellated directly to malleability
07:01:18	bramc:	Or rather, does it succeed in making it so that someone who doesn't want to allow third parties to mutate their signatures to keep that from happening?
07:01:28	petertodd:	no
07:01:43	bramc:	No to which of my questions?
07:01:55	petertodd:	no, it doesnt succeed
07:02:02	bramc:	At any of it?
07:02:11	phantomcircuit:	iirc bip 66 prevents all know mutations of the der ecdsa signatures
07:02:14	phantomcircuit:	petertodd, is this wrong?
07:02:26	petertodd:	like I said, BIP66 is to fix issues with openssl, not to prevent malleability
07:02:44	petertodd:	that it happens to be a subset of bip62 which aims to fix malleability is an accident
07:03:17	petertodd:	anyway, bbl, going for a hike with my parents :)
07:04:05	moa:	take a hike
07:04:10	bramc:	All these years and we're still dealing with the shittiness of openssl
07:04:12	petertodd:	moa: exactly!
07:05:56	bramc:	Nobody's commented on my scheme to screw over anyone who accepts zeroconf. Maybe that's too uncontroversial around here to provoke discussion.
07:06:40	bramc:	Mind you, I'm not advocating stealing, just pointing out how it could be done very effectively and that *somebody* will inevitably do it.
07:14:07	bramc:	Interesting, bip62 requires a new signature type, instead of just stricter acceptance like bip66
07:14:17	moa:	bramc: some outfit announced a service to provide double-spend confidence ratings
07:15:20	bramc:	moa, *sigh*
07:16:19	bramc:	The unstoppable attack is that people can post 'legit' transactions to the network, then post transactions with different targets including kickbacks to old mining reward targets to some darknet
07:17:19	bramc:	Or maybe the signatures for old mining rewards are used to give new targets to preserve the anonymity of the, ahem, service provider
07:17:55	bramc:	There's not much which can be done about this: If the miners are conspiring against your idiotic zeroconf acceptance, then you're fucked, and there's no reason for them not to do it.
07:19:02	bramc:	This practice wouldn't even be illegal, and would be very unlikely to be made illegal if clueful people explained to regulators what was going on.
07:19:40	p15:	could you just not accept zeroconf when an old mining reward was involved?
07:24:00	bramc:	p15, No it works like this: I post a transaction sending something to you. This is a completely legit transaction, nothing weird about it. It comes from me it goes to you. It goes through the bitcoin network properly. Separately, I post to some darknet a bunch of competing transactions, which all have the same input but their outputs split between a key I have and a kickback for the same key as will claim one of the old
07:24:00	bramc:	mining rewards. I post one of these for each of the last couple thousand mining operations
07:24:39	bramc:	So you accept the as legit as it can be zeroconf operation, and it gets magically undone by a miner who is, ahem, optimizing their mining rewards.
07:25:21	p15:	ok I see
07:26:08	p15:	it sounds pretty similar to a normal attack on zeroconf
07:26:26	p15:	just a new way to reward a miner
07:28:54	p15:	the killer attack would be one that didn't include a complicit miner
07:31:25	bramc:	You can do an 'okay' job of zeroconf if you assume that the miners are diligently trying to make everything fair and just and are acting as charitable entities
07:31:40	bramc:	Of course, that view is hopelessly naive.
07:33:53	p15:	if you could do a good job of zeroconf what we would we need miners for :D
07:34:14	CoinMuncher:	bramc: Hadn't heard your proposal before. Interesting. petertodd has a whole double-spend python library with even higher claimed success rates than yours.
07:34:40	CoinMuncher:	bramc: In the end zeroconf should just go to Lightning Network I guess.
07:35:23	bramc:	CoinMuncher, My attack is now, I buried in here: http://bramcohen.com/2015/06/02/gallus-and-simo-debate-whether-the-block-size-limit-should-be-increased
07:36:14	bramc:	If I'd made a ranty post calling zeroconf supporters stupid and just covering that one point it might have gotten some press. Putting it in the middle of a dense information-filled post not so much.
07:37:08	bramc:	And yes, lightning network or green transactions are a much better way to get immediate payments. That's a boringly uncontroversial statement around these parts.
07:40:35	CoinMuncher:	ah right still need to finish reading that post. Looked like a good summary. Putting a nice little candy in the middle is actually a good trick, teaches people to read your stuff. You don't want to play the sensationalist journalism headlines game, do you?
07:48:13	bramc:	Sometimes I play the sensationalist journalism game by accident when I'm a little too glib
08:05:15	sendak.freenode.net:	topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
08:05:15	sendak.freenode.net:	Users on #bitcoin-wizards: andy-logbot nessence Mably hktud0 CoinMuncher damethos ThomasV p15 gmaxwell arubi_ RoboTeddy antanst NewLiberty justanotheruser priidu a5m0 Populus jmcn_ TheSeven Dr-G felipelalli bramc d1ggy_ theymos moa Jouke c0rw|zZz bosma mikolalysenko kumavis runeks adams__ Muis artifexd dasource go1111111 belcher DrWatto lclc thrasher` dc17523be3 mengine superobserver Luke-Jr Relos prodatalab Artimage rustyn SDCDev wizkid057 melvster stonecoldpat metamarc
08:05:15	sendak.freenode.net:	Users on #bitcoin-wizards: null_radix gielbier SubCreative rht_ robogoat jgarzik hulkhogan_ Cory Starduster Adlai yrashk mariorz btcdrak CryptoGoon platinuum Oizopower CryptOprah catcow yorick LeMiner amiller koshii MoALTz_ Meeh davout jessepollak huseby espes GreenIsMyPepper spinza elastoma pollux-bts Logicwax PaulCapestany fript tromp lmatteis sneak CodeShark mountaingoat dgenr8 helo cryptowe- veox mm_1 luny ttttemp lnovy jbenet vonzipper waxwing sadoshi copumpkin
08:05:15	sendak.freenode.net:	Users on #bitcoin-wizards: phantomcircuit michagogo bedeho ebfull rasengan PRab yoleaux EasyAt wumpus comboy stevenroose pigeons kinlo gwillen sl01 akstunt600 [d__d] Madars Tiraspol kyuupichan gavinandresen nickler Iriez akrmn cdecker harrow dansmith_btc face Keefe jrayhawk K1773R luigi1111 Emcy tromp_ Apocalyptic prosodyContext ggreer Hunger- Pan0ram1x isis HM bsm117532 harrigan andytoshi scoria brand0 larraboj OneFixt mappum weex gnusha nsh triazo jonasschnelli berndj
08:05:15	sendak.freenode.net:	Users on #bitcoin-wizards: leakypat tucenaber Taek iddo epscy wiz lmacken cfields Krellan coryfields BrainOverfl0w @ChanServ STRML AdrianG Anduck BlueMatt midnightmagic otoburb starsoccer d9b4bef9 gribble ryan-c indolering Graet jaromil sturles [ace] merlincorey morcos roasbeef eric sdaftuar Xzibit17 warren forrestv nanotube ajweiss guruvan SwedFTP afdudley so phedny nephyrin richardus petertodd livegnik poggy Sqt dignork smooth xabbix Jaamg Fistful_of_Coins fluffypony
08:05:15	sendak.freenode.net:	Users on #bitcoin-wizards: throughnothing_ mr_burdell narwh4l Eliel optimator maaku BananaLotus heath binaryatrocity _whitelogger Zouppen crescend1 TD-Linux sparetire warptangent azariah bliljerk_ kanzure Alanius catlasshrugged
08:09:57	moa:	bramc: this one http://dev.blockcypher.com/#zero_confirmations
08:11:15	bramc:	moa, Yeah the point of the attack that I propose is that you could seem to have nearly 100% confidence that you're out there based on the data they collect and still be completely fucked.
08:11:46	moa:	hmmm, seems like they might like to know about it?
08:12:50	bramc:	moa, It tends to be very hard to convince someone of something when their funding is dependent on them not understanding it.
08:13:43	moa:	lol
08:14:40	moa:	conflicted
08:15:16	moa:	stomach neural mass rules cerebral cortex every time
09:02:04	stonecoldpat:	bramc: if i understand correctly, so you get the public key from an old coinbase, and send the miner that transaction directly? (splitting the bitcoins between yourself and the miner)? this just seems like a non-interactive way to stop the miner needing to send you his public key and creates a link on the blockchain. Please correct me if i'm wrong with understanding what you proposed. Although -you could derive a new publ
09:03:28	stonecoldpat:	(and since the public key is sent out of bounds and not stored in the OP_RETURN, its not an obvious stealth address).
09:21:14	CoinMuncher:	stonecoldpat: s/public key/address and I don't see how you would derive a new address.
09:23:42	CoinMuncher:	bramc: Also, why would you send the double spend directly to one particular miner address instead of just having a large fees so that *any* miner can pick it up? That makes it more deniable by the miner as well: it's just a fee.
09:28:29	stonecoldpat:	CoinMuncher: fair point, you would need to find where the coinbase has been spent to get the public key - and the fee does seem a more obvious way to do it, but it does look strange if the 'fee' is very large and it was not visible on the network before going into the blockchain (if its just a large fee, youd expect everyone to hear about it), whereas a transaction would be less supicious
09:30:46	stonecoldpat:	or may be less suspicious* (always arguable)
09:38:17	CoinMuncher:	yeah still suspicious, but a bit more plausible deniability for the miner than a straight transaction. (if you even consider this illegal or morally wrong...).
10:05:51	c0rw|zZz:	c0rw|zZz is now known as c0rw1n
11:15:45	GibsonA:	GibsonA is now known as thrasher`
14:23:12	jae:	jae is now known as Guest81298
16:16:35	lmatteis:	i imagine you guys saw this http://eprint.iacr.org/2015/521.pdf
16:24:03	kanzure:	"Democoin: A publicly verifiable and jointly serviced cryptocurrency"
16:27:07	kanzure:	hmm what's the utility of a proof of guilt
16:28:53	kanzure:	why would they care if they have a proof-of-guilt floating around?
16:30:04	gmaxwell:	It doesn't appear to specify. It may be an implicit assumptions that participants have known, issued identities, and are subject to some effective external process. Or it's a rehashing of the fraud proofs motivations we'd discussed previously.
16:31:27	kanzure:	it's also not clear what their actual goals are, so it's hard to evaluate their design against that
16:31:57	gmaxwell:	Their centeral coin design sounds essentially identical the very first thing discussed in this channel. (though we answered what you'd do with the fraud proofs, you'd use them to claim fidelity bonds)
16:33:54	kanzure:	this seems to be their criticism of bitcoin :P "However, these systems require a public file (”ledger”) that is very big and very inefficient to maintain and update. As a result, these systems too may not be too useful, particularly if the number of users and transactions grows."
16:33:56	lmatteis:	if anybody can summarize that document i'd be grateful
16:34:00	kanzure:	waste of time
16:34:28	lmatteis:	plus what is up with the "(This technology is covered by three patent applications"
16:34:34	kanzure:	the number of bitcoin users does not directly (and hardly indirectly) determines the size of the ledger
16:34:49	gmaxwell:	kanzure: yea, a little frustrating that that cite the bitcoin whitepaper but don't appear to be even aware of the scaling tools explictly disclosed in it with their own sections; much less that subsiquent tools this community has discussed over the past 5 years.
16:34:59	kanzure:	the number of bitcoin transactions can grow without insertion into the blockchain, so that's also a weird thing for them to claim
16:35:21	gmaxwell:	At the same time; I suppose actually being aware of the state of the art might inhibit their ability to gain expansive patents...
16:35:22	lmatteis:	here's the background of the author: http://people.csail.mit.edu/sergeyg/work.html
16:35:56	lmatteis:	it's unreal that someone can actually patent these "ideas"
16:35:57	kanzure:	i suspect that this is the same in other academic fields (nobody reads the literature carefully)
16:36:35	lmatteis:	their background seems more crypto-theory rather than distributed systems
16:43:10	lmatteis:	kanzure: you'd be surprised how stringent most top academic conferences are in terms of making sure related work is attributed
17:07:36	gmaxwell:	lmatteis: to the reviewers and organizers :)
17:08:53	ThomasV:	lol
17:09:48	gmaxwell:	really, its hard, but on papers I've done it was pretty easy to tell at least which instutions reviewers were with based on which papers they demanded you cite. :)
17:11:23	ThomasV:	gmaxwell: reviewers are often chosen based on which papers you cite in your manuscript
17:13:33	lmatteis:	but they're double-blinded
17:14:06	ThomasV:	not always
17:14:23	ThomasV:	double blind reviewing is pretty rare
17:14:33	ThomasV:	at least in some fields
17:14:54	binaryFate:	in my field most often they're not double-blinded (either journals or conference)
17:15:29	ThomasV:	I saw double blind reviewing at some conferences, but never for a journal
17:15:35	lmatteis:	really? most a, a* are double-blinded
17:17:10	ThomasV:	nature offers it only since this year
17:18:58	lmatteis:	"All submissions will be evaluated using a double-blind review process. To ensure blind reviewing, papers should be anonymized by removing author names and affiliations, as well as by masking any information about projects and bibliographic references, etc. that might reveal the authors’ identities."
17:19:06	lmatteis:	this is from an "average" academic conference
17:19:14	lmatteis:	actually rated C which is quite low
17:21:28	kanzure:	"the rate of citations is inversely proportional to the distance of the author from the other institution"
17:21:32	kanzure:	man that would be a terrible result to see
17:22:45	ThomasV:	heh.. I remember removing the hostname of my machine manually from some pdf figures
17:23:06	ThomasV:	was fun
17:23:34	binaryFate:	you could insert priv keys there to bribe reviewers :)
17:25:05	ThomasV:	binaryFate: ao generate them from your abstract
17:32:10	gmaxwell:	If you generated them from something other than the abstract they'd have to read something other than the abstract, win win. :P
17:32:13	waxwing:	just reading about chameleon hashes/sigs, something i don't get: what does this system give you that a simple HMAC doesn't? i.e. with a shared key hmac you have a non-transferrable signature, no?
17:36:31	gmaxwell:	waxwing: yes, HMAC works for a designated verifier system.
17:44:06	waxwing:	oh so if i read it right it's like, with chameleon you can still get non-repudiability because if there is a dispute the signer can generate a collision which he wouldn't otherwise be able to. you don't get that with hmac.
17:50:07	gmaxwell:	waxwing: right.
17:50:41	gmaxwell:	waxwing: You can see a little design where I used that idea here: https://bitcointalk.org/index.php?topic=318279.0
17:53:53	waxwing:	swedish gangsters lol
17:58:55	midnightmagic:	gmaxwell: Can both Alice and Bob publish forged contracts?
18:01:17	midnightmagic:	Ah, no, nevermind.
18:02:00	midnightmagic:	So if Alice can't forge a contract, then all they have to do is put a gun to Alice's head and force her to reveal the contract, correct?
18:03:15	waxwing:	wouldn't it be possible to do it symmetrically, each side signs the same contract using a chameleon sig?
18:04:18	midnightmagic:	Then how does anyone show what the original contract was in the event of a dispute?
18:04:37	gmaxwell:	midnightmagic: they don't, you just show bob is up to some crap.
18:06:17	waxwing:	Alice proves Bob has forged by demonstrating a collision. I think that works?
18:07:53	midnightmagic:	gmaxwell: Is there some property I'm missing which shows that the forgeries are forgeries after Alice publishes the original?
18:08:02	gmaxwell:	midnightmagic: that fact that there are two of them! :)
18:08:10	gmaxwell:	it means that one must be a forgery.
18:09:12	midnightmagic:	gmaxwell: And.. Alice can't forge, but in the narrow world of the arrangement, we can't tell which one came from bob and which came from alice without additional constructions that defeat the purpose of the arrangement?
18:10:47	gmaxwell:	midnightmagic: right, a key point though is that you know both came from bob, perhaps then the convention is that bob is automatically a fraudester unless he does the alice-favorable superset of both contracts.
18:12:30	waxwing:	gmaxwell: i think you're talking about your original construction, not my suggestion of it being done in both directions?
18:13:43	gmaxwell:	waxwing: yea sorry, only half reading. If it's done in both directions than alice and bob can coperate to forge; which has its utility too.
18:14:23	gmaxwell:	(I think I may have mentioned a bidi version in that thread? ... I know they were discussed somewhere. The problem with bidi is just more coordination required.)
18:14:53	waxwing:	right. i can't see a practical problem arising from them both being able to forge, perhaps there is.
18:14:58	waxwing:	(cooperatively)
18:15:21	waxwing:	it has the huge advantage that they're both protected from coercion though, if i got it right
18:16:59	midnightmagic:	Then the construction of a forgery shows that a forgery exists, and the creation of a forgery means Bob is evil if we all agree that constructing forgeries is evil. But we can never tell whether Bob is satisfying the contract since everything might be a forgery.
18:18:31	waxwing:	midnightmagic: i can't see the scenario where they would cooperate to create a forgery and then show that to the world? How would that benefit them both?
18:20:07	gmaxwell:	midnightmagic: you can, because you can require in the event of two contracts; both must be satisfied; and in the event of contradictory requirements alice choses.
18:21:12	midnightmagic:	gmaxwell: Ah, makes sense.
18:22:36	midnightmagic:	waxwing: Perhaps as part of the contract, Bob makes one in advance for Alice which he's willing to abide by in the event of coercion, to protect Alice.
18:22:40	waxwing:	another way to put it, cooperative forging is not forging, it's agreement (another contract)
18:22:50	frankenmint:	frankenmint has left #bitcoin-wizards
18:23:02	midnightmagic:	"I never told him to kill anyone, I told him to make me a website."
18:23:51	bramc:	stonecoldpat, Yeah the idea is that (1) the miner has authenticated themselves as a miner (2) the person doing the double-spend sends to them 'directly', possibly through a mixnet, and (3) whoever's running the mixnet can authenticate both that the transaction is going to a miner and that the transaction really is a double spend
18:24:01	waxwing:	yeah, that's cool, but even more, as long as everyone understands the properties of the primitive, no one will ever try to coerce.
18:24:14	bramc:	Lots of beautiful anti-spam properties in that system. There also can be kickbacks to whoever's running the mixnet.
18:24:23	waxwing:	in theory :) what always worries me about deniability stuff is that it relies on criminals not being thick as a brick :)
18:25:05	gmaxwell:	I object to the claim that only (or even mostly) criminals need deniability; in particular, as you not criminals tend to make poor life choices to begin with. :)
18:25:38	midnightmagic:	:)
18:25:46	gmaxwell:	But yes, in practice these things are not so hugely useful.. though its sad to adopt something like pay to contract in a way that _reduces_ security against some known threats.
18:25:57	midnightmagic:	It was the easiest example that arrived off the top of my head.
18:26:45	midnightmagic:	fwiw, I strongly think that normal people should use these sorts of constructs widely, if not this one specifically. Just to be clear.
18:27:52	waxwing:	well this one is obviously hugely useful in non-criminal contexts. at least looks that way to me.
18:31:02	waxwing:	wow "exposure freeness". that's cool, so the judge doesn't even have to know the contents of the contract :)
18:33:40	gmaxwell:	waxwing: the schemes we have for tree structured hashes also let you do things like prove sections of text, so you can redact most of a contract if only part is in dispute.
18:35:09	gmaxwell:	(e.g. use the hash of the full contract (plus optionally a nonce) to build a tree structured CSPRNG that assigns a nonce to each byte of the message. Then make a tree structured hash over the bytes with their nonces, sign the hash root... now you can compactly prove any character ranges from the original document, without revealing the whole document.)
18:35:18	waxwing:	gmaxwell: yes that's a great idea. although you'd have to make sure each *section* is signed independently.
18:35:49	gmaxwell:	waxwing: nope, see above, it can be done so a signal signature lets you cover arbritary ranges, down to the bit.
18:36:30	gmaxwell:	if the contract naturally has some structure like sections, the ranges could break along them too, e.g. if you wanted disclosure of certian data to always be forced.
18:36:32	waxwing:	i'm thinking semantically; Alice promises A,B,C if Bob abides by D,E,F - no point exposing only the A,B,C part. sort o fthing.
18:37:15	gmaxwell:	yea indeed, though if the scheme is interactive and bob reveals A,B,C and D but not E and F, alice can just expose E,F (or just whatever bob isn't complying with).
18:37:45	gmaxwell:	Main utility I saw in this was just a "here is my contact with them with the payment amounts, and my delivery address redacted"
18:37:52	waxwing:	yes
18:38:47	waxwing:	the conditional exposure solves it, or at least it's good enough. people who write legal contracts will have fun :)
18:39:47	waxwing:	one could imagine cases where Bob applies game theory, knowing Alice values the secrecy of C more than the fulfilment of the contract.
18:40:59	waxwing:	but exposure only to a judge/arbiter might make that almost purely theoretical
18:41:31	gmaxwell:	waxwing: sure, but without this scheme bob can do that over the whole contract; so at least its a strict improvement.
18:47:22	dgenr8:	bramc: the red double-spends were seen first in a block http://respends.thinlink.com/
19:03:34	bramc:	dgenr8, Maybe it's happening already?
20:13:45	dgenr8:	bramc: yes, either the double-spends were not broadcast, or the subnetwork that monitors for double-spends happened to miss them. that's grown a lot less likely recently
20:14:32	bramc:	dgenr8, Some of the red ones have very long delays between the first and second transaction, there might be some propagation problems involved, perhaps they're somewhat malformed
20:56:05	jae:	jae is now known as Guest88257
21:43:20	arubi_:	arubi_ is now known as arubi
22:19:55	lnovy:	lnovy is now known as RogerVer
22:20:03	RogerVer:	RogerVer is now known as lnovy
22:29:46	zveda:	zveda has left #bitcoin-wizards
23:46:44	akrmn:	silly question: What if force miners to hash the whole block instead of the header? Would that incentivize smaller blocks?
23:58:41	gmaxwell:	akrmn: that would be incompatible with lite clients. And it wouldn't just "icentivize" it would make it so you'd have to be stupid to include any txn at all so long as there is subsidy.