01:00:04c0rw1n:c0rw1n is now known as c0rw|zZz
02:13:17rusty:dumb q: AFAICT it would be better to use input and output canonical seralization, rather than random permutation. What am I missing?
02:13:53rusty:(I'm thinking that a canonical ordering could be eventually enforced, whereas random can't be)
02:14:12rusty:I am referring to the order of tx inputs and outputs, in cas that wasnt' clear.
02:49:11Guest95228:Guest95228 is now known as luigi1111
03:13:21jae:jae is now known as Guest23206
03:50:39frankenmint:frankenmint has left #bitcoin-wizards
03:53:15andytoshi:rusty: i think you're correct, maybe this just hadn't occured to anyone
03:53:23andytoshi:(cue gmaxwell posting a bct post of his from 2010 describing exactly this)
04:24:40jae:jae is now known as Guest56899
04:34:12rusty:andytoshi: thanks for sanity check. I'll get motivated RSN and write it up, w/ patch.
06:08:33blackwraith:blackwraith is now known as priidu
06:14:07jae:jae is now known as Guest58038
06:27:21Face900:Face900 has left #bitcoin-wizards
07:18:38waxwing:references Chicken so probably worth a look
07:21:35justanotheruser:Is there some significance to the word leakage?
07:21:50fluffypony:justanotheruser: yes
07:22:01fluffypony:from the seminal presentation on it
07:22:18fluffypony:"Leakage: leakage leakage; leakage, & leakage"
07:22:51justanotheruser:is there some trend of information leakage papers being nonsensical?
07:23:57fluffypony:nah I think they were just taking the piss out of the Chicken thing
07:24:28justanotheruser:isn't that the same guy from the chicken paper?
08:05:16wilhelm.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:16wilhelm.freenode.net:Users on #bitcoin-wizards: andy-logbot nessence adam3us oleganza p15 hktud0 Mably GAit arubi_ Guest58038 zmachine priidu waxwing wallet42 sadoshi antanst thrasher` TheSeven copumpkin brianhoffman Dr-G dgenr8 fanquake1 d1ggy_ moa metamarc Relos bosma Cory gielbier phantomcircuit NewLiberty DrWat felipelalli stonecoldpat sparetire_ c-cex-yuriy LeMiner Adlai spinza afk11 c0rw|zZz michagogo rustyn jgarzik bedeho ebfull b_lumenkraft justanotheruser rasengan PRab hashtag_
08:05:16wilhelm.freenode.net:Users on #bitcoin-wizards: dc17523be3 yoleaux EasyAt shesek wumpus comboy stevenroose|BNC hulkhogan_ elastoma pigeons robogoat kinlo Logicwax gwillen sl01 akstunt600 SubCreative superobserver mm_1 [d__d] Madars Tiraspol kyuupichan gavinandresen nickler Iriez ttttemp mountaingoat Transisto2 jmcn koshii gmaxwell wizkid057 Luke-Jr akrmn cdecker harrow dansmith_btc face Keefe jrayhawk K1773R luigi1111 luny Emcy melvster tromp_ theymos Apocalyptic prosodyContext ggreer
08:05:16wilhelm.freenode.net:Users on #bitcoin-wizards: Hunger- Pan0ram1x jcorgan isis cryptowest_ mengine sneak HM grandmaster Starduster bsm117532 lnovy harrigan andytoshi scoria brand0 larraboj OneFixt vonzipper mappum MoALTz Jouke weex gnusha nsh triazo jonasschnelli CryptoGoon berndj leakypat platinuum Oizopower jbenet dasource btcdrak tucenaber helo Taek iddo GreenIsMyPepper amiller epscy adams__ wiz mikolalysenko artifexd lmacken yrashk cfields Krellan coryfields catlasshrugged Alanius
08:05:16wilhelm.freenode.net:Users on #bitcoin-wizards: null_radix kanzure bliljerk_ azariah warptangent sparetire davout TD-Linux yorick crescend1 veox Zouppen huseby _whitelogger binaryatrocity heath BananaLotus maaku optimator Eliel narwh4l mr_burdell throughnothing_ fluffypony Fistful_of_Coins Jaamg xabbix mariorz catcow a5m0 smooth dignork runeks Sqt poggy livegnik petertodd richardus nephyrin phedny so afdudley SwedFTP guruvan ajweiss nanotube forrestv Muis warren Xzibit17 sdaftuar eric
08:05:16wilhelm.freenode.net:Users on #bitcoin-wizards: roasbeef CryptOprah morcos merlincorey [ace] sturles jaromil Graet indolering ryan-c jessepollak gribble d9b4bef9 starsoccer kumavis otoburb midnightmagic BlueMatt Anduck AdrianG espes STRML BrainOverfl0w @ChanServ
08:10:54gmaxwell:does the leakage paper encode another paper in typesetting modulation?
08:11:03vonzipper_:vonzipper_ is now known as vonzipper
08:11:30jbenet_:jbenet_ is now known as jbenet
08:29:48nsh:* nsh smiles
09:19:11wallet421:wallet421 is now known as wallet42
09:39:39waxwing:justanotheruser: the author is of course our lord and saviour: https://twitter.com/dchest/status/604410816675323904
09:49:05wallet421:wallet421 is now known as wallet42
10:07:52nsh:* nsh chants Djah-b, Cryptofari!
10:19:12rustyn_:rustyn_ is now known as rustyn
10:21:31_mm_1:_mm_1 is now known as mm_1
10:37:10hearn_:hearn_ is now known as hearn
11:22:12wallet421:wallet421 is now known as wallet42
11:36:25luny`:luny` is now known as luny
12:31:23c0rw|zZz:c0rw|zZz is now known as c0rw1n
13:49:08helo_:helo_ is now known as helo
14:16:10frankenmint:frankenmint has left #bitcoin-wizards
15:28:20antanst:antanst has left #bitcoin-wizards
16:38:34Guyver2:Guyver2 has left #bitcoin-wizards
17:12:59blackwraith:blackwraith is now known as priidu
17:20:11StephenM347:The main argument against a simple vote to increase block size (one vote per block solve), is that miners would form cartels to cut smaller miners out, right?
17:21:57StephenM347:Miners could already do this, though. If together they have >50% of the mining power, they just agree to only mine on each others blocks.
17:22:29StephenM347:It seems like a simple vote doesn't add any assumptions about miners that aren't already in place.
17:24:52andytoshi:StephenM347: miner incentives are not aligned with the incentives of any other party in the network, at least re blocksize
17:25:39andytoshi:since they are directly rewarded for larger blocks while everyone else sees only increased validation/bandwidth costs (tho potentially lower network fees i suppose)
17:27:28andytoshi:bottom of page 11 says this in https://download.wpsoftware.net/bitcoin/alts.pdf ... as i recall there are actually alts out there with adaptive blocksizes who have seen this problem, but i apparently did not write about them :/
17:27:53jae:jae is now known as Guest89542
17:30:25StephenM347:andytoshi: I see what you're saying, that may be just an inherent flaw. Probably not one we can't live with, though.
17:30:28StephenM347:No matter what happens, miners are going to have to be involved in order to change the block size limit.
17:31:08StephenM347:So why not give it to them within the protocol?
17:31:39StephenM347:Rather than debating for aeons and then still requiring miners' approval.
17:32:42andytoshi:StephenM347: because if you put blocksize adjustments into the protocol, only miners' consent is then needed to change it. but if changing it means changing consensus rules, then everybody needs to agree
17:33:40andytoshi:miners have very little power to effect hardforks, basically enough of them need to collude to plausibly threaten to attack the portion of the network that doesn't agree with them
17:34:00andytoshi:otherwise if they fork, they're just wasting power generating coins that nobody else recognizes
17:35:39StephenM347:andytoshi: requiring only miners' consent does seem to be a downside.
17:36:09StephenM347:and it's awfully hard to get the votes of users' included into a decentralized protocol
17:36:19tromp_:andytoshi: larger blocks could lead to lower avg fee per tx
17:36:37kanzure:votes are a completely wrong mechanism for that
17:37:13kanzure:andytoshi: they can effect hardforks by threatening to attack other chains, depending on their size
17:44:39StephenM347:andytoshi: I think I understand the dilemma more now. Thanks. Keeping complete control out of miners' hands is actually a benefit, even though it makes our lives difficult in times like these.
17:55:11andytoshi:StephenM347: can you clarify "makes our lives difficult in times like these"? to the best of my knowledge there is no pressing need for any forking changes, and certainly no need for minorities to have unilateral power to change the network rules for everyone else
17:56:24andytoshi:StephenM347: the point of a decentalized consensus system is that nobody can force their will on others; so no "tyranny of miners" nor "tyranny of the majority" nor "tyranny of several corps' PR departments" etc
18:02:16andytoshi:(i don't mean to be rude here; i'm well aware of what's being said on reddit and in the press; but this "either nothing changes forever or RIGHT NOW we must do something drastic" meme is hysterical at best .. and seems to be pushed by people who are not interested in decentralization and in fact seem willing to act deliberately against it. it's tiring.)
18:04:57StephenM347:andytoshi: I didn't take it as rude. I want to maintain decentralization, but I think an increase in the block size limit is necessary simply to buy us some time to develop systems such as lightning network.
18:05:14wumpus:andytoshi: "but this "either nothing changes forever or RIGHT NOW we must do something drastic" the tyranny of imagined necessity
18:05:31StephenM347:By times like these, I simply mean times when everyone is debating about changing a core characteristic of the bitcoin system
18:06:16andytoshi:StephenM347: well, lightning can work today with 1Mb blocks. it would need to see significant usage (and weird events where lots of transactions are simultaneously unwound/committed at the same time) before we saw constraints due to lightning
18:07:24andytoshi:but it is certainly true that in the future we will likely want a blocksize increase. but there is no evidence that that time is now, and there's a lot of engineering work re network scalability that ought to be done before that
18:08:00gmaxwell:StephenM347: right now, however, the network isn't full-- and we are not yet seeing a functioning fee market even. If there were some emergency situation with transactions backlogged for days; ---- then indeed a modest bump would be the least of the available evils. Fortunately doing that is technically trivial.
18:08:14gmaxwell:Especially since SPV clients cannot see the blocksize.
18:08:37StephenM347:andytoshi: Right, but since no such solution is currently available, we may need to keep using fully on-chain transactions for the immediate future. For this purpose, I do think increasing the max block size should be done as a temporary solution.
18:09:15gmaxwell:StephenM347: technically most transactions involving bitcoin are already off the chain, via centeralized services (in exchanges) for better or worse.
18:09:41gmaxwell:Not becuase of a lack of space but because of things like instant confirmation.
18:09:50StephenM347:gmaxwell: True. And we have ~500 kb blocks and many miners leave the limit to the default 750 kb. We're not quite full yet, but we're not too far away.
18:09:50andytoshi:StephenM347: i'm not sure what you mean? lightning could be implemented today and be working; it would only be affected by blocksize limitations given (a) a lot of usage and (b) a "perfect storm" of commits to the blockchain
18:10:41gmaxwell:StephenM347: Sure, but we're not there yet, don't know how long it'll take to be there yet; and continually bumping the limits ahead of demand has resulted in almost all wallet software being varrious degrees of broken (unable to handle a fee market enviroment smoothly)
18:11:14gmaxwell:(also it has resulted in the network being moderately broken, in that we do not have CPFP or (safe-mode)RBF universally deployed)
18:13:26StephenM347:andytoshi: The lightning network could (mostly) be implemented today, aside from some malleability fixes that need to be implemented. I was just trying to say that increasing the max block size is an unfortunate, but possibly necessary, temporary solution
18:14:18wumpus:it's not a temporary solution, a hardfork takes a long time to deploy and I doubt it will ever be reverted. We all know that kind of temporary measures...
18:15:26StephenM347:temporary in the sense that it buys us time, not in the sense that it will ever need to be reverted
18:15:50gmaxwell:StephenM347: it also could have been implemented in 2013; https://en.bitcoin.it/wiki/User:Aakselrod/Draft but absent actual pressure, these areas are not the most pressing concerns and they do not get investment. We also have seen this with CPFP and RBF... CPFP was actually written up and RBF was invented back at the beginnning of 2013 when blocks were full (relative to the soft limit) and then
18:15:51wumpus:more pressure may be better to actually get solutions out there
18:15:56gmaxwell:went dead once the limits were bumped.
18:16:19hulkhogan_:adam3us posted a very interesting proposal to the mailing list about the possiblilty of using opt-in blocks as another method. the notes he left made the scheme seem fairly complex to implement but it was compelling in the dimension of new considerations.
18:16:22wumpus:yes, all interest in them went away
18:17:58gmaxwell:hulkhogan_: I'm not a huge fan of extension blocks myself (and had previously been somewhat negative about proposing it); mostly because they have 90% of the negatives of just having a larger block-- and the people who are agressively demanding larger blocks wouldn't support them, because they're more complex and the argument for larger blocks begins with dismissing the negatives.
18:19:04gmaxwell:hulkhogan_: (and, in fact) the sidechains paper basically calls out 'a sidechain might turn into an extension block' as one of the risk factors of sidechains.
18:19:29StephenM347:gmaxwell: What do you mean by wallet software being 'unable to handle a fee market enviroment smoothly'? Are you saying wallet software should be more dynamic in its' fee calculation, looking at recent blocks to see what gets processed and what doesn't?
18:20:36wumpus:StephenM347: yes - this is what bitcoin core's wallet has done for a while
18:20:37hulkhogan_:gmaxwell: hm, i don't contextually undetstand all the implementation details of extension blocks, so maybe it was just because it was the first time i had seen the idea, but i should re-read adam's post to understand what security assumptions are gained/lost
18:20:53gmaxwell:StephenM347: two fold, that (right now most wallet software just sets static fees-- ones which are unrelated to the transaction size-- which makes very little sense; and causes both massive over and under payment)... and wallet software (including bitcoin core) has no graceful way to recover when you've paid a fee that is too small.
18:22:42gmaxwell:handling the latter really well may require something like safe-mode RBF in the behavior of miners and the relay network. (making easier to add fees to a transaction after the fact)
18:23:31gavinandresen:gmaxwell: there really isn't a way to handle "transaction won't confirm because insufficient fee paid" gracefully in a lock-wallet and/or multisig world.
18:24:13kanzure:you could do child-pays-for-parent there
18:24:17kanzure:without having to have everyone re-sign
18:24:50gavinandresen:gmaxwell: End-user wallets should probably target paying above-average fees to work around that. The high-volume-transaction uses of the blockchain are services (faucets, gambling, tumblers) not people, so that's OK.
18:25:34gmaxwell:gavinandresen: In cases where reissuing has greater costs, or CPFP isn't available-- one should be paying more fees upfront. Indeed. Paying more in those cases is seems quite reasonable to me.
18:27:26gmaxwell:* gmaxwell bbiab
18:27:29gavinandresen:gmaxwell: given that a majority of miners are running with default block size, do you think we could run the same experiment with "what happens if transaction volume ramps up" by simply leaving the default block size at 750K?
18:27:54kanzure:same as what?
18:28:06gavinandresen:The "what happens when blocks are full" experiment.
18:28:17gavinandresen:Max size and size miners are choosing to create are not the same
18:28:27hearn:we know what happens already. it would be a waste of time.
18:28:47gavinandresen:hearn: I'm just trying to find consensus here.....
18:28:58hearn:we've hit soft limits before
18:29:52hearn:what happened is lots of users came and complained and me and andreas because their payments didn't work. then i had to go around asking miners to raise their limits. then we raised the defaults. big time sink, don't want that to happen again. fee market = nice name for picking losers.
18:30:18gavinandresen:By the way... I don't like the "no pressure to solve the problem" arguments, because same argument could be used by either side ("No pressure to handle increasing fees" or "No pressure to work on optmizing for larger blocks")
18:31:44hearn:i don't like it because it assumes my time is free and that i have nothing better to do with it than work around self inflicted wounds :-)
18:32:02hearn:where by "my time" i mean "time of wallet developers around the world" of course
18:32:26gavinandresen:andytoshi: why do you think increasing the max block size will increase centralization to any significant degree? I've written a couple of blog posts on why I think it won't...
18:33:10kanzure:so the concern about increasingly higher average transaction fees is not related to the network failing to continue networking
18:33:34kanzure:i don't think that's relevant; the problems related to increasingly higher fees are other problems. they are still problems or concerns of course.
18:35:49andytoshi:gavinandresen: the same reasons that have been posted on reddit and elsewhere by gmax et al. i don't have anything new to say (and would rather not use -wizards scrollback rehashing this)
18:42:06hearn:andytoshi: then they have been addressed already
19:00:01kanzure:gavinandresen: could you describe a worst-case scenario that you could imagine for extremely high average transaction fees?
19:02:52Relos:wouldn't high transaction fees mean practically no privacy?
19:03:29kanzure:go on?
19:03:50Relos:well, you wouldn't be able to use mixing
19:04:05Relos:unless you pay some very high cost
19:05:21Relos:you wouldn't be able to use a new address, etc
19:05:43Relos:thus everyone would or could know how much you own etc and where you spend it, which is terrible
19:06:01kanzure:why would you be unable to use a new address?
19:06:18Relos:because high fee
19:06:24kanzure:can you be more specific?
19:06:50hulkhogan_:Relos: if a fee market enabled greater innovation in off-chain processing, then the privacy could even be increased because of settlement scenarios
19:07:12Relos:let us suppose we have lightning networks, and I have not looked into it, but if I have some bitcoins and the onchain transactions are super high
19:07:17Relos:then how do I use mixing?
19:07:39kanzure:presumably they would continue working the same way, except you would type in a higher value for the transaction fee.
19:07:53Relos:yes, so pay a lot of money for privacy
19:08:24gavinandresen:RE: lightning and scalability or privacy: good discussion on the recent LTB podcast: https://letstalkbitcoin.com/blog/post/epicenter-bitcoin-joseph-poon-and-tadge-dryja-scalability-and-the-lightning-network
19:08:56hulkhogan_:* hulkhogan_ is reminded to go over the lightning paper again
19:09:25Relos:and its not just privacy
19:09:47Relos:why would more people run a node than currently under a lightning network?
19:09:51gavinandresen:kanzure: worst case for high fees? Bitcoin dies a slow death as people abandon it for better options.
19:10:18kanzure:don't you think the average transaction fee would go down if there are zero transactions?
19:10:26gavinandresen:kanzure: ... where better is lower fee, more convenient (no unlocking your wallet three times to send one transaction because the first two didn't confirm), etc.
19:10:28kanzure:(like that seems related to the definition of average)
19:10:30GAit:do we know of better options of bitcoin? last i checked the alts coins are not really better nor can scale better than bitcoin
19:10:55Relos:presumably, considering that there are estimated to be some 2-5 million bitcoin users and only 5,000 nodes, the people who currently run a node do so only because they have to or are hobbyists, or researchers, etc
19:11:00kanzure:gavinandresen: unlocking your private key multiple times seems to be related to poor fee estimate, not the other thing
19:11:07GAit:gavinandresen: it wouldn't lock if we had RBF without limiter
19:11:23kanzure:whoops sorry i mean poor fee estimation
19:11:42Relos:therefore, the only way to increase node count is by increasing the number of people who have to run a node
19:12:19Relos:the only way you can do that is by allowing businesses to find new applications for the blockchain, by increasing the number of businesses, users, etc
19:13:40Relos:so, to be honest, personally I think a higher size is more likely to lead to decentralisation rather than centralisation, if its a size that is currently easily affordable such as say 8 - or 11mb plus some % yearly increase in line with the average increase in bandwith speed
19:14:24kanzure:gavinandresen: so it sounds like you are very interested in permanently low fees
19:14:37Relos:at 1mb I can see us loosing both privacy and decentralisation
19:15:26gavinandresen:kanzure: I have no opinion on how high or low fees should be, I think we need to be neutral and let it sort itself out.
19:15:51kanzure:gavinandresen: that sounds like a good and neutral statement, but you stated previously a few minutes ago that better is lower fees, and i'm trying to reconcile this in my head
19:15:58gavinandresen:kanzure: I think artificially limiting the block size in an attempt to ... what? maximize miner revenue? is a bad idea.
19:16:33hulkhogan_:relos, i think it makes more sense to understand why the node count has dropped recently. ex; if its the hdd constraints (30gb) then larger block size would exacerbate the problem. not saying that is the reason, just offering another line of thinking- hopes/wishes for node count to magically increase seems odd
19:17:42hulkhogan_:the reason to run a node is for self-verification/trustlessness, if it makes more sense for biz to outsource that function, they'd do that
19:17:42Relos:I'm just logically inferring and I may be wrong in my inference, but running a node currently is pretty much free, yet almost no one does so, because it is voluntary, they don't have to
19:18:02gavinandresen:Does anybody think that, given the choice between a full node processing 1MB blocks, a full node processing 20MB blocks, and an SPV wallet a significant fraction of users would choose either of the full node solutions over the lightweight SPV solution?
19:18:03Relos:so, I think, the only way to increase the node count is to increase the number of persons who have to run a node
19:18:06hulkhogan_:not voluntary, but resource unfriendly (is myu take)
19:18:34Relos:its inconvenient and people won't do something inconvenient if they have the choice
19:18:50Relos:as we can currently see
19:19:14gavinandresen:Relos: how do you think you can force somebody to run a full node?
19:19:14kanzure:gavinandresen: it is hard to predict how users will choose software, but i suspect that a full node can be made that can run on limited resources in an appealing way, with enough force perhaps
19:19:20hulkhogan_:well Relos, nobody 'has' to run a node, everyone can go SPV and trust the 1-2 nodes in our VISA-cryptodystopia, but they do it so they dont need to rely on others for blockchain/payment verfication
19:19:48Relos:hulkhogan_: I am not talking about any utopia, I am referring to the current situation
19:19:54kanzure:gavinandresen: so i think neutrality is a good strategy, but again you said above "Bitcoin dies a slow death as people abandon it for better options, where better is lower fee, [and other properties]"
19:20:06hulkhogan_:Relos: ex. i run a in-home node for verification of all my transactions, because i dont need to trust anyone else to know when my payments have succeeded.
19:20:08Relos:runnin a node currently is practically free, yet out of some 2 million users only 5,000 do so
19:20:12kanzure:gavinandresen: and i think it would be helpful to me (and others) to reconcile this somehow
19:20:27Relos:I think from that we can inferre that only people who need to run a node do so
19:20:33gavinandresen:kanzure: sure. If bitcoin transactions were $100 apiece, do you think there would be any interest? Would you be interested? At what point do you become un-interested?
19:20:33hulkhogan_:Relos: its not free, it takes 30+GB (cheap, not free) plus bandwith and compute
19:20:52Relos:thus, in regards to the question of decentralisation, we need to figure out how to increase the number of people who need to run a node
19:20:57kanzure:gavinandresen: my interests are very unusual and should not be relied on :-)
19:21:16kanzure:oh sorry
19:21:18Relos:and the only way I can think of doing so is by increasing the number of ways the blockchain can be used, the number of businesses, users, etc
19:21:20kanzure:you asked if there would be any interest
19:21:42hulkhogan_:Relos: i think getting others to run their own node helps autonomy in payment verification, but its only one aspect of decentralization that bitcoin offers
19:21:57kanzure:gavinandresen: yes, i think that by definition if transactions are paying those, then someone is paying those fees..
19:21:58Relos:a 1mb limit wont do anything for node count anyway if my assumption is correct that only people who need to run a node do so and some hobyists
19:22:38Relos:hulkhogan_: it certainly does, but most people, as we can see from the numbers, seem not to value highly that aspect to run their own node even currently when doing so is almost free
19:22:43hulkhogan_:curious as to where the assumption is coming from
19:23:36Relos:from the numbers
19:23:48hulkhogan_:Relos: perhaps they prefer the flexibility of SPV, perhaps self-verification is not as highly valued for some, its hard to say, but making resource constraints lower might help the node count, maybe
19:23:50Relos:out of some estimated 5 million bitcoiners there are only 5,000 nodes
19:24:05Relos:I don't think so
19:24:14kanzure:gavinandresen: i think that ultimately all transactions have to be selected over other possible transactions. i could create many potential transactions every second of every day, but i forego this because i have limited resources. i suspect the same is true of everyone and every transaction system.
19:24:17Relos:running a node is already pretty easy and as I say almost free
19:24:28Relos:people just don't want to do so because it is inconvenient
19:24:41gavinandresen:I think I'm lost in this discussion. I think Bitcoin will be more valuable with bigger blocks, so I want bigger blocks. I don't think 20MB blocks increase or decrease centralization of either number of full nodes or mining to any significant degree.
19:24:44Relos:why would anyone do something inconvenient, however slight, if they dont have to?
19:25:01binaryatrocity:free for you is not free for everyone though, even the assumption that the internet connection is "free" because it's already there is false for most of the world.
19:25:08kanzure:gavinandresen: yeah i think the Relos conversation started out a little flakey; seems like an unconnected rant (but still meaningful in its own sense i'm sure)
19:25:12hulkhogan_:Relos: right, but forcing it on people doesn't seem like it would make things much smoother
19:25:25gavinandresen:I think if we want more people to run full nodes (and I don't know why we would want that, we have plenty of full nodes) then finishing pruning and creating a fast way to bootstrap the chainstate are the right ways to fix that problem.
19:25:32hulkhogan_:Relos: it would burden the user which might hamper adoption, usabilty
19:25:48kanzure:gavinandresen: my own interest was querying you about your understanding of high-fee-pressure scenarios. you do seem to think that high-fee-scenarios will be associated with people abandoning bitcoin.
19:25:56GAit:gavinandresen: do you expect the node count to go up or down with bigger blocks and how would that impact SPV nodes and less descriptors available?
19:25:57skyraider:why would bitcoin be more valuable with bigger block? it can be argued that we don't need decentralized consensus for high-volume transactions; we need it for settlement; that's where technical problems lie in today's financial infrastructure
19:26:02Relos:that burden being $6 per month which is less than a netflix subscription
19:26:18gavinandresen:I also think that many people have a very limited view of "decentralization" -- number of full nodes is not the only relevant metric.
19:26:38kanzure:yes, you have mentioned "payment decentralization" before, e.g. "not using off-chain services or partial-chain services" i think
19:26:40binaryatrocity:Relos: where does your $6 a month estimate come from?
19:26:45GAit:number of full nodes is one of the metrics though and it has big impacts on SPV wallets too
19:26:55hulkhogan_:heh, its more than some are willing to pay.. depending on the thinking of the person 6/mo is more expensive than trusting mcdonalds to provide a node for them (or whoever, in the case of SPV)
19:27:33Relos:hulkhogan_: running a node is already "expensive" to some people
19:27:35hulkhogan_:* hulkhogan_ forgets if mycelium wallet supports SPV
19:27:42GAit:hulkhogan_: i don't think so
19:27:48Relos:thats why i started the discussion by enquiring who is currently motivated to run a node?
19:27:58skyraider:Relos: regulated companies
19:27:58GAit:last i checked it connects directly to their servers
19:28:01Relos:obviously it is a tiny minority of all bitcoin users
19:28:03GAit:(or via tor)
19:28:08Relos:who are these node runners?
19:28:11Relos:probably miners
19:28:15Relos:probably businesses
19:28:19kanzure:skyraider: if companies are the only entities running bitcoin nodes, then law enforcement can comple them to hardfork the network and use rules that are more centralized
19:28:23GAit:Relos: i run a few nodes in different continents
19:28:34Relos:probably individuals who have to  run a node
19:28:41Relos:or hobyists
19:29:02gavinandresen:kanzure: please stop arguing the "only companies can run" straw-man: http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized
19:29:10Relos:I cant see any of them being disuaded by $6 per month or $20 because by definition they have to run a node
19:29:23kanzure:gavinandresen: i did not say that only companies can run nodes
19:29:35Relos:thus to increase decentralisation, either under 1mb or 20mb or whatever cap, you have to increase the number of entities who have to run a node
19:29:46Relos:node decentralisation* I should say
19:30:06kanzure:gavinandresen: i think though that if we want to scale to 10e12 transactions per second, centralization is the key
19:30:10GAit:gavinandresen: i thought the discussion with chinese miner on the bitcoin dev mailing list demonstrated that it could increase centralization of mining by increasing advantages/disadvantages
19:30:53hulkhogan_:Relos i'm wondering how you would compel people to spin up a VPS at all :)
19:31:00skyraider:kanzure: indeed.. unless they are in different jurisdictions, perhaps. but this shows the importance of keeping the cost of running a node low. node cost can be estimated and possibly help serve as an objective metric for increasing vs not increasing block size
19:31:02kanzure:skyraider: i think gavinandresen's traditional argument here is something like, "bigger blocks mean more transactions which means potentially more people able to get transactions into the blockchain, so more participation makes the currency more valuable"
19:31:13gavinandresen:GAit: did you read the whole discussion? 20MB blocks would cost him something like $2 per day, hardly a crippling cost.
19:31:22kanzure:(to answer your "why would bigger blocks make bitcoin more valuable" question)
19:31:51gavinandresen:kanzure: yes, systems get more valuable the more people who use them.
19:32:00gavinandresen:.... if designed correctly, they get more robust, too...
19:32:10kanzure:well my ability to remember your statements has never been in question, you know :-)
19:32:59GAit:gavinandresen: it can only decrease node counts, that's for sure right?
19:33:12Relos:hulkhogan_: how is anyone compelled to run a node currently? Considering that there are only 6,000 of them, some tiny minority, it is probably reasonable to assume that the persons who currently run a node are either miners, businesses who need it to validate, hobbyists, researchers...
19:34:01kanzure:gavinandresen: so i am not talking about 20 megabyte blocks, but in general i think that centralized systems are a better design if the goal is to handle 1e9 transactions per second
19:34:03skyraider:kanzure: Bitcoin has a lot of very interesting advantages in settlement and clearing. also, quickly settling assets is not currently possible, and the ability to do so would be hugely innovative in financial markets. consumer payments already work out in the economy, but it'd be very interesting to have credit card companies settle through the blockchain,
19:34:17gavinandresen:GAit: if bigger blocks inspire more work on making it easier to run a full node (like finishing pruning or implementing a fast low-trust bootstrap) then no, bigger blocks could increase node counts.
19:34:23Relos:I can't see those individuals, who by definition have to run a node because they need to in order to perform their function being in any way disuaded by such hugely modest costs such as less than they spend on a netflix subscription
19:34:59hulkhogan_:Relos: yes so, to the regular user who only needs to verify their payment goes through (confirms, best chain) how do you ask those persons to move their SPV client to point to an in-house node, email campaigning?
19:35:01skyraider:off-chain transactions make a lot of sense for massive volumes
19:35:12gavinandresen:GAit: ... or if more people are attracted to Bitcoin because it is the obvious scalable solution for the future then node counts might go up with bigger blocks....
19:35:49gavinandresen:GAit: If you want me to say "Yes, absolutely, node counts will do THIS in the future" then sorry, I'll have to disappoint you. I have no idea what will happen with full-node counts.
19:36:20GAit:gavinandresen: we already have as is a lot of people taking and wasting space on the blockchain and you want to increase this process? yes it may speed up pruning work or implementing a fast low trust bootstrap but at the same time it doesn't bode well for bitcoin decentralization and we can't joke around with its social contract as it gets harder to decentralize later
19:36:25hulkhogan_:Relos: think of it this way, regular users care about accessibility and usability, you're proposing making it more difficult in some way to use bitcoin (although i dont think a email campaign is a terrible idea, either)
19:36:38Relos:how so?
19:36:46Relos:I'm describing the current situation
19:36:53Relos:or, at least I think I am
19:37:17hulkhogan_:well, i suppose i'm not sure, proposing we add some coercive measures to make those regular users run VPS' with bitcoind? (sorry if im missing the point)
19:37:27GAit:all i am saying is that intuitively you would think that a potential 2000% increase would cause nodes to go offline as they can't handle the disk or ram or network
19:37:29Relos:which users?
19:37:44Relos:the persons who already only run a node because they have to?
19:37:49hulkhogan_:lets say SPV users, who are probably relying on 3rd parties for verification
19:37:54Relos:if they have to run a node they will run a node....
19:38:09Relos:spv users wouldnt be affected by the blocksize
19:38:20gavinandresen:GAit: ok. I think that big an increase in transaction volume would be a good problem to have. Scaling problems are always good problems to have, they mean your system is successful and not dying.
19:38:26GAit:Relos: if common users have to necessarily run a node to use bitcoin they'll just not use bitcoin
19:38:26hulkhogan_:ok, i thought we were addressing node count, oops
19:38:45Relos:I meant full nodes of course, sorry
19:38:57Relos:I wasn't referring to spv users
19:39:12hulkhogan_:yea full nodes would be affected by blocksize increase in that resource requirements go up (if you believe the argument resource requirements are the reason node count is going down)
19:39:47Relos:I think my point was fairly simple
19:40:02hulkhogan_:i dont know how to quanitfy the other half of your statement above, that businesses would be incentivized to start more nodes because of increases to business
19:40:02Relos:I think that the people who currently run a node do so only because they have to
19:40:11Relos:they either miners
19:40:37Relos:hobbyists, researchers, etc... people who basically don't mind the "inconvenience" or have to deal with it
19:41:03Relos:they will have to run a node under a cost of $6 per month too or 20 per month whatever
19:41:13kanzure:gavinandresen: i think that some users are going to be misled into thinking that bitcoin will eventually handle high transaction rates (like 1e9/sec), whereas we could otherwise focus on areas where bitcoin is already better and unique. having a bunch of users that eventually learn that 1e9/sec isn't going to happen on-chain might be detrimental when they flip the bits in their head.
19:41:14GAit:gavinandresen: blocks are not full as is and there's practically no fee market. Even at 20MB you still have to handle blocks being full, there are other means we can achive better tx per second without impacting its centralization and those should be incentivized. Bitcoin is not famous for being best at tx/s, is famous for being decentralized
19:41:21Relos:thus the only way to increase node decentralisation is to increase the number of people who have to run a node
19:41:41Relos:I can't see such increase under 1mb
19:41:44gavinandresen:GAit: http://gavinandresen.ninja/the-myth-of-not-full-blocks
19:42:00hulkhogan_:Relos: well why would the situation change with 20mb
19:42:17Relos:but I can see it under a higher limit as more businesses use the blockchain for more applications thus more businesses have to run a node etc
19:42:17hulkhogan_:[erhaps ive missed that
19:42:27GAit:gavinandresen: some wallets already support smartfee and even during peak traffic transaction work as smoothly as ever
19:43:04GAit:and you have to handle full blocks even at 20MB
19:43:23kanzure:this is all way too low signal for my taste
19:43:54hulkhogan_:Relos what if i started some business that offers bitcoin-node-as-a-service? wouldnt node count still decrease? it would be a more convenient alternative to running a node (which requires administration, physical/virtual assets to manage)
19:44:40Relos:we already have those businesses
19:44:48hulkhogan_:i suppose i don't quite see how higher limit -> more buisness -> (confusing part) more businesses 'have to' run a node
19:45:18wumpus:people should be able to run their *own* nodes, that's the point of bitcoin, a third party running a node for you is no longer trustless (many examples; from blockchain.info to chain and other APIs)
19:46:13Relos:wumpus the problem is people don't want to run their own node even currently
19:46:14hulkhogan_:so wouldnt demand for those services go up? not too good at economics forecasts
19:46:45wumpus:Relos: if people don't want to run full nodes that's their own problem
19:46:51wumpus:Relos: it's about being able to.
19:47:03Relos:hulkhogan_ who do you think currently runs a node even under the current 1mb size?
19:47:18kanzure:wumpus: yes, forcing them to run nodes is just going to grow aminosity heh
19:47:26Relos:and bear in mind there are only 6k of them while there are 5 million users or so...
19:47:33wumpus:people that value privacy, security and trustlessness
19:47:51Relos:yes thats one part of them
19:48:02Relos:bot mostly it is probably miners
19:48:11Relos:who have to run a node
19:48:15Relos:who dont have a choice
19:48:37wumpus:I strongly doubt that most of them are miners, remember that most miners use pools so don't have to run their own node
19:48:41Relos:because as far as voluntarily choosing the data clearly seem to say people would, if they have the choice, rather not run a node, even as things stand
19:49:10wumpus:Relos: that's only because not enough disasters have happened with centralized services yet, people will learn
19:50:12Relos:thus an extra $6 per month, $10 or $20 I don't see how it will disuade any current node runner
19:50:44hulkhogan_:Relos: same folks you mentioned, most likely
19:50:53Relos:while under 1mb I don't see how bitcoin users can keep their privacy when mixing is so expensive due to high fees
19:51:08jae:jae is now known as Guest88589
19:51:08Relos:and I don't see why anyone would run a node under 1mb when most transactions are in hubs
19:51:40wumpus:I don't think it's realistic to expect most runners of nodes to spend those kinds of money just to keep running one
19:52:07Relos:they already spending something on it......
19:52:20Relos:why makes you think they would be disuaded by a netflix subscription?
19:52:20wumpus:bandwidth is quite expensive in some countries
19:52:39wallet421:wallet421 is now known as wallet42
19:52:57wumpus:not everyone has a netflix subscription either (and that's something different anyway - it directly brings entertainment)
19:53:11Relos:not everyone can afford to eat lol
19:53:14Relos:what's your point
19:53:46wumpus:... ok, bye
19:59:28hulkhogan_:* hulkhogan_ thinks there should be a #bitcoin-privacy chan
20:02:02Relos:I'm curious to know what other devs would do if it comes to an actual hardfork, would they follow the longest chain or...?
20:03:52helo:without consensus, it would boil down to a PR battle and an eventual (fatal?) stubborn fork
20:04:37Relos:yes, but lets say XT wins, will gmaxwell and jgarzik then go with the longest chain
20:04:48Relos:or will they move onto other things?
20:06:55maaku:Relos: the "longest" chain doesn't matter
20:07:28maaku:in that scenario XT would be a totally different altcoin that happened to have more mining power than bitcoin
20:07:44Relos:and users, so core would be the altcoin
20:07:58Relos:and businesses, etc
20:09:57maaku:it would be better if this debate did not happen on -wizards
20:10:55wumpus:create a #bitcoin-blocksize chan or so, or just move it to #bitcoin
20:14:16Relos:yes....... ignore the debate right, because nothing needs to be done
20:14:43maaku:Relos: no one is ignoring anything. this is just not the right channel
20:15:52hulkhogan_:Relos I'll see you in #bitcoin-blocksize .. ;)
20:16:17wumpus:whether something needs to be done or not, contentless 'debate' doesn't move anything forward, and indeed this is not the place
20:17:25Relos:sure, i said what I wanted to say anyway in regards to actually analysisng the nodes, why anyone runs them, and how they may be increased, so yeah, no point cluttering up the place
20:17:38Relos:wish gavinandresen could continue saying what he was
20:24:14warren:Relos: you seem to be missing the point that nobody is in favor of forever sticking to 1MB. The disagreement is how exactly to safely increase it, when, and if it will be something more future proofed than merely making the limit bigger once (guaranteeing more hardforks in the future).
20:46:00ortutay:ortutay has left #bitcoin-wizards
21:13:26binaryFate:oups sorry
21:15:37jae:jae is now known as Guest13900
23:00:39Guest77051:Guest77051 is now known as amiller_
23:01:05amiller_:amiller_ is now known as amiller
23:02:49wallet421:wallet421 is now known as wallet42