00:00:00gmaxwell: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:19bramc: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:24bramc: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:05gmaxwell: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:18bramc:I personally am perfectly well served using this here web interface
00:03:26gmaxwell:But in more recent times freenode has been better.
00:03:28brisque: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:53gmaxwell:yea, running an IRC network sucks. I wouldn't recommend it. (having done so in the past!)
00:04:00bsm117532:There's always bitmessage
00:04:03gmaxwell:IRC protocol encourages abuse in a number of ways.
00:04:06brisque:bsm117532: haha
00:05:41brisque:bitmessage is.. not what I'd want to be using to communicate.
00:06:17bramc:The only problem with bitmessage is that it's public. OTR should fix that
00:06:24bramc:(that was a joke)
00:07:56hearn: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:59bsm117532:Someone gets my jokes
00:08:07bsm117532:OTR is fucking cool too.
00:08:32hearn:of course getting people to use it would be hard. freenode is, well ..... free.
00:08:35hearn:and works well enough most of the time.
00:08:39bramc: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:41justanotheruser:OTR should fix bitmessage?
00:08:47justanotheruser:doesn't its design prohibit OTR?
00:09:12bramc:justanotheruser:OTR can work over any asynchronous messaging channel
00:10:12justanotheruser:right, you could just flood otr messages.
00:10:29bramc: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:12hearn:bramc: why do you think that is the consensus? i don't think gavin believes that, nor do i
00:11:34bramc:hearn:so what is your opinion of how scaling for bitcoin should be addressed?
00:11:43hearn:bramc: same as gavins. optimise optimise optimise.
00:12:32bramc:You can optimize and start charging real transaction fees. That will get you maybe an order of magnitude.
00:13:17hearn: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:48bramc:hearn:there's a hard limit on transactions per second because of the block size limit
00:14:14hearn:yes, obviously this discussion is assuming that is removed.
00:14:30bramc:I'm not assuming it's removed. I'm assuming it needs to be worked around.
00:15:18bramc:Because keeping running a full bitcoin node reasonably lightweight is important functionality
00:16:07hearn:go watch gavin's talk at the MIT conf that just happened
00:16:37justanotheruser:bramc: how is changing transaction fees a scaling improvemnet
00:16:52bramc:hearn:got a link for that?
00:17:12bramc:justanotheruser:it gets rid of spam garbage and gets people to do easy optimizations in their own stuff
00:18:00skittylx:bramc: https://www.youtube.com/watch?v=96ULlHhia_Q
00:18:03skittylx:first talk
00:20:10skittylx:bramc: read peter todd's for contrast. http://diyhpl.us/wiki/transcripts/mit-bitcoin-expo-2015/peter-todd-scalability/
00:20:13bramc:Thanks, I found it while y'all were posting
00:22:34justanotheruser:bramc: It only gets spammers to compete with transactors as they always have been?
00:27:57jcorgan:scalability is usually solved by an emergent hierarchy
00:28:37jcorgan:sidechains seem the first missing piece of the pie that would enable that
00:33:04bramc:jcorgan:micropayment channels can possibly do it as well
00:33:33instagibbs: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:51instagibbs:probably why you don't see a ton of it from these guys. Peter isn't quite so shy
00:34:36bramc: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:53bramc:Reading Gavin's talk now. Can schnorr signatures even be done with a soft fork?
00:38:16gmaxwell:of course.
00:38:22justanotheruser: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:08instagibbs:bramc: almost anything can be
00:39:22instagibbs:maybe not strictly true, but a lot more than I thought can
00:39:59bramc:justanotheruser:presumably the spam is of low value, so it would stop being done if transaction fees were higher
00:40:35bramc:justanotheruser:the block size limit can't be raised with a soft fork
00:40:52justanotheruser:was that 2nd messaged directed at me?
00:41:30justanotheruser:also, the block space limit can be raised with a softfork, however.
00:41:44bramc: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:08bramc:Sorry, meant for that second message to be directed to instagibbsagibbs
00:42:12instagibbs:it's much like p2sh rollout, most likely. "free money" lying around, for some reason you can't take
00:42:31brisque:adding new signature types isn't a problem really, we could add OP_LAMPORTVERIFY if it was so desirable
00:42:58brisque:wouldn't work well with rampant key re-use in bitcoin, but it would operate just fine
00:43:34justanotheruser: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:36kanzure: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:36bramc: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:11instagibbs:the block would be embedded, with miners rejecting blocks that don't have the correct block extension (my guess)
00:44:21brisque:bramc: reject and ban, yes.
00:45:29gmaxwell:bramc: technically the block size limit can be raised with a soft fork, though its quite ugly.
00:45:53bramc:kanzure:Do you use transcription software for this or do you type fast?
00:46:08bramc:Oh I see about the block size limit. That is ugly. Extremely ugly.
00:46:56kanzure:bramc: i type fast http://www.seanwrona.com/typeracer/profile.php?username=kanzure
00:48:19bramc:kanzure:those stats make my fingers hurt
00:50:08justanotheruser:kanzure: fake
00:50:30phantomcircuit: otherwise: don't run code from mixed security domains on the same hardware
00:50:35phantomcircuit:that's the winning answer for sure
00:51:06bramc:There are really two levels of soft fork. The harder one breaks SPV on older nodes
00:51:33phantomcircuit:gmaxwell, also lots of people holding these events have absolutely zero clue
00:52:08instagibbs:bramc: hm? you mean you'll miss out on funds?
00:52:11brisque:kanzure: damn, I can only get ~100 on a good day.
00:52:44kanzure: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:29bramc: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:58instagibbs:bramc: correct, spv nodes can already be hampered by lying through omission, this would just extend it in a sense
00:55:11instagibbs: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:42bramc:Fixing the malleability problem properly would also be an extremely problematic 'soft' fork
00:57:04instagibbs:that's a conceptually "straight forward" one though
00:57:40bramc:instagibbs:except that it makes older nodes not even be able to tell where transactions are coming from
00:57:50bramc:Or what utxos have been spent, for that matter
00:58:14bramc:By 'properly' I mean start referring to transactions by the transaction id rather than the signature id
00:59:30bramc: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:13bramc: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:24bramc:aka 'people should fix the damn servers'
01:00:49bramc:That also goes for how long it takes to download a complete blockchain. Pipelining over tcp ain't that hard.
01:01:47bramc:Then there are some things which get small constant factors, like schnorr signatures.
01:02:42bramc: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:51bramc: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:49bramc: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:38moa:exponential growth can be deceptively non-intuitive, nothing is urgent until it is overwhelming
01:07:14bramc: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:41bramc: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:10:11jcorgan:the size of entities in bitcoin appears power law distributed
01:10:27bramc: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:29jcorgan:which is quite typical of industries in general
01:11:18jcorgan:and that sort of distribution emerges whenever there are independent agents and economies of scale
01:12:15bramc:jcorgan:Still alarming and problematic
01:12:58jcorgan:i'm not so worried. looking the way it does seems an indicator of its health.
01:13:36kanzure:bramc: did you also read http://diyhpl.us/wiki/transcripts/mit-bitcoin-expo-2015/peter-todd-scalability/ ?
01:13:57bramc:The lack of widespread adoption of heirarchical wallets is not a sign of health :-P
01:14:04bramc:kanzure:That's up next
01:15:13brisque:bramc: some fun trivia for you, in block height 346927 there were 760 transactions, 427 were made by blockchain.info.
01:15:21amincd: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:26amincd: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:56brisque:bramc: just manually looking through them, approximately 50-60% of all transactions at the moment based on the last few blocks.
01:17:59kanzure: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:05kanzure:... the less-hashrate-participated blockchain?
01:18:19bramc: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:26kanzure: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:06instagibbs:bramc: Most of us agree with your prognosis.
01:19:11bramc:kanzure:In general random noise will cause one branch to win
01:19:42instagibbs:basic napkin math make it clear blocksize increases only get a tiny fraction of what you want, with questionable decentralization
01:20:12bramc: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:15moa:bramc: right, at present 100MB blocks would almost assuredly ruin bitcoin
01:20:43amincd: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:57instagibbs: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:25bramc:instagibbs:That's odd. I view hitting the limit as an important experiment to run
01:21:34instagibbs: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:01rusty:bramc: Just because it's not sufficient doesn't mean it's not necessary.
01:22:10kanzure:instagibbs: you mean in the do-nothing case?
01:22:13bramc: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:28amincd: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:55kanzure: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:15instagibbs:amincd: >50% of miners I assume. That's the issue. Including non-mining stakeholders
01:23:44amincd: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:02bramc:kanzure:I assume such things are there and somewhat embarrassing but entirely fixable
01:24:59kanzure:as far as i know, yeah
01:25:04instagibbs: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:17amincd: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:49instagibbs:right so a rolling soft fork of some type
01:26:53gmaxwell:amincd: That doesn't make any sense to me.
01:26:53bramc: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:27:37bramc:rusty:Has Gavin clarified whether he's talking a hard or a soft fork?
01:27:48gmaxwell: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:56gmaxwell:bramc: he's not talking about a soft fork.
01:28:00rusty:bramc: it has to be a hard fork.
01:28:21instagibbs:rusty: as per earlier it doesnt have to be, but its hella ugly
01:28:28gmaxwell: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:38bramc: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:48gmaxwell:because as bramc notes, it's really ugly.
01:29:47gmaxwell: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:23gmaxwell:(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:26gmaxwell:(as if that matters)
01:30:59instagibbs:you can say ~0 :P
01:31:07instagibbs:it's certainly not actually 0
01:31:16amincd:gmaxwell: my assumption is that miners care about the overall health of the Bitcoin economy enough to defend decentralization.
01:31:27jcorgan:is the marginal risk for stale blocks anything consequential?
01:32:05bramc: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:11gmaxwell: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:02gmaxwell: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:19gmaxwell:Efficient set reconciliation protocols can potentially send even less.
01:33:48bramc: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:34gmaxwell: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:40gmaxwell:(at least on the upper side)
01:34:41instagibbs:bramc: we already give power over txn ordering. giving power over protocol, esp at expense of users, is frankly nuts
01:35:07gmaxwell:instagibbs: if we could avoid tx ordering power we certantly would, alas. :)
01:35:37instagibbs:did I tell you about my wonderful Darkcoin innovation (kidding kidding)
01:35:55instagibbs:scroll back if lost
01:36:40bramc:Gavin said that five or six people have push access to bitcoinj. Git lists eight.
01:37:07gmaxwell:The rest are NSA sockpuppets?
01:37:23amincd: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:12gmaxwell: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:58gmaxwell: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:24gmaxwell: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:14bramc: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:50moa:it's a worry
01:40:55gmaxwell: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:14amincd: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:24gmaxwell:Unfortunately, as you've noted messaging around bitcoin is largely controlled by people who are focused on monetary policy.
01:41:30gmaxwell:amincd: this is not the case.
01:41:33moa:the "next layer" seems to be unaware of the foundations they are building upon
01:42:04brisque:flimsy moats.
01:43:15gmaxwell: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:43skittylx:they wut mate
01:43:52amincd:gmaxwell: well that's not good
01:44:08brisque:who the hell knows who most of these large miners are now anyway
01:44:12bramc: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:18brisque:bw.com sort of sprung out of nowhere and they own a lot of the network now
01:47:05bramc:Then he mentions net settlement (which is what I was just advocating) and talks about sharding. Sharding makes me cringe.
01:48:43bramc: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:09bramc:'optimizing bubble sort' is a good line though
01:49:23instagibbs:bramc: i assume you've read of his treechains idea? I'd start with that as an idea how it might work
01:50:01instagibbs:it at least answers how things would be ordered/reordered, etc, if perhaps not satisfactorily
01:51:32bramc:instagibbs:No I'll add that to my list of crap to read
01:53:54phantomcircuit:bramc, sharding?
01:54:30bramc:phantomcircuit:The idea behind sharding is that not everybody has everything
01:55:13phantomcircuit:bramc, oh
01:55:28phantomcircuit:bramc, that's fine and possibly preferable as long as everybody sees everything once
01:55:35phantomcircuit:but obviously hard to get right
01:55:51bramc: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:10instagibbs:the benefit is not seeing everything at once
01:56:22phantomcircuit:bramc, huh?
01:56:43phantomcircuit:lets use a mobile phone as an example
01:57:05phantomcircuit:it's not unreasonable to download and discard the entire blockchain on a phone over wifi
01:57:07instagibbs:we could use bitcoin as an example
01:57:24phantomcircuit:most of the consensus checks are cheap
01:57:44instagibbs:but you needed to process all the data
01:57:55bramc: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:00instagibbs:(excluding SPV which is trusting miners to do their job)
01:59:01bramc: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:34bramc:And work difficulty is of course utterly trivial in bitcoin. Not so much in some altcoins.
02:00:55jcorgan:sometimes i think bitcoin is better described as "programmable trust"
02:00:59instagibbs: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:13phantomcircuit:bramc, actually downloading but not saving the entire blockchain on a phone is entirely reasonable today
02:01:28gmaxwell:instagibbs: magic is nice like that.
02:01:31phantomcircuit:you can even run the signature checks for the last say 2016*4 blocks without it taking too long
02:02:02instagibbs:clearly impossible. Just trying to point out the obvious benefit if possible
02:02:06moa:jcorgan: it's somewhat like a trusted virtual grid machine
02:02:29instagibbs:simply saying "well <1MB blocks are easy" kind of missing the long term goal of such an idea
02:03:03jcorgan:moa: i mean, the various wallet designs are really differentiated by who you have to trust to not screw you.
02:03:27jcorgan:fully validating is less trusting then spv is less trusting the webwallet, etc.
02:03:53bramc: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:00bramc:That shards trivially but... ugh...
02:04:07phantomcircuit:instagibbs, i dont think anybody whose opposed to increasing the block size limit is missing the point...
02:04:10phantomcircuit:ditto sharding
02:04:12jcorgan:and at the root of the trust spectrum is trusting the properties of math
02:04:35Luke-Jr:anyone mind if I redirect vmatekole?
02:04:36instagibbs:We must be talking past each other then.
02:04:44phantomcircuit:Luke-Jr, please do
02:04:58gmaxwell: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:07phantomcircuit:bramc, iirc there's significant performance issues with that
02:05:09instagibbs:I'm not advocating a block size increase(??)
02:05:17phantomcircuit:(i totally could be wrong there)
02:05:28bramc:phantomcircuit:Correct, hence my ugh
02:05:30gmaxwell:(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:22moa:study by google?
02:06:43bramc:moa: not sure what you're asking
02:06:46gmaxwell:hah no some academic study, but I suppose google is pretty much an example of that every day.
02:07:51gmaxwell:has anyone here developed a yubikey neo applet?
02:12:27copumpkin:neo :O
02:12:39copumpkin:I played with their U2F thing
02:14:18phantomcircuit:gmaxwell, no but i believe it's just a standard javacard
02:14:35phantomcircuit:iirc you have to use their tools to switch it from the normal mode to the javacard mode
04:37:33FoxDay:FoxDay has left #bitcoin-wizards
04:49:28petertodd:"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:00petertodd:we can after all soft-fork *out* that ability
04:54:24gmaxwell: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:12petertodd:gmaxwell: well, that requires SPV nodes to change - not terribly interesting, and kinda obvious
04:59:22gmaxwell:petertodd: sure. but they don't get a choice.
04:59:49petertodd:gmaxwell: yeah, but that's still way more politically disruptive than my version
05:00:43gmaxwell: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:32petertodd:gmaxwell: sure, but like I say, in my horrid scheme it really is a soft-fork
05:05:32phantomcircuit: gmaxwell: sure, but like I say, in my horrid scheme it really is a soft-fork
05:29:33petertodd: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:54petertodd:or just the second 32 bytes: 0000000000aaaaaaaa00bbbbbbbb01cccccccc0000000004ddddddddeeeeeeee
05:33:54petertodd: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:49petertodd:(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:36phantomcircuit:petertodd, is a no output tx valid?
05:53:59brisque:phantomcircuit: no, that's invalid
06:21:59fanquake:fanquake has left #bitcoin-wizards
08:05:17tepper.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:17tepper.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:17tepper.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:17tepper.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:17tepper.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:05xenog:xenog is now known as Guest64996
11:45:40xenog_:xenog_ is now known as xenog
12:39:32petertodd: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:50brisque:petertodd: somehow I don't think the ballmer peak applies to cryptography.
13:37:53Adrian_G:Adrian_G is now known as AdrianG
15:55:14kanzure:""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:19kanzure:yeah i haven't thought about whether smaller would work
16:17:37instagibbs: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:38kanzure: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:08kanzure: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:30kanzure:at least, it is less likely to break the network in the same way that 50000 GB average block size would :-)
16:21:29instagibbs: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:44sipa:there are various forms of centralization
16:21:51sipa:they are not all related
16:22:24sipa:miner centralization is different from independent-parties-running-full-nodes centralization, is different from humans-able-to-interact-on-the-blockchain centralization
16:22:29kanzure:right, i was only suggesting a smaller blocksize to see what block size limits being reached means
16:22:35instagibbs:well... they're related... as in you break one completely you break the whole thing :P
16:22:45instagibbs:totally agreed though
16:22:56kanzure:was there a specific technical concern about network breakage if block size limits are reached consistently?
16:24:18instagibbs: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:44kanzure: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:27justanotheruser: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:48sipa:that's very vague
16:26:05instagibbs:justanotheruser: that doesn't map anything to do with being able to mine, for example
16:26:21sipa:a tiny blockchain where every pocket calculator in the world can validate the chain isn't useful
16:26:44sipa:(inter bank transfers are far superior for that use case)
16:27:07sipa:and a huge blockchain where only google-sized datacenters can can validate the chain isn't useful
16:27:14justanotheruser:sipa: there isn't an easy way to define what the block size should be in terms of those three parameters
16:27:25sipa:(we could just go back to trusting visa to process our transactions)
16:27:31justanotheruser:you can try estimating though
16:27:37sipa:so there is a balance between those, and IMHO, there are multiple possible balances
16:27:38instagibbs:every user has to decide for himself an lobby :/ which is why this discussion is hard
16:27:45sipa:and there is no right choice
16:27:51sipa:it depends what we want to use bitcoin for
16:28:23sipa:increasing the "range" of usecases is probably objectively useful
16:29:42instagibbs: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:11sipa:worse, people don't realize that all of them are a tradeoff
16:32:47instagibbs: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:53amiller:does anyone know of any tools for doing blockchain analysis
16:52:16amiller:like, i know i can parse the blockchain using bitcoinj or python-bitcoinlib or that little c tool
16:52:36amiller:but i dunno, something that makes some kind of database i can do graph queries on or something?
16:52:56adlai:do you mean tools for querying a local blockchain, or services that let you query their digested/indexed blockchain?
16:53:29amiller:querying a local blockchian
16:53:41adlai:familiar with jratcliffe's tools?
16:53:42hearn:there are companies that have built such tools
16:53:45hearn:and academics
16:54:05hearn: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:39hearn:amiller: otherwise plugging bitcoinj into a graph database like neo4j or hypergraphdb would not be very hard, i think
16:59:11maaku:amiller: i am very surprised that no one has modified bitcoind to replace LevelDB with
16:59:34maaku:that way you'd just keep a daemon running and it populates the database
16:59:56sipa:all you'd get is a utxo set, though
17:00:03amiller:not with tx-index turned on?
17:00:18sipa:right, with txindex you get more, but it's hardly optimized for that
17:02:46kanzure:amiller: https://github.com/monetizeio/sqlalchemy-bitcoin
17:04:05hearn: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:14hearn:maaku: however they only index the UTXO set, not the entire chain.
17:04:18MRL-Relay:[tacotime] we're working hard to make btcd database agnostic, too.
17:04:22hearn:maaku: but really for what amiller wants, you want a graph db
18:13:35gmaxwell: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:03tromp:possibly off-topic: latest Ethereum PoW revision at https://github.com/ethereum/wiki/wiki/Ethash
18:23:09hearn:yet another pow?
18:23:32tromp:not radically different, they just keep tweaking it
18:23:36sipa:we need a popow
18:23:43sipa:proof of pow
18:25:56hearn:gmaxwell: is anyone working on pruning at the p2p protocol level?
18:31:35instagibbs:you mean pruned nodes advertising blocks?
18:32:20hearn:ah, i found the latest autoprune patch
18:32:22hearn:seems it's not done yet
18:32:25sipa:someone should work on that, yes
18:32:32instagibbs:suspicion is "no"
18:32:33sipa:there have been proposals in the past
18:35:46kanzure: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:45waxwing__:waxwing__ is now known as waxwing
18:37:38kanzure: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:16jtimon:with a smaller block size we may also see more fee competition?
19:19:38Luke-Jr:jtimon: inherently. that's a miner topic though, not development ;)
19:19:59Luke-Jr:(if you mean below 1 MB)
19:40:56jtimon:Luke-Jr do you know the aswer to my question in #bitcoin-dev ?
19:57:41Luke-Jr:jtimon: no
20:13:10phantomcircuit: I don't think that 1MB is big enough
20:13:26phantomcircuit:the correct blocksize is the larger blocksize which doesn't cause centralization pressure
20:13:48phantomcircuit:empirically we're seeming a bit of centralization pressure even now with blocks that are largely less than 1MB
20:34:56MRL-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:55MRL-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:36MRL-Relay:[tacotime] (Will miners abuse it to drive fees insanely high? Etc)
21:25:38amincd: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:59amincd:what that point is I have no idea
21:27:22amincd:and 'regulate' is somewhat of a euphemism. Let's call it what it is: banning unrestricted hosting of a Bitcoin node
21:28:18smooth:im not convinced the current centralization pressure is significantly based on block size at all
21:28:50smooth:what matters is not centralization but the derivative of centralization with respect to block size
21:43:29amincd: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:56sipa:i also think the full node count is totally.irrelevant
21:44:35sipa:the question is how easy it is for independent interested parties to run one
21:44:53sipa:how many actually obviously depends on the usefulness of the network it supports
21:45:01smooth:a clear defintion of 'centralization' would help
21:45:33smooth:i think almost literally every single person who uses the term means something different
21:45:52sipa:decentralization is just a means to an end
21:46:05amincd:The end being censorship resistancfe
21:46:25sipa:that's one goal
21:46:28smooth:still more fuzziness: people have different ideas of a the desirable end
21:46:49sipa:another is having a currency where nobody can cheat
21:47:25sipa:it doesn't matter whether anyone runs a full node
21:47:32sipa:in that view
21:47:39sipa:just that i can run one if i want to
21:50:17amincd:so independence for trusted third parties
21:50:24sipa:yes, trustlessness
21:50:37sipa:which is imho more important than decentralization
21:50:54amincd:*independence from
21:51:08sipa:both are fuzzy terms of course
21:51:13sipa:as they are not absolute
21:51:23hearn:as a wallet developer, "enough" means "enough capacity to serve all SPV clients that want to be served, quickly"
21:51:58sipa:right, there is an actual service they provide to others as well
21:52:21sipa:that's of course relevant, but imho easier to satisfy
21:53:31sipa:anyway, zZzZ
22:06:50amincd: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:19amincd:fficulty is an effective check on centralization abuse
22:07:54hearn:if all you care about is checking/auditing, it can be done probabilistically
22:08:10hearn: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:14hearn:in the best case it's like a full node today.
23:20:02gmaxwell: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:36gmaxwell: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:58hearn:MAX_BLOCK_SIZE = fn(get_global_population())
23:27:32justanotheruser:can get_global_population ask me?
23:28:37gmaxwell:return 4; //chosen by fair random dice roll
23:47:32Pasha:Pasha is now known as Cory
23:51:39maaku:4MB sounds good to me!