00:15:13xcthulhu:http://www.reddit.com/r/ethereum/comments/39imrr/vitaliks_premine_sale_opportunity/
00:15:30xcthulhu:Let’s see if he’s gonna eat his own horseshit, shall we?
00:19:03gmaxwell:offtopic here.
00:26:12xcthulhu:(sorry)
00:34:48bosnia:bosnia is now known as bosma
00:35:19jae:jae is now known as Guest70975
01:51:06jae:jae is now known as Guest68086
02:00:36c0rw1n:c0rw1n is now known as c0rw|zZz
02:01:02www:hi
02:01:26www:is there a good way to publish extended public keys on the blockchain?
02:01:39sipa:why would you do such a thing?
02:02:01www:hi sipa :)
02:02:25www:to let people generate stealth addresses or other derived addresses from your main address
02:03:20sipa:that's utterly pointless if you publish the extended address
02:03:29www:why?
02:03:50www:how would you do it?
02:03:50sipa:the point against address reuse is because it reduces your privacy
02:04:08sipa:if you *publish* your extended address you've now given a way to the world to detect all related addresses
02:04:08www:stealth addresses increase your privacy?
02:04:20sipa:stealth addresses != extended addresses
02:04:49www:you definetly can have stealth with extendet keys
02:05:08www:which stealth do you mean?
02:06:26www:furthermore there are good usecases where you want to have a proven record of transactions. don't assume that always everything has to be private. but this is not related to stealth ;)
02:06:36sipa:sipa has left #bitcoin-wizards
02:06:40www:lol
02:07:02www:why is everybody here so arrogant?
02:10:47gmaxwell:www: What you're saying doesn't seem to make a lot of sense. You say it would be more private, but sipa points out that if you publish an extended public key then its not private at all.
02:11:35amiller:www, not arrogant, just with scarce attention
02:11:38gmaxwell:You had to give the payer the address some way, use that channel, give them the extended public key. Tada; and then thats also private if thats something you care about. The blockchain is not a message bus.
02:12:05www:maybe you are talking about a different way to do stealth?
02:12:42www:what if you can't establish a channel?
02:12:50www:because you are async?
02:13:40gmaxwell:www: you still have to give someone the address in the first place; there _must_ be communication otherwise they don't know anything at all.
02:14:01gmaxwell:www: well you asked about a specific thing-- giving someone an extended public key.
02:15:02gmaxwell:maybe you meant something else? regardless. If you need a communication channel you need a communication channel, the blockchain isn't good for that (though it can be abused that way)
02:16:01www:yes, I think to have the extended pubkey on chain is very reasonable and useful when you want to have certain types of stealth payments and to avoid address reuse
02:16:26gmaxwell:www: if the extended public key is public then everyone knowns all the addresses, its completely non-private.
02:16:29www:you just need to publish it once somewhere linked to yoru identity
02:17:10www:it's optional. public OR private/stealth
02:17:18gmaxwell:www: great, and you can include the extended public key there, and when they check that they'll have the whole thing! tada done! and no need to put it in a perpetual public database where it will be visible to the whole world.
02:18:25www:of course you do not generate the stealth addresses the 'HD' way
02:18:42www:then of course they would be public (which is still sometimes wanted)
02:18:47gmaxwell:Then why the heck are you asking about an extended public key?!
02:19:10gmaxwell:www: if you put the extended pubkey in the blockchain there would be no privacy because anyone else could go and derrive the same addresses. As you note, if you're already depending on publishing your address someplace linked to your identity, you can put the extended key _there_. Why do you not just put it there, and kill two birds with one stone.
02:19:20www:again and again: because you can have stealth addresses with it. don't get how?
02:19:54gmaxwell:www: so clarifying, what your'e asking about is not an extended public key, but a "stealth address". Okay, now that makes a little more sense.
02:20:54gmaxwell:But I have still not gathered why you are not happy with the point that when you check the publication-linked-to-your-identity that can't just encode the stealth address, saving you the extra publication step?
02:20:58www:because there is also a good censorship-free way to put other information... like a name to your address. even if you tell me not to do so
02:21:29www:you can't call somebody and tell them that you are 1xyca;sdhfalsjdfh&*y9rf
02:21:49www:usability is terrible
02:22:02gmaxwell:the Bitcoin network is very much not censorship free.
02:22:17gmaxwell:(alas)
02:22:27phantomcircuit:or is at least much less so than other channels
02:22:30gmaxwell:okay so what you are really looking for is something like namecoin then?
02:22:33www:if the bitcoin network is not, then nothing is?
02:22:45gmaxwell:e.g. something to attach unique human friendly names to keying material?
02:22:47www:no, it is way more simple than namecoin
02:22:58gmaxwell:namecoin is super simple.
02:22:58www:it is called bitcoin
02:23:54www:no need to use another network if you just want to have names with optional stealth payments for bitcoin
02:24:10gmaxwell:www: in the bitcoin network today your transactions can be freely surpressed by the decision of ~3-4 parties, at no cost to themselves; the main defense against that is being indistinguishable. (and hope that they don't target you)
02:24:31www:so bitcoin is broken?
02:24:38gmaxwell:www: I wasn't suggesting using namecoin, I'm trying to decode what you're actually trying to accomplish because it is unclear.
02:24:39Luke-Jr:* Luke-Jr suggests rename extended public key -> extended watch key
02:26:04www:maybe we need a well defined bitcoin dictionary
02:26:41gmaxwell:Extended public key is a well defined term, but I don't care what you call things so long as I can figure out what you mean.
02:27:13gmaxwell:I think I've figured out what fork of what you're asking for there. But now, this last part sounds like you're looking for a key value database.
02:27:25gmaxwell:Preumably you'd want it to be efficiently and securely queryable?
02:28:28www:would be best, yes
02:28:51gmaxwell:(otherwise, ... why not just have whatever centeralized services most people would trust to query it keep a list! :) )
02:29:51www:back to something you said: if 4-5 entities control bitcoin as yous aid, why don't they block e.g. the silkroad coins?
02:30:00gmaxwell:www: okay, well there currently isn't a way to do that in bitcoin even if you look aside at the misuse of the system to store key/value data. The challenge is in making it securely queryable. It's not fundimentally hard to do this, but it requires additional commitments that bitcoin doesn't have.
02:30:20www:just run a full node if you want highest security
02:30:23www:no?
02:31:43www:otherwise trust friends who run a full node
02:31:47www:and so on...
02:31:58gmaxwell:www: Perhaps but the overwhelming vast vast majority of users don't do that--- and the trends are in the opposit direction (esp with talk of increased load on the system); so IMO something that doesn't have security at all except for full nodes seems like a waste... just pretextual security. E.g. if most users are just going to trust bc.i why saddle everyone else with more load?
02:32:56www:trends are pointing in a bad direction for bitcoin, indeed
02:33:42www:when you download your full node client you trust again somebody that the right genesis hash is hardcoded, right?
02:34:20www:so fundamentally you always need to trust somebody initially
02:34:37www:if you can diversify trust (multiple friends) then security increases
02:35:28gmaxwell:www: thats not the case. I mean if the wrong one is hardcoded you'll notice that you're rejecting the longest chain.
02:35:58gmaxwell:www: in any case, so there you're imaging some kind of friend network. OKAY, but if you have the friend network, why isn't it just answering your queries?
02:36:11www:would you also check the magic byte and port number and difficulty?
02:36:28www:probably you would
02:36:34www:but most people don't... again
02:37:50gmaxwell:www: you could, if you liked. Come you must admit thats not really much of a plausable attack. Where lots of people trust websites which can just start giving false information at any time, due to hacks or bugs or because the operators were evil all along. While in the software case, there is one chance for it to be busted, and that much is auditable and detectable, and we use a public signing
02:37:56gmaxwell:process to make sure you're not being given a bad version just for you.
02:38:25gmaxwell:In any case, if you think its fine for people to just trust some popular website (or a few), okay, thats not a totally irrational position. For some applications it is. But then why the blockchain pretext?
02:39:08www:why not just a friend network? because I actually just want to send coins to names with a high-enough security in a convenient way. nothing is perfectly secure. but IMO it would be an improvement
02:39:20www:forget websites
02:39:24www:i never talked about websites
02:39:45www:hmm
02:40:30gmaxwell:But in your example you claimed that you didn't care if it could be efficiently securely queried because you could ask friends, ... in that case you're trusting the friends, so why not just do that?
02:40:32www:the attack could be done. several factors improve the security of bitcoin. it is not just one thing.
02:41:23gmaxwell:www: do any of your friends (e.g. people you already know offline?) run bitcoin full nodes today?
02:41:39www:yes
02:41:56wallet42:wallet42 is now known as Guest88920
02:41:56wallet421:wallet421 is now known as wallet42
02:41:56www:but with friends I mean several generally trusted entities.
02:42:05gmaxwell:I find that a little unlikely.
02:42:07gmaxwell:okay then.
02:42:23www:e.g. you download a wallet. you generally trust the wallet developer
02:43:26gmaxwell:in any case, ... if you are happy with security reducing to a "generally trusted entity" then why not have the entity keep the database? at that point your security is much better, e.g. it can be guarenteed instant update and reorg free (assuming the honesty of the 'generally trusted entitys' holds), and their behavior could be completely auditable.
02:43:55www:a lot of companies values is based on reputation. even if one of them becomes evil or just gets hacked, then it would be good ot have alternativesj to check against. aways. diversify
02:44:10gmaxwell:and just as a minor bonus you wouldn't be subjecting yourself to the censorship of both the generally trusted entity _and_ some small number of miners, but only the former.
02:44:32gmaxwell:www: true, but a collection of companies can keep a database without using bitcoin.
02:44:39www:because it is not good to trust just one entity?
02:44:44gmaxwell:see above
02:44:49www:but it is not open?
02:44:56kanzure:there are many open-source database implementations
02:45:02gmaxwell:and because of query efficiency you still are trusting one entity in that example.
02:45:20www:it is not about open source but about open access (censorship free)
02:45:31kanzure:yeah they can do that
02:45:41kanzure:but "censorship free" does not mean what you think it means
02:45:59www:kanzure: give me the dictionary please
02:46:39gmaxwell:www: again, if you're accessing via trusted entities x,y,z then any condition under which they could censor a database they ran they could also censor the queries they ran for you. Plus on the bittcoin case you get extra censorship from miners and potentially node operators that don't appricate you using their _currency_ as a rolodex. :)
02:46:40kanzure:well you're in a cryptography channel, so censorship resistance here is completely unrelated to whether something is open or closed access
02:47:46www:it has some similarities kanzure
02:48:05kanzure:nope
02:48:10www:gmaxwell: you say the miners own bitcoin?
02:48:38www:in my eyes the miners do rather stupid calculations
02:49:04www:and follow what the cool people (maybe you) say
02:49:36kanzure:why are you in charge of deciding who is cool
02:49:42kanzure:that doesn't make sense
02:49:57www:i don't do this
02:51:24kanzure:i think that you will find that nobody said that the miners own bitcoin
02:51:29www:if your assessment is right, gmaxwell, then bitcoin seems broken to me, because the miners (handful entities) have too much power
02:51:48kanzure:well it's also possible that the design is achieving something other than what you had considered
02:52:56www:i remember satoshi writing about 'one-cpu-one-vote'
02:53:16kanzure:that was one of the things he was wrong about
02:53:34kanzure:byzantine sybil resistance is incompatible with counting cpus
02:53:52www:but with counting asics it is?
02:55:35www:I also remember somebody quoting gavin "in the long run bitcoin will not be secured by PoW"... any development in this direction?
02:55:47kanzure:you also can't count asics because they have no identity
02:55:58kanzure:and identity is spoofable. that's what sybil resistance protects against.
02:57:05www:good point
02:57:25www:but you see that the initial design goals also evolve over time
02:57:46kanzure:if you say so
02:58:19www:are you a miner?
02:58:26www:operator?
02:58:28kanzure:i have been known to flip a few bytes
03:04:01www:so let me sum it up: there is no good way to add extended* public keys to the blockchain. bitcoin is controlled by a handful of people. and maybe: trusting identities is bad but trusting computational power is a good thing.
03:04:12www:i am not convinced ;)
03:07:20kanzure:"there is a specific design to bitcoin that makes some ideas workable and others not"
03:38:04gmaxwell:The hashpower distribution is currently busted. There are reasons to think things will improve. The bustedness is less concerning when the use is less trusting / less censorable (or could easily become much harder to censor); when you talk about something like a key value store, these current issues may be much more relevant.
03:39:19gmaxwell:I didn't say that 'trusting identities' is bad, it is what it is. But if you're going to trust parties to run a query server for you; why not trust them to just keep the database too; and then you remove a whole host of failure modes, and are just left with the trust related one.
03:42:04gmaxwell:since you can't do an efficient secure lookup against bitcoin, you assume some trusted servers (or at least some threshold like the majority is honest) OKAY; there are cases where thats totally reasonable. So why not stop there and use that rather than adding additional weaknesses and costs? thats all I was pointing out.
04:03:47www:thanks for your feedback, gmaxwell. I get what you say. the reason why to have the data on-chain is to have a open API where you don't need to ask for permission to use it. the trusted parties simply proxy you the results but ideally you interact directly with the blockchain. at least there is the option.
04:05:46www:of course this is flawed when transactions get blocked by some miners.
04:05:49gmaxwell:It's important to avoid decenteralization-theater though. E.g. if looking up names securely requires at 300 GByte download, whos going to do that? I say its important to avoid, because if we pretend something has all these fantastic security properties that it doesn't have in practice, then we're setting people up for a massive falure. Sort of the mess we've arrived at with the web CA system.
04:06:56gmaxwell:e.g. under some theory of operation the SSL/CA model could be quite nice, in the end the security it provides is very thin (e.g. anyone who can MITM your webserver towards the internet can get a cert as you) because of how its praticaly deployed and used.
04:13:14www:well... everybody who wants to become a trusted party for his friends/customers can easily download 300 GB. in case you bootstrap your chain via a torrent, this could be way less, right? the important thing is that entities can freely access the complete data for themselves or for others and that they can also disappear and be replaced by others (in case they become unreliable or loose reputation for a reason). yes, it is a layer on top of t
04:16:36www:hmm blockchain size is just 35 GB? also a super cool sidechain could be made for this, no? :D
04:17:34gmaxwell:right now, though the rules of the network let it grow 52gb/yr currently; and there is a proposal to increase that to 1TB/yr.
04:18:04gmaxwell:www: there are lots of ways to accomplish it in a parallel network sure, dunno that a sidechain would be super applicable though.
04:21:16www:1TB/yr is worst case, though. in 10 years 1 TB/year will also not really matter maybe. And is not one of the points to have sidechains that you don't need to be a full node for all the network but that you can be just a "full" node for your sidechain?
04:21:47www:can't the nodes of sidechains be teached to validate OP_RETURN data in a arbitrary way?
04:23:20gmaxwell:www: well it wouldn't be OP_RETURN... it would just be transaction data. ... but no thats not my point. If your system is just a database of X there is may be no reason to involve a cryptocurrency in it.
04:23:32gmaxwell:Surprise: there are other kinds of distributed database than blockchains!
04:24:04www:if a currency comes for free, why not use it for having a fee structure?
04:24:21www:...to avoid spam e.g.
04:24:38www:seems useful
04:25:18gmaxwell:True, though antispam can be done without the complexity of a two-way peg. E.g. by proof of solvency, or by hashcash, etc. lots of options.
04:26:34www:if hope you are working on abstracting the complexity of a two way peg ;)
04:26:44www:by the way, when will it be ready?
04:26:50www:on mainnet
04:27:21gmaxwell:"When its ready" :)
04:27:56www:and... how long will the debate be on whether or not sidechains need to be introduced? just looking at the current blocksize debate. such a super simple thing takes so much resources.
04:28:44www:was there a debate when the blocksize limit got introduced? was there a debate when the OP_RETURN size got halved? don't know
04:29:13gmaxwell:The blocksize stuff is a hard fork; it basically takes the rules of bitcoin and rewrites them to be against the current rules, everyone has to change, everyone is impacted.
04:29:27gmaxwell:op_return stuff is just node policy not a consensus rules of the system at all.
04:30:28gmaxwell:The 2wp stuff merely requires script enhancements, in fact I'm reasonably confident that it was actually possible (though a bit ugly) with bitcoin script before opcodes were disabled.
04:30:44gmaxwell:In any case, soft-forks; while also not trivial are much easier.
04:31:21www:sounds good
04:31:54gmaxwell:since, so long as they don't restrict tx patterns people are already using-- you're mostly free to not use them.
04:33:52www:but the nodes/miners need to understand that the new transactions are valid, otherwise they will reject them?
04:35:33gmaxwell:no, a soft fork only restricts the space of valid transactions. it takes a transaction that the old network sees like "anyone can spend" and restricts it to "can spend according to these rules"
04:35:45gmaxwell:it's like subtractivel carving a new feature out of marble.
04:36:39www:could altcoins become sidechains of bitcoin?
04:36:46www:migrate....
04:36:59www:WITH their own PoW?
04:38:01gmaxwell:well the whole thing about bitcoin sidechains is that they're backed by bitcoin, the bitcoin has to come from somewhere. And yes, a sidechain can have its own POW, at least so long as the chain its aside knows how to verify that POW if the spv-2wp is used.
04:39:02www:but altcoins could become 'assets' on a bitcoin sidechain then...?
04:39:15www:so you would pay just the tx fee with bitcoin
04:40:30gmaxwell:I'm not sure why you'd want to do that, but sure.
04:41:47www:back to the soft fork: what if half of the network plays according to the old rules "anyone can spend" and the other half restricts spending to the new rules. who is right?
04:43:17gmaxwell:hashpower majority; which is why soft-forks don't activate until picked up by a supermajority of hashpower. http://bitcoin.sipa.be/ver-ever.png shows the process for two softforks.
04:44:20www:could not the same be done with the blocksize issue (hardforks)?
04:44:34www:a fork is a fork
04:45:59www:i like the idea of having multiple with each other interacting blockchains with different PoW. would add security in my eyes.
04:50:00www:soft fork = fork on transcation level. hard fork = fork on block level (?) - both to be avoided in every case
04:57:09phantomcircuit:www, soft fork is when the change is backwards compatible
04:58:17phantomcircuit:ie rejecting transactions which the older versions accept is backwards compatible so long as the majority of mining power follows those new rules
04:58:44phantomcircuit:a hard fork is a change which older versions reject
05:16:02phantomcircuit:https://www.reddit.com/r/Bitcoin/comments/39hgzc/blockstream_cofounder_president_adam_back_phd_on/cs3ue6g
05:16:14phantomcircuit:"you're being too logical" -cypherdoc
05:16:21phantomcircuit:that is pure comedy gold
05:17:08gmaxwell:phantomcircuit: perhaps but not really ontopic here!
06:24:30wallet421:wallet421 is now known as wallet42
07:21:41frankenmint:frankenmint has left #bitcoin-wizards
07:45:15wallet42:wallet42 is now known as Guest80435
07:45:15wallet421:wallet421 is now known as wallet42
08:05:14card.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:14card.freenode.net:Users on #bitcoin-wizards: andy-logbot AaronvanW antanst dc17523be3 rht__ Quanttek priidu Relos b_lumenkraft hktud0 ThomasV bedeho rustyn_ spinza MoALTz droidr wizkid057 gill3s OneFixt Mably p15x sparetire_ TheSeven p15 SubCreative joecool Dr-G zooko Starduster_ d1ggy_ www jgarzik maaku jmcn_ dgenr8 ttttemp waxwing akrmn mariorz mikolalysenko Meeh akstunt600 cosmo justanotheruser devrandom arubi_ hashtag LeMiner midnightmagic Krellan kyuupichan bosma tucenaber ajweiss Cory
08:05:14card.freenode.net:Users on #bitcoin-wizards: temujin so cornusammonis cryptowest_ sparetire s1w catlasshrugged elastoma Iriez poggy PRab PaulCapestany lnovy HM shen_noe robogoat jouke Emcy dansmith_btc hayek gielbier heath gmaxwell tromp c0rw|zZz metamarc catcow btcdrak Xzibit17 prosodyContext vonzipper adams__ michagogo dasource yrashk CryptoGoon mappum CryptOprah artifexd Muis runeks kumavis platinuum jbenet fenn phantomcircuit Madars yorick mm_1 melvster tromp_ sneak go1111111 sadoshi
08:05:14card.freenode.net:Users on #bitcoin-wizards: gwillen amiller fluffypony livegnik mountaingoat a5m0 Apocalyptic triazo wiz wumpus ebfull EasyAt Alanius iddo koshii Luke-Jr forrestv theymos Taek zmachine AlexStraunoff luny copumpkin null_radix helo smooth lmatteis narwh4l thrasher` otoburb Keefe weex pigeons sturles nephyrin [d__d] rasengan berndj harrow STRML qawap lclc mengine superobserver stonecoldpat davout jessepollak huseby espes GreenIsMyPepper Logicwax CodeShark veox yoleaux comboy
08:05:14card.freenode.net:Users on #bitcoin-wizards: stevenroose kinlo sl01 gavinandresen nickler cdecker jrayhawk K1773R ggreer isis bsm117532 harrigan andytoshi scoria brand0 larraboj gnusha nsh jonasschnelli leakypat epscy lmacken cfields coryfields kanzure azariah warptangent TD-Linux crescend1 Zouppen _whitelogger binaryatrocity BananaLotus optimator Eliel mr_burdell throughnothing_ Fistful_of_Coins Jaamg xabbix dignork petertodd richardus afdudley SwedFTP guruvan nanotube warren sdaftuar eric
08:05:14card.freenode.net:Users on #bitcoin-wizards: roasbeef morcos merlincorey [ace] jaromil Graet indolering ryan-c gribble BrainOverfl0w @ChanServ AdrianG Anduck BlueMatt starsoccer d9b4bef9
08:05:14card.freenode.net:[freenode-info] channel trolls and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
08:26:53rustyn_:rustyn_ is now known as rustyn
08:56:27gmaxwell:gmaxwell is now known as Guest2862
11:41:19c0rw|zZz:c0rw|zZz is now known as c0rw1n
12:10:16justanotheruser:justanotheruser is now known as sunna
12:10:20sunna:sunna is now known as justanotheruser
15:01:52jae:jae is now known as Guest5208
16:11:25bramc:There seems to be some grumbling about whether full nodes which can't accept incoming connections really count
16:11:40bramc:It would be possible to make them mostly count using uTP and the DHT
16:14:45gavinandresen:bramc : nifty idea. I've been saying for years I'd like to see more diversity in the network protocols that are used to relay bitcoin transactions/blocks
16:15:06gavinandresen:... and doing that doesn't require any sort of fork at all...
16:15:26sipa:bramc: define "make them count" ?
16:16:07bramc:gavinandresen, uTP is basically a swap-in replacement for TCP. It wouldn't change things all that much except to make NAT traversal easier
16:17:05bramc:sipa, Apparently the graph showing a huge drop in full node count *might* be caused by a change in methodology where they stopped counting nodes which can't accept incoming connections, which might be most of them
16:17:20sipa:bramc: there are two ways in which full nodes "count", one is towards the network (which requires them to be reachable, have bandwidth, serve and relay blocks, ...), another is towards the decentralization of validation (which requires people to pay attention to what they're doing, using them to validate their transactions or connect other bitcoin software to it)
16:17:32bramc:speaking of which someone asked me where that data came from and I have no idea. If anybody knows the original source I'll pass that info along.
16:17:44sipa:bramc: of the first afaik, we have plenty
16:17:51sipa:bramc: the second however is not measurable
16:18:49bramc:https://imgur.com/EL0zHRe
16:19:24sipa:bramc: more protocols in which nodes can talk to eachother are welcome, of course
16:20:39bramc:The other dumb question is, uh, does bitcoin core pull in miniupnp? That makes a big difference in how likely something is to be reachable.
16:21:10hearn:yes it does
16:23:22nubbins`:quick question
16:23:42nubbins`:why do we pretend that there are less than 6,000 nodes when that's actually the number of nodes running 0.8.x or higher?
16:24:03bramc:nubbins`, Do you have info about where these stats come from?
16:24:18nubbins`:bramc bitnodes.com footer states explicitly
16:24:33nubbins`:just wondering why nobody cares how many nodes there /actually/ are.
16:24:45nubbins`:er bitnodes.io, whatever it is
16:24:53nubbins`:"Bitnodes uses Bitcoin protocol version 70001 (i.e. >= /Satoshi:0.8.x/), so nodes running an older protocol version will be skipped"
16:25:00sipa:my seeder counts around 4300 well-reachable one, a historically low number
16:26:20nubbins`:sipa: you wanna see historically low numbers, check how many of the nodes in the hard-coded seed list are still alive :D
16:26:54nubbins`:(for those of you playing at home: about a half-dozen)
16:27:26sipa:nubbins`: that list is updated every year or so
16:27:43sipa:and node IP mobility does not mean a decreasing number
16:28:10nubbins`:ah. maybe once a year is a bit long.
16:28:36nubbins`:we're talking 1% of hard-coded nodes being reachable here
16:29:13hearn:well, that's why there are dns seeds too
16:29:30hearn:the hard coded list is meant as a kind of nuclear bomb shelter in case of some kind of big DoS attack/disaster
16:29:36wumpus:yes, the hard-coded node list still needs to be updated for 0.11
16:29:37hearn:but sure more frequent refreshes would be good
16:30:06nubbins`:agreed, not much of a bomb shelter atm :)
17:11:14bramc:nubbins`, I don't know the answer to your original question, but the answer is likely some combination of 'there are very few nodes that old and we didn't feel like supporting it' and 'nodes on that old of a protocol are so poor performing they're doing more harm than good'
17:12:05nubbins`:bramc i'm not so sure those are the reasons, and i'd love to see the numbers on how many total nodes there are.
17:12:24sipa:total nodes?
17:12:28sipa:including spv nodes?
17:12:34sipa:including unreachable nodes?
17:12:44sipa:including versions that are not useful to new clients?
17:12:58frankenmint:frankenmint has left #bitcoin-wizards
17:13:00nubbins`:would you like some pedantry with your fries?
17:13:12hearn:bramc: i think there is a min protocol version, no?
17:13:32nubbins`:hearn, somewhere around 0.5.x
17:13:49nubbins`:any earlier than that and you'll have problems
17:15:05nubbins`:the cynical part of me thinks that ignoring pre-0.8.x nodes is part of a greater push for getting rid of nodes that don't want to play nicely with newer "features" being rolled out
17:15:17nubbins`:but that's probably silly
17:15:32nubbins`:after all, why would anyone want to use something like bitcoin to further their own personal objectives?
17:15:46BitcoinErrorLog:probably not, thats likely to happen even as just apassive influence
17:16:17nubbins`:hopefully i'll have popcorn handy when the block size thing gets pushed out
17:16:27nubbins`:then we'll really see how many nodes there are, and what they're running :D
17:17:27bramc:*if* the block size thing gets pushed out, then there *will* be a fork
17:17:49bramc:And two competing blockchains which different peers are constantly arguing about which is the newer one
17:18:29bramc:As a practical matter, peers will soon have to identify whether they're on the fork or not, to make the networks be physically distinct and stop them from DDOSing each other.
17:19:17hearn:no, old peers will ignore the >1mb chain completely and follow the pre-fork chain even if it's shorter
17:19:26nubbins`:^
17:19:54nubbins`:they'll also spin up a new node and send some coins out in a >1mb block to cover their bases.
17:19:56nubbins`:should be fun
17:20:03hearn:new peers would follow whatever the hardest valid chain is according to their new rules, which as those rules wouldn't kick in until a majority of miners supported them, should be the >1mb chain
17:20:46badmofo:badmofo has left #bitcoin-wizards
17:20:53nubbins`:when was the last fork, anyone have the date or version # handy
17:21:50bramc:nubbins`, There's never been a hard fork
17:22:00nubbins`:* nubbins` claps softly
17:22:30nubbins`:an immeasurable number of people claim differently
17:22:46bramc:hearn, Old peers would continue to make progress on the <1mb chain, resulting in a literal fork of the two chains
17:23:17hearn:old miners, yes
17:24:09nubbins`:surely large mining operations are running the latest phoundation release ;p
17:24:16bramc:nubbins`, I said 'hard' fork, there have been many 'soft' forks, which means extensions which older nodes would accept but not themselves create. To date, the current block chain would have been accepted by the very first version of bitcoin ever released.
17:24:36bramc:hearn, Also new miners who think the >1mb block is bullshit
17:24:57nubbins`:bramc you'd (maybe not) be surprised at how many people think, say, 0.8.0 was a hard fork.
17:25:35bramc:nubbins`, There's also a difference between an incompatibility of the blockchain and an incompatibility of the peer protocol. I don't know if that second one has ever happened.
17:25:40BitcoinErrorLog:wasnt 0.8.0 the almost-fork that had to be handled actively after the fact?
17:26:11bramc:nubbins`, It's certainly the case that peer efficiency has been improved enough that an original codebase peer would be doing more harm than good in the current network even if it could talk to anything.
17:26:16hearn:the soft vs hard fork distinction is deeply questionable. you really don't want "backwards compatibility" when auditing things
17:26:30BitcoinErrorLog::/
17:26:33bramc:hearn, What?
17:26:51jae:jae is now known as Guest43254
17:26:53bramc:BitcoinErrorLog, How so? (I'm honestly asking, I don't know what bit of history)
17:27:12fluffypony:precisely what hearn is saying is why we're doing this: https://forum.getmonero.org/4/academic-and-technical/303/a-formal-approach-towards-better-hard-fork-management
17:27:21hearn:let me try an analogy. think of a full node as like a human auditor checking the books. now imagine some clever trader somewhere else in the company who wants to execute a clever trade, but knows that the auditors will reject it
17:27:40fluffypony:it would be a more monumental challenge, but I would be interested in Bitcoin adopting a similar periodical fork
17:27:55hearn:so the trader goes to his colleague and says, hey bob. how about we come to an arrangement. when i send you money and put in the notes field that this is a trade for a ton of coal, i want you to interpret that as actually being a ton of gold
17:28:10BitcoinErrorLog:I forget the details bramc, wasnt it a Berkdb issue? i remember all the miners having emerggency meeting with devs to revert and stop the fork from happening
17:28:23nubbins`:BitcoinErrorLog yes
17:28:29hearn:bob says, "uh why alice"? and alice says, well, if we put in "ton of gold" the auditors will flag it as a bad transaction. we could go all through the process to get this type of trade accepted, but it's quicker if we just bypass them
17:28:32hearn:call it backwards compatibility
17:28:34nubbins`:it's just a config update ;/
17:28:38bramc:BitcoinErrorLog, Oh right, the result of that one was that the implicit restriction of the older shittier nodes was accepted
17:28:39fluffypony:nubbins`: no
17:28:48fluffypony:well
17:28:55fluffypony:it was a BerkeleyDB issue, but not BerkeleyDB vs. LevelDB
17:28:58hearn:now - would this be accepted in a real company? hopefully not. though maybe given the behaviour in the last few years.....
17:29:08fluffypony:it was BerkeleyDB (bad) vs. BerkeleyDB (good) & LevelDB
17:29:24hearn:as the goal of the auditors is to fully understand the transactions and check the ledger. if people are fooling them with clever tricks, that audit is being undermined.
17:29:40hearn:do you see this argument?
17:29:44bramc:So there was a temporary fork and it was fixed by rolling back to the pre-fork protocol
17:30:05bramc:hearn, I have no idea what you're saying. Are you arguing against backwards compatibility as a goal?
17:30:12hearn:when it comes to consensus systems? yes
17:30:23hearn:obviously in most software systems backwards compatibility is highly desirable
17:30:24bramc:hearn, You're on crack
17:30:28hearn:as it is for things like bitcoin p2p protocol, etc
17:30:35nubbins`: it was BerkeleyDB (bad) vs. BerkeleyDB (good) & LevelDB << +1
17:30:35fluffypony:I 100% agree with bramc
17:30:41fluffypony:erk
17:30:41hearn:bramc: that argument is "not excellent" :)
17:30:42fluffypony:I mean
17:30:45fluffypony:I 100% agree with hearn
17:30:54fluffypony:you don't know "who" is running a node
17:30:55hearn:hehe :)
17:30:57fluffypony:you can't communicate with them directly
17:31:01nubbins`:hell, even i could be running one
17:31:03nubbins`:or six, or w/e
17:31:07fluffypony:so the only thing you can do is drop them off the network if they don't upgrade
17:31:16hearn:well, there is a middle path
17:31:29hearn:nodes that can't fully audit the ledger any more can still be useful - for serving and filtering the chain for others
17:32:14hearn:if there was a way to have a hard fork trigger a shutdown of the RPC interface, for example, and maybe flagging somehow (~NODE_NETWORK?) that it's now in a kind of 95%-SPV mode, it may still be a reasonable thing to do
17:32:21hearn:as SPV clients could still benefit
17:32:33hearn:however, businesses relying on the quality of the audit ..... well, if they want to opt-in to pseudo-spv mode, that's fine by me.
17:32:37hearn:but it should be something they knowingly accept
17:33:06hearn:anyway this is why the whole argument for soft forks has never convinced me
17:33:11bramc:There's a fundamental difference between forking the block chain and dropping support for old versions of the peer protocol
17:33:27fluffypony:bramc you're not forking the network
17:33:40fluffypony:the network is moving forward and outdated participants are left for dead
17:33:58fluffypony:that some of them may have a tip of their own is largely irrelevant to the main herd ;)
17:34:40bramc:There's a reason why HTTP has moved forward while DNS has not
17:35:08kanzure:isn't dns a consensus system of some kind
17:35:23fluffypony:it's a poor comparison, though - protocols are mostly governed by committees
17:35:50fluffypony:when did they seek public input on whether SPDY should be part of the protocol?
17:36:01hearn:HTTP/2 is the equivalent of a "hard fork", so ...... not sure it's a great suggestion. it's totally incompatible with HTTP/1 except at a high semantic level
17:36:13kanzure:i think the bitgo person submitted a spdy ietf rfc.. if that's what you mean?
17:36:51fluffypony:kanzure: I mean that the userbase "at large" don't care about changes to SNMP, TCP/IP, DNS, or anything else
17:37:21fluffypony:even companies heavily invested in a particular protocol tend to care very little
17:37:26kanzure:(perhaps the user base would be better not using bitcoin if they don't care about its features (even if it may be objectively safer for them to use, i don't know about forcing them))
17:38:46bramc:hearn, No you aren't getting it. DNS is a database, HTTP is not. Hence incompatible changes to HTTP can be made much more frequently than can incompatible changes to DNS, which happen essentially never.
17:40:09hearn:sigh. DNS is not a consensus system. my argument applies to consensus systems. where you want to audit every last change.
17:40:39fluffypony:DNS also went through a period of retardation where they added idiotic record types, like GPOS and SPF
17:41:45sipa:sipa has left #bitcoin-wizards
17:43:15bramc:Looking over things right now, I think the most likely thing with the block size increase is that it gets dropped. The next most likely thing is that it gets forced out and either fails or, worse, mostly fails, and the partisans who have been pushing it so hard wind up not being involved in bitcoin development any more.
17:46:10fluffypony:bramc: dropped as in no longer discussed and remains unchanged, or dropped as in it gets unilaterally removed?
17:46:36nubbins`:heh
17:46:37bramc:fluffypony, As in the people pushing it give up and drop the subject
17:46:38nubbins`:fuck the partisans
17:47:06nubbins`:the amount of astroturfing and obvious shilling re: block size increase is pretty lel-worthy
17:47:32fluffypony:yeah the Reddit hivemind stuff is a little annoying, hard for some people to see the wood for the trees
17:48:19bramc:It isn't a mystery who's behind the push for the block size increase, they're in this channel with us now.
17:48:26hearn:there is zero chance of that. even if me and gavin vanished in a puff of smoke, other people would do it instead.
17:48:43hearn:(as was made clear to us by the number of people asking when the new XT will be ready)
17:49:15bramc:By 'other people' you mean people on reddit who don't understand the subject but have gotten whipped up into a fury about it because they like having causes to rant about.
17:49:26fluffypony:bramc: quite
17:49:58hearn:not at all
17:50:02hearn:but believe that if you like
17:50:20BitcoinErrorLog:anecdotal observations nonetheless
17:50:30jposner:bramc: the issue isn't just being pushed by "people," it's being pushed by circumstances. stuffed blocks, whether that results in transaction delays or fee increases, is not going to be ignored.
17:50:39fluffypony:* fluffypony hugs BitcoinErrorLog
17:52:19bramc:The actual players in bitcoin have overwhelmingly made it clear that they don't like the idea. Whipping up a mob isn't convincing any of them.
17:52:52BitcoinErrorLog:honestly the mob is what has heightened my skepticism and brought me here
17:53:21bramc:jposner, There's overwhelming support for building support for real transaction fees
17:54:02bramc:jposner, which doesn't require a fork at all
17:55:01nubbins`:bramc i doubt many actual players read reddit ;p
17:56:00bramc:nubbins`, reddit is on the pro-increase side. It's the whipped up mob.
17:56:10nubbins`:you got that right
17:56:30nubbins`:but then again, reddit is generally broke kids w/ dreams that their 0.5 btc is gonna make them a jillionaire
17:57:35Relos:that sounds pretty elitist
17:58:20jposner:dismissing the proponents of increasing the block size as a "mob" or with ad hominem is not very convincing. those arguments could just as easily be made against those who would rather keep the 1MB limit.
17:58:56nubbins`:Relos ?
17:59:06nubbins`:jposner oh absolutely
17:59:12Relos:I can hear mary antoinette saying: "let them eat cake"
17:59:29nubbins`:what can you hear marie antoinette saying?
17:59:48nubbins`:8)
17:59:57bramc:Relos, The attempt to unilaterally make an incompatible change to the protocol using a magic number which somebody pulled out of their butt is what's elitist
18:00:09nubbins`:anyway. jposner i'm dismissing redditards based on general behaviour patterns, not their response to this one thing
18:00:27Relos:I said enough, I just switched to the tab and saw your comment, I don't know if there was a real discussion ongoing and I wouldn't want to in anyway take up its space
18:01:13jposner:nubbins': I think it's more productive not to focus on the "retards" in the debate, but rather the best arguments on each side
18:01:39nubbins`:jposner oh, undoubtedly
18:02:12bramc:jposner, A survey of bitcoin developers and people who run major bitcoin services indicates that they overwhelmingly don't want to make the change
18:02:24nubbins`:i've yet to see a good argument for >1mb blocks other than "it'll help the people who want to take away the average person's ability to run a full node"
18:02:34nubbins`:which is actually a REALLY good argument
18:02:36bramc:The push for it can be traced directly to Gavin's full frontal PR campaign
18:02:43nubbins`:just, y'know...
18:02:46nubbins`:not a thing that i want
18:02:54BitcoinErrorLog:nubbins i see no problem classism in bitcoin anyway
18:03:06nubbins`:o.O
18:03:11BitcoinErrorLog:with
18:03:17maaku:guys please this is all way OT
18:03:23maaku:take it to #bitcoin-blocksize
18:03:39nubbins`:bramc remember when the NSA totally wasn't reading everyone's emails until it turned out they definitely were?
18:03:46BitcoinErrorLog:worst spam is moderation spam, with that i'll shut up
18:05:12nubbins`:bramc this gavin-pushing-for-big-blocks thing reminds me of that
18:08:59nickler:sipa: Do you think the different prediction between your simulator and Gavin's simulator is purely because you are also modelling fees? See my graph for well vs. poorly connected nodes in Gavin's simulation https://raw.githubusercontent.com/jonasnick/bitcoin_miningsim/master/analysis/plots/poorly_connected_big_blocks.png
18:10:27nickler:so does the smaller group have a lower orphan rate when the big group creates 20mb blocks?
18:14:52nickler:wait, my link was for the smaller group creating bigger blocks. This is the actual graph: https://raw.githubusercontent.com/jonasnick/bitcoin_miningsim/master/analysis/plots/poorly_connected_small_blocks.png
18:17:16nickler:and when you say that they 'are only connected to each other through a slow 2 Mbit/s
18:18:10nickler:link', does this mean both groups are only connected via one link or is the network fully connectd?
18:25:12maaku:both groups are only connected via one link
18:25:26maaku:a link whose parameters happen to match the great firewall
18:25:33maaku:(or, roughly, Tor)
18:25:42maaku:(but that would have a different connectivity graph)
18:28:35wallet421:wallet421 is now known as wallet42
18:29:55nickler:ah thanks, seems to be a fairly strong assumption. I'll see if there's the same effect with Gavin's simulation.
18:31:09bramc:Do bitcoin nodes drop connections if the peer sends them too much garbage?
19:00:01Guest2862:Guest2862 is now known as gmaxwell
19:38:26waxwing:in 3.3.1 of Borromean, step 2c, it seems like the range of j indices is wrong. should start at j_i* + 1 i think.
19:47:58waxwing:the notation for step 3 there also seems to be wrong?
19:48:31antanst1:antanst1 has left #bitcoin-wizards
19:51:18andytoshi:waxwing: i think 3.3.1 is correct
19:52:05andytoshi:notation of step 3 is wrong, good catch, says m_j but should be m_i
19:52:19andytoshi:actually those i's should be 1's
19:52:26waxwing:yeah that one, but even then, it's m_i-1 is the last index
19:52:55waxwing:i couldn't find any way of making step 3 look right. but, it's not as if the basic idea isn't obvious.
19:52:59waxwing:just seems that the notation is off.
19:53:07andytoshi:yup
19:53:59andytoshi:waxwing: there are two sG - eP phrases; the first should have {1, m_0 - 1} as its subscript, the last should have {n, m_n - 1}
19:54:05andytoshi:i think that fixes it
19:54:48waxwing:right
19:54:56waxwing:that was what i was hoping
19:56:33waxwing:andytoshi: so shouldn't it start at j_i* + 1 in 2c?
19:57:10andytoshi:waxwing: it is always assigning to j+1, so i think that covers it
19:57:47andytoshi:i'm pretty sure i copied the code directly for that line, so i hope it's not wrong :)
19:57:59waxwing:andytoshi: but in (b) you already set e_{i,j_i^* + 1}
19:58:20waxwing:heh
19:58:24andytoshi:oh, hmm, shit
19:58:43waxwing:a few bitcoins here there, no big deal :)
19:58:51andytoshi:lol
19:59:21andytoshi:if there is a corresponding bug in the code it'd completely break the sigs, i'm not too worried .. i'm sure i transcribed it wrong
20:00:08waxwing:yeah i know. much of our security is based on this principle. "If it had any bugs it woulda crashed by now" :)
20:00:24andytoshi:hehehe #notactuallyfunny
20:00:35waxwing:sorry bit cheeky, just jking
20:01:24andytoshi:it's cool, i don't mean #notactuallyfunny like it's a bad joke, i mean that it's totally true..
20:01:32andytoshi:and very dangerous
20:01:57andytoshi:in any case, yeah, i transcribed it wrong, the code has the loop offset in a weird way so that step (b) is absorbed into (c)
20:02:11andytoshi:so you are correct, i will fix the range in the doc
20:02:17waxwing:andytoshi: somehow reminds me of that old fallacy: "well, if you can decrypt it, it must be the right key, so it's authenticated, right?"
20:02:34waxwing:(not this particular case, just the general idea)
20:02:52andytoshi:i'm actually laughing out loud, but still shouldn't be funny..
20:03:36gmaxwell:whats weird is that I thought I checked the agreement with the writeup there.
20:03:53gmaxwell:verification is hard because of confirmation bias. :(
20:04:17andytoshi:gmaxwell: the range in the writeup is the same as the range in the loop; difference is what part of the loop tmp is assigned (where `tmp` is the input to the hash function)
20:04:29gmaxwell:it doesn't help that the software and the paper use pretty different nomenclature I guess, maybe I should have updated the software after the document to agree with the markup.
20:04:41andytoshi:it's a pretty subtle thing, one of us Should Have Caught It but i'm not too suprised it got thruogh
20:05:11andytoshi:well, the paper can just say H(some algebraic formula), the code needs to have temporary variables and stuff, i don't think you can force them to match
20:05:12gmaxwell:and indeed, there are classes of mistake that I probably do not look for because if they're made they are just guarenteed to not work at all.
20:05:23andytoshi:without adding a bunch of temp variables to the writeup that'd leave it unreadable
20:05:35gmaxwell:andytoshi: e.g. the code can line by line reference the writeup even where they don't exactly match.
20:05:43andytoshi:ah, right
20:06:01waxwing:i wouldn't pay much attention to this kind of thing; there is a certain flexibility in interpretation of notation like that, and the preceding section of the doc makes it pretty obvious how it *should* work. no matter what you happen to call the various indices.
20:06:31waxwing:i mean yeah fix it but it's not like someone's going to "accidentally" code it wrong.
20:06:33gmaxwell:sure sure, but, you know.. advancing the art. I wouldn't want to waste a second of anyone's time on stuff like this.
20:06:58andytoshi:waxwing: welll, the hope is that you can reimplement from the writeup, if you need to look at our code that seems like we're wasting future programmers' time
20:07:08gmaxwell:so they might not actually ship something wrong they may waste a while trying to get it right.
20:07:37waxwing:yeah good point. try to make it ultra clear, but it's difficult with these multidimensional array scenarios.
20:07:42waxwing:it's always ugly even when it's right :)
20:07:54andytoshi:it's always uglier when it's right ;)
20:07:57gmaxwell:It's also important because some pepole will never in a million years review code. (which is sad and makes the world worse off; but I'd still want to benefit from their understanding)
20:08:22gmaxwell:andytoshi: funny you say that, when I first wrote the verification code, it was so clean relative to my expectation that I thought it had to be wrong.
20:08:34andytoshi:lol, yeah, verification is funny in this case, i was impressed too
20:08:53andytoshi:i will try to submit a PR at some point today which adds comments to both sign and verify which reference the writeup..
20:09:16gmaxwell:The signing implementation is also much cleaner than I _expected_ it would need to be, but uh. well. still pretty twisty.
20:09:33waxwing:gmaxwell: i have been having the code open while going through it
20:09:46waxwing:but it's slow going for me, i'm not used to the bitcoin codebase
20:10:04waxwing:i found myself sidetracked into reading about jacobian form or whatever :)
20:10:08gmaxwell:haha
20:10:25waxwing:just trying to plod through and write the algo in Python to make sure i understood it
20:10:31andytoshi:waxwing: :) unfortunately you need to do that to understand basically any part of libsecp256k1
20:10:46andytoshi:waxwing: if you want some intuition and it'd help to have a voice you can call me
20:11:28waxwing:andytoshi: very kind; but this kind of support is already amazing...
20:12:03gmaxwell:waxwing: cost of an optimized implementation is a bit more complexity. OTOH, .. less for the ringsig, but very much for the range proofs-- building an optimized first implementation prevented me from making some pretty severe design errors that would have greatly hurt performance.
20:12:36gmaxwell:so I can't say I regret doing that instead of e.g. making a super simplistic python implementation.
20:13:00waxwing:gmaxwell: yes the thing it made me think about was whether it's possible to somehow split things like (prevent timing attacks) from (program logic). i guess maybe it isn't.
20:13:02andytoshi:waxwing: the kind of support where you do free in-depth review for us and we answer questions that (should be) at the front of our minds anyway? yeah, we are saints ;)
20:13:24andytoshi:this is seriously really helpful, most projects of this algebraic complexity do not get any review
20:13:28Mably:gmaxwell
20:13:35gmaxwell:(wrt performance, in the range proof, I avoid the ringsig commiting to all the derrived points; which means they don't ever need to be converted back to affine corrids, which is a non-trivial performance impact)
20:13:55Mably:may be you already answered, but have you studied Sumcoin compact confidential transactions?
20:14:15andytoshi:Mably: i am in the process of studying it, don't have anything more to say than "cautiously optimistic", sorry
20:14:21andytoshi:(at this point)
20:14:30gmaxwell:waxwing: yea, making a constant time and uniform memory prover-- one which was constant both for secret keys _and_ the ring membership, for this would sadly have really high overhead.
20:15:00gmaxwell:I believe my implementation is private for the keys though, or close to it. It hasn't been carefully reviewed for that (as in CT it doesn't matter much).
20:15:21waxwing:yeah i saw the comment about privacy leaks vs key leaks
20:15:30antanst:antanst has left #bitcoin-wizards
20:15:34gmaxwell:Mably: I've talked to the author some. I'm very excited about it.
20:18:41Mably:gmaxwell: so it significantly improves current solution?
20:19:09Mably:that's some great news then
20:20:40andytoshi:waxwing: updated writeup at https://github.com/ElementsProject/borromean-signatures-writeup with the two errors you found
20:25:20kanzure_:wasn't there also a repo on the blockstream github account, and is that confusing
20:25:41andytoshi:kanzure_: i don't think so .. one sec
20:26:03kanzure_:https://github.com/Blockstream/borromean_paper
20:26:06waxwing:yeah i also found that confusing, there is one for the contracthashtool and paper
20:26:10waxwing:yeah that one
20:26:11andytoshi:kanzure_: oh, right, that one .. it only has binaries .. we created that before the source code was public
20:26:32kanzure_:it's too bad that hosting pdfs has to be so ridiculous
20:26:54waxwing:github recently allow pdf embedding. or i think it was recent.
20:27:08andytoshi:yeah. it is confusing, but i don't wanna take the PDF one down to avoid breaking links and i don't really want binaries in the source repo
20:36:16Adlai:can't github host binaries separately?
20:36:28kanzure_:kanzure_ is now known as kanzure
20:36:36maaku:Adlai: not anymore
20:50:48fluffypony:maaku: not even as part of a tagged release?
20:51:21maaku:fluffypony: you tag a release and it just makes a tarball of the source code...
20:52:12fluffypony:nuh uh
20:52:15fluffypony:you can add binaries
20:52:25fluffypony:here
20:53:08fluffypony:maaku: http://i.imgur.com/8GHErSE.png
22:01:52mrkent:Regarding all this debate about block size recently, does anyone else think there isn't enough debate about the fact that we're trying to *change the rules*?
22:02:15mrkent:The rules that everyone agreed to to begin with
22:04:10mrkent:When we approach 21m BTC and miners complain about fees, what's to say the 21m can't be changed?
22:04:33mrkent:I feel like it sets dangerous precedence.
22:05:29gmaxwell:mrkent: I know sipa has repeadily over and over raised the concern about making hardforks in the face of controversy.
22:05:35gmaxwell:It concerns me greatly.
22:06:41PRab:To me is an "I wish I had a time machine" topic.
22:07:15gmaxwell:mrkent: I think that the rules change in and of itself is not the gravest concern, if you imagine a change that is necessary for the survival of the system and that everyone (or very very nearly so) agress with, I don't see a /huge/ cause for concern there.
22:07:33gmaxwell:Ideally the system could never change but, mistakes are made... we can't engineer something so perfect.
22:07:38mrkent:gmaxwell: I mean if you feel strongly about this, maybe you should redirect debate this very different question
22:08:18gmaxwell:mrkent: I'm unable. I've tried. At least on reddit people are very much might makes right.
22:09:15mrkent:Well, what were your points?
22:09:21gmaxwell:In any case, if you look at the history of soft forks you'll see there have been many backwards compatible rules changes that were completely uncontroversial. These things don't worry me.
22:10:39brand0:I thought consensus was forming around 8mb
22:10:53gmaxwell:brand0: 0_o
22:10:57mrkent:brand0: yes the last big reddit post was 8mb
22:10:59bramc:mrkent, I brought up the bad precedent argument, along with many others. Highly technical argumentation doesn't get the same kind of popular response as righteous ranting unfortunately: http://bramcohen.com/2015/06/02/gallus-and-simo-debate-whether-the-block-size-limit-should-be-increased
22:11:39bramc:We can probably get consensus around 1mb :-P
22:11:39gmaxwell:mrkent: That the value of the system is that it's resistant to change, and that if you're fine with a system ruled by political whim you should stick with the fiat of a major democracy. That with bitcoin we hope to approximate cryptographic security, where your control of your funds is autotonymous and as free from other people's choices as possible. And that changing the system in ways detrimen
22:11:46gmaxwell:tal to their interest out from under a substantial minority of users is a taking, that its unethical, and that it undermines the primary value proposition of the system, even for the majority. ::shrugs::
22:12:02mrkent:I mean the fact that there are is debate over arbitrary #s is insane
22:12:32gmaxwell:mrkent: yea, specific values aren't so much of a concern for me. Thats really not the point of the concern.
22:13:14bramc:mrkent, It's become clear that the hard fork would really and truly result in a fork, with effectively two bitcoins which have to be treated independently.
22:13:21mrkent:bramc: I think personal blogs won't do as well as a self.post or medium post or something
22:13:48gmaxwell:Concerns are the implications of forcful changes to the rules of the system, long term security incentives, short term market incentives between miners, preserving the system's decenteralized properties, and missing out on the pressure to actually improve things. that kinda stuff. 2MB is about as good as 1Mb is about as good as 500k, actual numbers aren't critical.
22:14:30bramc:mrkent, Are self posts considered more confidence inspiring than personal blog posts now?
22:14:58mrkent:gmaxwell: ya agreed, i was just about to write something on this, and decided to come ask here first.
22:15:18bramc:Maybe I should make a medium post entitled 'How to steal from anyone accepting zeroconf'
22:15:22gmaxwell:I'm also concerned with this recent event that it completely bypassed the normal process. No Bip, no PR, no bitcoin-development post.. just a straight call to the largely uninformed public with a one sided argument, and when that wasn't overwhelming, it was followed up with a threat to fork the network in some kind of insane king solomon's trial.
22:15:58mrkent:I think perhaps the way to say this is: 1. why don't we also increase the 21m limit while we're at it? 2. or inflate btc relative to economic growth?
22:16:00gmaxwell:an interesting thing I learned is that lots of redditors think there existing a huge network partition is no big deal! like, they think thats its (likely to be) a recoverable faulure!
22:16:09bramc:gmaxwell, And a flooding 'experiment' which demonstrated nothing whatsoever.
22:16:45gmaxwell:mrkent: I made that point, actually had a very interesting discussion with one person where he argued miners should control the block limit, and I said well why not also the 21m cap. And delightfully, he responded saying they probably should control that too!
22:17:02brand0:gmaxwell, crazy!
22:17:03gmaxwell:I thought that was like the best discussion ever, because at least his position was logically consistent!
22:17:45bramc:Let's also let miners decide whether bitcoin is a PoW or a PoS system
22:18:03mrkent:I feel like a lot of this comes from fear of BTC not scaling thus bitcoiner's investment does not go up
22:18:07gmaxwell:It's not completely crazy to say miners should control the 21m cap... its just that the reason the rules exist even against miners is that we use the rules to keep miners incentive aligned, we don't "trust" miners except at arms length. But if your mental model is that miners are trusted by definition, why not let them control all the things?
22:18:53gmaxwell:mrkent: some people on reddit were quite specific that they are very concerned with driving up the value of their bitcoins. But it's hopeless to try to guess everyone's motivations.
22:19:34mrkent:I mean which one of us doesn't want the price to go up
22:20:11mrkent:but we're risking all that makes bitcoin special in the process
22:20:18bramc:mrkent, The price of bitcoin right now mostly is indicative of the amount of electricity which is burned mining. I for one view it going up as a bad thing in and of itself.
22:20:32brand0:I was happy with a $1 BTC
22:21:01mrkent:You're on point in that if public opinion determines economic policy, then stick with fiat (already 100% adoption)
22:21:07gmaxwell:mrkent: sure, absolutely. but different time horizons. But I can't draw any seperating lines, it's not like all the people with one perspective fit into one box.
22:21:33gmaxwell:yea, fiat has huge advantages if you don't care about the few things bitcoin does uniquely better.
22:21:56justanotheruser:justanotheruser is now known as justanother
22:22:02justanother:justanother is now known as justanotherusr
22:22:03bramc:The undermining of the integrity of the bitcoin ecosystem implied by a fork is likely to hurt the value of BTC more than whatever value increase could be had from the modifications anyway.
22:22:18gmaxwell:(I get seriously downvoted on reddit for saying things like that)
22:22:35bramc:gmaxwell, But fiat currency is TEH DEVIL!
22:23:14bramc:It's a funny thing in the bitcoin community that the biggest doubters are the core devs. Everybody's surprised when I tell them that.
22:23:21gmaxwell:bramc: maybe not-- at least until it happens, because strangely (*!@#*! many people on reddit think that persistant network forks are no big deal!
22:23:42mrkent:gmaxwell: well, not everyone knows your reddit username so there isn't as much weight behind that guy
22:23:50bramc:gmaxwell, That's a lesson not worth learning the hard way!
22:24:20bramc:Most redditors probably know the name 'Gavin' and that's about it on the dev side.
22:24:38brand0:What *do* you guys think is the right process forward here? (I've heard tons about what's wrong)
22:24:40gmaxwell:Well there are very important reasons that you do not want to be well known.
22:24:49Adlai:they know other names from targeted ad-hominem shilling
22:25:28bramc:brand0, The right process is to do nothing to the block chain, work on making everything support real transaction fees
22:25:56gmaxwell:brand0: there are several proposals that fix some of the ugly incentive problems and would likely make larger blocks safer. Those need to mature and be explored.
22:26:05bramc:gmaxwell, Thanks for the warning, I'll take every step necessary to avoid ever being well known.
22:26:13gmaxwell:oops
22:26:41gmaxwell:brand0: And yep, as bramc, says, actual scaling tools need to be developed so that whole subject is not a redicilous false tradeoff.
22:27:09mrkent:So what are the most likely outcomes at the current time?
22:27:39mrkent:I don't actually read into the debates much...
22:28:12kanzure:mrkent: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08183.html
22:28:16bramc:mrkent, Do you mean outcomes for block size increases or outcomes for scaling the block chain as a whole?
22:29:34mrkent:bramc: or not do anything, or something else..
22:29:40bramc:Unfortunately doing actual work can get you labelled TEH DEVIL. For example Peter Todd's work on malleability. I have some issues with Peter Todd. His work on malleability is most definitely NOT one of them.
22:29:54gmaxwell:brand0: We know with almost absoute certanty that we can scale-out bitcoin into complete centeralization at some level (no consensus exactly where and how) it's no longer viable as a decenteralized system (no consensus on how you define decenteralized). But at the same time, no certanty that any particular blocksize will accomimdate any particular new application space.
22:29:55mrkent:Any sort of hardforking change
22:30:41bramc:mrkent, Most likely outcome is probably that a hard fork never happens. Next most likely is that a hard fork happens but fails. Next after that is that a hardfork happens, only half fails, the shit hits the fan, and wallets have to support the new reality of two incompatible block chains.
22:30:53gmaxwell:brand0: there are varriosu proposals (e.g. lightning being the newest and most advanced) to achieve actual scalablity for Bitcoin which need to mature, and I think these are the only way we can address actual massive scale use cases.
22:31:06kanzure:as much as i don't want a centralized system design, it would be prudent to have backup plans for orderly wind-downs into centralized systems so that there isn't too much murder
22:31:44bramc:kanzure, The solution to the shit hitting the fan from one fork is not another fork
22:31:49mrkent:Accounting for the "politics" of it all. e.g. If Gavin pushed new code that hardforks, is it likely that more than 50% will just go with it?
22:31:58kanzure:bramc: nah, i was speaking more long-term
22:32:09gmaxwell:if the users of the system choose to keep craking the limit up to avoid any fees, rather than developing and adoptiong things that actually scale, then the system will likely fail (though maybe in a way that doesn't cause massive monetary losses for its users, e.g. it could just become a new popular centerally administered fiat)
22:32:14kanzure:mrkent: depends on what 50% you are asking about
22:33:20kanzure:gmaxwell: if that is what happens (an actual centralization many years down the line, conversion into visa-like system, etc...), there will be much in-fighting between different groups trying to grab control...
22:33:21bramc:mrkent, Depends on how it's rolled out. If there's a vote amongst miners as to whether to accept it it will likely fail. If there's a vote amongst miners and it passes the vote it will likely half-fail. If there's no vote amongst miners and it's just unilateral then it will either fail of half-fail, hard to guess which
22:33:30mrkent:kanzure: I think just 50% of the people?
22:33:41gmaxwell:kanzure: who says that you're not seeing that already?
22:33:59gmaxwell:mrkent: well of what people? probably 99% of bitcoin users don't run node softare at all.
22:34:01mrkent:I don'
22:34:02kanzure:mrkent: the bitcoin system has no way of counting people, so no
22:34:17bramc:Whether what's being proposed is an adoption vote like the soft forks of the past I'm unclear on.
22:34:29kanzure:gmaxwell: because i also don't see any proposals for safe wind-down into a centralized system. it should not be bloody, if that's what $whoever really wants.
22:35:16gmaxwell:kanzure: you can't preprepare that without both a fight over who would be the reciever of it, AND without creating an incentive to cause that outcome.
22:35:21mrkent:kanzure: Miners tend to be pretty centralized (via pools). If miners say no, but everyone else who actually transacts say yes, then miners are not going to mine their fork that no one will recognize
22:35:24Adlai:bramc: iiuc, mrkent is asking "what happens to the winners and losers after an intentional hardfork occurs"
22:35:31kanzure:gmaxwell: hm not sure i understand your incentive comment there
22:35:43kanzure:gmaxwell: i guess it would flag the people that would be willing to support that proposal?
22:35:55kanzure:but wouldn't that be useful for those who want to keep things decentralized?
22:36:06gmaxwell:kanzure: if I get to be the king of bitcoin if bitcoin becomes centeralized; that might be a pretty good reason for me to make sure it becomes centeralized?
22:36:27gmaxwell:(if I were an idiot at least, you really do not want to be king of bitcoin)
22:36:29kanzure:yes, but nobody can centralize it without lots of bloodshed i think- at least not without proposals.
22:36:33kanzure:right
22:36:44bramc:gmaxwell, The king of bitcoin gets all the concubines
22:36:56gmaxwell:bramc: who has time for that?
22:37:15kanzure:well anyway; it might be helpful to identify those who are interested in that direction, which can help assign various weights to how much we know to be thorough when checking their analyses on other topics.
22:37:59kanzure:gmaxwell: i was wondering if you would be kind enough to brain dump about all the missing things from my list here http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08183.html
22:38:00gmaxwell:kanzure: well it already has, exact number right now is hard to estimate, alarge supermajority of hashpower is in the hands of a half dozen or so. E.g. someone could rationally argue that in that sense, at the moment, bitcoin is less decenteralized that the ludriciriously centeralized federated consensus in alpha. :(
22:38:29kanzure:i have read your fedpeg python source code and i am not amused :-)
22:39:30bramc:I'm going to be giving a talk at the bitcoin-dev meeting on the 22nd. The title will be 'Removing the waste from cryptocurrencies: Challenges and more challenges'
22:40:12gmaxwell:kanzure: typesafty is for fusses. who doesn't like floats being used to index lists. :) in any case, that stuff is throwaway, and for good reason. :) And yet, works fine.
22:40:57kanzure:gmaxwell: well what i would be most worried about is others using that code for non-testnet things. i was thinking about making a client/library instead..
22:41:04bramc:gmaxwell, My mining ideas on paper look great for maintaining decentralization. They're still very much in the crazy out their ideas category though.
22:42:03gmaxwell:kanzure: well kinda self correcting there! (doh), I do think we really adequately warned people not to do that.
22:42:24kanzure:bramc: i'm not sure even your proof of sequential work could allow the system to withstand users switching out rules and degrading behavior
22:43:05bramc:kanzure, Not sure what you mean by that
22:44:24kanzure:the problems that we are encountering with centralization pressure at the moment are not just the number of mining nodes, but also apparently people wanting to change critical parameters in ways that further degrade those system properties
22:44:47kanzure:or er, not just the (decentralizedish) distribution of mining hashrate
22:44:50bramc:Do you mean hard forks or soft forks or something else?
22:44:57kanzure:hard forks.
22:45:21kanzure:oh right; never allowing a hardfork fixes this.
22:45:37bramc:There's only so much which can be done against hard forks. If the whole world forgets about a system and does something unrelated no amount of rulesmaking in the old system can do anything about it.
22:46:11kanzure:it's not just that though
22:46:33kanzure:it's that even if a small chunk of users hardforks, you still get degraded system performance anyway
22:48:08kanzure:(depending on which chunk of the network that was)
22:48:56bramc:podpot mining allows miners to mine on multiple cryptocurrencies and forks simultaneously with very little overhead. This is both good and bad.
22:49:09gmaxwell:bramc: no system can be immune to the users rewriting the rules, but it surely can resist them... and bitcoin does, thus this drama. :)
22:49:13kanzure:perhaps there's a way to use extension blocks here to prevent that sort of behavior, a sort of nuclear "i'll just soft-fork all of you into using the same set of extension blocks" plan or something
22:49:23mrkent:this whole thing feels like a bailout, actually kinda depressing
22:57:39bramc:mrkent, The cap increase is sort of a bailout in the sense that it's meant to avoid transaction fees. It isn't clear that that's a necessary or even desirable thing to do though.
22:59:35mrkent:It's also a bailout in the sense that if people really wanted a bigger blocks sizes, they should just switch to an altcoin or BIGcoin that has bigger blocks, rather than altering agreements they've already made with the bitcoin network
22:59:51kanzure:er, i don't think that explains the bail part there?
23:00:05mrkent:ah sorry, msg got too long forgot where i was going
23:00:18mrkent:No one wants the risk of a new altcoin
23:00:49mrkent:they want Gavin to increase value of BTC without having much downside
23:01:20mrkent:or "oh shit, i bought this coin that has a low blocksize thus cannot scale to be valuable, please change rule so it's not the case"
23:02:16kanzure:bramc: did you look at the extension block proposals?
23:03:41mrkent:If this can be turned into a tabular form for easy reddit digestion, i think it would do a lot of good for public opinion
23:06:58mrkent:Can someone remind me why we can't have no-limit blocksize and let miners determine themselves?
23:07:24kanzure:runaway effects
23:07:58mrkent:kanzure: like?
23:08:34gmaxwell:mrkent: please go read jeff's bip100 document, it talks reasonably enough about many of these things.
23:08:45gmaxwell:I'm worn out after the 1001st repetition.
23:08:55kanzure:is there a good link for fedpeg vs extension blocks
23:09:02gmaxwell:(jeff's document isn't comprehensive, but I thought it more useful to point you to something I didn't write)
23:09:14kanzure:unfortunately the only one i'm aware of is https://www.youtube.com/watch?v=jE_elgnIw3M which is not a document
23:09:23gmaxwell:* gmaxwell is really not a fan of extension blocks.
23:09:49gmaxwell:* gmaxwell discouraged adam from publishing anything on them for basically months, until people started talking about similar stuff anyways.
23:10:09kanzure:yeah my eyes sort of went wide when i read that email
23:13:04zooko:kanzure: what email?
23:13:30kanzure:zooko: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08183.html
23:13:35kanzure:whoops
23:13:37kanzure:zooko: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07937.html
23:13:40gmaxwell:really the extension block stuff has 90% of the disadavantages of a larger block. but the disadvantages may be less clear to people. We specifically called out soft-forking-in-a-sidechain as a risk in the sidechain whitepaper.
23:14:16kanzure:but i don't have to process it
23:14:17mrkent:gmaxwell: I read it this morning and just took a look again
23:15:38gwillen:gwillen is now known as Guest33644
23:15:38mrkent:It basically says it is a constraint that incentivizes efficiency and conservation and avoids spam
23:16:56mrkent:Market (miners) can determine the supply (blocksize), so I don't buy that argument
23:17:06gmaxwell:maybe he dropped that part.
23:17:43gmaxwell:mrkent: there are several issues, one is that miners and the rest of the network have interests at odds. Miners get paid to make their block bigger (free monies!), and everyone else has to swollow the block-- its an externality.
23:18:43gmaxwell:The next is that larger blocks favor bigger more centeralized miners in several ways, e.g. if your bandwidth and validation costs are macrosopic, then the most centeralized pool is the most profitable, and since mining is an equalibrium that seeks zero average profits, you'll be mining at a loss unless you use that pool.
23:20:26gmaxwell:The next is, assuming multiple miners still exist, if there is no limit on size it will always be locally in your best interest to take all the transactions you can, even very low fee ones. -- let someone else turn up their nose and delay very low fee transactions to create anti-spam and market pressures to increase fees. Absent a limit there the rational equlibrium fee should be very low, and a
23:20:32gmaxwell:ll of that fee should be paying for the verification, which enjoys perfect centeralization gains.
23:20:49gmaxwell:(and none of it going to POW, which provides security, but is a free parameter and can basically adapt to 0)
23:22:39gmaxwell:mrkent: does this stuff convince you that its not quite as simple as "do whatever you want?"
23:22:40kanzure:was there ever a thing in here discussed about compression proof-images to make commitments about large quantities of transactions instead of just lists of transactions or instead of just transaction commitments.
23:22:55kanzure:or was i dreaming that
23:24:16mrkent:gmaxwell: some of those do and some don'tt
23:25:07kanzure:i don't think that providing ways for people to move coins out of the system will keep them from trying to hardfork the main chain
23:26:16kanzure:i suppose one argument is, "well if you hardfork successfully, then you *really* should have considered using an extension block or sidechain or some other bitcoin teleportation technique, because now you will have to do that anyway with the forked utxos"
23:26:52mrkent:I mean centralization is bound to occur to some degree
23:27:58gmaxwell:sure, but it already has. Right now you could freely rewrite the chain at the tipe by coercing or kidnapping less than a half dozen people. What degree is acceptable?
23:28:01mrkent:Realistically speaking, it's likely as adoption grows, more people will use services like coinbase than send blockchain transactions
23:28:30gmaxwell:mrkent: sure, but when that happens its at the edges and people opt into it, and they takes the risks that come with it and they can choose it.
23:28:57gmaxwell:vs when centeralization happens at the center its forced onto you and you can't 'opt out' except by abandoning bitcoin.
23:31:48mrkent:I get that, but larger pools are always going to be favorable, so it is only logical that there is 1 pool on which everyone mines for 0 profit (regardless of the blocksize)
23:32:55mrkent:> Absent a limit there the rational equlibrium fee should be very low
23:33:45bramc:kanzure, I hadn't seen extension blocks. That would be less bad than a hard fork
23:34:25mrkent:not sure if that's obvious (fee being low)
23:35:03gmaxwell:mrkent: uh? "larger pools are always going to be favorable, " what?! no.
23:35:23gmaxwell:please don't tell me you're in this channel without the most basic understanding of how mining works?
23:35:23bramc:Although I'd like to point out that the non-extended part of extension blocks would still be subject to having transaction fees when it's transacted within or when coin is moved into or out of it
23:35:46kanzure:bramc: sure, yes
23:35:49mrkent:gmaxwell: I mean in terms of efficieny
23:36:08gmaxwell:mrkent: explain what you're thinking further?
23:37:00mrkent:Well, the guy that invests $10m into a minging farm vs guy at home will always make more money
23:37:02bramc:Gavin's rebuttal to extension blocks is... weird https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07938.html
23:37:11gmaxwell:mrkent: thats not correct.
23:37:21mrkent:So at 0 profit, the only guys that can mine are the big scale ones
23:37:33kanzure:bramc: yes
23:37:44mrkent:So we have a small number of mega miners
23:37:58gmaxwell:mrkent: mining is a _lottery_ not a race. You win proportionally to your hashrate (ignoring issues around propagation). The process is linear, and there isn't a large scaling advantage (and there are a few scaling disadvantages, e.g. heat dissapation is harder at larger scales)
23:38:15mrkent:So, when we get to 21m BTC, these guys are only going to make money off fees
23:38:36gmaxwell:mrkent: long before then, effectively.
23:38:47gmaxwell:(because of the geometric behavior)
23:39:20mrkent:So if they accept very low fees like you claim, why would anyone pay more that that low amount?
23:39:58gmaxwell:right. They wouldn't.
23:40:03bramc:mrkent, It's a regular supply and demand thing. Once the demand has exceeded the supply, which in this case is set by the block size limit, then the price will go up
23:41:05gmaxwell:It's like asking how carbon cap and trade would work... without the cap. :)
23:41:16bramc:gmaxwell, exactly
23:41:17mrkent:effectively, mining becomes, how soon do I get next block (thus how much fee I charge * # of txns)
23:42:01bramc:mrkent, You don't get to decide on the fee, each transaction says what its fee is, so you take the transactions with the highest fee/byte and include them
23:42:20mrkent:so in order to secure the network to the degree that people want, I need to charge at least fee of x satoshi...
23:42:28kanzure:"charge"
23:43:11brand0:Can anyone point me to code/documentation/whitepaper on which transaction scheme they think would scale best?
23:44:41gmaxwell:mrkent: huh? you take all that you get and you put the result in your pocket. nothing makes you spend it on security.
23:45:08bramc:brand0, The lightning network paper isn't quite ready yet, there will be a presentation at Stanford on monday https://crypto.stanford.edu/seclab/sem-14-15/poon.html
23:45:55mrkent:gmaxwell: I'm not sure I understand what you mean there
23:46:04bramc:kanzure, If the big proposal right now was for 20mb extension blocks there would be a lot of controversy but not half the amount of bitter vitriol going on right now.
23:46:26brand0:bramc, thank you
23:46:57gmaxwell:mrkent: there is no "charge" mechenism. transactions have a fee they pay. You take it or you leave it.
23:47:33gmaxwell:you can choose to produce a smaller block, leaving fees on the floor that you could have otherwise earned, and other miners will earn them if they break rank with you and accept the transactions you turned up.
23:47:35mrkent:Yes but miners don't have to accept them
23:47:47bramc:brand0, The super-quick summary of lightning network is that it uses net settlement where there's no need for anything to hit the chain until the net goes past the deposit amount, and then that's just a single transaction. It requires a relative timelock opcode to work properly, for reasons which are very technical and interesting.
23:48:30gmaxwell:right, now saw you accept at some cutoff. you'll make less. Someone else accepts them, they'll make more than you, and yet they'll still benefit from your design to reject since it delays the transactions somewhat.
23:48:52gmaxwell:but you never increase your income by rejecting, not unless almost everyone else does too.
23:49:01gmaxwell:and everyone can make more right now by not rejecting.
23:49:30gmaxwell:Then once you've made whatever you've made, you can just put that in your pocket. It doesn't go to pay for security, only your competition with other miners can result in that.
23:50:05akrmn:There's many different forms of extension blocks. No one has still provided any fundamental flaw in my "subchains" idea, which is a form of extension blocks.
23:50:16jgarzik:gmaxwell, never say never ;p
23:51:05jgarzik:gmaxwell, if e.g. your orphan rate decreases due to block minimalism. there are other incentives besides fees... IMO that's a big part of PoW is that some real world externalities salt the system versus PoS.
23:52:28gmaxwell:well I'm disregarding orphan rates there, because they are prefectly solvable via another simpler means: pool centeralization. It basically never makes sense to lower your blocksize to lower orphan rates, see pieters simulation results. If orphaning is an issue due to bandwidth you centeralize pooling.
23:53:07gmaxwell:Which is what people were doing some months ago which is much of how we ended up with half the hashrate under a single parties control. Fortunately the block relay protocol reduced the incentive to do that, at least for a bit.
23:53:14mrkent:There may be some other strategies a miner can employ to get higher pay
23:53:26mrkent:Like perhaps some block withholding tactic
23:54:19mrkent:Or like partnership with payment providers or something
23:54:28gmaxwell:sure, miners with more than about a third of the hashpower can get a large advantage by withholding.
23:55:11mrkent:like visa POS wants BTC confirmed immediately, so they pay the 1 asshole miner who charge 2x everyone else
23:56:15jgarzik:still might take 60 wall clock minutes even at highest fees
23:56:24wallet421:wallet421 is now known as wallet42
23:56:41gmaxwell:mrkent: that still doesn't get you anything close to immediately though.
23:57:01mrkent:sure, i mean ASAP i suppose
23:57:44gmaxwell:mrkent: and again, externality: everyone else still gets paid from people doing that. and the person with the too high bar will operate at a loss while his conservativism subsidizes everyone else.
23:58:21mrkent:Ultimately, it'll boil down to some equilibrium point at which miners collect fee based on how much value they provide to the network
23:58:52mrkent:certainly more transactions = more value they provide right?
23:59:11wallet42:wallet42 is now known as Guest18833
23:59:12wallet421:wallet421 is now known as wallet42
23:59:22gmaxwell:gmaxwell has left #bitcoin-wizards
23:59:39mrkent:oh shit did i anger him?