| 01:32:44 | rusty: | rusty has left #bitcoin-wizards |
| 01:52:45 | bramc: | Hey everybody |
| 01:52:55 | bramc: | I just published this: http://bramcohen.com/2015/06/02/gallus-and-simo-debate-whether-the-block-size-limit-should-be-increased |
| 01:52:55 | gmaxwell: | bramc: HI |
| 01:54:08 | bramc: | We'll see whether it proves to be controversial or ignored |
| 01:54:22 | bramc: | Hey gmaxwell |
| 01:54:29 | sipa: | * sipa guesses: both (without actually reading the linked document) |
| 01:54:44 | sipa: | (also: hello, i'm back from vacation) |
| 01:55:30 | bramc: | 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:43 | sipa: | 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:35 | bramc: | 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:51 | kanzure: | "Protecting privacy with electronic cash" hal finney 1993 http://fennetic.net/irc/extropy/ext10_1.pdf |
| 02:03:35 | bramc: | Any feedback on my post would be much appreciated |
| 02:05:21 | kanzure: | 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:42 | bramc: | kanzure, I've definitely seen that presented in total seriousness somewhere |
| 02:05:46 | kanzure: | 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:09 | bramc: | With 'somewhere' being not on this irc channel obviously |
| 02:06:51 | kanzure: | 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:10 | kanzure: | or at least, not quite disasters at first but at least stating various obvious consequences |
| 02:07:57 | bramc: | 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:10 | bramc: | It took me several hours to write that post today, even starting from extensive notes. |
| 02:08:54 | dgenr8: | bramc: thanks, now all my reddit-avoiding is for nothing |
| 02:09:39 | kanzure: | 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:48 | bramc: | 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:20 | kanzure: | 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:27 | bramc: | 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:53 | kanzure: | bramc: sure, i was just trying to preface my link and (poor substitute for a) link anchor |
| 02:11:42 | dgenr8: | 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:13 | kanzure: | everybody wont download it because the p2p graph is not fully saturated or something |
| 02:12:28 | kanzure: | insert appropriate graph theory term |
| 02:14:52 | bramc: | 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:35 | kanzure: | 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:35 | gwillen: | kanzure: fully-connected |
| 02:15:47 | dgenr8: | a node that downloads the whole thing will reject it because it's bigger than 1MB, or so it looks to me |
| 02:15:49 | kanzure: | gwillen: that's way too esoteric for me to remember |
| 02:15:56 | sipa: | dgenr8: bitcoin core master today will disconnect before the whole message is received in memory |
| 02:16:08 | sipa: | iirc 0.10.2 will do the same |
| 02:16:13 | bramc: | kanzure, Nobody goes there any more, the lines are too long |
| 02:16:29 | kanzure: | bramc: i mean from the logs and the locatio ni nthe logs that i pointed you at |
| 02:16:37 | dgenr8: | sipa: welcome back. so that's in the deserializer then? |
| 02:16:46 | sipa: | this is in the network code |
| 02:16:52 | sipa: | long before we even try to deserialize |
| 02:17:05 | bramc: | I would view fees of $10 as a serious problem to be dealt with. Fees of $0.01 are not. |
| 02:17:20 | kanzure: | bramc: $10 average fees are a problem why? |
| 02:17:52 | kanzure: | how else are you going to pick transactoins for inclusion? |
| 02:18:04 | gwillen: | kanzure: or 'complete' |
| 02:18:05 | bramc: | kanzure, At that price probably some totally reasonable transactions are getting held up. |
| 02:18:27 | kanzure: | gwillen: i'm just joshing you, yes that's correct terminology :-) |
| 02:18:42 | dgenr8: | sipa: ah, looks like 2MiB |
| 02:18:49 | gwillen: | kanzure: haha, sorry, it's hard to read tone of voice on IRC :-) |
| 02:18:52 | kanzure: | bramc: well there are many possible potentially reasonable transactoins, far more than bitcoin will ever be capable of handling at any scale |
| 02:19:02 | d3vz3r0: | what would be considered a ‘reasonable’ max transaction fee? |
| 02:19:07 | kanzure: | bramc: i mean we could trivially imagine billions of transactions per second that might be completely legitimate, in a large-enough civilization |
| 02:19:29 | d3vz3r0: | and what criteria would be for determining that transaction fee? |
| 02:19:39 | bramc: | 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:41 | kanzure: | d3vz3r0: users and wallets choose the transaction fee |
| 02:20:02 | kanzure: | bramc: i think that a lot of the current block size talk is motivated by concerns about eventually increasing transaction fees |
| 02:20:03 | d3vz3r0: | yes , Iknow that, but I’m really just asking the question in terms of what it means to be ‘too large’ |
| 02:20:32 | bramc: | kanzure, Yes that's clearly the subtext |
| 02:20:41 | kanzure: | hooray i am capable of reading |
| 02:21:12 | kanzure: | 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:31 | kanzure: | (or neutral about them) |
| 02:22:16 | bramc: | 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:45 | kanzure: | well, there are many potentially good transactions that wont happen because fees are too high (always) |
| 02:22:49 | bramc: | 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:54 | kanzure: | the only exception is when fees are literally-zero. but then what's the point of fees? |
| 02:23:12 | d3vz3r0: | I guess I’m wondering if there’s some formal way to determine what a ‘proper’ fee is |
| 02:23:26 | d3vz3r0: | and what are the economics behind how that fee should be selected |
| 02:23:33 | bramc: | d3vz3r0, I'm making a completely subjective statement about when I personally would start worrying |
| 02:23:49 | kanzure: | 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:53 | d3vz3r0: | I could potentially see cases where a 10$ fee is proper, and a .01$ fee is proper |
| 02:24:38 | d3vz3r0: | in the ‘normal’ world this is usually a percentage of the transaction value, ie 3% or something for visa |
| 02:24:39 | kanzure: | 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:41 | bramc: | 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:51 | kanzure: | there are also other complicated and boring "ask a miner for a fee estimation" schemes, but those get kinda wacky i think |
| 02:25:09 | kanzure: | bramc: er, is that currently implemented behavior? for all of them? |
| 02:25:31 | bramc: | (it's more complicated because of child pays, but that's the basic idea) |
| 02:25:32 | d3vz3r0: | a ‘fee bid’ market or some such thing |
| 02:25:42 | bramc: | kanzure, Probably not, but I'm being idealistic |
| 02:25:53 | kanzure: | alright |
| 02:26:15 | bramc: | The way wallets *should* behave is dependent on your assumption of whether it's receiver pays or sender pays |
| 02:26:50 | kanzure: | well for the moment let's assume receiver pays and child pays works |
| 02:27:09 | bramc: | 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:22 | bramc: | By 'receiver pays' I mean 'child pays' |
| 02:28:35 | d3vz3r0: | so it’s really just about fishing for miners |
| 02:28:56 | d3vz3r0: | at this point anyway.. .set the bait (fee) and hope that someone grabs yours before the others |
| 02:29:03 | bramc: | d3vz3r0, It's a general technique called escalator, nothing weird about it |
| 02:29:33 | d3vz3r0: | sure, I get the mechanism, but there’s not formal way of determining the proper fee for a transaction |
| 02:29:38 | d3vz3r0: | unless I’m completely missing something |
| 02:30:23 | bramc: | 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:32 | sipa: | d3vz3r0: you're not; "reasonable" in this context was a completely subjective, and presumably context and time-dependent assessment |
| 02:31:30 | d3vz3r0: | ah sure, “reasonable” means that historically that’s what has worked |
| 02:32:03 | d3vz3r0: | but what happens as the cost of operating a mining rig goes up significantly.. ie: bandwidth costs for a larger block size |
| 02:32:15 | d3vz3r0: | I guess that’s really where my interest lies in the fees arena |
| 02:32:29 | d3vz3r0: | does the ‘fee market’ naturally reset |
| 02:32:49 | d3vz3r0: | ie: miners start rejecting every transaction with fees under 1$ for example |
| 02:33:13 | bramc: | d3vz3r0, The fees are determined by the max block size, not how expensive it is to run a miner |
| 02:33:14 | d3vz3r0: | this is all just speculation and thought expiraments |
| 02:33:41 | moa: | bramc: currently |
| 02:33:42 | kanzure: | the fees are determined by max block size, demand for transaction inclusion, other transaction fees, other transactions, higher priority transactions, etc. etc.. |
| 02:33:56 | d3vz3r0: | how are the fees determined by max block size? |
| 02:34:14 | sipa: | they are depetermined by available block space |
| 02:34:23 | sipa: | sorry, influenced by, not determined by |
| 02:34:28 | kanzure: | 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:39 | sipa: | and available block space is a miner's decision, but it is also influence by the max block size consensus rules |
| 02:35:22 | moa: | kanzure: as reward goes away fees will be the incentive to secure the chain also |
| 02:36:24 | kanzure: | /win 2 |
| 02:36:27 | kanzure: | gah, fail :( |
| 02:36:30 | sipa: | /loose 2 |
| 02:36:54 | kanzure: | (lose) |
| 02:37:09 | bramc: | 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:14 | kanzure: | 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:24 | kanzure: | er, not simulations in this case; this just requires arithmetic. |
| 02:38:50 | bramc: | kanzure, The arithmetic is pretty simple, and right now it doesn't have to do with fees, just amounts to be fronted |
| 02:39:17 | bramc: | In that post I do the math on the current system. It's a bit sad. |
| 02:39:23 | kanzure: | 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:43 | bramc: | 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:25 | kanzure: | oh wait, it's easier to just mine zero-sized blocks instead |
| 02:41:27 | bramc: | 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:31 | kanzure: | well, i guess they might be interested in taking up hard drive space |
| 02:42:51 | moa: | interesting that all lot of miners are in china where they really do have bandwidth limitations |
| 02:43:22 | bramc: | kanzure, Reading through that log, Gavin seems to just keep repeating that transaction fees will go up and that that's bad. |
| 02:45:09 | bramc: | 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:11 | moa: | 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:12 | bramc: | moa, It's also bad if nobody gets ready to make it happen before rewards drop because there's no need to |
| 02:46:33 | kanzure: | bramc: right.. i think he wants lots of consumer adoption. |
| 02:46:53 | kanzure: | and believes that consumer adoption is incompatible with the other parts of bitcoin |
| 02:46:53 | d3vz3r0: | consumer adoption occurs due to low transactions fees is the assumption there? |
| 02:47:00 | moa: | bramc: quite |
| 02:49:25 | bramc: | 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:07 | d3vz3r0: | but if the money never leaves the system, it’s potentially a lot |
| 02:50:26 | bramc: | 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:43 | moa: | bramc: but if you wanted to perform 100's of mixing transactions then 100x$1 would be a consequence |
| 02:51:32 | bramc: | 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:16 | bramc: | moa, We already have perfectly good technology for making mixing vastly better than that |
| 02:53:40 | bramc: | 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:53 | moa: | 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:55 | moa: | but i think you make a good point about the guy who is going into btc not be influenced by $1 fee |
| 03:00:18 | kanzure: | 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:33 | bramc: | 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:05 | kanzure: | bramc: would the local cities be bidding? |
| 03:02:10 | kanzure: | (for residential water user) |
| 03:02:10 | bramc: | Oddly, that proposal is viewed as extremist by people on both sides of the political aisle. |
| 03:02:19 | kanzure: | *water use |
| 03:02:43 | kanzure: | (actually i'm not sure how california municipal water is configured. i assume city-based.) |
| 03:03:04 | bramc: | 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:11 | kanzure: | indeed |
| 03:03:24 | kanzure: | right, home use is something like 2%. perhaps they wouldn't be auctioning that off. |
| 03:03:44 | bramc: | 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:04 | moa: | pray for rain |
| 03:04:27 | bramc: | moa, a modest reduction in agricultural usage and our water problems would be gone |
| 03:04:33 | kanzure: | 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:41 | moa: | some food items too no doubt |
| 03:05:21 | bramc: | 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:38 | kanzure: | 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:41 | d3vz3r0: | the price of alfalfa would just go up |
| 03:05:48 | d3vz3r0: | to a point |
| 03:05:58 | bramc: | 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:20 | bramc: | kanzure, Yeah it's all the same stuff |
| 03:06:22 | kanzure: | do you mean city water price, or do you mean price of water from restuarants? |
| 03:06:32 | bramc: | I mean the retail price |
| 03:06:45 | ggreer: | https://twitter.com/DLin71/status/601068631854813185 |
| 03:06:48 | bramc: | Er, the price from your faucet, not the price of bottled water |
| 03:06:48 | kanzure: | .tw |
| 03:06:49 | yoleaux: | “WAGE AND PRICE DISTORTIONS WILL CONTINUE UNTIL MORALE IMPROVES” - California politicians (@DLin71) |
| 03:06:57 | kanzure: | wise words. |
| 03:07:18 | moa: | alfalfa is great stuff that keeps animals fed and highly nutritious too |
| 03:07:37 | c0rw1n: | c0rw1n is now known as c0rw|zZz |
| 03:07:42 | moa: | bottled water seems extravagant by comparison |
| 03:08:34 | kanzure: | 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:31 | kanzure: | 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:52 | kanzure: | (er, this is for fees significantly higher than $100 of course.) |
| 03:10:06 | d3vz3r0: | or it creates a market for transaction brokers |
| 03:10:59 | kanzure: | brokers that would do "matchmaking" to combine fees and transactions? |
| 03:11:25 | d3vz3r0: | yea, something like that |
| 03:11:49 | kanzure: | i don't know which one but there's at least one mixing network proposal that operates like that |
| 03:11:49 | d3vz3r0: | consolidating partial-chain or off-chain transactions for lower-fees |
| 03:13:06 | kanzure: | 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:24 | kanzure: | whoops i mean before it is signed |
| 03:13:29 | d3vz3r0: | yea, before it’s signed |
| 03:14:39 | NewLiberty: | More likely on alt-coins or side chains than brokers imp |
| 03:15:27 | kanzure: | altcoins aren't very likely; currency tends to be winner-takes-all. |
| 03:15:42 | kanzure: | however, you could easily argue that many bitcoin-powered sidechains can harbor altcoins, in which case i'll cede. |
| 03:20:21 | NewLiberty: | 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:35 | sipa: | god please stop saying that |
| 03:20:50 | sipa: | for everything blockstream wants to do, larger blocks would make things easier |
| 03:21:19 | NewLiberty: | I don't disagree. |
| 03:21:24 | kanzure: | 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:45 | kanzure: | (and not the fun kind) |
| 03:26:03 | kanzure: | .title http://www.faqs.org/rfcs/rfc1217.html |
| 03:26:03 | yoleaux: | RFC 1217 - Memo from the Consortium for Slow Commotion Research (RFC1217) |
| 03:48:40 | bramc: | 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:31 | bramc: | Or the following rant and entitle it 'How to block all bitcoin transactions of less than $10 using only $25,000' |
| 05:52:13 | gmaxwell: | 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:31 | gmaxwell: | This ring signature is a building block for a much bigger cryptosystem which I'll be publishing soon. |
| 05:52:46 | gmaxwell: | (also with code implementing whats in that paper too.) |
| 05:54:47 | gmaxwell: | 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:55 | jcorgan: | gmaxwell: will be a nice read, and a welcome change from all the politics recently. thanks. |
| 05:56:33 | akrmn: | can this be softforked into bitcoin? And what are the applications? More anonymity? |
| 05:57:22 | gmaxwell: | 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:03 | gmaxwell: | 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:53 | akrmn: | 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:56 | gmaxwell: | [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:59 | andytoshi: | 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:40 | andytoshi: | plus this doesn't even improve anonymity, it just has "ring signature" in the name so people'll think it does :) |
| 05:59:48 | gmaxwell: | 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:16 | gmaxwell: | well "done", as in actually usable. Nothing is ever really done. |
| 06:00:18 | akrmn: | Well ya it's good to wait until you are sure of something before you publish |
| 06:00:37 | leishman: | gmaxwell: thanks for sharing. looking forward to reading it |
| 06:00:41 | gmaxwell: | And have something that actually makes sense. Communicating is very hard, making good software is very hard, etc. |
| 06:01:53 | amiller: | this is fun |
| 06:02:35 | moa: | like rain on a hot day |
| 06:20:21 | amiller: | 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:03 | midnightmagic: | To publish early is unethical anyway. |
| 06:23:04 | andytoshi: | that's pretty close to "so simple it's obvious" :) |
| 06:23:11 | andytoshi: | amiller: ^ |
| 06:23:45 | andytoshi: | 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:54 | midnightmagic: | ... highly unethical, in some cases. It doesn't make sense to complain about work being done privately. |
| 06:26:30 | andytoshi: | 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:30 | gmaxwell: | 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:22 | gmaxwell: | (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:53 | gmaxwell: | Paper updated with a citation that fell out, https://github.com/Blockstream/borromean_paper/raw/master/borromean_draft_0.01_34241bb.pdf |
| 08:05:13 | asimov.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:13 | asimov.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:13 | asimov.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:13 | asimov.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:13 | asimov.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:13 | asimov.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:27 | jae: | jae is now known as Guest25520 |
| 10:08:56 | moa: | are borromean rings linked to trefoil knots? |
| 10:55:35 | stonecoldpat: | stonecoldpat has left #bitcoin-wizards |
| 11:55:51 | fluffypony: | 'The name "Borromean rings" comes from their use in the coat of arms of the aristocratic Borromeo family in Northern Italy.' |
| 11:55:59 | fluffypony: | TIL |
| 11:58:46 | nsh: | .wik Borromean ring |
| 11:58:46 | yoleaux: | "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:17 | nsh: | trefoil knots are a single...bit of string -- borromean rings are three disjoint but interlinked... bits of string |
| 12:00:45 | fluffypony: | I'm going to struggle not to pronounce it borrow-mean |
| 12:04:05 | Jaamg: | are there people who think that avg block size approaching max block size is actually desirable? |
| 12:06:35 | Taek: | jaamg: the bigger problem is the risks that accompany increasing the block size. |
| 12:07:51 | Jaamg: | Taek: that doesn't answer my question though |
| 12:10:27 | Taek: | 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:09 | Jaamg: | 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:54 | Jaamg: | I try to find someone to tell me why it isn't true |
| 12:16:05 | Jaamg: | if there is no such people, i think we should accept that as an axiom of some sort |
| 13:18:37 | fluffypony: | 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:55 | Jaamg: | fluffypony: that doesn't answer my question though |
| 13:19:03 | fluffypony: | the issue is with *when* the size should change, *how* it should change, *by how much* it should change |
| 13:19:37 | fluffypony: | Jaamg: to answer your very first question, yes |
| 13:19:38 | Jaamg: | fluffypony: what i want to know is: are there people who think that avg block size approaching max block size is desirable |
| 13:19:55 | Jaamg: | fluffypony: why would that be desirable? |
| 13:20:05 | fluffypony: | jtimon, afair, wanted it to happen to observe a fee market and gather real, meaningful data |
| 13:20:12 | frankenmint: | what is a large enough priority for free transactions to be sent? |
| 13:20:40 | fluffypony: | anyway, I'm getting on a plane, so a conversation for another time |
| 13:59:40 | Jaamg: | * Jaamg wonders why current data isn't real/meaningful and when will it become real/menaingful |
| 14:00:40 | gavinandresen: | frankenmint: there's a graph here: http://bitcoincore.org/smartfee/priority_graph.html |
| 14:00:59 | frankenmint: | nice that's the first time you've addressed me personally, thanks |
| 14:01:52 | frankenmint: | would you confirm that you potentially plan to work w/ mike hearn on xt if consensus cannot be reached on blocksize? |
| 14:02:18 | frankenmint: | 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:21 | gavinandresen: | yes, I think diversity and choice is good.... |
| 14:03:12 | zooko: | Hi folks. |
| 14:03:25 | gavinandresen: | howdy zooko |
| 14:04:29 | Taek: | 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:57 | akstunt600: | 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:24 | frankenmint: | what is priority a measure of? I thought it was perhaps seconds since last spend |
| 14:06:35 | frankenmint: | perhaps milliseconds? |
| 14:08:58 | gavinandresen: | 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:25 | gavinandresen: | frankenmint: See CCoinsViewCache::GetPriority and CTransaction::ComputerPriority for gory details |
| 14:09:26 | Jaamg: | Taek: why would the fees ever rise in an artificially limited system when people can switch to (more) free system? |
| 14:10:20 | gavinandresen: | Jaamg: ask an economist who knows a lot about pricing of commodities-- convenience, switching costs, security, reliability.... |
| 14:10:54 | gavinandresen: | I don't think many economists hang out here in -wizards... (chime in if I'm wrong) |
| 14:11:37 | stonecoldpat: | 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:38 | frankenmint: | Jaamg: creation of artificial barriers to facilitate commerce |
| 14:11:48 | akstunt600: | Honestly i dont think too many economists really understand the mechanics here. |
| 14:11:55 | frankenmint: | I'm speculating here: 21co is working with quallcomm and intel |
| 14:12:08 | frankenmint: | to allow users to trade earned btc for hardware locked overclocking |
| 14:12:31 | frankenmint: | so that continued use of device allows for a sort of 'free upgrade' |
| 14:13:02 | gavinandresen: | 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:57 | gavinandresen: | 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:13 | gavinandresen: | I also don't like "what will happen in eleven years..." speculating: http://gavinandresen.ninja/when-the-block-reward-goes-away |
| 14:15:49 | akstunt600: | well satishi kinda hinted that it needs to be popular by that time, right? |
| 14:16:00 | Taek: | 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:01 | akstunt600: | wehn sub ends |
| 14:16:14 | frankenmint: | 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:49 | gavinandresen: | frankenmint: http://gavinandresen.ninja/bigger-blocks-another-way |
| 14:16:52 | frankenmint: | such that larger sizing is required but a sustained increase has a cooldown period after X growth per period |
| 14:17:03 | akstunt600: | yeah kinda stuck to scheduled hard cap increase by blockheight, but that sucks in the case of exponetial growth |
| 14:17:31 | Jaamg: | 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:34 | akstunt600: | frankenmint, It has a bias toward smaller blocks that way :-/ |
| 14:17:37 | frankenmint: | akstunt600: what event would occur that isn't considered block spam at this point that would be considered such growth? |
| 14:18:14 | akstunt600: | frankenmint, not sure, but not a gamble i am willing to take. Remember PGP is on Facebook now. The times are changing |
| 14:19:17 | akstunt600: | Like i said above Satoshi intends on adoption in large numbers before subsidy issues come into play. |
| 14:20:01 | frankenmint: | 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:25 | gavinandresen: | 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:26 | akstunt600: | could yeah |
| 14:20:33 | akstunt600: | but doesnt have security of the main chain |
| 14:20:53 | stonecoldpat: | gavinandresen: cheers, that makes sense then (its not been tried and tested). |
| 14:20:55 | akstunt600: | well not the same level* you know what i mean |
| 14:21:13 | gavinandresen: | in any case, this is all not -wizards-level discussion. |
| 14:21:19 | kanzure: | 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:33 | kanzure: | or wait, er, "things that don't get into the blockchain" are not always spam |
| 14:21:38 | kanzure: | sorry, i got it backwards |
| 14:22:19 | Taek: | 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:32 | frankenmint: | gavinandresen: when is pruning scheduled to be available on core implementation? |
| 14:22:39 | priidu: | i hope things don't go as far as a serious fork in bitcoin development (i.e. XT vs Core) |
| 14:22:42 | kanzure: | Taek: i believe gavinandresen disagrees with that (although i'm still trying to figure out why) |
| 14:22:44 | frankenmint: | not that this has anything to do w/ trx limits currently |
| 14:23:34 | priidu: | that would make me feel much like a lost child in the midst of a messy divorce |
| 14:23:45 | zooko: | lol |
| 14:23:57 | frankenmint: | priidu: i read that someplace else earlier today from you :) |
| 14:24:06 | zooko: | priidu: thank you for that. I think that's a serious truth for me to remember. |
| 14:24:21 | akstunt600: | kanzure, I hope that is not the case. |
| 14:24:22 | zooko: | We love *both* gavinandresen *and* gmaxwell, and we don't want them to fight! |
| 14:24:27 | priidu: | frankenmint: yes, i think i might have said it once earlier :p |
| 14:24:28 | gavinandresen: | 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:33 | akstunt600: | no infighting!!! lol |
| 14:24:39 | gavinandresen: | frankenmint: pruning is in the lastes Core release. |
| 14:25:00 | gavinandresen: | I'm not fighting with gmaxwell, I just disagree with him about timing and vision for scaling up. |
| 14:25:22 | akstunt600: | pruning is whicked fast another sync in only 6 hours or so |
| 14:25:32 | akstunt600: | wicked* |
| 14:26:04 | gavinandresen: | 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:12 | kanzure: | hmm |
| 14:26:35 | kanzure: | 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:40 | akstunt600: | Awesome! |
| 14:26:45 | gavinandresen: | kanzure: absolutely. |
| 14:27:25 | kanzure: | ah right; now i remember. yesterday the concern was more oriented towards "(perhaps perpetually) extremely high fees", not full blocks. |
| 14:27:41 | gavinandresen: | 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:36 | kanzure: | 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:50 | gavinandresen: | kanzure: applications are already driven off-chain because of the transaction fee market. |
| 14:35:28 | kanzure: | that's always going to be true (e.g. there are some applications that will always prefer zero transaction fees, i think) |
| 14:35:42 | gavinandresen: | 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:45 | kanzure: | (i mean; they also have to compete with other transactions just on size alone, so...) |
| 14:36:48 | kanzure: | i think we need more words for off-chain and partial-chain tech stuff |
| 14:37:14 | kanzure: | by which i mean names |
| 14:37:31 | Jaamg: | 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:34 | zooko: | Heya bramc. |
| 14:38:37 | gavinandresen: | bramc: I enjoyed the Gallus and Simo debate |
| 14:38:44 | bramc: | Hey zooko |
| 14:39:16 | kanzure: | 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:23 | bramc: | gavinandresen, Thanks, it was an earnest attempt to engage in technical discussion rather than just rant |
| 14:39:33 | gavinandresen: | bramc: ... although you lost me at merge-mining.... |
| 14:39:35 | kanzure: | 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:18 | zooko: | Where was this earnest discussion posted? May I have a link? |
| 14:40:22 | gavinandresen: | http://bramcohen.com/2015/06/02/gallus-and-simo-debate-whether-the-block-size-limit-should-be-increased |
| 14:40:29 | helo: | 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:00 | kanzure: | helo: that is hard to deterimne, plus it's not -wizards appropriate :P |
| 14:41:07 | helo: | doh :P |
| 14:41:15 | bramc: | 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:54 | priidu: | helo: still though... it'd be understandable if we already had 20MB and someone was trying to push 200MB blocks |
| 14:42:54 | priidu: | helo: but 1MB -> 20MB isn't really that bad imho, on the other hand it would give some serious headroom |
| 14:43:27 | gavinandresen: | 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:43 | kanzure: | if the money supply is doubled then you might as well do merge mining i think |
| 14:44:02 | bramc: | 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:05 | kanzure: | i mean "in the event that the scenario ends up being that the supply has doubled..." |
| 14:45:12 | gavinandresen: | bramc: Bitshare? Too many bitcoin companies with 'bit' in their name for me to keep track of.... |
| 14:45:45 | kanzure: | he probably means bitshares |
| 14:45:49 | helo: | 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:32 | bramc: | 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:34 | gavinandresen: | helo: you just pushed one of my pet peeve buttons... "totally" unpredictable? Really? totally? |
| 14:47:00 | helo: | gavinandresen: well, you just lost the moral high ground by ignoring everything but one word :P |
| 14:47:03 | kanzure: | yes at any moment transactions can spontaneously turn into blocks or something. totally unpredictable. |
| 14:47:35 | kanzure: | helo: nah you said "until this happens". but some aspects are predictable before that. |
| 14:47:48 | gavinandresen: | 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:58 | akstunt600: | ehh, i just realized the fee market is irrelevant until the sub is in the dirt. |
| 14:49:18 | akstunt600: | fee market is critical for long term, but does it really matter right now? |
| 14:49:26 | gavinandresen: | akstunt600: yes, I wrote about that, too: http://gavinandresen.ninja/block-size-and-miner-fees-again |
| 14:49:28 | kanzure: | sub? |
| 14:49:33 | akstunt600: | subsidy |
| 14:51:27 | akstunt600: | thanks, and well said |
| 14:51:28 | Jaamg: | when "fee market" happens, it means that people are already pissed off by the slow confirmations |
| 14:51:41 | akstunt600: | Im glad that you recognize the important of the exchange rate in all this too |
| 14:51:50 | akstunt600: | importance* |
| 14:52:01 | kanzure: | Jaamg: user expectations should be shaped by system capabilities in many cases |
| 14:52:59 | kanzure: | 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:48 | akstunt600: | kanzure, LOL, eveyone is too depressed to talk about BTC going to mewn. :p |
| 14:54:07 | kanzure: | that's not what i mean |
| 14:54:26 | gavinandresen: | 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:35 | kanzure: | i agree that you do not make that argument |
| 14:54:48 | kanzure: | i was stating that i was surprised that i don't see anyone making that argument at all |
| 14:55:15 | akstunt600: | yeah kanzure Im saying the small miers, alot of them got down on their spirits and left or sold miners. |
| 14:55:24 | helo: | from the perspective of establishing long term business plan, "totally unpredictable" is a fine characterization at this point in the experiment |
| 14:55:42 | akstunt600: | lot of bad information and underperforming asics out there to really drive the point home too |
| 14:56:45 | priidu: | helo: what's "totally predictable" though? only death and taxes |
| 14:56:59 | akstunt600: | Which really really sux IMO, as im still profitable with my old s3+ |
| 14:57:11 | akstunt600: | s3+'s |
| 14:57:14 | gavinandresen: | ... trolls in any public forum are also completely predictable.... |
| 14:57:29 | Jaamg: | 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:11 | c0rw1n_: | priidu: hang around transhumanist libertarians enough and the unavoidability of those begin to seem like technical problems soon to be solved |
| 14:59:00 | kanzure: | c0rw1n_: yes |
| 14:59:21 | kanzure: | 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:52 | kanzure: | oh i suspect it is a missing word- i think your sentence needs to hvae the word "developers" added to it perhaps? |
| 15:01:07 | akstunt600: | they dont care. they just want to ship the smallest block to help prevent against orphan. Dat .3% |
| 15:01:15 | helo: | the bathysphere hasn't even been exposed to pressures at depth, and we're installing stadium seating |
| 15:01:31 | nsh: | * nsh smiles |
| 15:01:33 | helo: | okay, work time... i'll stop being offtopic |
| 15:02:55 | akstunt600: | trolololol |
| 15:04:53 | bramc: | kanzure, Ah I have a copy editing problem there which makes it look funny |
| 15:05:35 | bramc: | kanzure, It's a point about miners though, there isn't much in it for miners to increase the max block size |
| 15:06:16 | kanzure: | miners can squash out smaller-scale miners that don't have resources for handling larger blocks (significantly larger, mind you). |
| 15:07:27 | bramc: | kanzure, I doubt that block sizes below something like a gigabyte would be a serious issue for anyone actually running a miner |
| 15:07:42 | kanzure: | right, i'd agree with that estimation |
| 15:08:29 | bramc: | 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:53 | bramc: | gavinandresen, It does not appear to be a parody. |
| 15:09:15 | bramc: | At least, not an *intentional* parody |
| 15:13:00 | gavinandresen: | kanzure: no, they can't: http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners |
| 15:14:26 | kanzure: | everything in that post is completely unrelated to what i was just talking about |
| 15:14:59 | kanzure: | 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:40 | gavinandresen: | 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:49 | gavinandresen: | kanzure: if we were talking gigabyte-sized blocks then I would agree costs would get significant. |
| 15:17:20 | kanzure: | in general i prefer to talk about "in the limit" because that helps inform long-reaching engineering implications somewhat |
| 15:17:46 | gavinandresen: | kanzure: in the limit, we all die.... |
| 15:18:13 | kanzure: | that's only because nobody is trying http://diyhpl.us/~bryan/papers2/longevity/ |
| 15:18:42 | gavinandresen: | 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:53 | kanzure: | 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:58 | gavinandresen: | kanzure: anyway, my perspective on taking the "long term engineering" approach: http://gavinandresen.ninja/when-the-block-reward-goes-away |
| 15:20:05 | kanzure: | 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:05 | moarrr: | hey gavinandresen, its Daniel Michael Abraham, how are you? |
| 15:21:43 | moarrr: | gavinandresen: /me is 1EW6G5DfewxJtAintR1pwVR6TpEYHFfwdZ |
| 15:24:27 | c0rw1n_: | c0rw1n_ is now known as c0rw1n |
| 15:25:11 | temujin: | 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:04 | moarrr: | * moarrr is concerned about bitcoin's development |
| 15:29:03 | gavinandresen: | 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:19 | akrmn: | 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:53 | gavinandresen: | * gavinandresen reminds himself not to feed trolls..... |
| 15:39:11 | akrmn: | 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:39 | CoinMuncher: | respect, Gavin... respect! |
| 15:40:18 | temujin: | 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:30 | moarrr: | gavinandresen: being concerned makes one a troll? |
| 15:40:38 | akrmn: | temujin: How is it not a problem? |
| 15:41:22 | temujin: | 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:38 | temujin: | explain the problem in detail |
| 15:41:44 | CoinMuncher: | From 1MB to 20MB is the same as from my RaspberryPi full node to NSA level of computing power? FUD much? |
| 15:41:53 | akrmn: | Yes each full node has to store O(n^2) unspent outputs as far as I understand |
| 15:42:06 | akrmn: | in order to validate |
| 15:42:10 | temujin: | wat |
| 15:42:27 | akrmn: | UTXO, someone can correct me if I'm wrong |
| 15:42:31 | gavinandresen: | ah, that might be the last post I haven't linked to today: http://gavinandresen.ninja/utxo-uhoh |
| 15:42:38 | CoinMuncher: | akrmn: "as far as I understand" first honest words so far |
| 15:43:17 | akrmn: | 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:34 | moarrr: | * moarrr gives up - Daniel Michael Abraham |
| 15:43:35 | moarrr: | moarrr has left #bitcoin-wizards |
| 15:43:47 | akrmn: | my proposed solution splits the validation up so that not every full node has to verify every transaction |
| 15:43:53 | c0rw1n: | that is what makes it trust-free akrmn, why are you questioning the basic principle of bitcoin |
| 15:44:05 | temujin: | 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:37 | temujin: | there are a few easy solutions to that problem, which can be implemented without hard-forking the network |
| 15:44:51 | gavinandresen: | 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:50 | gavinandresen: | 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:04 | akrmn: | 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:16 | akstunt600: | gavinandresen, there is the same or more of risk to mempool bloat by not increasing the blocksize, in reguards to utxos |
| 15:46:36 | akstunt600: | that argument goes both ways really |
| 15:46:40 | gavinandresen: | akrmn: oh, you're the subchains guy. Sorry, your idea won't work. |
| 15:46:52 | akrmn: | ok then explain |
| 15:47:24 | gavinandresen: | I send a transaction that is on subchain eleven. It spends coins from subchains six through fourteen. How do I validate it? |
| 15:47:53 | temujin: | akstunt600: can you elaborate? how can there be risk of more bloat with smaller block sizes? |
| 15:48:24 | akstunt600: | backlogs, if blocks are filled mempool bloat not BS bloat |
| 15:48:43 | akstunt600: | i agree with what u said above temujin |
| 15:48:45 | akrmn: | 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:02 | akrmn: | So I hope that you're not trying to put more at a time |
| 15:50:33 | CoinMuncher: | How do you verify the sibling chain without verifying the next-sibling? |
| 15:50:35 | gavinandresen: | 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:52 | gavinandresen: | (... I mean to say: each SPENDING inputs from a maximum of 2 sibling chains...) |
| 15:52:47 | jae: | jae is now known as Guest59130 |
| 15:53:26 | temujin: | 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:37 | akrmn: | 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:46 | akstunt600: | temujin, 100% agree |
| 15:53:57 | akstunt600: | that is actually my greatest concern by FAR |
| 15:54:08 | temujin: | very annoying for businesses and users to have to deal with one more "gotcha", and a potential hurdle to adoption |
| 15:54:21 | akstunt600: | stuck tx are no fun and peter tods tool still would look terrible to "new" users |
| 15:54:50 | gavinandresen: | 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:55 | akstunt600: | yeah i would probably freak out if i were green and my money justy didnt send or dissapeared |
| 15:55:03 | CoinMuncher: | * 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:24 | akstunt600: | ^ yes probably |
| 15:55:30 | akstunt600: | IMO |
| 15:55:39 | akstunt600: | i think shit got taken out of context |
| 15:55:47 | akrmn: | 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:48 | akstunt600: | but i only know what i saw |
| 15:56:00 | temujin: | mempool weirdness and edge-cases cause some 3rd party wallets to bug out too |
| 15:56:08 | akstunt600: | yup |
| 15:56:13 | akstunt600: | i broke electrum a few times |
| 15:56:26 | bramc: | 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:49 | akrmn: | 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:11 | gavinandresen: | 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:54 | akrmn: | gavinandresen: I validate that your coins are fine by pulling in the headers of subchain 11 |
| 15:58:09 | frankenmint: | akrmn: which software are you using? |
| 15:58:14 | frankenmint: | is it machine level or person level? |
| 15:58:23 | akrmn: | then the transaction gets store on both subchain 11 and 13 |
| 15:58:37 | akrmn: | there are duplicates but it's ok |
| 15:58:48 | gavinandresen: | 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:06 | gavinandresen: | ... which is fine, but isn't the same as running a fully validating node |
| 15:59:37 | akrmn: | gavinandresen: I run a fully validating node on subchain 13 |
| 15:59:56 | akrmn: | SPV is risky only because you can have a denial of service (not see transactions) |
| 16:00:14 | akrmn: | but all I need is proof that I received coins on subchain 13 |
| 16:00:32 | frankenmint: | 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:33 | akrmn: | the fully validating is needed to make sure that I see all transactions on 13 and in that path |
| 16:01:03 | frankenmint: | 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:08 | akrmn: | this is how distributed computing works. Not everyone does the same task, it is spread. |
| 16:01:09 | bramc: | 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:27 | akrmn: | though there will be lots of intersection at the top of the tree of chains. |
| 16:01:36 | gavinandresen: | 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:56 | frankenmint: | gavinandresen: nope, not american - gotta think globally |
| 16:01:57 | gavinandresen: | frankenmint: There are lots of people who would argue "amateur hour is over" and say that's too low.... |
| 16:02:11 | frankenmint: | gavinandresen: should be free |
| 16:02:15 | gavinandresen: | frankenmint: ok, if you can find stats on how much the average global citizen spends on hobbies, great. |
| 16:02:16 | frankenmint: | I know that's a really tall order |
| 16:02:28 | kanzure: | "amateur hour" is the wrong way to think about this. there are no "experts" when there's no authority anyway. |
| 16:02:32 | akrmn: | 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:35 | frankenmint: | but ultimately, its about distribution and lowest ease of entry to ensure highest propegation |
| 16:02:39 | gavinandresen: | frankenmint: targeting the free level of Amazon EC2 would be an option. I haven't run the numbers..... |
| 16:02:44 | akrmn: | it gives flexibility, instead of "one size fits all" |
| 16:03:17 | frankenmint: | gavinandresen: the answer is zero |
| 16:03:27 | frankenmint: | I know that sounds crazy |
| 16:03:28 | gavinandresen: | http://aws.amazon.com/ec2/pricing/ ... looks like bandwidth wouldn't be the bottleneck... CPU might... |
| 16:03:32 | akstunt600: | 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:03 | kanzure: | frankenmint: perhaps not zero but a good plan towards zero sounds like an interesting strategy to consider |
| 16:04:19 | akstunt600: | basically something to peter todds replacebyfee |
| 16:04:29 | akstunt600: | s/to/like/ |
| 16:05:33 | Taek: | 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:50 | temujin: | gavinandresen: I have a $50/month amazon medium server and it's just fine for a full node at the moment |
| 16:05:55 | gavinandresen: | Taek: trusting your ISP is better? |
| 16:06:13 | akstunt600: | heh goog point |
| 16:06:15 | gavinandresen: | Taek: until we have widespread mesh p2p networks you're going to have to trust somebody at least a little bit |
| 16:06:29 | frankenmint: | he means 'your isp' |
| 16:06:46 | gavinandresen: | (now somebody is going to say we shouldn't touch the block size until mesh network are widely deployed) |
| 16:07:14 | akstunt600: | hahhaha fahk, but thats chicken in the egg if you ask me |
| 16:07:25 | temujin: | 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:52 | akstunt600: | yeah, that was great |
| 16:08:05 | Taek: | 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:46 | temujin: | 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:58 | temujin: | 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:25 | stevenroose|BNC: | stevenroose|BNC is now known as stevenroose |
| 16:23:49 | dgenr8: | SPV network nodes are the path to scalability IMHO |
| 16:27:20 | akrmn: | by the way |
| 16:27:45 | akrmn: | what I said is not equivalent to just storing random subsets, far from it, but I will write more about it |
| 16:28:36 | dgenr8: | 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:37 | akrmn: | also, an ISP can't fake digital cryptographic signatures if properly implemented, so not sure where that is going |
| 16:30:19 | akrmn: | dgenr8: ok will think about it. One thing you said makes sense. |
| 16:37:46 | akrmn: | 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:57 | frankenmint: | frankenmint has left #bitcoin-wizards |
| 17:12:36 | jae: | jae is now known as Guest36097 |
| 17:42:04 | temujin: | 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:24 | hearn_: | hearn_ is now known as hearn |
| 18:00:15 | DanielBTC: | DanielBTC is now known as Guest81362 |
| 18:04:12 | jae: | jae is now known as Guest10940 |
| 18:22:03 | Dizzle_: | Dizzle_ is now known as Dizzle |
| 18:24:46 | frankenm_: | frankenm_ has left #bitcoin-wizards |
| 19:41:09 | tdryja: | tdryja has left #bitcoin-wizards |
| 19:43:03 | kanzure: | 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:03 | kanzure: | 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:23 | gmaxwell: | 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:21 | kanzure: | 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:08 | gmaxwell: | 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:35 | gmaxwell: | E.g. that it's consistent in all implementations, regardless of it doing anything in particular that anyone intended. |
| 20:07:17 | gmaxwell: | 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:41 | gmaxwell: | 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:37 | gmaxwell: | 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:52 | gmaxwell: | Since thats just a much smaller problem than all of libconsensus. |
| 20:11:04 | gmaxwell: | 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:27 | Populus_: | Populus_ is now known as Populus |
| 20:35:18 | andytoshi: | 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:20 | andytoshi: | macros, at compile time) |
| 20:38:13 | bramc: | There's a big difference between formally proving the correctness of the codebase and formally proving the correctness of the protocol |
| 20:38:27 | gmaxwell: | 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:43 | bramc: | 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:13 | gmaxwell: | 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:10 | gmaxwell: | And when "what you would intend" starts incorporating psychology or economics you start exiting the space where SMT solvers can save you. :) |
| 20:47:44 | bramc: | Even before that you get into things like 'Will usually propagate messages across the network with low latency in practice' |
| 20:47:52 | bramc: | Good luck 'proving' anything about that one. |
| 20:48:23 | kanzure: | but that's network stuff |
| 20:48:44 | bramc: | kanzure, The whole point of the codebase is to do network stuff! |
| 20:49:18 | gmaxwell: | 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:26 | bramc: | 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:32 | bramc: | Although yes, better than nothing. |
| 21:38:45 | jgarzik_: | jgarzik_ is now known as jgarzik |
| 22:01:27 | belcher_: | belcher_ is now known as belcher |
| 22:33:22 | frankenmint: | frankenmint has left #bitcoin-wizards |
| 23:55:21 | Sub|afk: | Sub|afk is now known as SubCreative |