01:49:39	c0rw1n:	c0rw1n is now known as c0rw|sleep
03:19:30	grubles:	grubles is now known as Guest21092
03:27:39	NewLiberty:	Is there a mitigation to the risk of a node advertising itself as a version different from what it truly is?
03:29:22	Adlai:	not paying attention to the self-reported version strings
03:29:52	NewLiberty:	Intentional misrepresentation, say if there were a hostile reaction to a hard fork
03:30:26	Adlai:	* Adlai is half-serious... nodes should treat all data as potentially hostile
03:31:31	NewLiberty:	Sure, but orthogonal. If a node is running on a different fork (because different version) but masquerading as the opposite fork in order to disrupt it
03:33:29	NewLiberty:	If I were putting together a realtime blackhole list of nodes that are not on my fork using version, and they are masquerading, the list is bad
03:38:30	zooko``:	zooko`` has left #bitcoin-wizards
03:40:22	Adlai:	* Adlai shrugs, this also sounds more for #bitcoin-dev or even #bitcoin
03:42:19	NewLiberty:	* NewLiberty thanks you for your patience
03:52:10	Luke-Jr:	NewLiberty: the version is software, not network. if you need to "blackhole" nodes on a different network, you're already dead.
03:53:22	NewLiberty:	Thanks for responding, but you've misunderstood the risk.
03:54:23	Luke-Jr:	there is no risk, when it comes to reported software version. *shrug*
03:54:52	NewLiberty:	Adlai answered already. Don't trust it.
03:56:00	Adlai:	judge peers based on behavior, which incidentally is what the current software already dose
03:59:27	NewLiberty:	Right. just will need the distinguishing behaivor (which can't exist yet anyway)
04:05:19	NewLiberty:	Luke-Jr consider if you are looking for nodes validating vs 20mb blocks and some trouble maker sets up many nodes that pretend to do so by reporting new version, but are running old version on 1mb chain instead.
04:07:18	Adlai:	if one chain has higher total work than the other, and both are valid by your own node's consensus rules, should you care about anything else?
04:09:20	Adlai:	partitioning your own node to intentionally use a less secure fork will only make it easier to perform attacks involving reorganizations against your node
04:09:58	NewLiberty:	Of course not, in such case there isn't an issue. but that state would be temporary, and likely brief.
04:10:40	NewLiberty:	These would be chaff nodes, just to get in the way of the fork they would want to fail
04:11:13	NewLiberty:	So it is sort of thier goal to make it iasier to perform such attacks
04:16:38	Adlai:	maybe you can explain what "such attacks" entail? afaik the relevant "attack" in this situation is an economic one, that of incentivizing a majority of hashrate to mine your preferred fork; and this is because the fork with the majority hashrate wins, no matter what the "chaff nodes" say
04:17:33	NewLiberty:	Hashrate will follow investment
04:17:47	NewLiberty:	yes?
04:18:05	Adlai:	do you have a specific attack in mind, one at the level of the wire protocol?
04:18:29	NewLiberty:	Not at the wire...
04:18:37	NewLiberty:	If all the TX on one fork aren't getting to miners
04:18:55	Adlai:	"wire" in the sense of protocol messages sent between nodes, maybe that's the wrong word
04:22:37	NewLiberty:	With no TX that fork isn't going anywhere, and then divergence in pricing between two forks occurs, miners might be switch to the other more lucerative fork.
04:25:56	NewLiberty:	Anyhow, you answered what I sought in your first line, so TY
04:29:00	Adlai:	np. also check out https://en.bitcoin.it/wiki/Freenet
04:30:18	Adlai:	(in case you're worried about getting partitioned in the clearnet p2p network)
04:35:58	NewLiberty:	I'm not worried for myself, just looking at some attack vectors that might be used to leverage an economic attacks by disrupting during a rare event. Corner case risks.
04:37:38	NewLiberty:	* NewLiberty tumbles down the freenetproject rabbithole anyway
08:05:14	weber.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:14	weber.freenode.net:	Users on #bitcoin-wizards: andy-logbot gielbier p15x Mably felipelalli blackwraith xenog hktud0 gill3s antanst o84wb76g b_lumenkraft hashtag_ kompreni s3gfault RoboTeddy [7] wizkid057 Guest21092 [d__d] optimator_ cluckj Dr-G2 NewLiberty GGuyZ fanquake1 veox shesek d1ggy_ DougieBot5000 mkarrer MoALTz hashtag airbreather koshii moa metamarc PRab LeMiner dc17523be3 Emcy justanotheruser prodatalab sparetire_ Madars bsm117532 mr_burdell Eliel azariah isis NeatBasis kyuupichan
08:05:14	weber.freenode.net:	Users on #bitcoin-wizards: gnusha amiller kanzure harrow xabbix HM iddo michagogo harrigan mariorz epscy vonzipper catcow a5m0_ smooth dignork ttttemp_ pollux-bts runeks coryfields CryptoGoon Sqt poggy jbenet cfields platinuum adams__ livegnik K1773R Alanius nsh tromp petertodd brand0 yorick ir2ivps5 OneFixt richardus luny null_radix PaulCapestany nephyrin phedny so davout phantomcircuit afdudley cdecker jonasschnelli pigeons Luke-Jr SwedFTP BananaLotus guruvan Meeh
08:05:14	weber.freenode.net:	Users on #bitcoin-wizards: bliljerk101 lnovy ajweiss wiz nanotube dardasaba__ forrestv artifexd mappum yrashk mikolalysenko Muis lmatteis warren gmaxwell weex_ Xzibit17 GreenIsMyPepper sdaftuar eric roasbeef s1w CryptOprah huseby dasource mm_1 Taek morcos crescendo nickler EasyAt Iriez wumpus merlincorey [ace] sturles berndj comboy jaromil Apocalyptic cryptowest_ Graet indolering Keefe larraboj ryan-c jessepollak gribble d9b4bef9 starsoccer kumavis otoburb midnightmagic
08:05:14	weber.freenode.net:	Users on #bitcoin-wizards: BlueMatt TD-Linux Anduck luigi1111 gavinandresen AdrianG espes__ warptangent STRML sl01 kinlo gwillen Oizopower @ChanServ BrainOverfl0w scoria sipa Cory theymos deego rustyn dgenr8 se3000 binaryatrocity dansmith_btc Jaamg yoleaux Fistful_of_Coins _whitelogger uumdbmd fluffypony bedeho btcdrak bosma andytoshi maaku face elastoma Logicwax SubCreative sadoshi sparetire Tiraspol hulkhogan_ jmcn_ ebfull lmacken c0rw|sleep tromp_ crowleyman heath
08:05:14	weber.freenode.net:	Users on #bitcoin-wizards: CodeShark melvster1 Adlai sneak copumpkin helo Starduster_ KuDeTa roconnor mengine catlasshrugged throughnothing_ Krellan_ stonecoldpat spinza leakypat
08:08:00	kompreni:	Adlai said ``miners might be switch to the other more lucerative fork.'' I have thought about this often. What if a majority of miners worked together to create a fork that was profitable while not necessarily nefarious. For instance, I often think about ``lost coins'', or coins where the private key is no longer accessible for whatever reason. Since there will only ever be 21e6 coins, expiring lost coins should only increase
08:08:01	kompreni:	value of the remaining coins.
08:08:44	Luke-Jr:	kompreni: miners don't get to decide hardforks.
08:08:46	kompreni:	It seems at least in theory it would be possible for miners to expire these coins. Suppose we have some block height X and some number of blocks Y. Starting from blockheight X-Y, people could prove control over private keys by creating a transaction to themselves. At block X, all tx inputs for new transactions must come from tx outputs from blocks with height greater than X-Y.
08:13:15	stonecoldpat:	kompreni: if i understand right, the miners would take control of the expired bitcoins - if they have not been used for 'y' blocks?
08:13:47	stonecoldpat:	if that was the case, then miners have the incentive to censor high-valued transactions - and then just claim them when 'y' happens, assuming their greedy
08:14:09	Luke-Jr:	how does expiry work with cold wallets?
08:16:38	kompreni:	stonecoldpat: Not necessarily take control — that would be a more nefarious scheme. I was thinking something more honest, like ``these coins have not been used in however long, so we will reject them if they are not proven usable by a certain time’’
08:17:26	kompreni:	Luke-Jr: the transaction would get rejected by the network if the source address is not proven spendable within the timeframe
08:17:57	Luke-Jr:	kompreni: there is no such thing as a source address in bitcoin
08:18:20	Luke-Jr:	and killing cold wallets would be annoying
08:18:24	kompreni:	Luke-Jr: sorry, I meant utxos
08:18:53	stonecoldpat:	kompreni: would that not just encourage more broadcasting on the network? and if they become invalid - do the coins become recycled in the coinbase? or lost forever?
08:19:10	Luke-Jr:	I see no benefit to such expiry. Just downsides.
08:19:47	kompreni:	Luke-Jr That would be annoying, but to quote gmaxwell: ``My perspective is that absolute soundness is best (rules which cannot be broken at all), followed by cryptographic soundness (rules that breaking requires P=NP, theft of a secret, or insane luck), followed by economic soundness (rules that cannot be profitably broken), followed by honesty soundness (rules that hold when the participants follow the rules and aren't fault
08:20:05	kompreni:	What if it was economically sound to do so?
08:20:13	stonecoldpat:	kompreni: if they are recycled, then the miners would take control and we're back to censoring transactions
08:20:49	kompreni:	I’m wasn’t considering them recycled… I was thinking lost forever.
08:20:53	stonecoldpat:	if i cant 'spend' the utxo / prove ownership of it - then no one is entitled to those coins
08:20:59	kompreni:	Right
08:21:23	kompreni:	The value of everyone else's bitcoin would increase, provided they could prove spendability
08:21:30	Luke-Jr:	I don't see how you think that quote is relevant.
08:21:39	stonecoldpat:	if they are lost forever then all we do is reduce the utxo set, i dont think the data saved in ram would be enough
08:22:44	kompreni:	Luke-Jr: I think it’s relevant because this exploit would be at the fault of the bottom two rungs of soundness - that is economic soundness and honesty soundness.
08:23:01	kompreni:	The miners need not be honest to the core devs
08:23:03	Luke-Jr:	what exploit?
08:23:05	kompreni:	(honesty)
08:23:46	kompreni:	And it also might be more profitable for miners to run nodes that requires provable spendability
08:23:53	kompreni:	(economics)
08:25:51	stonecoldpat:	i can see that what you suggest would be to explicitly show people that there are less coins, but this is already done implicitly if coins have not been used for a long time (zombie coins) - i cant comment to say if the explicit is worthwhile, it could be counter-productive as people lose large stocks of coins and then leave the eco-system
08:26:58	stonecoldpat:	i think the fact we already have a hard-limit of 21m is already worrying people of the future, never mind being explicit that we have less than 21m
08:27:53	s3gfault:	there should never be expiry on coins, unless its dust.
08:28:21	kompreni:	People at risk of losing large quantities of coins could be buffered with ample block time (say, a year).
08:28:27	s3gfault:	i think most people would be alright with giving UTXO's under 0.0001BTC to miners if they're not moved in say, 4-5 years
08:29:27	s3gfault:	i bet that sort of code could be merged in without much objection... it would really need to be dust though... 1000 satoshis or less and not moved for 4 years
08:29:37	s3gfault:	brb
08:30:38	stonecoldpat:	s3gfault: i can see right now that would work yeah, in 40 years time if dust is standard usage (so 0.0010 represnts $20, with $1 transaction fees) then it may not be
08:30:52	stonecoldpat:	s/$10/$20 ...
08:31:31	s3gfault:	thats why it needs to be sweeped within 4 years , not 4 years. so people losing their dust can't complain
08:31:38	s3gfault:	'not 40 years'
08:31:46	kompreni:	Also, and I may be getting myself neck deep here, but I think it’s tough to institutionalize an asset like Bitcoin when people don’t know how many coins are actually usable. For instance, consider Satoshi’s mined blocks. All together, he contains several percentages of the total supply of Bitcoin. Is it not of significant investor interest to determine if such high quantities are actually usable?
08:32:05	s3gfault:	fees will be adjusted... any UTXO worth less then 1 cent USD should be given to miners if not spent after X blocks
08:32:08	s3gfault:	brb
08:32:17	stonecoldpat:	i just mean if the code was merged and we had this cycle of sweeping for a long time - in the future it will probably need removed if small coins become valuable
08:33:25	Jaamg:	why should the dust be sweeped?
08:33:39	stonecoldpat:	kompreni: thats a bit like saying - nobody knows who owns this gold so lets melt it and blast it into space, so we are certain it can no longer be counted
08:33:50	Jaamg:	what if i, say, just printed a big pile of 1 and 10 μBTC notes and dug them in the ground
08:33:57	Jaamg:	to be dug out after 15 years
08:35:18	stonecoldpat:	kompreni: people may very well find their private key again, satoshi may even return (or his grandkids) to cash-out and buy a super-yhoat to escape the press
08:35:56	stonecoldpat:	yacht***
08:38:04	kompreni:	stonecoldpat I was actually thinking of it as a one-time expiry, not a periodic occurrence necessarily. I think the idea of some mystery figures owning large stakes of Bitcoin is causing big players who want to be involved, to not take the risk. I have no facts to back this up though (lol)
08:39:53	Jaamg:	who should decide when this one-time expiry happens?
08:39:55	kompreni:	So I guess my argument is from multiple perspectives. To recap: it would increase the value of spendable Bitcoins, since those not proven so would become worthless. And, it would remove some of the confusion around the true market cap, shareholding, etc of Bitcoin
08:40:02	Jaamg:	and what expires
08:42:06	kompreni:	Jaamg the Mining network collectively would decide to run nodes that hardfork to reject txs composed of utxos dating back from a block height less than a (network agreed upon) block-height-threshold, so to speak.
08:43:48	Jaamg:	kompreni: i think it would pretty hard for them to find consensus on this
08:44:10	kompreni:	Certainly not NP Hard, though ;)
08:45:49	stonecoldpat:	id be worried though - if miners collectively started to censor these transactions, this further opens the gate to censorship
08:46:27	Jaamg:	kompreni: maybe not, but i don't think there is anything that can be done to it
08:46:46	Jaamg:	or is there?
08:47:15	stonecoldpat:	while miners do have that power - i dont think its a miners role to dictate what transaction gets in/out as some type of gate-keeper, they should be accepting all valid transactions
08:48:02	stonecoldpat:	of course if theres a backlog, there is a priority attached to transactions, but that should be well-defined
08:52:17	kompreni:	I would not doubt the power of group of people to effectively ``unionize''
08:53:04	kompreni:	The people in this case being miners
08:54:52	kompreni:	I think it is foolish to think the Core Devs will be able to maintain a grapple on the entire network out of good faith. Because that is ultimately what it comes down to — good faith. If enough support is garnered from running some custom hardfork node in the biggest pools, the entire ecosystem could be easily hijacked
08:55:27	kompreni:	And by ``entire'' I mean 51%
08:56:17	kompreni:	What is stopping them?
08:56:59	stonecoldpat:	as you said earlier, the economic factors, that type of censorship could kill the value of bitcoin, (we dont know if it would or not) - but its an unknown that is stopping them
09:05:22	kompreni:	I agree it could kill it. But I could also see it being part of a process to supplant that radical, free (awesome!) value with institutional value, i.e. the consensus algorithm becomes entangled with special interest groups, lobbying, etc.
09:11:43	kompreni:	I mean hey, look at how being ``free'' in America has changed over time — we live in a constant state of surveillance. Granted, that consensus algorithm (the constitution) has evolved pretty slowly, but technology evolves fast. And I think (economic) security can be seen as a driving factor in both cases. I think we should give credence to patterns in history and prepare as best as we can :)
09:54:53	[1]LeMiner:	[1]LeMiner is now known as LeMiner
10:09:06	stonecoldpat:	does anyone know if spv wallets today support building a merkle-tree to prove that an utxo they can spend has been accepted to the blockchain?
10:11:15	ThomasV:	stonecoldpat: this seems to be the definition of spv
10:12:17	stonecoldpat:	i mean, is there a wallet today that would generate that information for me, that I could then give to someone in a seperate communication channel
10:12:44	ThomasV:	generate the merkle branch, or the whole tree?
10:12:50	stonecoldpat:	just the branch
10:13:09	sipa:	spv wallets don't build such proofs, they request them and verify them
10:13:18	sipa:	to build them, you need to have the block
10:13:44	sipa:	and bitcoin core has recently a patch merged to create such a proof
10:13:52	ThomasV:	electrum requests the merkle branch from an electrum server; you could use that
10:15:53	ThomasV:	sipa: so it will be available with bitcoin-cli?
10:18:01	stonecoldpat:	ah that is cool ill check out that patch and the electrum server is a good idea thanks thomas - i wasnt sure if an spv client would keep the merkle tree locally once it hears about the new transaction or not (that could then be regurigated).
10:31:39	ThomasV:	stonecoldpat: added that for you: https://github.com/spesmilo/electrum/commit/5fa2a48343be7253497bb96ad70d091011ef4389
10:38:24	c0rw|sleep:	c0rw|sleep is now known as c0rw1n
10:50:59	stonecoldpat:	ThomasV: thanks! :)
11:17:08	LeMiner2:	LeMiner2 is now known as LeMiner
12:04:19	moa:	so -prune=1000 keeps blockchain files around ~1Gbyte now right?
12:33:26	BrainOverfl0w:	Recommended reading: proposal for a memory-hard function for mining http://eprint.iacr.org/2015/430.pdf
12:40:33	sausage_factory:	sausage_factory is now known as priidu
14:27:27	Guest21092:	Guest21092 is now known as grubles
15:25:30	andytoshi:	an old essay linked recently https://www.schneier.com/crypto-gram/archives/1998/1015.html#cipherdesign on amateur crypto
15:56:50	instagibbs:	seems relevant in this space too... especially #1,2,4 of the take-aways
15:59:53	instagibbs:	ofc #3 as well. 5/6 seems pretty standard these days
16:54:37	tromp:	tromp has left #bitcoin-wizards
17:09:55	Guest24344:	Guest24344 is now known as amiller_
17:10:12	amiller_:	amiller_ is now known as amiller
17:22:49	gmaxwell:	re: bitcoin-development@ ... it's been a while since someone propoposed DHTs, I was getting nostalgic the other day.
17:26:08	petertodd:	gmaxwell: the latest coolness is CHT's
17:27:40	fluffypony:	petertodd: Cycloheptatriene?
17:28:21	petertodd:	fluffypony: Centralized Hash Tables
17:28:30	fluffypony:	ah yes
17:28:34	fluffypony:	centralisation is all the rage these days
17:28:56	petertodd:	fluffypony: I'm not even going to ask why you know about Cycloheptatriene...
17:29:08	Tiraspol:	* Tiraspol slaps petertodd around a bit with a large trout
17:30:05	petertodd:	Tiraspol: I'm not going to say on a public forum whether or not I'm into that...
17:30:25	Tiraspol:	everyone knows you are
17:30:47	petertodd:	heh
18:42:56	grubles:	grubles is now known as Guest45787
18:53:24	maaku:	maaku is now known as Guest18989
19:10:49	Guest45787:	Guest45787 is now known as elgrubles
20:27:40	dEBRUYNE_:	dEBRUYNE_ is now known as dEBRUYNE
21:02:35	amiller:	im announcing my coinscope project today
21:02:37	amiller:	project page and paper: http://cs.umd.edu/projects/coinscope/
21:07:08	StephenM347:	amiller: the image resource isn't showing, fyi
21:07:19	amiller:	ive been quiet about it mostly because i wanted a chance to collect some of the data before the technique is widely known
21:07:33	amiller:	StephenM347, uh, i think i just fixed it try again :(
21:07:53	StephenM347:	amiller: yeah, works now
21:08:08	amiller:	one of the main ideas is to use 'addrman' finger printing to figure out which nodes in the public network are connected to each other
21:08:38	sipa:	amiller: hah, did you know about the technique beforehand, or did you learn about it from nickler?
21:08:40	amiller:	i.e., whats the topology of the reachable network? is it actually random or is it skewed towards well connected nodes or is it vulnerable to partitions
21:09:11	amiller:	sipa, i've been using it since jan 2013 or so.
21:09:22	sipa:	ha
21:09:26	sipa:	evil
21:10:11	amiller:	ive shown preprints of my paper to gmaxwell and a few others earlier btw to cover my ass and have a better chance of not inadvertently breaking the network
21:10:23	amiller:	also tested it on local networks and partially tested it in my shadow simulator
21:11:02	amiller:	(i'm actually very anxious / self concious about doing anything 'bad' to the network especially after chainalysis etc. so im trying to stay on the non-evil side here)
21:11:46	sipa:	i'm mostly talking about not trying to get it fixed for so long :)
21:12:59	amiller:	well, like i said i mentioned the technique discreetly, so it could have been stopped quicker if it seemed urgent
21:13:24	amiller:	im of the opinion that this kind of measurement / fingerprinting is more of a positive thing than a negative thing so im a bit sad newer versions make it harder for that reason
21:17:24	CodeShark:	"It is therefore possible to block a node from hearing about a transaction for two minutes by sending an INV message and then ignoring the resultant GETDATA." - I don't think that's a good thing :p
21:19:03	hulkhogan_:	it depends on how it will be used, analysis has its place but a network map of all p2p nodes , if its a effective technique would probably be used to analyze a part of the topology before attempting a sybil (so its useful in that regard, i suppose)
21:19:35	CodeShark:	I'm not so much talking about the use cases but about the fact it's possible to do this
21:23:08	KuDeTa:	" Assuming honest pools broadcast using the standard protocol, and the selfish pool selectively creates low latency connections to the influential set, the latter can gain huge broadcast advantage."
21:23:38	KuDeTa:	^^interesting, is this well known>?
21:25:01	KuDeTa:	"Prior work has shown that a selfish mining pool can gain advantage if it initially withholds blocks it finds, but then releases them as soon as a competing block is found." (Prior work, i guess so, nm)
21:25:27	amiller:	ah yeah so besides the topology mapping, the mining pool decloaking stuff is entirely new and i havent talked about it at all yet
21:31:30	KuDeTa:	i am by no common measure, a wizard of any type,but amiller am i right in thinking that a carefully constructed DOS attack to that "2%" IP address would cause havock?
21:31:38	KuDeTa:	havoc*
21:32:23	KuDeTa:	sorry, 2% list of IP addresses..*
21:34:41	KuDeTa:	i guess if you can knock 3/4 of the hashing power out, even only for a few hours, that could be a very profitable little adventure.
21:34:51	amiller:	KuDeTa, i think its possible. i think its likely (but my evidence is not totally conclusive) that there are several mining entities with a single publicly reachable frontend, so those could be dosed. i *speculate* that what is happening is that other pools including the largest pools have outgoing-connection-only frontends and so that would be harder to dos
21:35:56	amiller:	also just because i found a bunch of nodes with high affinity for one pool or another, it oculd be they are just the lowest latency connections, and if those were taken out there are lots of other connections too just marginally higher latency, so they dont win races
21:40:09	KuDeTa:	hmm, yeah, i figure the big pools have thought about this and taken counter measures (i think i remember some pools being dos'd in the early days) - still, i wonder if your work leads to ways of constructing attacks that could do harm? Have you thought about it much?
21:58:21	CodeShark:	"i figure the big pools have thought about this and taken counter measures" - famous last words :p
21:59:05	KuDeTa:	would sure be interesting to watch if someone tried to do it..
21:59:07	CodeShark:	even assuming equal propagation chances, the selfish miner attack still only requires 1/3 of the network
21:59:08	KuDeTa:	;)
22:01:49	CodeShark:	we like to live dangerously, though ;)
23:29:42	belcher:	is there anything that could be done about services like cryptograffiti.info bloating up the utxo set ?
23:30:12	belcher:	sending small amounts of thousands of addresses in an effort to store data
23:33:16	chmod755:	* chmod755 adds cryptograffiti.info btc addresses to his blacklist
23:33:44	copumpkin:	wtf, people putting torrent URLs in there
23:34:25	belcher:	chmod755 how do you know what they are in advance?
23:34:32	belcher:	copumpkin also whole images
23:37:11	belcher:	might be easier to live with if it was with op_return
23:37:16	belcher:	but this junk is unprunable
23:38:34	belcher:	chmod755 also what blacklist? i assume your miner..
23:39:38	belcher:	you can detect them by checking if the address hex is all ascii characters
23:39:44	gmaxwell:	if only there were some way to limit the amount of data the network carried! or perhaps a way to neutrally allocate capacity between more and less valuable uses, without passing a personal judgement over each one? Too bad no one has any idea how to accomplish that!
23:40:03	gmaxwell:	belcher: that test has a pretty poor false positive rate, sadly. :(
23:43:09	c0rw1n:	c0rw1n is now known as c0rw|zZz
23:43:54	chmod755:	belcher, it looks like they are reusing some addresses
23:43:58	gmaxwell:	hm. higher than I thought, so "contains a non-printable character" looks like about one in 250 million. unless I'm math failing.
23:44:21	gmaxwell:	In anycase; going and blocking particular things is a not great route.
23:44:37	belcher:	yep, that would reduce confidence in bitcoin
23:44:52	gmaxwell:	chmod755: I dunno about that one; but many of those things required their users pay to some static service address; so a generic high reuse deprioritizer catches them; but thats easily changed.
23:45:18	belcher:	chmod755 they might be reusing addresses because common messages are repeated
23:45:30	gmaxwell:	belcher: the more generic the less concerning; but really the system has mecneisms to deal with it more fundimentally; limits and a market for the limit.
23:46:21	belcher:	the utxo set is a common good if im not mistaken, the market for fees is only for blockchain space
23:46:32	belcher:	perhaps some kind of outreach ? convince developers to use op_return instead of utxos
23:47:10	gmaxwell:	belcher: can't add to the UTXO without using blockchain space.
23:47:55	gmaxwell:	the whole motivation is to externalize cost for people, using an encoding that helps people not store your data doesn't sound like a great pitch. :)
23:51:21	belcher:	regarding fees, the market doesnt operate on utxos, spending 100 utxos to create one isnt cheaper than spending 1 to create 100, the calculation the miner does is presumably related to propagation time not utxo size
23:52:16	sipa:	belcher: it actually is, in the current bitcoin core calculation
23:52:18	belcher:	i understand the blockchain will always need to be stored somewhere, to bootstrap new nodes and all, so op_return will still fulfill their desire for permanent storage
23:52:46	belcher:	sipa i didnt know that, thats nice of the miners
23:53:02	belcher:	i guess they're full nodes and store the utxo set too
23:53:21	gmaxwell:	more like "thats nice of them to not pay any attention to the changes gmaxwell made"
23:53:38	belcher:	i wont tell anyone :)
23:53:42	gmaxwell:	but that behavior is only to change the calculation for 'free' transactions; -- I figured more would cause action.
23:54:00	gmaxwell:	since changing the priority of w/ fee would arguably reduce income.
23:54:26	gmaxwell:	In any case; there are lots of people proposing that nodes don't bother with history and just hotstart from some trusted database.
23:55:04	gmaxwell:	I'm not personally fond of it; but it seems likely to happen to varrious degrees. Reachability of OP_RETURN data isn't necessarily so good, and even if a node has it-- that doesn't mean it'll serve it to you.