| 01:00:04 | c0rw1n: | c0rw1n is now known as c0rw|zZz |
| 02:13:17 | rusty: | dumb q: AFAICT it would be better to use input and output canonical seralization, rather than random permutation. What am I missing? |
| 02:13:53 | rusty: | (I'm thinking that a canonical ordering could be eventually enforced, whereas random can't be) |
| 02:14:12 | rusty: | I am referring to the order of tx inputs and outputs, in cas that wasnt' clear. |
| 02:49:11 | Guest95228: | Guest95228 is now known as luigi1111 |
| 03:13:21 | jae: | jae is now known as Guest23206 |
| 03:50:39 | frankenmint: | frankenmint has left #bitcoin-wizards |
| 03:53:15 | andytoshi: | rusty: i think you're correct, maybe this just hadn't occured to anyone |
| 03:53:23 | andytoshi: | (cue gmaxwell posting a bct post of his from 2010 describing exactly this) |
| 04:24:40 | jae: | jae is now known as Guest56899 |
| 04:34:12 | rusty: | andytoshi: thanks for sanity check. I'll get motivated RSN and write it up, w/ patch. |
| 06:08:33 | blackwraith: | blackwraith is now known as priidu |
| 06:14:07 | jae: | jae is now known as Guest58038 |
| 06:27:21 | Face900: | Face900 has left #bitcoin-wizards |
| 07:18:29 | waxwing: | www.anagram.com/jcrap/Volume_8/leakage.pdf |
| 07:18:38 | waxwing: | references Chicken so probably worth a look |
| 07:21:35 | justanotheruser: | Is there some significance to the word leakage? |
| 07:21:50 | fluffypony: | justanotheruser: yes |
| 07:22:01 | fluffypony: | from the seminal presentation on it |
| 07:22:18 | fluffypony: | "Leakage: leakage leakage; leakage, & leakage" |
| 07:22:30 | fluffypony: | https://www.youtube.com/watch?v=89K3j_Rsbco |
| 07:22:51 | justanotheruser: | is there some trend of information leakage papers being nonsensical? |
| 07:23:57 | fluffypony: | nah I think they were just taking the piss out of the Chicken thing |
| 07:24:28 | justanotheruser: | isn't that the same guy from the chicken paper? |
| 07:24:37 | justanotheruser: | s/paper/presentation/ |
| 08:05:16 | wilhelm.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:16 | wilhelm.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:16 | wilhelm.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:16 | wilhelm.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:16 | wilhelm.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:16 | wilhelm.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:54 | gmaxwell: | does the leakage paper encode another paper in typesetting modulation? |
| 08:11:03 | vonzipper_: | vonzipper_ is now known as vonzipper |
| 08:11:30 | jbenet_: | jbenet_ is now known as jbenet |
| 08:29:48 | nsh: | * nsh smiles |
| 09:19:11 | wallet421: | wallet421 is now known as wallet42 |
| 09:39:39 | waxwing: | justanotheruser: the author is of course our lord and saviour: https://twitter.com/dchest/status/604410816675323904 |
| 09:49:05 | wallet421: | wallet421 is now known as wallet42 |
| 10:07:52 | nsh: | * nsh chants Djah-b, Cryptofari! |
| 10:19:12 | rustyn_: | rustyn_ is now known as rustyn |
| 10:21:31 | _mm_1: | _mm_1 is now known as mm_1 |
| 10:37:10 | hearn_: | hearn_ is now known as hearn |
| 11:22:12 | wallet421: | wallet421 is now known as wallet42 |
| 11:36:25 | luny`: | luny` is now known as luny |
| 12:31:23 | c0rw|zZz: | c0rw|zZz is now known as c0rw1n |
| 13:49:08 | helo_: | helo_ is now known as helo |
| 14:16:10 | frankenmint: | frankenmint has left #bitcoin-wizards |
| 15:28:20 | antanst: | antanst has left #bitcoin-wizards |
| 16:38:34 | Guyver2: | Guyver2 has left #bitcoin-wizards |
| 17:12:59 | blackwraith: | blackwraith is now known as priidu |
| 17:20:11 | StephenM347: | 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:57 | StephenM347: | 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:29 | StephenM347: | It seems like a simple vote doesn't add any assumptions about miners that aren't already in place. |
| 17:24:52 | andytoshi: | StephenM347: miner incentives are not aligned with the incentives of any other party in the network, at least re blocksize |
| 17:25:39 | andytoshi: | 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:28 | andytoshi: | 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:53 | jae: | jae is now known as Guest89542 |
| 17:30:25 | StephenM347: | 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:28 | StephenM347: | No matter what happens, miners are going to have to be involved in order to change the block size limit. |
| 17:31:08 | StephenM347: | So why not give it to them within the protocol? |
| 17:31:39 | StephenM347: | Rather than debating for aeons and then still requiring miners' approval. |
| 17:32:42 | andytoshi: | 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:40 | andytoshi: | 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:00 | andytoshi: | otherwise if they fork, they're just wasting power generating coins that nobody else recognizes |
| 17:35:39 | StephenM347: | andytoshi: requiring only miners' consent does seem to be a downside. |
| 17:36:09 | StephenM347: | and it's awfully hard to get the votes of users' included into a decentralized protocol |
| 17:36:19 | tromp_: | andytoshi: larger blocks could lead to lower avg fee per tx |
| 17:36:37 | kanzure: | votes are a completely wrong mechanism for that |
| 17:37:13 | kanzure: | andytoshi: they can effect hardforks by threatening to attack other chains, depending on their size |
| 17:44:39 | StephenM347: | 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:11 | andytoshi: | 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:24 | andytoshi: | 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:16 | andytoshi: | (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:57 | StephenM347: | 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:14 | wumpus: | andytoshi: "but this "either nothing changes forever or RIGHT NOW we must do something drastic" the tyranny of imagined necessity |
| 18:05:31 | StephenM347: | By times like these, I simply mean times when everyone is debating about changing a core characteristic of the bitcoin system |
| 18:06:16 | andytoshi: | 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:24 | andytoshi: | 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:00 | gmaxwell: | 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:14 | gmaxwell: | Especially since SPV clients cannot see the blocksize. |
| 18:08:37 | StephenM347: | 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:15 | gmaxwell: | StephenM347: technically most transactions involving bitcoin are already off the chain, via centeralized services (in exchanges) for better or worse. |
| 18:09:41 | gmaxwell: | Not becuase of a lack of space but because of things like instant confirmation. |
| 18:09:50 | StephenM347: | 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:50 | andytoshi: | 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:41 | gmaxwell: | 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:14 | gmaxwell: | (also it has resulted in the network being moderately broken, in that we do not have CPFP or (safe-mode)RBF universally deployed) |
| 18:12:56 | zooko: | clear |
| 18:12:57 | zooko: | oops |
| 18:13:26 | StephenM347: | 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:18 | wumpus: | 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:26 | StephenM347: | temporary in the sense that it buys us time, not in the sense that it will ever need to be reverted |
| 18:15:50 | gmaxwell: | 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:51 | wumpus: | more pressure may be better to actually get solutions out there |
| 18:15:56 | gmaxwell: | went dead once the limits were bumped. |
| 18:16:19 | hulkhogan_: | 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:22 | wumpus: | yes, all interest in them went away |
| 18:17:58 | gmaxwell: | 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:04 | gmaxwell: | 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:29 | StephenM347: | 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:36 | wumpus: | StephenM347: yes - this is what bitcoin core's wallet has done for a while |
| 18:20:37 | hulkhogan_: | 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:53 | gmaxwell: | 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:21:05 | gmaxwell: | gracefully* |
| 18:22:42 | gmaxwell: | 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:31 | gavinandresen: | 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:13 | kanzure: | you could do child-pays-for-parent there |
| 18:24:17 | kanzure: | without having to have everyone re-sign |
| 18:24:50 | gavinandresen: | 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:34 | gmaxwell: | 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:26 | gmaxwell: | * gmaxwell bbiab |
| 18:27:29 | gavinandresen: | 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:54 | kanzure: | same as what? |
| 18:28:06 | gavinandresen: | The "what happens when blocks are full" experiment. |
| 18:28:17 | gavinandresen: | Max size and size miners are choosing to create are not the same |
| 18:28:27 | hearn: | we know what happens already. it would be a waste of time. |
| 18:28:47 | gavinandresen: | hearn: I'm just trying to find consensus here..... |
| 18:28:58 | hearn: | we've hit soft limits before |
| 18:29:52 | hearn: | 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:18 | gavinandresen: | 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:44 | hearn: | 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:02 | hearn: | where by "my time" i mean "time of wallet developers around the world" of course |
| 18:32:26 | gavinandresen: | 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:10 | kanzure: | so the concern about increasingly higher average transaction fees is not related to the network failing to continue networking |
| 18:33:34 | kanzure: | 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:49 | andytoshi: | 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:06 | hearn: | andytoshi: then they have been addressed already |
| 19:00:01 | kanzure: | gavinandresen: could you describe a worst-case scenario that you could imagine for extremely high average transaction fees? |
| 19:02:52 | Relos: | wouldn't high transaction fees mean practically no privacy? |
| 19:03:29 | kanzure: | go on? |
| 19:03:50 | Relos: | well, you wouldn't be able to use mixing |
| 19:04:05 | Relos: | unless you pay some very high cost |
| 19:05:21 | Relos: | you wouldn't be able to use a new address, etc |
| 19:05:43 | Relos: | thus everyone would or could know how much you own etc and where you spend it, which is terrible |
| 19:06:01 | kanzure: | why would you be unable to use a new address? |
| 19:06:18 | Relos: | because high fee |
| 19:06:24 | kanzure: | can you be more specific? |
| 19:06:50 | hulkhogan_: | 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:12 | Relos: | 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:17 | Relos: | then how do I use mixing? |
| 19:07:39 | kanzure: | presumably they would continue working the same way, except you would type in a higher value for the transaction fee. |
| 19:07:53 | Relos: | yes, so pay a lot of money for privacy |
| 19:08:24 | gavinandresen: | 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:56 | hulkhogan_: | * hulkhogan_ is reminded to go over the lightning paper again |
| 19:09:25 | Relos: | and its not just privacy |
| 19:09:47 | Relos: | why would more people run a node than currently under a lightning network? |
| 19:09:51 | gavinandresen: | kanzure: worst case for high fees? Bitcoin dies a slow death as people abandon it for better options. |
| 19:10:18 | kanzure: | don't you think the average transaction fee would go down if there are zero transactions? |
| 19:10:26 | gavinandresen: | 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:28 | kanzure: | (like that seems related to the definition of average) |
| 19:10:30 | GAit: | 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:55 | Relos: | 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:00 | kanzure: | gavinandresen: unlocking your private key multiple times seems to be related to poor fee estimate, not the other thing |
| 19:11:07 | GAit: | gavinandresen: it wouldn't lock if we had RBF without limiter |
| 19:11:23 | kanzure: | whoops sorry i mean poor fee estimation |
| 19:11:42 | Relos: | therefore, the only way to increase node count is by increasing the number of people who have to run a node |
| 19:12:19 | Relos: | 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:40 | Relos: | 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:24 | kanzure: | gavinandresen: so it sounds like you are very interested in permanently low fees |
| 19:14:37 | Relos: | at 1mb I can see us loosing both privacy and decentralisation |
| 19:15:26 | gavinandresen: | 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:51 | kanzure: | 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:58 | gavinandresen: | kanzure: I think artificially limiting the block size in an attempt to ... what? maximize miner revenue? is a bad idea. |
| 19:16:33 | hulkhogan_: | 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:42 | hulkhogan_: | 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:42 | Relos: | 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:02 | gavinandresen: | 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:03 | Relos: | 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:06 | hulkhogan_: | not voluntary, but resource unfriendly (is myu take) |
| 19:18:34 | Relos: | its inconvenient and people won't do something inconvenient if they have the choice |
| 19:18:50 | Relos: | as we can currently see |
| 19:19:14 | gavinandresen: | Relos: how do you think you can force somebody to run a full node? |
| 19:19:14 | kanzure: | 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:20 | hulkhogan_: | 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:48 | Relos: | hulkhogan_: I am not talking about any utopia, I am referring to the current situation |
| 19:19:54 | kanzure: | 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:06 | hulkhogan_: | 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:08 | Relos: | runnin a node currently is practically free, yet out of some 2 million users only 5,000 do so |
| 19:20:12 | kanzure: | gavinandresen: and i think it would be helpful to me (and others) to reconcile this somehow |
| 19:20:27 | Relos: | I think from that we can inferre that only people who need to run a node do so |
| 19:20:33 | gavinandresen: | 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:33 | hulkhogan_: | Relos: its not free, it takes 30+GB (cheap, not free) plus bandwith and compute |
| 19:20:52 | Relos: | 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:57 | kanzure: | gavinandresen: my interests are very unusual and should not be relied on :-) |
| 19:21:16 | kanzure: | oh sorry |
| 19:21:18 | Relos: | 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:20 | kanzure: | you asked if there would be any interest |
| 19:21:42 | hulkhogan_: | 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:57 | kanzure: | gavinandresen: yes, i think that by definition if transactions are paying those, then someone is paying those fees.. |
| 19:21:58 | Relos: | 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:38 | Relos: | 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:43 | hulkhogan_: | curious as to where the assumption is coming from |
| 19:23:36 | Relos: | from the numbers |
| 19:23:48 | hulkhogan_: | 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:50 | Relos: | out of some estimated 5 million bitcoiners there are only 5,000 nodes |
| 19:24:05 | Relos: | I don't think so |
| 19:24:14 | kanzure: | 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:17 | Relos: | running a node is already pretty easy and as I say almost free |
| 19:24:28 | Relos: | people just don't want to do so because it is inconvenient |
| 19:24:41 | gavinandresen: | 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:44 | Relos: | why would anyone do something inconvenient, however slight, if they dont have to? |
| 19:25:01 | binaryatrocity: | 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:08 | kanzure: | 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:12 | hulkhogan_: | Relos: right, but forcing it on people doesn't seem like it would make things much smoother |
| 19:25:25 | gavinandresen: | 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:32 | hulkhogan_: | Relos: it would burden the user which might hamper adoption, usabilty |
| 19:25:48 | kanzure: | 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:56 | GAit: | 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:57 | skyraider: | 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:02 | Relos: | that burden being $6 per month which is less than a netflix subscription |
| 19:26:13 | skyraider: | blocks* |
| 19:26:18 | gavinandresen: | 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:38 | kanzure: | yes, you have mentioned "payment decentralization" before, e.g. "not using off-chain services or partial-chain services" i think |
| 19:26:40 | binaryatrocity: | Relos: where does your $6 a month estimate come from? |
| 19:26:45 | GAit: | number of full nodes is one of the metrics though and it has big impacts on SPV wallets too |
| 19:26:55 | hulkhogan_: | 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:33 | Relos: | hulkhogan_: running a node is already "expensive" to some people |
| 19:27:35 | hulkhogan_: | * hulkhogan_ forgets if mycelium wallet supports SPV |
| 19:27:42 | GAit: | hulkhogan_: i don't think so |
| 19:27:48 | Relos: | thats why i started the discussion by enquiring who is currently motivated to run a node? |
| 19:27:58 | skyraider: | Relos: regulated companies |
| 19:27:58 | GAit: | last i checked it connects directly to their servers |
| 19:28:01 | Relos: | obviously it is a tiny minority of all bitcoin users |
| 19:28:03 | GAit: | (or via tor) |
| 19:28:08 | Relos: | who are these node runners? |
| 19:28:11 | Relos: | probably miners |
| 19:28:15 | Relos: | probably businesses |
| 19:28:19 | kanzure: | 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:23 | GAit: | Relos: i run a few nodes in different continents |
| 19:28:32 | kanzure: | compel |
| 19:28:34 | Relos: | probably individuals who have to run a node |
| 19:28:41 | Relos: | or hobyists |
| 19:29:02 | gavinandresen: | kanzure: please stop arguing the "only companies can run" straw-man: http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized |
| 19:29:10 | Relos: | 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:23 | kanzure: | gavinandresen: i did not say that only companies can run nodes |
| 19:29:35 | Relos: | 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:46 | Relos: | node decentralisation* I should say |
| 19:30:06 | kanzure: | gavinandresen: i think though that if we want to scale to 10e12 transactions per second, centralization is the key |
| 19:30:10 | GAit: | 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:53 | hulkhogan_: | Relos i'm wondering how you would compel people to spin up a VPS at all :) |
| 19:31:00 | skyraider: | 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:02 | kanzure: | 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:13 | gavinandresen: | GAit: did you read the whole discussion? 20MB blocks would cost him something like $2 per day, hardly a crippling cost. |
| 19:31:22 | kanzure: | (to answer your "why would bigger blocks make bitcoin more valuable" question) |
| 19:31:51 | gavinandresen: | kanzure: yes, systems get more valuable the more people who use them. |
| 19:32:00 | gavinandresen: | .... if designed correctly, they get more robust, too... |
| 19:32:10 | kanzure: | well my ability to remember your statements has never been in question, you know :-) |
| 19:32:59 | GAit: | gavinandresen: it can only decrease node counts, that's for sure right? |
| 19:33:12 | Relos: | 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:01 | kanzure: | 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:03 | skyraider: | 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:03 | skyraider: | too. |
| 19:34:17 | gavinandresen: | 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:23 | Relos: | 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:59 | hulkhogan_: | 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:01 | skyraider: | off-chain transactions make a lot of sense for massive volumes |
| 19:35:12 | gavinandresen: | 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:49 | gavinandresen: | 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:20 | GAit: | 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:25 | hulkhogan_: | 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:38 | Relos: | how so? |
| 19:36:46 | Relos: | I'm describing the current situation |
| 19:36:53 | Relos: | or, at least I think I am |
| 19:37:17 | hulkhogan_: | 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:27 | GAit: | 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:29 | Relos: | which users? |
| 19:37:44 | Relos: | the persons who already only run a node because they have to? |
| 19:37:49 | hulkhogan_: | lets say SPV users, who are probably relying on 3rd parties for verification |
| 19:37:54 | Relos: | if they have to run a node they will run a node.... |
| 19:38:09 | Relos: | spv users wouldnt be affected by the blocksize |
| 19:38:20 | gavinandresen: | 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:26 | GAit: | Relos: if common users have to necessarily run a node to use bitcoin they'll just not use bitcoin |
| 19:38:26 | hulkhogan_: | ok, i thought we were addressing node count, oops |
| 19:38:45 | Relos: | I meant full nodes of course, sorry |
| 19:38:57 | Relos: | I wasn't referring to spv users |
| 19:39:12 | hulkhogan_: | 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:47 | Relos: | I think my point was fairly simple |
| 19:40:02 | hulkhogan_: | 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:02 | Relos: | I think that the people who currently run a node do so only because they have to |
| 19:40:11 | Relos: | they either miners |
| 19:40:14 | Relos: | businesses |
| 19:40:33 | hulkhogan_: | ya |
| 19:40:37 | Relos: | hobbyists, researchers, etc... people who basically don't mind the "inconvenience" or have to deal with it |
| 19:41:03 | Relos: | they will have to run a node under a cost of $6 per month too or 20 per month whatever |
| 19:41:13 | kanzure: | 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:14 | GAit: | 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:21 | Relos: | thus the only way to increase node decentralisation is to increase the number of people who have to run a node |
| 19:41:41 | Relos: | I can't see such increase under 1mb |
| 19:41:44 | gavinandresen: | GAit: http://gavinandresen.ninja/the-myth-of-not-full-blocks |
| 19:42:00 | hulkhogan_: | Relos: well why would the situation change with 20mb |
| 19:42:17 | Relos: | 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:17 | hulkhogan_: | [erhaps ive missed that |
| 19:42:27 | GAit: | gavinandresen: some wallets already support smartfee and even during peak traffic transaction work as smoothly as ever |
| 19:43:04 | GAit: | and you have to handle full blocks even at 20MB |
| 19:43:23 | kanzure: | this is all way too low signal for my taste |
| 19:43:54 | hulkhogan_: | 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:40 | Relos: | we already have those businesses |
| 19:44:48 | hulkhogan_: | i suppose i don't quite see how higher limit -> more buisness -> (confusing part) more businesses 'have to' run a node |
| 19:45:18 | wumpus: | 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:13 | Relos: | wumpus the problem is people don't want to run their own node even currently |
| 19:46:14 | hulkhogan_: | so wouldnt demand for those services go up? not too good at economics forecasts |
| 19:46:45 | wumpus: | Relos: if people don't want to run full nodes that's their own problem |
| 19:46:51 | wumpus: | Relos: it's about being able to. |
| 19:47:03 | Relos: | hulkhogan_ who do you think currently runs a node even under the current 1mb size? |
| 19:47:18 | kanzure: | wumpus: yes, forcing them to run nodes is just going to grow aminosity heh |
| 19:47:26 | Relos: | and bear in mind there are only 6k of them while there are 5 million users or so... |
| 19:47:33 | wumpus: | people that value privacy, security and trustlessness |
| 19:47:51 | Relos: | yes thats one part of them |
| 19:48:02 | Relos: | bot mostly it is probably miners |
| 19:48:11 | Relos: | who have to run a node |
| 19:48:15 | Relos: | who dont have a choice |
| 19:48:37 | wumpus: | 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:41 | Relos: | 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:10 | wumpus: | Relos: that's only because not enough disasters have happened with centralized services yet, people will learn |
| 19:50:12 | Relos: | thus an extra $6 per month, $10 or $20 I don't see how it will disuade any current node runner |
| 19:50:44 | hulkhogan_: | Relos: same folks you mentioned, most likely |
| 19:50:53 | Relos: | 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:08 | jae: | jae is now known as Guest88589 |
| 19:51:08 | Relos: | and I don't see why anyone would run a node under 1mb when most transactions are in hubs |
| 19:51:40 | wumpus: | 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:07 | Relos: | they already spending something on it...... |
| 19:52:20 | Relos: | why makes you think they would be disuaded by a netflix subscription? |
| 19:52:20 | wumpus: | bandwidth is quite expensive in some countries |
| 19:52:28 | Relos: | what* |
| 19:52:39 | wallet421: | wallet421 is now known as wallet42 |
| 19:52:57 | wumpus: | not everyone has a netflix subscription either (and that's something different anyway - it directly brings entertainment) |
| 19:53:11 | Relos: | not everyone can afford to eat lol |
| 19:53:14 | Relos: | what's your point |
| 19:53:46 | wumpus: | ... ok, bye |
| 19:59:28 | hulkhogan_: | * hulkhogan_ thinks there should be a #bitcoin-privacy chan |
| 20:02:02 | Relos: | 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:52 | helo: | without consensus, it would boil down to a PR battle and an eventual (fatal?) stubborn fork |
| 20:04:37 | Relos: | yes, but lets say XT wins, will gmaxwell and jgarzik then go with the longest chain |
| 20:04:48 | Relos: | or will they move onto other things? |
| 20:06:55 | maaku: | Relos: the "longest" chain doesn't matter |
| 20:07:28 | maaku: | in that scenario XT would be a totally different altcoin that happened to have more mining power than bitcoin |
| 20:07:44 | Relos: | and users, so core would be the altcoin |
| 20:07:58 | Relos: | and businesses, etc |
| 20:09:57 | maaku: | it would be better if this debate did not happen on -wizards |
| 20:10:55 | wumpus: | create a #bitcoin-blocksize chan or so, or just move it to #bitcoin |
| 20:14:16 | Relos: | yes....... ignore the debate right, because nothing needs to be done |
| 20:14:43 | maaku: | Relos: no one is ignoring anything. this is just not the right channel |
| 20:15:52 | hulkhogan_: | Relos I'll see you in #bitcoin-blocksize .. ;) |
| 20:16:17 | wumpus: | whether something needs to be done or not, contentless 'debate' doesn't move anything forward, and indeed this is not the place |
| 20:17:25 | Relos: | 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:38 | Relos: | wish gavinandresen could continue saying what he was |
| 20:24:14 | warren: | 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:00 | ortutay: | ortutay has left #bitcoin-wizards |
| 21:13:16 | binaryFate: | #bitcoin-fungibility |
| 21:13:26 | binaryFate: | oups sorry |
| 21:15:37 | jae: | jae is now known as Guest13900 |
| 23:00:39 | Guest77051: | Guest77051 is now known as amiller_ |
| 23:01:05 | amiller_: | amiller_ is now known as amiller |
| 23:02:49 | wallet421: | wallet421 is now known as wallet42 |