01:32:44rusty:rusty has left #bitcoin-wizards
01:52:45bramc:Hey everybody
01:52:55bramc:I just published this: http://bramcohen.com/2015/06/02/gallus-and-simo-debate-whether-the-block-size-limit-should-be-increased
01:52:55gmaxwell:bramc: HI
01:54:08bramc:We'll see whether it proves to be controversial or ignored
01:54:22bramc:Hey gmaxwell
01:54:29sipa:* sipa guesses: both (without actually reading the linked document)
01:54:44sipa:(also: hello, i'm back from vacation)
01:55:30bramc:sipa, I was looking for names to debate with Gallus, and since variants on 'maxwell' were all awkward, I looked into variants on 'sipa', and realized that Sippas is probably the root of your name and a little too close.
01:56:43sipa:bramc: the origin of my nickname is an abbreviation of an abbreviation of a concatenation of childhood friends of mine, none of which you've ever heard about :)
01:57:35bramc:In this particular case I'm trying to explain the reasoning for and against increasing the block limit, throwing in some original observations and ideas and overall coming in against it.
02:00:51kanzure:"Protecting privacy with electronic cash" hal finney 1993 http://fennetic.net/irc/extropy/ext10_1.pdf
02:03:35bramc:Any feedback on my post would be much appreciated
02:05:21kanzure:bramc: well, this argument is certainly novel to me "The wallet codebases are poorly written and maintained and can’t be realistically expected to be made to handle real transaction fees."
02:05:42bramc:kanzure, I've definitely seen that presented in total seriousness somewhere
02:05:46kanzure:on the other hand, i could imagine this being true "There aren’t any good way to handle transaction fees." for some definitions of good :-)
02:06:09bramc:With 'somewhere' being not on this irc channel obviously
02:06:51kanzure:bramc: i think it would be prudent to include more speculation about disaster scenarios regarding hardforks (there is a document baking somewhere about forks in general but it's not ready)
02:07:10kanzure:or at least, not quite disasters at first but at least stating various obvious consequences
02:07:57bramc:kanzure, The ones which I gave seem bad enough. I'm sure there are others, but (a) they didn't occur to me and (b) it was already getting fairly long
02:08:10bramc:It took me several hours to write that post today, even starting from extensive notes.
02:08:54dgenr8:bramc: thanks, now all my reddit-avoiding is for nothing
02:09:39kanzure:bramc: i happen to think transaction fees are a good idea, take a look at http://gnusha.org/bitcoin-wizards/2015-06-01.log starting near "slow death"
02:09:48bramc:This post makes claims about things being too hard for wallets to handle. It's emphasizing payment channels, but the same counter-arguments apply: https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e
02:10:20kanzure:i could imagine transaction fee estimation being something that might be construed as non-trivial, but surely that's an argument for just using a library that you trust in your wallet?
02:10:27bramc:kanzure, I think transaction fees are a good idea as well, I was just trying to give most of the basic points a fair shake
02:10:53kanzure:bramc: sure, i was just trying to preface my link and (poor substitute for a) link anchor
02:11:42dgenr8:assertion. please refute: miner can create and transmit a 32MB block today. everybody will download it because they don't know how big it is until they receive it.
02:12:13kanzure:everybody wont download it because the p2p graph is not fully saturated or something
02:12:28kanzure:insert appropriate graph theory term
02:14:52bramc:dgenr8, I don't off the top of my head know if that's true but it will get rejected. That would be a spam DDOS attack, and not a very good one.
02:15:35kanzure:bramc: so the claim from the g man is that everyone will abandon bitcoin once anyone starts making lots of high-fee transactions
02:15:35gwillen:kanzure: fully-connected
02:15:47dgenr8:a node that downloads the whole thing will reject it because it's bigger than 1MB, or so it looks to me
02:15:49kanzure:gwillen: that's way too esoteric for me to remember
02:15:56sipa:dgenr8: bitcoin core master today will disconnect before the whole message is received in memory
02:16:08sipa:iirc 0.10.2 will do the same
02:16:13bramc:kanzure, Nobody goes there any more, the lines are too long
02:16:29kanzure:bramc: i mean from the logs and the locatio ni nthe logs that i pointed you at
02:16:37dgenr8:sipa: welcome back. so that's in the deserializer then?
02:16:46sipa:this is in the network code
02:16:52sipa:long before we even try to deserialize
02:17:05bramc:I would view fees of $10 as a serious problem to be dealt with. Fees of $0.01 are not.
02:17:20kanzure:bramc: $10 average fees are a problem why?
02:17:52kanzure:how else are you going to pick transactoins for inclusion?
02:18:04gwillen:kanzure: or 'complete'
02:18:05bramc:kanzure, At that price probably some totally reasonable transactions are getting held up.
02:18:27kanzure:gwillen: i'm just joshing you, yes that's correct terminology :-)
02:18:42dgenr8:sipa: ah, looks like 2MiB
02:18:49gwillen:kanzure: haha, sorry, it's hard to read tone of voice on IRC :-)
02:18:52kanzure:bramc: well there are many possible potentially reasonable transactoins, far more than bitcoin will ever be capable of handling at any scale
02:19:02d3vz3r0:what would be considered a ‘reasonable’ max transaction fee?
02:19:07kanzure:bramc: i mean we could trivially imagine billions of transactions per second that might be completely legitimate, in a large-enough civilization
02:19:29d3vz3r0:and what criteria would be for determining that transaction fee?
02:19:39bramc:kanzure, The next question would be, what should you do if the price hits $10? I'd argue that (a) that's really getting ahead of ourselves at this point (b) you can probably wait for whoever's doing a DOS to run out of money, (c) the best approach is to get a jump on implementing lightning network
02:19:41kanzure:d3vz3r0: users and wallets choose the transaction fee
02:20:02kanzure:bramc: i think that a lot of the current block size talk is motivated by concerns about eventually increasing transaction fees
02:20:03d3vz3r0:yes , Iknow that, but I’m really just asking the question in terms of what it means to be ‘too large’
02:20:32bramc:kanzure, Yes that's clearly the subtext
02:20:41kanzure:hooray i am capable of reading
02:21:12kanzure:i think that more thought should be put into thinking about high-transaction-fee scenarios and what would be good or bad about them
02:21:31kanzure:(or neutral about them)
02:22:16bramc:d3vz3r0, I'd argue that if a transaction gets abandoned because of a 1 cent fee then that isn't much of any loss to society. If it gets abandoned because of a $10 fee then maybe it was worth something nontrivial and it not happening is a loss
02:22:45kanzure:well, there are many potentially good transactions that wont happen because fees are too high (always)
02:22:49bramc:Of course, if there are functioning payment channels then maybe that $10 transaction was abandoned in favor of a $0.01 channel transaction, which isn't any loss at all.
02:22:54kanzure:the only exception is when fees are literally-zero. but then what's the point of fees?
02:23:12d3vz3r0:I guess I’m wondering if there’s some formal way to determine what a ‘proper’ fee is
02:23:26d3vz3r0:and what are the economics behind how that fee should be selected
02:23:33bramc:d3vz3r0, I'm making a completely subjective statement about when I personally would start worrying
02:23:49kanzure:bramc: i think that partial-chain and off-chain solutions definitely give conduit for significantly lower fees, but that it is also useful to talk about the other limits of the system (not really "in their absence", but just so we know how the blockchain might be operating anyway)
02:23:53d3vz3r0:I could potentially see cases where a 10$ fee is proper, and a .01$ fee is proper
02:24:38d3vz3r0:in the ‘normal’ world this is usually a percentage of the transaction value, ie 3% or something for visa
02:24:39kanzure:d3vz3r0: well, practically speaking, wallets should look at recent transactions from their mempool, then look at which transactions got into a block, then decide which transaction fee might be accepted
02:24:41bramc:d3vz3r0, The way *miners* select fees is a straightforward auction: They look at the available transactions, sort by largest fee per byte, and go with the most worthwile until they're full
02:24:51kanzure:there are also other complicated and boring "ask a miner for a fee estimation" schemes, but those get kinda wacky i think
02:25:09kanzure:bramc: er, is that currently implemented behavior? for all of them?
02:25:31bramc:(it's more complicated because of child pays, but that's the basic idea)
02:25:32d3vz3r0:a ‘fee bid’ market or some such thing
02:25:42bramc:kanzure, Probably not, but I'm being idealistic
02:26:15bramc:The way wallets *should* behave is dependent on your assumption of whether it's receiver pays or sender pays
02:26:50kanzure:well for the moment let's assume receiver pays and child pays works
02:27:09bramc:If it's receiver pays then the sender sends it and forgets about it while the receiver starts with a low fee and slowly increases it until the transaction goes through. If it's sender pays then the sender starts with a very low fee and increases it using malleability until it goes through.
02:27:22bramc:By 'receiver pays' I mean 'child pays'
02:28:35d3vz3r0:so it’s really just about fishing for miners
02:28:56d3vz3r0:at this point anyway.. .set the bait (fee) and hope that someone grabs yours before the others
02:29:03bramc:d3vz3r0, It's a general technique called escalator, nothing weird about it
02:29:33d3vz3r0:sure, I get the mechanism, but there’s not formal way of determining the proper fee for a transaction
02:29:38d3vz3r0:unless I’m completely missing something
02:30:23bramc:Right, it needs to be discovered empirically. There's an information gathering component of market systems which can't be done if they aren't running.
02:30:32sipa:d3vz3r0: you're not; "reasonable" in this context was a completely subjective, and presumably context and time-dependent assessment
02:31:30d3vz3r0:ah sure, “reasonable” means that historically that’s what has worked
02:32:03d3vz3r0:but what happens as the cost of operating a mining rig goes up significantly.. ie: bandwidth costs for a larger block size
02:32:15d3vz3r0:I guess that’s really where my interest lies in the fees arena
02:32:29d3vz3r0:does the ‘fee market’ naturally reset
02:32:49d3vz3r0:ie: miners start rejecting every transaction with fees under 1$ for example
02:33:13bramc:d3vz3r0, The fees are determined by the max block size, not how expensive it is to run a miner
02:33:14d3vz3r0:this is all just speculation and thought expiraments
02:33:41moa:bramc: currently
02:33:42kanzure:the fees are determined by max block size, demand for transaction inclusion, other transaction fees, other transactions, higher priority transactions, etc. etc..
02:33:56d3vz3r0:how are the fees determined by max block size?
02:34:14sipa:they are depetermined by available block space
02:34:23sipa:sorry, influenced by, not determined by
02:34:28kanzure:bramc: so i think that if partial-chain solutions (payment channels, sidechains, whatever) can accept low fee transactions, then what's wrong with $10 or higher fee transactions in the blockchain? does a $0.0001 transaction really need permanent recording in the ledger?
02:34:39sipa:and available block space is a miner's decision, but it is also influence by the max block size consensus rules
02:35:22moa:kanzure: as reward goes away fees will be the incentive to secure the chain also
02:36:24kanzure:/win 2
02:36:27kanzure:gah, fail :(
02:36:30sipa:/loose 2
02:37:09bramc:kanzure, Yes if partial chain solutions are in place and widespread a $10 fee wouldn't be very worrisome. I'm just saying that $10 is around the point where I'd take the claim that it was maybe a bit high somewhat seriously, as opposed to 10 cents, at which point I'd just laugh at anybody who made that claim, regardless of what else was going on
02:38:14kanzure:bramc: i think it would be interesting to run simulations like, "how long could a very wealthy bitcoiner spam the blockchain and clog blocks with high-fee transactions" given 1 MB blocks versus much larger.
02:38:24kanzure:er, not simulations in this case; this just requires arithmetic.
02:38:50bramc:kanzure, The arithmetic is pretty simple, and right now it doesn't have to do with fees, just amounts to be fronted
02:39:17bramc:In that post I do the math on the current system. It's a bit sad.
02:39:23kanzure:i suppose there might be a situation where the blockchain could get stuck in a loop where the wealthy bitcoiner is also the miner?
02:40:43bramc:Miners can run up transaction fees by accepting fewer of them, although they can make more money as individuals by accepting as many as they can but screwing over other miners later
02:41:25kanzure:oh wait, it's easier to just mine zero-sized blocks instead
02:41:27bramc:Perhaps once mining rewards go away then inevitably the block limit will fall down to an amount which results in significant transaction fees as all the big miners collude
02:41:31kanzure:well, i guess they might be interested in taking up hard drive space
02:42:51moa:interesting that all lot of miners are in china where they really do have bandwidth limitations
02:43:22bramc:kanzure, Reading through that log, Gavin seems to just keep repeating that transaction fees will go up and that that's bad.
02:45:09bramc:There are about 100,000 seconds in a day, so if you wanted to force transaction fees to $1 and nobody else was willing to pay that much it would cost you $400,000/day. Probably less in practice as others upped their fees.
02:45:11moa:bramc: the thinking seems to be that it is bad if that happens before rewards drop ... and free block space is a "loss leader"
02:46:12bramc:moa, It's also bad if nobody gets ready to make it happen before rewards drop because there's no need to
02:46:33kanzure:bramc: right.. i think he wants lots of consumer adoption.
02:46:53kanzure:and believes that consumer adoption is incompatible with the other parts of bitcoin
02:46:53d3vz3r0:consumer adoption occurs due to low transactions fees is the assumption there?
02:47:00moa:bramc: quite
02:49:25bramc:I would argue that if person A wants to send money to person B a $1 transaction fee would be of no consequence because it's lower than the fees they spend getting money into and out of the system
02:50:07d3vz3r0:but if the money never leaves the system, it’s potentially a lot
02:50:26bramc:If someone's business is critically dependent on transaction fees being less than a penny then you have to seriously wonder whether they're doing anything of value
02:50:43moa:bramc: but if you wanted to perform 100's of mixing transactions then 100x$1 would be a consequence
02:51:32bramc:This is an argument in favor of taxes on real world financial transactions, by the way. It turns out that having transaction taxes can actually save money for the bona fide participants because it puts the people who front run trades out of business.
02:52:16bramc:moa, We already have perfectly good technology for making mixing vastly better than that
02:53:40bramc:And when you're mixing you should burn some amount of your coin in transaction fees just so the exact amount is less of an identifying piece of information anyway.
02:53:53moa:maybe I'm just pointing out where the volume of tx are coming from presently, not to mention http://cryptograffiti.info/ that maybe influenced by fees
02:54:55moa:but i think you make a good point about the guy who is going into btc not be influenced by $1 fee
03:00:18kanzure:bramc: i suspect (but i don't entirely believe yet) that transaction fees are somewhat focusing, and allow people to figure out which out of all the potential transactions they could be doing, which ones happen to be the most important to them. instead of, you know, just doing all of them.
03:01:33bramc:kanzure, Yes, market based mechanisms are good for making everyone figure out the most valuable thing. Hence the proposals here in California that we should deal with our water problems by having the state just plain auction it off.
03:02:05kanzure:bramc: would the local cities be bidding?
03:02:10kanzure:(for residential water user)
03:02:10bramc:Oddly, that proposal is viewed as extremist by people on both sides of the political aisle.
03:02:19kanzure:*water use
03:02:43kanzure:(actually i'm not sure how california municipal water is configured. i assume city-based.)
03:03:04bramc:kanzure, Politically you'd probably have to earmark some for home use, but that's a small fraction of all of california water use. 80% of it goes to agriculture.
03:03:24kanzure:right, home use is something like 2%. perhaps they wouldn't be auctioning that off.
03:03:44bramc:It's a giant mess of 100 year old regulations involving the federal government, the city government, landowners, hereditary water rights owners, and consumers.
03:04:04moa:pray for rain
03:04:27bramc:moa, a modest reduction in agricultural usage and our water problems would be gone
03:04:33kanzure:i could understand some disagreements related to not pitting citizens versus agriculture companies, but that doesn't seem to be what's happening according to your summary.
03:04:41moa:some food items too no doubt
03:05:21bramc:Everybody assumes that if water prices went up to a reasonable amount then we'd stop producing alfalfa, but the truth is we don't know.
03:05:38kanzure:i suppose those are similar to concerns about bitcoin transaction fees ("there's no way that individuals can compete against companies that are willing to pay large fees to record transactions")
03:05:41d3vz3r0:the price of alfalfa would just go up
03:05:48d3vz3r0:to a point
03:05:58bramc:Right now farmers are paying less for water to grow grass in the desert than city residents are paying for the water they drink. This is a bit messed up.
03:06:20bramc:kanzure, Yeah it's all the same stuff
03:06:22kanzure:do you mean city water price, or do you mean price of water from restuarants?
03:06:32bramc:I mean the retail price
03:06:48bramc:Er, the price from your faucet, not the price of bottled water
03:06:49yoleaux:“WAGE AND PRICE DISTORTIONS WILL CONTINUE UNTIL MORALE IMPROVES” - California politicians (@DLin71)
03:06:57kanzure:wise words.
03:07:18moa:alfalfa is great stuff that keeps animals fed and highly nutritious too
03:07:37c0rw1n:c0rw1n is now known as c0rw|zZz
03:07:42moa:bottled water seems extravagant by comparison
03:08:34kanzure:bramc: i suspect that if companies are hogging all the block space with high-fee transactions that at least a few of those will be related to consolidating partial-chain or off-chain low-fee transactions.
03:09:31kanzure:i suppose there's a concern related to whether the transaction relay network will be maintained if every transaction is high fee. ("why would i want to relay transactions when i'm not able to get a transaction included on my own?")
03:09:52kanzure:(er, this is for fees significantly higher than $100 of course.)
03:10:06d3vz3r0:or it creates a market for transaction brokers
03:10:59kanzure:brokers that would do "matchmaking" to combine fees and transactions?
03:11:25d3vz3r0:yea, something like that
03:11:49kanzure:i don't know which one but there's at least one mixing network proposal that operates like that
03:11:49d3vz3r0:consolidating partial-chain or off-chain transactions for lower-fees
03:13:06kanzure:d3vz3r0: well the mechanism of consolidation has to happen before the transaction is created, because otherwise you have an immutable signed transaction, but yes.
03:13:24kanzure:whoops i mean before it is signed
03:13:29d3vz3r0:yea, before it’s signed
03:14:39NewLiberty:More likely on alt-coins or side chains than brokers imp
03:15:27kanzure:altcoins aren't very likely; currency tends to be winner-takes-all.
03:15:42kanzure:however, you could easily argue that many bitcoin-powered sidechains can harbor altcoins, in which case i'll cede.
03:20:21NewLiberty:Thus the block size debate is one of the intersections of conflict of interest between Blockstream and Bitcoin. Fortunately the individuals involved are much more ethical than typical.
03:20:35sipa:god please stop saying that
03:20:50sipa:for everything blockstream wants to do, larger blocks would make things easier
03:21:19NewLiberty:I don't disagree.
03:21:24kanzure:sipa: it creates a conflict of interest because they are incentivized to respond to millions of conflict of interest claims, instead of working on bitcoin they are busy defending their decisions
03:21:45kanzure: (and not the fun kind)
03:26:03kanzure:.title http://www.faqs.org/rfcs/rfc1217.html
03:26:03yoleaux:RFC 1217 - Memo from the Consortium for Slow Commotion Research (RFC1217)
03:48:40bramc:No response to my post so far. Maybe I'd get more response if I take out just the rant about zeroconf and title it 'zeroconf advocates should get over it'
03:49:31bramc:Or the following rant and entitle it 'How to block all bitcoin transactions of less than $10 using only $25,000'
05:52:13gmaxwell:Hey all-- there may be some interest in this draft publication on a new ring signature construction that we've created: https://github.com/Blockstream/borromean_paper/raw/master/borromean_draft_0.01_58a5cbc.pdf
05:52:31gmaxwell:This ring signature is a building block for a much bigger cryptosystem which I'll be publishing soon.
05:52:46gmaxwell:(also with code implementing whats in that paper too.)
05:54:47gmaxwell:This new ring-signature is asymptotically 2x more efficient than the one used in Monero/Bytecoin: It needs pubkey+1 field elements in the signature instead of 2*pubkeys. In particular, it retains that 2x efficiency when doing an AND of many smaller rings, because the +1 gets amortized across all of them.
05:54:55jcorgan:gmaxwell: will be a nice read, and a welcome change from all the politics recently. thanks.
05:56:33akrmn:can this be softforked into bitcoin? And what are the applications? More anonymity?
05:57:22gmaxwell:It also describes a new way to think about ring signatures; which might be helpful to anyone whos looked at them before and found them confusing. (If we were successful, you'll think the new construction was so simple that it was obvious; I can assure you it was not... fortunately andytoshi came up with an especially good way to explain it. :) :P )
05:58:03gmaxwell:akrmn: The application is that it is a building block for a larger cryptosystem which is yet to be disclosed. (If you guess what it is, you'll guess wrong. :) )
05:58:53akrmn:gmaxwell: I don't like too much the idea of secret projects being worked on that will in the end benefit everyone. But maybe I'm wrong.
05:58:56gmaxwell:[I think it would be a bit impolite to publish a new cryptosystem, itself built from new cryptosystems, all at once; plus this was ready now.]
05:58:59andytoshi:akrmn: having said that, in principle, yes we could softfork this into bitcoin, but there are no plans for this (and won't be -- any features that might be perceived as increasing anonymity are too political)
05:59:40andytoshi:plus this doesn't even improve anonymity, it just has "ring signature" in the name so people'll think it does :)
05:59:48gmaxwell:akrmn: every project is secret until its first published, besides I'm tired of being flamed for vaporware; so at the moment I'm only publishing things that are done. I mean if you're going to complain I can take it back. :)
06:00:16gmaxwell:well "done", as in actually usable. Nothing is ever really done.
06:00:18akrmn:Well ya it's good to wait until you are sure of something before you publish
06:00:37leishman:gmaxwell: thanks for sharing. looking forward to reading it
06:00:41gmaxwell:And have something that actually makes sense. Communicating is very hard, making good software is very hard, etc.
06:01:53amiller:this is fun
06:02:35moa:like rain on a hot day
06:20:21amiller:on first glance, it seems like you would get the same thing by applying one of the generic zkpok compilers that works on groups like that http://www.trust.rub.de/media/trust/veroeffentlichungen/2010/06/10/ESORICS10_CertifyingZKCompiler.pdf
06:23:03midnightmagic:To publish early is unethical anyway.
06:23:04andytoshi:that's pretty close to "so simple it's obvious" :)
06:23:11andytoshi:amiller: ^
06:23:45andytoshi:but i'm not sure it's true, mainly because i didn't see a generic way to do AND proofs (tho maybe there is and i'm just being daft), i actually was stuck with this disjunctive-normal-form requirement
06:23:54midnightmagic:... highly unethical, in some cases. It doesn't make sense to complain about work being done privately.
06:26:30andytoshi:amiller: in particular, that paper gives you the monero-style rings i think (see page 7 "boolean composition") where you have a bunch of hashes that are supposed to sum to a random-oracle output
06:27:30gmaxwell:amiller: according to 2.4 in that paper it constructs the OR proofs in the non-chained manner, e.g. two elements per pubkey.
06:29:22gmaxwell:(last paragraph of the boolean composition section). It would be great news to find someone had constructed exactly what we're describing before though.
06:33:53gmaxwell:Paper updated with a citation that fell out, https://github.com/Blockstream/borromean_paper/raw/master/borromean_draft_0.01_34241bb.pdf
08:05:13asimov.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:13asimov.freenode.net:Users on #bitcoin-wizards: andy-logbot adam3us thrasher` rht_ p15 gielbier SDCDev HostFat antanst b_lumenkraft gill3s Mably hktud0 ThomasV d1ggy priidu dabura667 arubi_ d3vz3r0 dc17523be3 robogoat jgarzik_ p15x hulkhogan_ maraoz Cory Starduster [7] superobserver moa NewLiberty Adlai Dr-G2 yrashk mariorz bramc sipa btcdrak CryptoGoon platinuum Oizopower kumavis runeks CryptOprah catcow Muis adams__ yorick joecool Sub|afk prodatalab LeMiner amiller koshii Relos zmachine
08:05:13asimov.freenode.net:Users on #bitcoin-wizards: MoALTz_ Meeh davout jessepollak sparetire_ huseby espes GreenIsMyPepper spinza elastoma bosma pollux-bts Logicwax justanotheruser paveljanik DrWat PaulCapestany fript tromp lmatteis sneak CodeShark mountaingoat dgenr8 helo melvster cryptowe- veox mm_1 luny Luke-Jr go1111111 ttttemp lnovy jbenet vonzipper waxwing sadoshi copumpkin metamarc phantomcircuit c0rw|zZz michagogo bedeho ebfull rasengan PRab yoleaux EasyAt shesek wumpus comboy
08:05:13asimov.freenode.net:Users on #bitcoin-wizards: stevenroose|BNC pigeons kinlo gwillen sl01 akstunt600 [d__d] Madars Tiraspol kyuupichan gavinandresen nickler Iriez Transisto2 jmcn gmaxwell wizkid057 akrmn cdecker harrow dansmith_btc face Keefe jrayhawk K1773R luigi1111 Emcy tromp_ theymos Apocalyptic prosodyContext ggreer Hunger- Pan0ram1x jcorgan isis mengine HM bsm117532 harrigan andytoshi scoria brand0 larraboj OneFixt mappum Jouke weex gnusha nsh triazo jonasschnelli berndj leakypat
08:05:13asimov.freenode.net:Users on #bitcoin-wizards: dasource tucenaber Taek iddo epscy wiz mikolalysenko artifexd lmacken cfields Krellan coryfields catlasshrugged Alanius null_radix kanzure bliljerk_ azariah warptangent sparetire TD-Linux crescend1 Zouppen _whitelogger binaryatrocity heath BananaLotus maaku optimator Eliel narwh4l mr_burdell throughnothing_ fluffypony Fistful_of_Coins Jaamg xabbix a5m0 smooth dignork Sqt poggy livegnik petertodd richardus nephyrin phedny so afdudley SwedFTP
08:05:13asimov.freenode.net:Users on #bitcoin-wizards: guruvan ajweiss nanotube forrestv warren Xzibit17 sdaftuar eric roasbeef morcos merlincorey [ace] sturles jaromil d9b4bef9 starsoccer otoburb midnightmagic BlueMatt Anduck AdrianG STRML @ChanServ BrainOverfl0w gribble ryan-c indolering Graet
08:56:27jae:jae is now known as Guest25520
10:08:56moa:are borromean rings linked to trefoil knots?
10:55:35stonecoldpat:stonecoldpat has left #bitcoin-wizards
11:55:51fluffypony:'The name "Borromean rings" comes from their use in the coat of arms of the aristocratic Borromeo family in Northern Italy.'
11:58:46nsh:.wik Borromean ring
11:58:46yoleaux:"In mathematics, the Borromean rings[a] consist of three topological circles which are linked and form a Brunnian link (i.e., removing any ring results in two unlinked rings). In other words, no two of the three rings are linked with each other as a Hopf link, but nonetheless all three are linked." — http://en.wikipedia.org/wiki/Borromean_ring
12:00:17nsh:trefoil knots are a single...bit of string -- borromean rings are three disjoint but interlinked... bits of string
12:00:45fluffypony:I'm going to struggle not to pronounce it borrow-mean
12:04:05Jaamg:are there people who think that avg block size approaching max block size is actually desirable?
12:06:35Taek:jaamg: the bigger problem is the risks that accompany increasing the block size.
12:07:51Jaamg:Taek: that doesn't answer my question though
12:10:27Taek:jaamg: I think everybody philisophically believes that it would be best if the blockchain never ran out of space, though it's uncertain where the block-subsidy will come from long-term if there is no fee structure. That's far enough away to not be an issue for a long while. Other than that, I don't think there's any reason that running out of space is 'desirable'.
12:13:09Jaamg:Taek: I'm hoping "everybody philisophically believes that it would be best if the blockchain never ran out of space" is true. I'm trying to figure out whether it is true and that's why I asked what I asked
12:14:54Jaamg:I try to find someone to tell me why it isn't true
12:16:05Jaamg:if there is no such people, i think we should accept that as an axiom of some sort
13:18:37fluffypony:Jaamg: nobody here (that I know of) thinks that the size should *never* change (at least not without sidechain / lightning network stuff to provide scalability)
13:18:55Jaamg:fluffypony: that doesn't answer my question though
13:19:03fluffypony:the issue is with *when* the size should change, *how* it should change, *by how much* it should change
13:19:37fluffypony:Jaamg: to answer your very first question, yes
13:19:38Jaamg:fluffypony: what i want to know is: are there people who think that avg block size approaching max block size is desirable
13:19:55Jaamg:fluffypony: why would that be desirable?
13:20:05fluffypony:jtimon, afair, wanted it to happen to observe a fee market and gather real, meaningful data
13:20:12frankenmint:what is a large enough priority for free transactions to be sent?
13:20:40fluffypony:anyway, I'm getting on a plane, so a conversation for another time
13:59:40Jaamg:* Jaamg wonders why current data isn't real/meaningful and when will it become real/menaingful
14:00:40gavinandresen:frankenmint: there's a graph here: http://bitcoincore.org/smartfee/priority_graph.html
14:00:59frankenmint:nice that's the first time you've addressed me personally, thanks
14:01:52frankenmint:would you confirm that you potentially plan to work w/ mike hearn on xt if consensus cannot be reached on blocksize?
14:02:18frankenmint:I looked at XT's github page and don't see any sort of references to the larger blocksize being on the roadmap in development
14:02:21gavinandresen:yes, I think diversity and choice is good....
14:03:12zooko:Hi folks.
14:03:25gavinandresen:howdy zooko
14:04:29Taek:jaamg: the data on a fee market wouldn't really be considered valuable today because fees are nearly trivial and free transactions still make it into blocks
14:05:57akstunt600:Bitcoin is like DNA. DNA holds all life in balance with a distibuted ledger like system. If we break bitcoin in 2 pieces will bitcoin have any value as the currency of the future. To me bitcoin is all about putting greed in check, comprimise. I'm not really worried about us coming to consensus. We have a fair amount of time to get our ducks in a row right?
14:06:24frankenmint:what is priority a measure of? I thought it was perhaps seconds since last spend
14:06:35frankenmint:perhaps milliseconds?
14:08:58gavinandresen:frankenmint: priority is a product of the number of bitcoins in each transaction input times how deep that input is buried in the chain, modified so that transactions that sweep up inputs and reduce the UTXO set size get higher priority
14:09:25gavinandresen:frankenmint: See CCoinsViewCache::GetPriority and CTransaction::ComputerPriority for gory details
14:09:26Jaamg:Taek: why would the fees ever rise in an artificially limited system when people can switch to (more) free system?
14:10:20gavinandresen:Jaamg: ask an economist who knows a lot about pricing of commodities-- convenience, switching costs, security, reliability....
14:10:54gavinandresen:I don't think many economists hang out here in -wizards... (chime in if I'm wrong)
14:11:37stonecoldpat:gavinandresen: i came across your o(1) propragation post earlier today (thx to benjamindees), i'm surprised it hasnt been mentioned yet in the e-mail discussions about blocksize - is there any particular problem with it?
14:11:38frankenmint:Jaamg: creation of artificial barriers to facilitate commerce
14:11:48akstunt600:Honestly i dont think too many economists really understand the mechanics here.
14:11:55frankenmint:I'm speculating here: 21co is working with quallcomm and intel
14:12:08frankenmint:to allow users to trade earned btc for hardware locked overclocking
14:12:31frankenmint:so that continued use of device allows for a sort of 'free upgrade'
14:13:02gavinandresen:stonecoldpat: O(1) depends on mempools being almost identical across the network, and we don't really know if that will be the case long-term. I think if the incentives are to keep your mempool in sync with your neighbors, then they WILL be almost identical
14:13:57gavinandresen:I don't like to bring "but we can just write THIS code to fix the problem" into the debate, because it is speculation whether or not the code will actually work until it is up and running.
14:15:13gavinandresen:I also don't like "what will happen in eleven years..." speculating: http://gavinandresen.ninja/when-the-block-reward-goes-away
14:15:49akstunt600:well satishi kinda hinted that it needs to be popular by that time, right?
14:16:00Taek:gavinandresen: my understanding is that miners will have strong incentives to keep their mempools in sync with at least 51% of the hashing power on the network. Except for instances of collussion, this should lead to the whole network having nearly-identical mempools
14:16:01akstunt600:wehn sub ends
14:16:14frankenmint:i saw you mention the issue of a dynamic block size w/ a malicious actor throwing in a huge 11gb block for the network to chug on...why not make X previous blocks enforce average accepted block size?
14:16:49gavinandresen:frankenmint: http://gavinandresen.ninja/bigger-blocks-another-way
14:16:52frankenmint:such that larger sizing is required but a sustained increase has a cooldown period after X growth per period
14:17:03akstunt600:yeah kinda stuck to scheduled hard cap increase by blockheight, but that sucks in the case of exponetial growth
14:17:31Jaamg:gavinandresen: yea, convenience, switching costs, security etc. all are valid reasons, but the point I was trying to make was kind of: why would anybody choose Bitcoin with "small blockchain-capacity" if there is Bitcoin with "big blockchain-capacity available in a hard fork situation
14:17:34akstunt600:frankenmint, It has a bias toward smaller blocks that way :-/
14:17:37frankenmint:akstunt600: what event would occur that isn't considered block spam at this point that would be considered such growth?
14:18:14akstunt600:frankenmint, not sure, but not a gamble i am willing to take. Remember PGP is on Facebook now. The times are changing
14:19:17akstunt600:Like i said above Satoshi intends on adoption in large numbers before subsidy issues come into play.
14:20:01frankenmint:basically all serivies that user btc can do so in a seperate closed off chain system with atomicity to overcome the transaction fee limitations
14:20:25gavinandresen:I really want to get away from making policy decisions about what is, or isn't, "spam" . That's why I start with "what do we think is a reasonable upper limit cost to running a full node" and want to let all the rest be driven by economics.
14:20:26akstunt600:could yeah
14:20:33akstunt600:but doesnt have security of the main chain
14:20:53stonecoldpat:gavinandresen: cheers, that makes sense then (its not been tried and tested).
14:20:55akstunt600:well not the same level* you know what i mean
14:21:13gavinandresen:in any case, this is all not -wizards-level discussion.
14:21:19kanzure:gavinandresen: "spam" is not just "things that don't get into the blockchain". out of millions of possible transactions it's not surprising that reality can only accomodate some subset.
14:21:33kanzure:or wait, er, "things that don't get into the blockchain" are not always spam
14:21:38kanzure:sorry, i got it backwards
14:22:19Taek:kanzure: I do like the data-agnostic approach. If we come to an agreement on what sort of block size is acceptable, then the highest bidder seems like a fully reasonable way to determine who gets space on the blockchain
14:22:32frankenmint:gavinandresen: when is pruning scheduled to be available on core implementation?
14:22:39priidu:i hope things don't go as far as a serious fork in bitcoin development (i.e. XT vs Core)
14:22:42kanzure:Taek: i believe gavinandresen disagrees with that (although i'm still trying to figure out why)
14:22:44frankenmint:not that this has anything to do w/ trx limits currently
14:23:34priidu:that would make me feel much like a lost child in the midst of a messy divorce
14:23:57frankenmint:priidu: i read that someplace else earlier today from you :)
14:24:06zooko:priidu: thank you for that. I think that's a serious truth for me to remember.
14:24:21akstunt600:kanzure, I hope that is not the case.
14:24:22zooko:We love *both* gavinandresen *and* gmaxwell, and we don't want them to fight!
14:24:27priidu:frankenmint: yes, i think i might have said it once earlier :p
14:24:28gavinandresen:If you DO want to do some -wizards-level work, start at http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners and work up some theoretical models.
14:24:33akstunt600:no infighting!!! lol
14:24:39gavinandresen:frankenmint: pruning is in the lastes Core release.
14:25:00gavinandresen:I'm not fighting with gmaxwell, I just disagree with him about timing and vision for scaling up.
14:25:22akstunt600:pruning is whicked fast another sync in only 6 hours or so
14:26:04gavinandresen:kanzure: I don't disagree, I just believe blocks should be "as large as practical" (where practical is defined by "doesn't cost an arm and a leg or require a full rack of servers")
14:26:35kanzure:okay interesting. you do not in principle disagree with "If we come to an agreement on what sort of block size is acceptable, then the highest bidder seems like a fully reasonable way to determine who gets space on the blockchain".
14:26:45gavinandresen:kanzure: absolutely.
14:27:25kanzure:ah right; now i remember. yesterday the concern was more oriented towards "(perhaps perpetually) extremely high fees", not full blocks.
14:27:41gavinandresen:kanzure: I wrote the original fee estimation code for Core (improved upon by Mike Hearn and Alex Morcos) exactly because bidding for space is the right approach
14:32:36kanzure:sounds like you're perhaps worried about potential adoption being priced out of the transaction fee market (to the extent that any such fee market exists at the moment, whatever)
14:34:50gavinandresen:kanzure: applications are already driven off-chain because of the transaction fee market.
14:35:28kanzure:that's always going to be true (e.g. there are some applications that will always prefer zero transaction fees, i think)
14:35:42gavinandresen:kanzure: I am more worried that we are failing to be predictable. If I was going to start a business, I'd like to know what the scalability plan was so I could plan accordingly.
14:35:45kanzure:(i mean; they also have to compete with other transactions just on size alone, so...)
14:36:48kanzure:i think we need more words for off-chain and partial-chain tech stuff
14:37:14kanzure:by which i mean names
14:37:31Jaamg:kanzure: perhaps potential adopters are not so much _priced_ out but rather _timed_ out. People get frustrated with hard-to-predict confirmation waiting times and abandon the system -> less pressure for the fees to go up
14:37:34zooko:Heya bramc.
14:38:37gavinandresen:bramc: I enjoyed the Gallus and Simo debate
14:38:44bramc:Hey zooko
14:39:16kanzure:Jaamg: hmm, i'm not sure that all potential bitcoin users are users that also must have transactions in the blockchain that they created- surely they could still have an interest without having a utxo assigned to them.
14:39:23bramc:gavinandresen, Thanks, it was an earnest attempt to engage in technical discussion rather than just rant
14:39:33gavinandresen:bramc: ... although you lost me at merge-mining....
14:39:35kanzure:Jaamg: i mean, all things being equal i would prefer everyone to have utxos they are interested in, but all things are not particularly equal etc
14:40:18zooko:Where was this earnest discussion posted? May I have a link?
14:40:29helo:gavinandresen: starting a business that is based on bitcoin right now seems pretty ill advised. it's stuck in its highly experimental phase until we see how it functions best with full blocks. (the way it functions will inevitably rule out many business approaches)
14:41:00kanzure:helo: that is hard to deterimne, plus it's not -wizards appropriate :P
14:41:07helo:doh :P
14:41:15bramc:gavinandresen, I might have bungled that a bit - the idea was that if you're doing a hard fork to raise the maximum block size you could allow it to be merge mined at the same time. That might make it harder and forkier, but at least it results in the fork not having such a lousy security parameter when it starts out
14:41:54priidu:helo: still though... it'd be understandable if we already had 20MB and someone was trying to push 200MB blocks
14:42:54priidu:helo: but 1MB -> 20MB isn't really that bad imho, on the other hand it would give some serious headroom
14:43:27gavinandresen:bramc: I never considered doing that, and I don't think it could work without doubling the money supply (which is an absolute non-starter). In any case, any hard fork I propose won't happen unless there is a clear super-majority of exchanges, merchants, and miners who have expressed support
14:43:43kanzure:if the money supply is doubled then you might as well do merge mining i think
14:44:02bramc:Some of the high flying Bitcoin companies have business models which don't make any sense unless the value of Bitcoin transactions goes up a couple orders of magnitude. And then there's Bitshare.
14:44:05kanzure:i mean "in the event that the scenario ends up being that the supply has doubled..."
14:45:12gavinandresen:bramc: Bitshare? Too many bitcoin companies with 'bit' in their name for me to keep track of....
14:45:45kanzure:he probably means bitshares
14:45:49helo:priidu: all of the headroom just increases how long it takes for the system to begin functioning in its long term steady state (full blocks). the system is totally unpredictable until that has happened.
14:46:32bramc:gavinandresen, Right, the sort of voting which has happened in the past (although those were for soft forks). I think even a supermajority would be problematic, it should be more than 90% to a void a horrible fork. That's for miners though, I don't know how to survey exchanges and merchants.
14:46:34gavinandresen:helo: you just pushed one of my pet peeve buttons... "totally" unpredictable? Really? totally?
14:47:00helo:gavinandresen: well, you just lost the moral high ground by ignoring everything but one word :P
14:47:03kanzure:yes at any moment transactions can spontaneously turn into blocks or something. totally unpredictable.
14:47:35kanzure:helo: nah you said "until this happens". but some aspects are predictable before that.
14:47:48gavinandresen:helo: I just get frustrated talking repeated about things I've already written about: http://gavinandresen.ninja/the-myth-of-not-full-blocks
14:48:58akstunt600:ehh, i just realized the fee market is irrelevant until the sub is in the dirt.
14:49:18akstunt600:fee market is critical for long term, but does it really matter right now?
14:49:26gavinandresen:akstunt600: yes, I wrote about that, too: http://gavinandresen.ninja/block-size-and-miner-fees-again
14:51:27akstunt600:thanks, and well said
14:51:28Jaamg:when "fee market" happens, it means that people are already pissed off by the slow confirmations
14:51:41akstunt600:Im glad that you recognize the important of the exchange rate in all this too
14:52:01kanzure:Jaamg: user expectations should be shaped by system capabilities in many cases
14:52:59kanzure:gavinandresen: i happen to disagree with the following point, but i'm a little surprised i haven't seen anyone argue "something something market price increasing, current node operators with small amounts of BTC will be able to upgrade their hardware to run equipment and more-resource-heavy software".
14:53:48akstunt600:kanzure, LOL, eveyone is too depressed to talk about BTC going to mewn. :p
14:54:07kanzure:that's not what i mean
14:54:26gavinandresen:kanzure: I don't think I make that argument. I do talk about the decline in full nodes here: http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized
14:54:35kanzure:i agree that you do not make that argument
14:54:48kanzure:i was stating that i was surprised that i don't see anyone making that argument at all
14:55:15akstunt600:yeah kanzure Im saying the small miers, alot of them got down on their spirits and left or sold miners.
14:55:24helo:from the perspective of establishing long term business plan, "totally unpredictable" is a fine characterization at this point in the experiment
14:55:42akstunt600:lot of bad information and underperforming asics out there to really drive the point home too
14:56:45priidu:helo: what's "totally predictable" though? only death and taxes
14:56:59akstunt600:Which really really sux IMO, as im still profitable with my old s3+
14:57:14gavinandresen:... trolls in any public forum are also completely predictable....
14:57:29Jaamg:kanzure: I 100% agree that system capabilities shape user expectations. Mike Hearn's crash landing blog post was great description what happens when system capabilities shape user expectations
14:58:11c0rw1n_:priidu: hang around transhumanist libertarians enough and the unavoidability of those begin to seem like technical problems soon to be solved
14:59:00kanzure:c0rw1n_: yes
14:59:21kanzure:bramc: someone relayed some commentary and questions about your blog post; near "have little reason" the questions are "why would miners have a goal to avoid or reduce transaction fees?"
14:59:52kanzure:oh i suspect it is a missing word- i think your sentence needs to hvae the word "developers" added to it perhaps?
15:01:07akstunt600:they dont care. they just want to ship the smallest block to help prevent against orphan. Dat .3%
15:01:15helo:the bathysphere hasn't even been exposed to pressures at depth, and we're installing stadium seating
15:01:31nsh:* nsh smiles
15:01:33helo:okay, work time... i'll stop being offtopic
15:04:53bramc:kanzure, Ah I have a copy editing problem there which makes it look funny
15:05:35bramc:kanzure, It's a point about miners though, there isn't much in it for miners to increase the max block size
15:06:16kanzure:miners can squash out smaller-scale miners that don't have resources for handling larger blocks (significantly larger, mind you).
15:07:27bramc:kanzure, I doubt that block sizes below something like a gigabyte would be a serious issue for anyone actually running a miner
15:07:42kanzure:right, i'd agree with that estimation
15:08:29bramc:gavinandresen, The recently announced bitshares mining chip is a bitcoin mining chip which runs on mobile devices. They seem to have a model where they give the chips out for free and the chips only work with their pool which keeps 75% of the proceeds
15:08:53bramc:gavinandresen, It does not appear to be a parody.
15:09:15bramc:At least, not an *intentional* parody
15:13:00gavinandresen:kanzure: no, they can't: http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners
15:14:26kanzure:everything in that post is completely unrelated to what i was just talking about
15:14:59kanzure:well, perhaps not completely unrelated. the line about "marginal miners" always being priced out of the market is correct, and relevant to what i was saying.
15:15:40gavinandresen:kanzure: yes, and of all the costs that go into mining bandwidth/connectivity is in the noise. Electricity costs, cost of capital, access to latest mining hardware....
15:16:49gavinandresen:kanzure: if we were talking gigabyte-sized blocks then I would agree costs would get significant.
15:17:20kanzure:in general i prefer to talk about "in the limit" because that helps inform long-reaching engineering implications somewhat
15:17:46gavinandresen:kanzure: in the limit, we all die....
15:18:13kanzure:that's only because nobody is trying http://diyhpl.us/~bryan/papers2/longevity/
15:18:42gavinandresen:mmm, I suppose we should stop working on this bitcoin thing and all help out with immortality research, more important problem to solve first.....
15:18:53kanzure:aubrey de grey mentioned to me once the secret of the longevity research community is that nobody reads a lot... just reading a few thousand papers a year is enough to accumulate a significant perspective on plausible approaches to not dying.
15:19:58gavinandresen:kanzure: anyway, my perspective on taking the "long term engineering" approach: http://gavinandresen.ninja/when-the-block-reward-goes-away
15:20:05kanzure:well, i have much to say on that topic, although i can't tell if you're being sarcastic in the good or bad way
15:21:05moarrr:hey gavinandresen, its Daniel Michael Abraham, how are you?
15:21:43moarrr:gavinandresen: /me is 1EW6G5DfewxJtAintR1pwVR6TpEYHFfwdZ
15:24:27c0rw1n_:c0rw1n_ is now known as c0rw1n
15:25:11temujin:gavinandresen: do you think Peter Todd's O(n^2) argument is invalid in the context of a single node? certainly all nodes verifying all transactions can be expressed as an n^2 complexity problem, but each individual node only needs to verify the entire blockchain once
15:27:04moarrr:* moarrr is concerned about bitcoin's development
15:29:03gavinandresen:temujin: yes, his argument is invalid in the context of a single node. And the scalability vision was never, ever, "every single user validates every single transaction" -- that is a straw-man
15:37:19akrmn:gavin clearly doesn't care about the O(n^2) problem, which basically means, if you keep increasing the block size, you eventually end up with one NSA-style node monitoring all transactions, and there is no more a transparent blockchain that is easy for everyone to see (which is convenient for government/corporate corruption to hide inside it)
15:38:53gavinandresen:* gavinandresen reminds himself not to feed trolls.....
15:39:11akrmn:there are ways to solve this problem, but as you will see, try to talk to him, and he will not be interested in the solutions
15:39:39CoinMuncher:respect, Gavin... respect!
15:40:18temujin:akrmn: my question was to make sure i understood correctly that the problem isn't actually a problem, it's just a scary way to say something not quite related to the problem to instill FUD
15:40:30moarrr:gavinandresen: being concerned makes one a troll?
15:40:38akrmn:temujin: How is it not a problem?
15:41:22temujin:i think you're the one making the claim there is a problem, are you not? it is true that the entire network complexity is O(n^2), but no single node has to do anywhere near that many calculations, it's just a "fun fact" more than anything
15:41:38temujin:explain the problem in detail
15:41:44CoinMuncher:From 1MB to 20MB is the same as from my RaspberryPi full node to NSA level of computing power? FUD much?
15:41:53akrmn:Yes each full node has to store O(n^2) unspent outputs as far as I understand
15:42:06akrmn:in order to validate
15:42:27akrmn:UTXO, someone can correct me if I'm wrong
15:42:31gavinandresen:ah, that might be the last post I haven't linked to today: http://gavinandresen.ninja/utxo-uhoh
15:42:38CoinMuncher:akrmn: "as far as I understand" first honest words so far
15:43:17akrmn:but basically, each full node has to validate all transactions, so even O(n) is bad (n is the number of transactions on the network)
15:43:34moarrr:* moarrr gives up - Daniel Michael Abraham
15:43:35moarrr:moarrr has left #bitcoin-wizards
15:43:47akrmn:my proposed solution splits the validation up so that not every full node has to verify every transaction
15:43:53c0rw1n:that is what makes it trust-free akrmn, why are you questioning the basic principle of bitcoin
15:44:05temujin:akrmn: UTXO bloat scales at worst _linearly_ with block size, and it's true that this is a problem, however it is understood that this problem should be solved before block sizes are increased
15:44:37temujin:there are a few easy solutions to that problem, which can be implemented without hard-forking the network
15:44:51gavinandresen:akrmn: yes, the definition of a full node is "validates all transactions" ... if you don't have the resources to validate all transactions, then you run as an SPV node. In the future, there might be options to probabalistically validate, and trust your neighbors will alert you if something you didn't validate is invalid.
15:45:50gavinandresen:akrmn: that is obviously not as secure as "I will validate all transactions myself" . I have proposed that we scale up so the cost of validating all transactions yourself remains modest.
15:46:04akrmn:You can read what I wrote about it on the mailing list (Scaling Bitcoins with Subchains). It's similar to the tree chains idea but solves some problems I think tree chains had, but it's actually quite a simple idea, but I don't want to bother gavin anymore about it. I was planning to ask some people later this week.
15:46:16akstunt600:gavinandresen, there is the same or more of risk to mempool bloat by not increasing the blocksize, in reguards to utxos
15:46:36akstunt600:that argument goes both ways really
15:46:40gavinandresen:akrmn: oh, you're the subchains guy. Sorry, your idea won't work.
15:46:52akrmn:ok then explain
15:47:24gavinandresen:I send a transaction that is on subchain eleven. It spends coins from subchains six through fourteen. How do I validate it?
15:47:53temujin:akstunt600: can you elaborate? how can there be risk of more bloat with smaller block sizes?
15:48:24akstunt600:backlogs, if blocks are filled mempool bloat not BS bloat
15:48:43akstunt600:i agree with what u said above temujin
15:48:45akrmn:gavinandresen: My restriction (I added it to my reply to the topic) was that only 2 sibling chains at a time can be involved in a transaction
15:49:02akrmn:So I hope that you're not trying to put more at a time
15:50:33CoinMuncher:How do you verify the sibling chain without verifying the next-sibling?
15:50:35gavinandresen:akrmn: how does that help? I'm validating subchain eleven. I get six hundred transactions, each on a maximum of 2 sibling chains. How do I avoid needed ALL of the sibling chains to validate those 600 transactions?
15:51:52gavinandresen:(... I mean to say: each SPENDING inputs from a maximum of 2 sibling chains...)
15:52:47jae:jae is now known as Guest59130
15:53:26temujin:akstunt600: i see, i misread your statement. you're right, but i think the fears about mempool bloat are overblown... a greater problem with the mempool "forgetting" backlogged transactions is user experience and logistics (re-broadcasting forgotten transactions). it isn't a strong DOS attack vector
15:53:37akrmn:gavinandresen: The coins have to be on subchain eleven or one other chain to be used (if you want to publish the transaction on 11). Though I have to think because I may be misunderstanding your question.
15:53:46akstunt600:temujin, 100% agree
15:53:57akstunt600:that is actually my greatest concern by FAR
15:54:08temujin:very annoying for businesses and users to have to deal with one more "gotcha", and a potential hurdle to adoption
15:54:21akstunt600:stuck tx are no fun and peter tods tool still would look terrible to "new" users
15:54:50gavinandresen:akrmn: "have to be on subchain eleven to be used" -- if users have to think about what subchains the coins in their wallets are on, then that's absolutely not workable. If you think wallets will just move coins from one subchain to another when needed... then you've just increased the transaction volume. And how does the moving work?
15:54:55akstunt600:yeah i would probably freak out if i were green and my money justy didnt send or dissapeared
15:55:03CoinMuncher:* CoinMuncher wonders if an apology to Gavin is near, after spreading FUD and "gavin clearly doesn't care about the O(n^2) problem" and "but as you will see, try to talk to him, and he will not be interested in the solutions"
15:55:24akstunt600:^ yes probably
15:55:39akstunt600:i think shit got taken out of context
15:55:47akrmn:gavinandresen: You make sure all your coins are on one path of subchains (or other paths if you want to track other identities)
15:55:48akstunt600:but i only know what i saw
15:56:00temujin:mempool weirdness and edge-cases cause some 3rd party wallets to bug out too
15:56:13akstunt600:i broke electrum a few times
15:56:26bramc:The appropriate behavior of a wallet when its transactions don't go through is to increase the fee over time until the transaction goes through.
15:56:49akrmn:Then you can send to someone whos on another chain. If you want more complex transactions involving multiple sibiling chains, then you have to do multiple transactions (that's ok)
15:57:11gavinandresen:akrmn: who is "you" ? If I've got coins in my wallet on subchain eleven, and I'm sending them to you but you're only validating subchain thirteen, what happens?
15:57:54akrmn:gavinandresen: I validate that your coins are fine by pulling in the headers of subchain 11
15:58:09frankenmint:akrmn: which software are you using?
15:58:14frankenmint:is it machine level or person level?
15:58:23akrmn:then the transaction gets store on both subchain 11 and 13
15:58:37akrmn:there are duplicates but it's ok
15:58:48gavinandresen:akrmn: That is equivalent to just running an SPV node that stores a random subset of the UTXO and validates what it can.
15:59:06gavinandresen:... which is fine, but isn't the same as running a fully validating node
15:59:37akrmn:gavinandresen: I run a fully validating node on subchain 13
15:59:56akrmn:SPV is risky only because you can have a denial of service (not see transactions)
16:00:14akrmn:but all I need is proof that I received coins on subchain 13
16:00:32frankenmint:gavinandresen: what is the ideal price target to holding a full node and do you have any opinions on the long term storage of chains? will this ultimately be a utliliatarian system or one that holds value in the consnsus users (the miners and node holders which vote by the sofware they opt to use)
16:00:33akrmn:the fully validating is needed to make sure that I see all transactions on 13 and in that path
16:01:03frankenmint:seems like ulitmately a conjunction will come together where one network would be used over the other but that one netowrk (largerblock) would be able to validate both
16:01:08akrmn:this is how distributed computing works. Not everyone does the same task, it is spread.
16:01:09bramc:My understanding from the blockchain people is that they don't mean for subchains to be a scaling solution, at least not by making lots of subchains. With everything merge-mined they wouldn't particularly help anyway.
16:01:27akrmn:though there will be lots of intersection at the top of the tree of chains.
16:01:36gavinandresen:frankenmint: I've said you should be able to run a full node as a hobby. And the average american spends about $50 per month on hobbies, so somewhere in the $20 to $50 per month range seems reasonable to me.
16:01:56frankenmint:gavinandresen: nope, not american - gotta think globally
16:01:57gavinandresen:frankenmint: There are lots of people who would argue "amateur hour is over" and say that's too low....
16:02:11frankenmint:gavinandresen: should be free
16:02:15gavinandresen:frankenmint: ok, if you can find stats on how much the average global citizen spends on hobbies, great.
16:02:16frankenmint:I know that's a really tall order
16:02:28kanzure:"amateur hour" is the wrong way to think about this. there are no "experts" when there's no authority anyway.
16:02:32akrmn:I don't care about your chocolate bar purchases on level 8 chains with 10^7 block size equivalent volume, I care only about my chocolate bar purchases, or whoever elses I want to track
16:02:35frankenmint:but ultimately, its about distribution and lowest ease of entry to ensure highest propegation
16:02:39gavinandresen:frankenmint: targeting the free level of Amazon EC2 would be an option. I haven't run the numbers.....
16:02:44akrmn:it gives flexibility, instead of "one size fits all"
16:03:17frankenmint:gavinandresen: the answer is zero
16:03:27frankenmint:I know that sounds crazy
16:03:28gavinandresen:http://aws.amazon.com/ec2/pricing/ ... looks like bandwidth wouldn't be the bottleneck... CPU might...
16:03:32akstunt600:IDK there seems to be an obvious path to resolution here IMO. Add in escalating fees to mempool and a way to kill stuck txs in the GUI, then proceed to looking at scheduled, algo, or hard cap blaocksize.
16:04:03kanzure:frankenmint: perhaps not zero but a good plan towards zero sounds like an interesting strategy to consider
16:04:19akstunt600:basically something to peter todds replacebyfee
16:05:33Taek:gavinandresen: I disagree with the emphasis on the cost of running a node from a datacenter. A node run from a datacenter means you are trusting the datacenter to run the node correctly.
16:05:50temujin:gavinandresen: I have a $50/month amazon medium server and it's just fine for a full node at the moment
16:05:55gavinandresen:Taek: trusting your ISP is better?
16:06:13akstunt600:heh goog point
16:06:15gavinandresen:Taek: until we have widespread mesh p2p networks you're going to have to trust somebody at least a little bit
16:06:29frankenmint:he means 'your isp'
16:06:46gavinandresen:(now somebody is going to say we shouldn't touch the block size until mesh network are widely deployed)
16:07:14akstunt600:hahhaha fahk, but thats chicken in the egg if you ask me
16:07:25temujin:i'm reminded of a reddit post on /r/bitcoin 2 years ago that went through the logical analysis of trusting each step in the supply chain of connecting to the internet, down to the last point of manufacturing your own silicon chips because there could be a manufacturer backdoor...
16:07:52akstunt600:yeah, that was great
16:08:05Taek:temujin: it's very daunting when you get down to it, especially since governments have been known to intercept computer parts and tamper with them
16:08:46temujin:Taek: yep, and it's cropped up in my real life, too. *thinks back to Lenovo self-signed cert attack from a few months ago*. good times!
16:09:58temujin:but realistically we can't worry about every little detail of trust, the system has to be decentralized _enough_ to get around any entity's attempt at censorship, which bitcoin is really good at right now
16:22:25stevenroose|BNC:stevenroose|BNC is now known as stevenroose
16:23:49dgenr8:SPV network nodes are the path to scalability IMHO
16:27:20akrmn:by the way
16:27:45akrmn:what I said is not equivalent to just storing random subsets, far from it, but I will write more about it
16:28:36dgenr8:but they won't store UTXO's. You can't prove an output is unspentm, but you can fail to prove it is spent. To use subsets effectively they can't be random .. they must be routable
16:28:37akrmn:also, an ISP can't fake digital cryptographic signatures if properly implemented, so not sure where that is going
16:30:19akrmn:dgenr8: ok will think about it. One thing you said makes sense.
16:37:46akrmn:If you have enough headers, you can prove it has valid outputs still unspent...but ya I need to think about other things damnit, this damn block size "surprise attack" is distracting.
16:39:57frankenmint:frankenmint has left #bitcoin-wizards
17:12:36jae:jae is now known as Guest36097
17:42:04temujin:can I have two OP_RETURN outputs in a single transaction on mainnet? i see them on testnet but don't see any on main net.
17:55:24hearn_:hearn_ is now known as hearn
18:00:15DanielBTC:DanielBTC is now known as Guest81362
18:04:12jae:jae is now known as Guest10940
18:22:03Dizzle_:Dizzle_ is now known as Dizzle
18:24:46frankenm_:frankenm_ has left #bitcoin-wizards
19:41:09tdryja:tdryja has left #bitcoin-wizards
19:43:03kanzure:does anyone have a good link to an overview of the current plans regarding formal verification and correctness of bitcoin consensus or at least script implementations?
19:54:03kanzure:it was something like: libbitcoinconsensus is being slowly converted over to a library that is more easily analyzed by formal verification and for correctness, probably going to be using z3 or coq somehow, and uhh then other node implementations will be strongly encouraged to use this formally verified library instead of relying on novel subtle side effects
20:02:23gmaxwell:kanzure: still infeasable while its written in C++, there are tools to subject C code to formal analysis, but I think it's unlikely to see anything like that for C++ anytime soon, as the language is so much more complex. But yes, it certantly moves things in that direction.
20:03:21kanzure:so are there any vague plans regarding those directions? rewriting in rust, haskell, c, something? and then is that something that we know anyone is working on at the moment?
20:06:08gmaxwell:Well keep in mind that there are many very different goals of applying formal methods to this code. One of them is making sure that it does what you expect (e.g. can people steal coins?), another is making sure that it doesn't result in a consensus fault in the system.
20:06:35gmaxwell:E.g. that it's consistent in all implementations, regardless of it doing anything in particular that anyone intended.
20:07:17gmaxwell:One thing that has been discussed is compiling the code to a bytecode which could be run by a very simple virtual machine (e.g. moxie), and the virtual machine could be very hard to implement wrong (and formally proven correct).
20:07:41gmaxwell:But beyond a bit of expirementation (which resulted in improvements to the moxie instruction set) there isn't a concrete plan with respect to that.
20:08:37gmaxwell:I'd like to do more fomal proving of libsecp256k1, which is written in C and somewhat with formal methods in mind (or at least I have some expirence with formal validation of C code and pushed out most of the things that tend to break it).
20:08:52gmaxwell:Since thats just a much smaller problem than all of libconsensus.
20:11:04gmaxwell:Rust is super nice from a software engineering perspective, but it's probably about as far from being itself subjectable to formal methods as C++ is, unfortunately.
20:13:27Populus_:Populus_ is now known as Populus
20:35:18andytoshi:note tho that rust has a stronger type system and is less likely to have consensus anomalies due to differences in systems. re formal analysis i think it's also a lot closer than C++ but still a loong way from C. but for doing things like contracts/assertions it's actually much better than C because it is designed with annotations (which are accessible to syntax extensions, which are sorta like lisp
20:35:20andytoshi:macros, at compile time)
20:38:13bramc:There's a big difference between formally proving the correctness of the codebase and formally proving the correctness of the protocol
20:38:27gmaxwell:andytoshi: yes, I was putting it equal to C++ because its new and not widely used yet, which offsets the relatively small advantages.
20:39:43bramc:You could prove that, say, it only ever accepts valid bitcoin histories and has no buffer overflows, but still have a ruinous bug in the logic to decide which of several forks to accept
20:40:13gmaxwell:Yes, thats also another layer. The protocol does with you intend, what you intend is what you would intend if you knew everything, the code implements the protocol, and this other code implements the same functionality... are all different problems.
20:41:10gmaxwell:And when "what you would intend" starts incorporating psychology or economics you start exiting the space where SMT solvers can save you. :)
20:47:44bramc:Even before that you get into things like 'Will usually propagate messages across the network with low latency in practice'
20:47:52bramc:Good luck 'proving' anything about that one.
20:48:23kanzure:but that's network stuff
20:48:44bramc:kanzure, The whole point of the codebase is to do network stuff!
20:49:18gmaxwell:bramc: See SEL4 though, they prove all kinds of important behaviors about their small microkernel written in C, including worst case latency. (obviously you have to approximate the network; which indeed limits the utility... but isn't it nice to know that it won't just spontaniously fail given _known_ network behaviors, or even a perfect network?)
20:50:26bramc:gmaxwell, You can prove things about a well-behaved network with specified behaviors, but the correlation between that and real networks, which behave sort of 'badly' is a bit tenuous
20:50:32bramc:Although yes, better than nothing.
21:38:45jgarzik_:jgarzik_ is now known as jgarzik
22:01:27belcher_:belcher_ is now known as belcher
22:33:22frankenmint:frankenmint has left #bitcoin-wizards
23:55:21Sub|afk:Sub|afk is now known as SubCreative