| 00:00:00 | gmaxwell: | Freenode's behavior is really crappy. They're super agressive with these broad bans that don't stop _that_ much abuse, and simultaniously powerless to stop a 14 year old kid with a botnet. Kind of worst of all worlds. Oh well. No use debating it here. |
| 00:01:19 | bramc: | gmaxwell:I told freenode to go fuck themselves after they blew away my account for having been inactive for too long and obliterated all permissions it had and were as a matter of policy unresponsive to attempts to fix it so that *somebody* had admin |
| 00:02:24 | bramc: | I was told afterwards that their reputation had long since gone into the gutter and a bunch of people had left freenode to form oftc |
| 00:03:05 | gmaxwell: | Gnome and Xiph.Org had moved off freenode onto an IRC network we created (that we ran for about a decade) because freenode staff interfeared with our fundraising meetings, trying to tell people they should _instead_ donate to freenode because it supports all these projects. |
| 00:03:18 | bramc: | I personally am perfectly well served using this here web interface |
| 00:03:26 | gmaxwell: | But in more recent times freenode has been better. |
| 00:03:28 | brisque: | I'd say I'd run a bitcoin-related IRC server, but I don't really think my mailbox would enjoy being stuffed with subpoenas every time someone does something moronic. |
| 00:03:53 | gmaxwell: | yea, running an IRC network sucks. I wouldn't recommend it. (having done so in the past!) |
| 00:04:00 | bsm117532: | There's always bitmessage |
| 00:04:03 | gmaxwell: | IRC protocol encourages abuse in a number of ways. |
| 00:04:06 | brisque: | bsm117532: haha |
| 00:05:41 | brisque: | bitmessage is.. not what I'd want to be using to communicate. |
| 00:06:17 | bramc: | The only problem with bitmessage is that it's public. OTR should fix that |
| 00:06:24 | bramc: | (that was a joke) |
| 00:07:56 | hearn: | group chat isn't that hard to implement. a version that used proofs-of-sacrifice to control abuse would be a fun project. |
| 00:07:59 | bsm117532: | Someone gets my jokes |
| 00:08:07 | bsm117532: | OTR is fucking cool too. |
| 00:08:32 | hearn: | of course getting people to use it would be hard. freenode is, well ..... free. |
| 00:08:35 | hearn: | and works well enough most of the time. |
| 00:08:39 | bramc: | Back on topic, there's a general consensus among developers that the way to scale bitcoin is with some kind of net settlement, either micropayment channels or sidechains or both |
| 00:08:41 | justanotheruser: | OTR should fix bitmessage? |
| 00:08:47 | justanotheruser: | doesn't its design prohibit OTR? |
| 00:09:12 | bramc: | justanotheruser:OTR can work over any asynchronous messaging channel |
| 00:10:12 | justanotheruser: | right, you could just flood otr messages. |
| 00:10:29 | bramc: | A funny thing about that consensus, which I agree with, is that it isn't explained very clearly anywhere, you have to go talk to bitcoin developers for a while to figure that out |
| 00:11:12 | hearn: | bramc: why do you think that is the consensus? i don't think gavin believes that, nor do i |
| 00:11:34 | bramc: | hearn:so what is your opinion of how scaling for bitcoin should be addressed? |
| 00:11:43 | hearn: | bramc: same as gavins. optimise optimise optimise. |
| 00:12:32 | bramc: | You can optimize and start charging real transaction fees. That will get you maybe an order of magnitude. |
| 00:13:17 | hearn: | just one? bitcoin already scaled through three orders of magnitude with the only real optimisations being SPV mode and internal optimisations in Core to make indexing faster (e.g. ultraprune) |
| 00:13:48 | bramc: | hearn:there's a hard limit on transactions per second because of the block size limit |
| 00:14:14 | hearn: | yes, obviously this discussion is assuming that is removed. |
| 00:14:30 | bramc: | I'm not assuming it's removed. I'm assuming it needs to be worked around. |
| 00:14:52 | hearn: | why? |
| 00:15:18 | bramc: | Because keeping running a full bitcoin node reasonably lightweight is important functionality |
| 00:16:07 | hearn: | go watch gavin's talk at the MIT conf that just happened |
| 00:16:37 | justanotheruser: | bramc: how is changing transaction fees a scaling improvemnet |
| 00:16:52 | bramc: | hearn:got a link for that? |
| 00:17:12 | bramc: | justanotheruser:it gets rid of spam garbage and gets people to do easy optimizations in their own stuff |
| 00:18:00 | skittylx: | bramc: https://www.youtube.com/watch?v=96ULlHhia_Q |
| 00:18:03 | skittylx: | first talk |
| 00:18:24 | hearn: | http://diyhpl.us/wiki/transcripts/mit-bitcoin-expo-2015/keynote-gavin-andresen/ |
| 00:20:10 | skittylx: | bramc: read peter todd's for contrast. http://diyhpl.us/wiki/transcripts/mit-bitcoin-expo-2015/peter-todd-scalability/ |
| 00:20:13 | bramc: | Thanks, I found it while y'all were posting |
| 00:22:34 | justanotheruser: | bramc: It only gets spammers to compete with transactors as they always have been? |
| 00:27:57 | jcorgan: | scalability is usually solved by an emergent hierarchy |
| 00:28:37 | jcorgan: | sidechains seem the first missing piece of the pie that would enable that |
| 00:33:04 | bramc: | jcorgan:micropayment channels can possibly do it as well |
| 00:33:33 | instagibbs: | scaling up (specifically increasing blocksize) is fraught with politics. Now with blockstream esp I'm guessing they are shy at weighing in quite as much |
| 00:33:51 | instagibbs: | probably why you don't see a ton of it from these guys. Peter isn't quite so shy |
| 00:34:36 | bramc: | justanotheruser:If a spammer wants to pay the transaction fees they can do that. Past tricks for getting the spam under control are things like making transactions for larger amounts of coin and older transactions take priority, which are obviously short-term hacks |
| 00:37:53 | bramc: | Reading Gavin's talk now. Can schnorr signatures even be done with a soft fork? |
| 00:38:16 | gmaxwell: | of course. |
| 00:38:22 | justanotheruser: | bramc: I don't understand your argument unless you think a higher ratio of transactors:spammers will pay high fees than low fees |
| 00:39:08 | instagibbs: | bramc: almost anything can be |
| 00:39:22 | instagibbs: | maybe not strictly true, but a lot more than I thought can |
| 00:39:59 | bramc: | justanotheruser:presumably the spam is of low value, so it would stop being done if transaction fees were higher |
| 00:40:35 | bramc: | justanotheruser:the block size limit can't be raised with a soft fork |
| 00:40:52 | justanotheruser: | was that 2nd messaged directed at me? |
| 00:41:30 | justanotheruser: | also, the block space limit can be raised with a softfork, however. |
| 00:41:44 | bramc: | I ask about schnorr signatures because it isn't obvious that old clients will even be able to parse at that point. I do need to read through the reference in detail though. |
| 00:42:08 | bramc: | Sorry, meant for that second message to be directed to instagibbsagibbs |
| 00:42:12 | instagibbs: | it's much like p2sh rollout, most likely. "free money" lying around, for some reason you can't take |
| 00:42:31 | brisque: | adding new signature types isn't a problem really, we could add OP_LAMPORTVERIFY if it was so desirable |
| 00:42:58 | brisque: | wouldn't work well with rampant key re-use in bitcoin, but it would operate just fine |
| 00:43:34 | justanotheruser: | bramc: I recommend reading BIP12 if you want to understand how the scripting system can basically be redefined in any way with a softfork including adding opcodes. |
| 00:43:36 | kanzure: | disclaimer: i make no claims of accuracy of those transcripts. often i replaced the speaker's opinions with my own when they were obviously broken. (well, not so often.) |
| 00:43:36 | bramc: | It's my impression that old clients flat reject too-big blocks without even parsing them, which would make raising that limit require a hard fork |
| 00:44:11 | instagibbs: | the block would be embedded, with miners rejecting blocks that don't have the correct block extension (my guess) |
| 00:44:21 | brisque: | bramc: reject and ban, yes. |
| 00:45:29 | gmaxwell: | bramc: technically the block size limit can be raised with a soft fork, though its quite ugly. |
| 00:45:53 | bramc: | kanzure:Do you use transcription software for this or do you type fast? |
| 00:46:08 | bramc: | Oh I see about the block size limit. That is ugly. Extremely ugly. |
| 00:46:56 | kanzure: | bramc: i type fast http://www.seanwrona.com/typeracer/profile.php?username=kanzure |
| 00:48:19 | bramc: | kanzure:those stats make my fingers hurt |
| 00:50:08 | justanotheruser: | kanzure: fake |
| 00:50:30 | phantomcircuit: | otherwise: don't run code from mixed security domains on the same hardware |
| 00:50:35 | phantomcircuit: | that's the winning answer for sure |
| 00:51:06 | bramc: | There are really two levels of soft fork. The harder one breaks SPV on older nodes |
| 00:51:33 | phantomcircuit: | gmaxwell, also lots of people holding these events have absolutely zero clue |
| 00:52:08 | instagibbs: | bramc: hm? you mean you'll miss out on funds? |
| 00:52:11 | brisque: | kanzure: damn, I can only get ~100 on a good day. |
| 00:52:44 | kanzure: | bramc: i definitely think there needs to be better public documentation about the known types and examples of variations on soft forks and hard forks. |
| 00:53:29 | bramc: | instagibbs:meaning an old node can't tell you what's spent any more. That would happen with a block size increasing 'soft' fork |
| 00:53:58 | instagibbs: | bramc: correct, spv nodes can already be hampered by lying through omission, this would just extend it in a sense |
| 00:55:11 | instagibbs: | I've been meaning to write something on it softforks, but havent gotten past a really rough writeup, busy with job search. maybe after |
| 00:56:42 | bramc: | Fixing the malleability problem properly would also be an extremely problematic 'soft' fork |
| 00:57:04 | instagibbs: | that's a conceptually "straight forward" one though |
| 00:57:40 | bramc: | instagibbs:except that it makes older nodes not even be able to tell where transactions are coming from |
| 00:57:50 | bramc: | Or what utxos have been spent, for that matter |
| 00:58:14 | bramc: | By 'properly' I mean start referring to transactions by the transaction id rather than the signature id |
| 00:59:30 | bramc: | Done with Gavin's talk. He's mixing together a whole bunch of things, all of which have theoretical limitations which can be worked out straightforwardly |
| 01:00:13 | bramc: | There are basic implementation things, which fall under the category of 'unix systems having limited inodes is not a good reason for having a political process around newsgroup creation' |
| 01:00:24 | bramc: | aka 'people should fix the damn servers' |
| 01:00:49 | bramc: | That also goes for how long it takes to download a complete blockchain. Pipelining over tcp ain't that hard. |
| 01:01:47 | bramc: | Then there are some things which get small constant factors, like schnorr signatures. |
| 01:02:42 | bramc: | Finally, there's raising the block size limit, which he gives some dubious justification for and no explanation of how to go about doing it (this whole soft/hard fork discussion isn't in there) |
| 01:03:51 | bramc: | Home net connections might be able to handle much larger bandwidth usage in the future, but net connections are increasing in size slowly, and the scaling size needed to not be a joke is at least two orders of magnitude |
| 01:04:49 | bramc: | On the flip side, things aren't very urgent. You can leave things as they are for a few years and nothing bad happens. |
| 01:05:38 | moa: | exponential growth can be deceptively non-intuitive, nothing is urgent until it is overwhelming |
| 01:07:14 | bramc: | Oh I just realized the justification behind that goofy ECC thing for blocks: It's for the blockchain relay network, which doesn't know state of anybody watching |
| 01:08:41 | bramc: | decentralization in bitcoin isn't going so well. Blocks are all coming off the relay network and more than half the 'real' transaction volume is coming from blockchain.info, which has everybody's keys stored on their servers |
| 01:09:30 | jcorgan: | meh |
| 01:10:11 | jcorgan: | the size of entities in bitcoin appears power law distributed |
| 01:10:27 | bramc: | moa: That's roughly my point. Expanding the block size right now isn't needed, and when it is needed that solution likely won't be enough. |
| 01:10:29 | jcorgan: | which is quite typical of industries in general |
| 01:11:18 | jcorgan: | and that sort of distribution emerges whenever there are independent agents and economies of scale |
| 01:12:15 | bramc: | jcorgan:Still alarming and problematic |
| 01:12:58 | jcorgan: | i'm not so worried. looking the way it does seems an indicator of its health. |
| 01:13:36 | kanzure: | bramc: did you also read http://diyhpl.us/wiki/transcripts/mit-bitcoin-expo-2015/peter-todd-scalability/ ? |
| 01:13:57 | bramc: | The lack of widespread adoption of heirarchical wallets is not a sign of health :-P |
| 01:14:04 | bramc: | kanzure:That's up next |
| 01:15:13 | brisque: | bramc: some fun trivia for you, in block height 346927 there were 760 transactions, 427 were made by blockchain.info. |
| 01:15:21 | amincd: | Increasing scale by 100X might not be enough for every person on Earth, but it would certainly expand the use-cases of Bitcoin, and potential size of the Bitcoin economy, which in turn can increase the capital and engineering mindshare dedicated to Bitcoin that could help come up with alternate scaling solutions (e.g. mphub network) |
| 01:16:26 | amincd: | It also makes Bitcoin a more attractive proposition to investors and major businesses (e.g. banks). A hard limit and no consensus on how/when to raise it is a source of uncertainty |
| 01:16:56 | brisque: | bramc: just manually looking through them, approximately 50-60% of all transactions at the moment based on the last few blocks. |
| 01:17:59 | kanzure: | hmm. suppose there was, for whatever reason, a miner that was trying to fork the network. and you wanted that miner to continue working on their fork (in vain), rather than attacking the other smaller less-hashrate-protected blockchain. on the miner-specific fork, everyone could just send the miner their BTC, in an attempt to make a larger incentive to that miner to not switch off of their fork. this might provide some protection to ... |
| 01:18:05 | kanzure: | ... the less-hashrate-participated blockchain? |
| 01:18:19 | bramc: | amincd: My point is that even increasing transaction volume by 100x can't be done just by increasing the block size for a while. People just don't have the bandwidth, and won't for over a decade. |
| 01:18:26 | kanzure: | this probably only works when the hashrates are already close though, if the gap is too big then even 0.1% of the attacker infrastructure/hashrate could cause lots of problem and no amount of incentives will prevent that |
| 01:19:06 | instagibbs: | bramc: Most of us agree with your prognosis. |
| 01:19:11 | bramc: | kanzure:In general random noise will cause one branch to win |
| 01:19:42 | instagibbs: | basic napkin math make it clear blocksize increases only get a tiny fraction of what you want, with questionable decentralization |
| 01:20:12 | bramc: | instagibbs:Good, that was my understanding. I'm surprised Gavin doesn't feel the same way. He didn't give numbers on exact rates of growth and specific times in the future though, so it's a little hard to tell what he's thinking. |
| 01:20:15 | moa: | bramc: right, at present 100MB blocks would almost assuredly ruin bitcoin |
| 01:20:43 | amincd: | bramc: Gavin's proposal is to increase the hard limit to 16.8 MB and then 40% every year thereafter. It'll get to 100 MB in about five years. And that's just the hard limit. It gives the Bitcoin community the option to go to 100 MB blocks, not the obligations. There are plenty of mechanisms to keep it below that size if broadband connection speeds don't grow fast enough |
| 01:20:57 | instagibbs: | bramc: for one, Gavin is really afraid of hitting the block size limit. This I think is coupled with his dislike of replace-by-fee |
| 01:21:25 | bramc: | instagibbs:That's odd. I view hitting the limit as an important experiment to run |
| 01:21:34 | instagibbs: | amincd: the current game theory suggests that miners will be forced to make larger and larger blocks to keep up with their competition |
| 01:22:01 | rusty: | bramc: Just because it's not sufficient doesn't mean it's not necessary. |
| 01:22:10 | kanzure: | instagibbs: you mean in the do-nothing case? |
| 01:22:13 | bramc: | How do we know how much of a problem scaling really is if we don't have a measurement of what the transaction costs are? |
| 01:22:23 | kanzure: | "scaling" |
| 01:22:28 | amincd: | instagibbs: I agree. I wrote this: http://amincd.tumblr.com/post/100736367493/the-economics-of-the-block-size But >50% can enforce a rule to keep blocks smaller |
| 01:22:55 | kanzure: | bramc: there are some known bottlenecks in a few places in the source code at the moment, if that's what you're asking about |
| 01:23:15 | instagibbs: | amincd: >50% of miners I assume. That's the issue. Including non-mining stakeholders |
| 01:23:44 | amincd: | instagibbs: yes, miners in control of >50% of the network hashrate. I really think it's a safe assumption that we can get that, if it's widely perceived to be healthy for the Bitcoin economy |
| 01:24:02 | bramc: | kanzure:I assume such things are there and somewhat embarrassing but entirely fixable |
| 01:24:59 | kanzure: | as far as i know, yeah |
| 01:25:04 | instagibbs: | amincd: I think it would be really damaging(confusing? energy-wasting?) to hardfork a higher limit, then later softfork a lower(which is what that is) |
| 01:26:17 | amincd: | instagibbs: the softfork can set the limit above whatever the average block size is. Historically the average block size has increased rather slowly, so we'll have plenty of 'warning' that it's increasing too fast, if it is. I acknowledge there are risks, but I think the risks of not setting Bitcoin to scale soon and fast and are greater. |
| 01:26:49 | instagibbs: | right so a rolling soft fork of some type |
| 01:26:53 | gmaxwell: | amincd: That doesn't make any sense to me. |
| 01:26:53 | bramc: | softforking to raise the block size limit shouldn't be mentioned so lightly. In some ways it would be more damaging than a hard fork to raise that limit. |
| 01:26:57 | instagibbs: | err |
| 01:27:37 | bramc: | rusty:Has Gavin clarified whether he's talking a hard or a soft fork? |
| 01:27:48 | gmaxwell: | amincd: Softfork is something miners can do unilatterly to the network, other users have no say in it. Miners have no reason to control the blocksize, they don't bare 99.99999% of the cost related to it. |
| 01:27:56 | gmaxwell: | bramc: he's not talking about a soft fork. |
| 01:28:00 | rusty: | bramc: it has to be a hard fork. |
| 01:28:21 | instagibbs: | rusty: as per earlier it doesnt have to be, but its hella ugly |
| 01:28:28 | gmaxwell: | rusty: it doesn't. But most people do not know this. Intentionally because whenever someone has brought it up on bct they've been asked to not promote it. |
| 01:28:38 | bramc: | Yeah there's this problem that a miner who makes a big block gets to keep all the transaction fees for it but doesn't bear any of the costs. |
| 01:28:48 | gmaxwell: | because as bramc notes, it's really ugly. |
| 01:29:47 | gmaxwell: | bramc: well they bare an infinitesmal fraction of the cost. (the cost in recieving the transactions once, and maybe the cost of transmitting them once-- depending on what transport optimizations are in play; and they'll have the same costs if another miner includes the txn so its hard to avoid them via policy anyways) |
| 01:30:23 | gmaxwell: | (I'm just being pedantic because I've found when I simplify that to nothing people argue with me that its not zero) |
| 01:30:26 | gmaxwell: | (as if that matters) |
| 01:30:59 | instagibbs: | you can say ~0 :P |
| 01:31:07 | instagibbs: | it's certainly not actually 0 |
| 01:31:16 | amincd: | gmaxwell: my assumption is that miners care about the overall health of the Bitcoin economy enough to defend decentralization. |
| 01:31:27 | jcorgan: | is the marginal risk for stale blocks anything consequential? |
| 01:32:05 | bramc: | jcorgan:larger blocks definitely increase the rate of stale blocks, but how much is unclear, a lot of it has to do with how centralized mining is |
| 01:32:11 | gmaxwell: | amincd: why would you say that? We can objectively see the exact opposite in the mining ecosystem today? There is enormous centeralization, and this is in spite of some pretty heroic efforts to limit it. |
| 01:33:02 | gmaxwell: | jcorgan: it's ~0 effect with the right transport protocol. (e.g. bluematt's relay protocol has to send only 2 bytes per each well relayed transaction a block includes) |
| 01:33:19 | gmaxwell: | Efficient set reconciliation protocols can potentially send even less. |
| 01:33:48 | bramc: | Yeah there's this unfortunate thing that larger blocks create yet even more incentive for mining pools, and mining pools are the ones who get to decide if the block size should be increased |
| 01:34:34 | gmaxwell: | bramc: right, well in the instance of soft-forking to control block size they do. Otherwise they're bounded by the network rules. |
| 01:34:40 | gmaxwell: | (at least on the upper side) |
| 01:34:41 | instagibbs: | bramc: we already give power over txn ordering. giving power over protocol, esp at expense of users, is frankly nuts |
| 01:35:07 | gmaxwell: | instagibbs: if we could avoid tx ordering power we certantly would, alas. :) |
| 01:35:37 | instagibbs: | did I tell you about my wonderful Darkcoin innovation (kidding kidding) |
| 01:35:55 | instagibbs: | scroll back if lost |
| 01:36:40 | bramc: | Gavin said that five or six people have push access to bitcoinj. Git lists eight. |
| 01:37:07 | gmaxwell: | The rest are NSA sockpuppets? |
| 01:37:11 | gmaxwell: | :P |
| 01:37:23 | amincd: | gmaxwell: so you believe pools would react to a request for a soft limit the same way they've reacted to increasing mining decentralization via P2Pool and getblocktemplate? If that's the case, then I'd have re-evaluate my assumptions. |
| 01:38:12 | gmaxwell: | amincd: I would give that something like 99% probablity. Especially if most users are on SPV clients (or even worse security model webwallets / centeralized services) and are thus personally feeling the pain. |
| 01:38:58 | gmaxwell: | Keep in mind the discussion here from two days ago where apparently there were people on stage at MIT loudy arguing (without counter apparently) that no commercial party should be running bitcoind themselves. |
| 01:39:24 | gmaxwell: | So not just miners ignoring calls to curb behavior (at a cost to the miners), but also the calls mostly not existing in the first place. |
| 01:40:14 | bramc: | gmaxwell:Given some of the questions from the audience I wonder how many people there even understand at the very most basic level what bitcoin is and does. |
| 01:40:50 | moa: | it's a worry |
| 01:40:55 | gmaxwell: | It hasn't been well communicated for sure, and there are lot of people who've basically built a business out of obfscuating that understanding. |
| 01:41:14 | amincd: | I sort of had this impression that the core developers had a close line of communication with the pool operators and had a lot of influence on them. I guess that's not the case |
| 01:41:24 | gmaxwell: | Unfortunately, as you've noted messaging around bitcoin is largely controlled by people who are focused on monetary policy. |
| 01:41:30 | gmaxwell: | amincd: this is not the case. |
| 01:41:33 | moa: | the "next layer" seems to be unaware of the foundations they are building upon |
| 01:42:04 | brisque: | flimsy moats. |
| 01:43:15 | gmaxwell: | amincd: a significant fraction of hashpower we know how to reach is more or less unresponsive. (e.g. we send an email saying there is an urgent risk of a network fork and we need a technical contact right away, and it gets ignored for two days and then we get a response back saying they'll have someone talk to us next week) |
| 01:43:35 | skittylx: | ^ |
| 01:43:43 | skittylx: | they wut mate |
| 01:43:52 | amincd: | gmaxwell: well that's not good |
| 01:44:08 | brisque: | who the hell knows who most of these large miners are now anyway |
| 01:44:12 | bramc: | Peter Todd started his talk by saying that SPV scales and talking about some of the challenges in making it more secure, which is true but besides the point |
| 01:44:18 | brisque: | bw.com sort of sprung out of nowhere and they own a lot of the network now |
| 01:47:05 | bramc: | Then he mentions net settlement (which is what I was just advocating) and talks about sharding. Sharding makes me cringe. |
| 01:48:43 | bramc: | The problem with sharding is (a) doing it right requires a reorg of how blocks work, (b) it gets you a small constant factor hit immediately, and most importantly (c) it has trust issues which nobody knows what to do about |
| 01:49:09 | bramc: | 'optimizing bubble sort' is a good line though |
| 01:49:23 | instagibbs: | bramc: i assume you've read of his treechains idea? I'd start with that as an idea how it might work |
| 01:50:01 | instagibbs: | it at least answers how things would be ordered/reordered, etc, if perhaps not satisfactorily |
| 01:51:32 | bramc: | instagibbs:No I'll add that to my list of crap to read |
| 01:53:54 | phantomcircuit: | bramc, sharding? |
| 01:54:30 | bramc: | phantomcircuit:The idea behind sharding is that not everybody has everything |
| 01:55:13 | phantomcircuit: | bramc, oh |
| 01:55:28 | phantomcircuit: | bramc, that's fine and possibly preferable as long as everybody sees everything once |
| 01:55:35 | phantomcircuit: | but obviously hard to get right |
| 01:55:51 | bramc: | phantomcircuit:Well if they have to see it all once it defeats the purpose because they need to use the bandwidth to transfer it anyway |
| 01:56:10 | instagibbs: | the benefit is not seeing everything at once |
| 01:56:22 | phantomcircuit: | bramc, huh? |
| 01:56:43 | phantomcircuit: | lets use a mobile phone as an example |
| 01:57:05 | phantomcircuit: | it's not unreasonable to download and discard the entire blockchain on a phone over wifi |
| 01:57:07 | instagibbs: | we could use bitcoin as an example |
| 01:57:24 | phantomcircuit: | most of the consensus checks are cheap |
| 01:57:44 | instagibbs: | but you needed to process all the data |
| 01:57:55 | bramc: | phantomcircuit:That's a bit ridiculous even today, but the discussion of sharding was in the context of scaling bitcoin in the future |
| 01:58:00 | instagibbs: | (excluding SPV which is trusting miners to do their job) |
| 01:59:01 | bramc: | If you're checking a complete block chain it's fairly reasonable to not do much checks on older stuff as long as the work difficulties of the later blocks check out. |
| 02:00:34 | bramc: | And work difficulty is of course utterly trivial in bitcoin. Not so much in some altcoins. |
| 02:00:55 | jcorgan: | sometimes i think bitcoin is better described as "programmable trust" |
| 02:00:59 | instagibbs: | If you could magically shard Bitcoin, it'd be obvious why you'd do it though. You could ramp up Bitcoin 1000x with no increased difficulty of running a fully validating node. |
| 02:01:13 | phantomcircuit: | bramc, actually downloading but not saving the entire blockchain on a phone is entirely reasonable today |
| 02:01:28 | gmaxwell: | instagibbs: magic is nice like that. |
| 02:01:31 | phantomcircuit: | you can even run the signature checks for the last say 2016*4 blocks without it taking too long |
| 02:02:02 | instagibbs: | clearly impossible. Just trying to point out the obvious benefit if possible |
| 02:02:06 | moa: | jcorgan: it's somewhat like a trusted virtual grid machine |
| 02:02:29 | instagibbs: | simply saying "well <1MB blocks are easy" kind of missing the long term goal of such an idea |
| 02:03:03 | jcorgan: | moa: i mean, the various wallet designs are really differentiated by who you have to trust to not screw you. |
| 02:03:27 | jcorgan: | fully validating is less trusting then spv is less trusting the webwallet, etc. |
| 02:03:53 | bramc: | If you're designing from scratch you can make each block point to a root of the whole utxo set instead of a data structure containing the new stuff |
| 02:04:00 | bramc: | That shards trivially but... ugh... |
| 02:04:07 | phantomcircuit: | instagibbs, i dont think anybody whose opposed to increasing the block size limit is missing the point... |
| 02:04:10 | phantomcircuit: | ditto sharding |
| 02:04:12 | jcorgan: | and at the root of the trust spectrum is trusting the properties of math |
| 02:04:35 | Luke-Jr: | anyone mind if I redirect vmatekole? |
| 02:04:36 | instagibbs: | We must be talking past each other then. |
| 02:04:44 | phantomcircuit: | Luke-Jr, please do |
| 02:04:58 | gmaxwell: | jcorgan: complicated by the fact that objectively people make bad trust decisions, and as a whole ecosystem other people's bad decisions also effect you. |
| 02:05:07 | phantomcircuit: | bramc, iirc there's significant performance issues with that |
| 02:05:09 | instagibbs: | I'm not advocating a block size increase(??) |
| 02:05:17 | phantomcircuit: | (i totally could be wrong there) |
| 02:05:28 | bramc: | phantomcircuit:Correct, hence my ugh |
| 02:05:30 | gmaxwell: | (there was a nice study where someone stood on a street corner and bought people's SSN/name/dob/address for pieces of candy or something like that :) ) |
| 02:06:22 | moa: | study by google? |
| 02:06:43 | bramc: | moa: not sure what you're asking |
| 02:06:46 | gmaxwell: | hah no some academic study, but I suppose google is pretty much an example of that every day. |
| 02:07:51 | gmaxwell: | has anyone here developed a yubikey neo applet? |
| 02:12:27 | copumpkin: | neo :O |
| 02:12:39 | copumpkin: | I played with their U2F thing |
| 02:14:18 | phantomcircuit: | gmaxwell, no but i believe it's just a standard javacard |
| 02:14:35 | phantomcircuit: | iirc you have to use their tools to switch it from the normal mode to the javacard mode |
| 04:37:33 | FoxDay: | FoxDay has left #bitcoin-wizards |
| 04:49:28 | petertodd: | "softforking to raise the block size limit" <- oh, via how you can fool a SPV node into accepting a merkle path that includes a minimally-sized transaction part way because the hashing algorithm for inner nodes is the same as transactions? |
| 04:53:00 | petertodd: | we can after all soft-fork *out* that ability |
| 04:54:24 | gmaxwell: | petertodd: no, by commiting to more block data in a block, and enforcing new rules in that block data in all further blocks, and by (optionally) censoring all normal transactions in the regular blocks. |
| 04:55:12 | petertodd: | gmaxwell: well, that requires SPV nodes to change - not terribly interesting, and kinda obvious |
| 04:59:22 | gmaxwell: | petertodd: sure. but they don't get a choice. |
| 04:59:49 | petertodd: | gmaxwell: yeah, but that's still way more politically disruptive than my version |
| 05:00:43 | gmaxwell: | As it stands spv nodes don't enforce blocksize at all, so one need not even do that much; just hardfork to softfork a blocksize change on spv nodes... |
| 05:03:32 | petertodd: | gmaxwell: sure, but like I say, in my horrid scheme it really is a soft-fork |
| 05:05:32 | phantomcircuit: | gmaxwell: sure, but like I say, in my horrid scheme it really is a soft-fork |
| 05:29:33 | petertodd: | so basically a minimal valid transaction is < 64 bytes, which lets the following 64-byte tx be valid: b2x(CTransaction([CTxIn(COutPoint(b'\00'*32,0xaaaaaaaa),nSequence=0xbbbbbbbb)],[CTxOut(0xcccccccc,CScript(b'\xdd'*4))],nLockTime=0xeeeeeeee).serialize()) -> 01000000010000000000000000000000000000000000000000000000000000000000000000aaaaaaaa00bbbbbbbb01cccccccc0000000004ddddddddeeeeeeee |
| 05:29:54 | petertodd: | or just the second 32 bytes: 0000000000aaaaaaaa00bbbbbbbb01cccccccc0000000004ddddddddeeeeeeee |
| 05:33:54 | petertodd: | in the above naively we have about 20 bytes that we can pick freely, leaving 12 bytes to brute force, and with a whole pile of txouts to choose from and/or shitloads of btc, we can get that down to ~8 bytes to brute force |
| 05:34:49 | petertodd: | (I had remembered nSequence being *after* prevout in the serialization; it's before which makes the above scheme probably unfeasible... if it were after this would probably actually be practical :/) |
| 05:52:36 | phantomcircuit: | petertodd, is a no output tx valid? |
| 05:53:59 | brisque: | phantomcircuit: no, that's invalid |
| 06:21:59 | fanquake: | fanquake has left #bitcoin-wizards |
| 08:05:17 | tepper.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:17 | tepper.freenode.net: | Users on #bitcoin-wizards: andy-logbot rusty OneFixt zooko cbeams RoboTeddy Dr-G2 adam3us1 lclc_ Logicwax hktud0 kyletorpey coiner midnightmagic GAit p15 mkarrer prodatalab jcorgan d1ggy Starduster Pan0ram1x justanotheruser nuke1989 waxwing PaulCapestany Emcy shesek devrandom crescendo stevenroose dc17523be3 arubi wizkid057 nessence p15x_ embicoin maraoz antgreen bosma grandmaster c0rw1n harrow SDCDev Cory otoburb spinza binaryatrocity copumpkin wumpus jaekwon sneak |
| 08:05:17 | tepper.freenode.net: | Users on #bitcoin-wizards: kinlo huseby GreenIsMyPepper phantomcircuit jgarzik cryptowest BlueMatt luny melvster jaromil espes__ tromp_ dgenr8 Apocalyptic gwillen dasource alferz bbrittain fenn gribble hashtag_ amincd HM2 prepost tromp ahmed_ eordano nickler Alanius face PRab BananaLotus guruvan ryan-c MoALTz lnovy DoctorBTC adlai sipa Luke-Jr amiller ebfull cluckj brisque cfields sdaftuar veorq coryfields helo Hunger- xabbix burcin runeks null_radix bedeho gmaxwell |
| 08:05:17 | tepper.freenode.net: | Users on #bitcoin-wizards: SwedFTP LarsLarsen epscy nanotube andytoshi bliljerk101 starsoccer comboy nsh Taek iddo EasyAt maaku btcdrak NikolaiToryzin s1w Visheate livegnik optimator fluffypony Meeh cursive yoleaux dansmith_btc [d__d] berndj morcos Fistful_of_Coins dardasaba isis airbreather smooth ajweiss Xzibit17 yrashk artifexd Zouppen kumavis mariorz catcow Krellan michagogo Muis platinuum Oizopower catlasshrugged Keefe JonTitor petertodd kanzure eric mappum jbenet |
| 08:05:17 | tepper.freenode.net: | Users on #bitcoin-wizards: wiz heath gnusha warren Adrian_G Iriez lechuga_ dignork jessepollak Graet Eliel veox warptangent indolering K1773R TD-Linux leakypat CryptOprah Anduck a5m0 d9b4bef9 mr_burdell NeatBasis davout brand0 @ChanServ BrainOverfl0w roasbeef phedny so hguux__ MRL-Relay azariah btc___ throughnothing |
| 11:04:05 | xenog: | xenog is now known as Guest64996 |
| 11:45:40 | xenog_: | xenog_ is now known as xenog |
| 12:39:32 | petertodd: | phantomcircuit: unfortunately, or my whacky trick would be a lot more feasible... and re-reading this with a lower BAC, no, the thing that would make it very feasible would be in nValue was a variable-length integer, not a fixed 8-bytes integer... but in any case, the fact that it's possible at all again just shows that you really should use different hashing algorithms for inner nodes and leaf nodes in merkle trees (easy to do with HMAC) |
| 12:52:50 | brisque: | petertodd: somehow I don't think the ballmer peak applies to cryptography. |
| 13:37:53 | Adrian_G: | Adrian_G is now known as AdrianG |
| 15:55:14 | kanzure: | ""It harms decentralization" is not a valid argument without some way to determine what the optimal level of decentralization is; otherwise who's to say we shouldn't have an even smaller blocksize limit than we do now." |
| 15:55:19 | kanzure: | yeah i haven't thought about whether smaller would work |
| 16:17:37 | instagibbs: | Well, it's plausible we are in a fairly flat area in our parameter space wrt decentralization. But we have no real idea what the function really is, other than some untested hypothesis. We know what it looks like roughly at 1MB, and it isn't that encouraging. |
| 16:18:38 | kanzure: | smaller block sizes would be interesting in the short-term because we could experiment with what the results of hitting a block size limit would look like |
| 16:19:08 | kanzure: | and since we already know that these limits can be increased to 1 MB (sort of....), that sort of experiment is unlikely to completely break the network in terms of storage space and node participation |
| 16:19:30 | kanzure: | at least, it is less likely to break the network in the same way that 50000 GB average block size would :-) |
| 16:21:29 | instagibbs: | I'd argue the current centralization has very little to do with the current blocksize but to ignorance and the early non-commodity ASIC phenomena, but I could be wrong, and increasing blocksize does nothing to fix these issues. |
| 16:21:44 | sipa: | there are various forms of centralization |
| 16:21:51 | sipa: | they are not all related |
| 16:22:24 | sipa: | miner centralization is different from independent-parties-running-full-nodes centralization, is different from humans-able-to-interact-on-the-blockchain centralization |
| 16:22:29 | kanzure: | right, i was only suggesting a smaller blocksize to see what block size limits being reached means |
| 16:22:35 | instagibbs: | well... they're related... as in you break one completely you break the whole thing :P |
| 16:22:45 | instagibbs: | totally agreed though |
| 16:22:56 | kanzure: | was there a specific technical concern about network breakage if block size limits are reached consistently? |
| 16:24:18 | instagibbs: | 1MB access limit to the blockchain is clearly not today's limiting factor though, so I don't think it plays into anything |
| 16:24:44 | kanzure: | right, we could reduce that to 0.25 MB and get some data, whereas increasing to 400 TB per block to get some data would be catastrophic |
| 16:25:27 | justanotheruser: | I would argue the optimal amount of decentralization is the amount that allows bitcoin to provide the most utility in terms of number of transactions, volume of transactions and safety of those transactions |
| 16:25:48 | sipa: | that's very vague |
| 16:26:05 | instagibbs: | justanotheruser: that doesn't map anything to do with being able to mine, for example |
| 16:26:21 | sipa: | a tiny blockchain where every pocket calculator in the world can validate the chain isn't useful |
| 16:26:44 | sipa: | (inter bank transfers are far superior for that use case) |
| 16:27:07 | sipa: | and a huge blockchain where only google-sized datacenters can can validate the chain isn't useful |
| 16:27:14 | justanotheruser: | sipa: there isn't an easy way to define what the block size should be in terms of those three parameters |
| 16:27:25 | sipa: | (we could just go back to trusting visa to process our transactions) |
| 16:27:31 | justanotheruser: | you can try estimating though |
| 16:27:37 | sipa: | so there is a balance between those, and IMHO, there are multiple possible balances |
| 16:27:38 | instagibbs: | every user has to decide for himself an lobby :/ which is why this discussion is hard |
| 16:27:45 | sipa: | and there is no right choice |
| 16:27:51 | sipa: | it depends what we want to use bitcoin for |
| 16:28:23 | sipa: | increasing the "range" of usecases is probably objectively useful |
| 16:29:42 | instagibbs: | writing out the list of "bitcoin should be able to do these strictly on chain" would be helpful. Lots of people have quite vague or impossible notions |
| 16:30:11 | sipa: | worse, people don't realize that all of them are a tradeoff |
| 16:32:47 | instagibbs: | To backup, people need to decide if hitting max blocksize is a crisis to be avoided at all costs, natural state of function long-term, or an interesting experiment. A lot of this rhetorical haste appears to derive from this. |
| 16:51:53 | amiller: | does anyone know of any tools for doing blockchain analysis |
| 16:52:16 | amiller: | like, i know i can parse the blockchain using bitcoinj or python-bitcoinlib or that little c tool |
| 16:52:36 | amiller: | but i dunno, something that makes some kind of database i can do graph queries on or something? |
| 16:52:56 | adlai: | do you mean tools for querying a local blockchain, or services that let you query their digested/indexed blockchain? |
| 16:53:29 | amiller: | querying a local blockchian |
| 16:53:41 | adlai: | familiar with jratcliffe's tools? |
| 16:53:42 | hearn: | there are companies that have built such tools |
| 16:53:45 | hearn: | and academics |
| 16:54:05 | hearn: | there is a woman at a university in london who has built/got access to some kind of graph db analysis tool, i forgot her name |
| 16:54:39 | hearn: | amiller: otherwise plugging bitcoinj into a graph database like neo4j or hypergraphdb would not be very hard, i think |
| 16:54:54 | adlai: | https://code.google.com/p/blockchain/ |
| 16:59:11 | maaku: | amiller: i am very surprised that no one has modified bitcoind to replace LevelDB with |
| 16:59:34 | maaku: | that way you'd just keep a daemon running and it populates the database |
| 16:59:56 | sipa: | all you'd get is a utxo set, though |
| 17:00:03 | amiller: | not with tx-index turned on? |
| 17:00:18 | sipa: | right, with txindex you get more, but it's hardly optimized for that |
| 17:02:46 | kanzure: | amiller: https://github.com/monetizeio/sqlalchemy-bitcoin |
| 17:04:05 | hearn: | maaku: bitcoinj has UTXO store engines for mysql, postgres, h2 and someone has contributed a leveldb one but it's not merged yet |
| 17:04:14 | hearn: | maaku: however they only index the UTXO set, not the entire chain. |
| 17:04:18 | MRL-Relay: | [tacotime] we're working hard to make btcd database agnostic, too. |
| 17:04:22 | hearn: | maaku: but really for what amiller wants, you want a graph db |
| 18:13:35 | gmaxwell: | I don't think that 1MB is big enough, which makes it hard to come to terms with the fact that the best observations we have about behavior at the moment suggest that 1MB may be too large to be sustainable in a decenteralized system. I am still hopeful that immediately pending improvements turn the tides on full node deployments. |
| 18:22:03 | tromp: | possibly off-topic: latest Ethereum PoW revision at https://github.com/ethereum/wiki/wiki/Ethash |
| 18:23:09 | hearn: | yet another pow? |
| 18:23:32 | tromp: | not radically different, they just keep tweaking it |
| 18:23:36 | sipa: | we need a popow |
| 18:23:43 | sipa: | proof of pow |
| 18:25:56 | hearn: | gmaxwell: is anyone working on pruning at the p2p protocol level? |
| 18:31:35 | instagibbs: | you mean pruned nodes advertising blocks? |
| 18:32:04 | hearn: | yes |
| 18:32:20 | hearn: | ah, i found the latest autoprune patch |
| 18:32:22 | hearn: | seems it's not done yet |
| 18:32:25 | sipa: | someone should work on that, yes |
| 18:32:32 | instagibbs: | suspicion is "no" |
| 18:32:33 | sipa: | there have been proposals in the past |
| 18:35:46 | kanzure: | gmaxwell: i think instead of "the best observations we have about behavior" you mean "the best conclusions we could possibly derive from these observations"? changes meaning a little bit: one is a comment about what observations and explanations we can give, the other is a possibly more limited comment about material evidence. anyway, just a minor nitpick. |
| 18:36:45 | waxwing__: | waxwing__ is now known as waxwing |
| 18:37:38 | kanzure: | gmaxwell: personally i think it is excellent that we can lower the block size. that gives us something to test that we can be more strongly convinced wont cause the network to come to a complete halt. (although i haven't contemplated any sort of traps this might be equivalent to, so no claims as to whether it is perfectly better or not) |
| 19:10:16 | jtimon: | with a smaller block size we may also see more fee competition? |
| 19:19:38 | Luke-Jr: | jtimon: inherently. that's a miner topic though, not development ;) |
| 19:19:59 | Luke-Jr: | (if you mean below 1 MB) |
| 19:40:56 | jtimon: | Luke-Jr do you know the aswer to my question in #bitcoin-dev ? |
| 19:57:41 | Luke-Jr: | jtimon: no |
| 20:13:10 | phantomcircuit: | I don't think that 1MB is big enough |
| 20:13:26 | phantomcircuit: | the correct blocksize is the larger blocksize which doesn't cause centralization pressure |
| 20:13:48 | phantomcircuit: | empirically we're seeming a bit of centralization pressure even now with blocks that are largely less than 1MB |
| 20:13:59 | phantomcircuit: | largest* |
| 20:34:56 | MRL-Relay: | [tacotime] I think *=2 every 18 months is okay... and I'm more or less okay with Bitcoin being a FEDWIRE replacement. You can use sidechains/altchains as micropayment channels. |
| 20:37:55 | MRL-Relay: | [tacotime] Curious to see what the heck happens with Monero's network if it actually gets real use, since we still have adaptive block sizing. |
| 20:38:36 | MRL-Relay: | [tacotime] (Will miners abuse it to drive fees insanely high? Etc) |
| 21:25:38 | amincd: | phantomcircuit: "the correct blocksize is the larger blocksize which doesn't cause centralization pressure" I think that needs some qualifiers. Centralization pressure up to some point doesn't reach the tipping point of making Bitcoin easy to regulate. I think we're far from that point i.e. we can afford a lot more centralization pressure. |
| 21:25:59 | amincd: | what that point is I have no idea |
| 21:27:22 | amincd: | and 'regulate' is somewhat of a euphemism. Let's call it what it is: banning unrestricted hosting of a Bitcoin node |
| 21:28:18 | smooth: | im not convinced the current centralization pressure is significantly based on block size at all |
| 21:28:50 | smooth: | what matters is not centralization but the derivative of centralization with respect to block size |
| 21:43:29 | amincd: | A larger block size could conceivably lead to a higher full node count, if it allows for a larger Bitcoin userbase. A thought experiment demonstrates this: a Bitcoin with a 1 KB block size would have very light full nodes, yet we wouldn't expect the full node count to increase. Instead the Bitcoin economy would be non-existent, and very few people care to run a full node. |
| 21:43:56 | sipa: | i also think the full node count is totally.irrelevant |
| 21:44:35 | sipa: | the question is how easy it is for independent interested parties to run one |
| 21:44:53 | sipa: | how many actually obviously depends on the usefulness of the network it supports |
| 21:45:01 | smooth: | a clear defintion of 'centralization' would help |
| 21:45:33 | smooth: | i think almost literally every single person who uses the term means something different |
| 21:45:52 | sipa: | decentralization is just a means to an end |
| 21:46:05 | amincd: | The end being censorship resistancfe |
| 21:46:25 | sipa: | that's one goal |
| 21:46:28 | smooth: | still more fuzziness: people have different ideas of a the desirable end |
| 21:46:49 | sipa: | another is having a currency where nobody can cheat |
| 21:47:25 | sipa: | it doesn't matter whether anyone runs a full node |
| 21:47:32 | sipa: | in that view |
| 21:47:39 | sipa: | just that i can run one if i want to |
| 21:50:17 | amincd: | so independence for trusted third parties |
| 21:50:24 | sipa: | yes, trustlessness |
| 21:50:37 | sipa: | which is imho more important than decentralization |
| 21:50:54 | amincd: | *independence from |
| 21:51:08 | sipa: | both are fuzzy terms of course |
| 21:51:13 | sipa: | as they are not absolute |
| 21:51:23 | hearn: | as a wallet developer, "enough" means "enough capacity to serve all SPV clients that want to be served, quickly" |
| 21:51:58 | sipa: | right, there is an actual service they provide to others as well |
| 21:52:21 | sipa: | that's of course relevant, but imho easier to satisfy |
| 21:53:31 | sipa: | anyway, zZzZ |
| 22:06:50 | amincd: | I would submit that the 'sweet spot' for the block size, assuming blocks are filled with 'legitimate' transactions (UTXOs that are economically spendable), is likely the maximum size that still allows a significant (a fuzzy term) subset of the population to run a full node without upgrading their storage or bandwidth, i.e. by using only spare capacity. They may choose not to run a full node, but millions having the *ability* |
| 22:07:19 | amincd: | fficulty is an effective check on centralization abuse |
| 22:07:54 | hearn: | if all you care about is checking/auditing, it can be done probabilistically |
| 22:08:10 | hearn: | that is you can fit a "somewhat full" node into almost any kind of hardware. in the worst case it degrades to full SPV. |
| 22:08:14 | hearn: | in the best case it's like a full node today. |
| 23:20:02 | gmaxwell: | phantomcircuit: I agree with that in principle, but the carrying capacity for people on earth goes only so high. So I think that independant of whatever admissable limit there is, there is also a pratical size at which no more is helpful. |
| 23:20:36 | gmaxwell: | And what I was intending to express was the obvious point that 1MB isn't that number, at least not in the long run assuming Bitcoin continues to become more widely used. |
| 23:20:58 | hearn: | MAX_BLOCK_SIZE = fn(get_global_population()) |
| 23:27:32 | justanotheruser: | can get_global_population ask me? |
| 23:28:37 | gmaxwell: | return 4; //chosen by fair random dice roll |
| 23:47:32 | Pasha: | Pasha is now known as Cory |
| 23:51:39 | maaku: | 4MB sounds good to me! |