1 2015-11-30 11:13:00 <rook520> Are we the next 1%?
  2 2015-11-30 11:13:20 <chmod755> possibly
  3 2015-11-30 11:13:32 <rook520> This is amazing..
  4 2015-11-30 11:13:34 <Diablo-D3> yes
  5 2015-11-30 11:13:39 <jeremias> depends who you mean by "we"
  6 2015-11-30 11:13:50 <sipa> #bitcoin please
  7 2015-11-30 11:14:04 <rook520> Active bitcoin farmers trying to farm as much as possible...?
  8 2015-11-30 13:51:54 <BW^-> 0.11.2 gives me "Leaving block file [N]: CBlockFileInfo(blocks=0, size=0, heights=0...0, time=1970-01-01...1970-01-01)"
  9 2015-11-30 13:52:01 <BW^-> it said 1970 for all block files until now
 10 2015-11-30 13:52:22 <BW^-> i don't know if anything is broken about my leveldb implementation but if not then that date report is clearly a bug?
 11 2015-11-30 13:52:30 <sipa> BW^-: known bug
 12 2015-11-30 13:52:39 <sipa> not sure if it's already fixed in master
 13 2015-11-30 13:52:48 <sipa> it's harmelss
 14 2015-11-30 13:52:51 <sipa> *harmess
 15 2015-11-30 13:52:54 <sipa> **harmless
 16 2015-11-30 13:52:56 <BW^-> aha ot it.
 17 2015-11-30 13:52:58 <BW^-> super. thanks.
 18 2015-11-30 13:53:17 <BW^-> good to know there's not like random bitrot going on in my installation so there could be unexpected surprises later - thanks.
 19 2015-11-30 14:03:02 <tulip> sipa: it's fixed in master.
 20 2015-11-30 14:03:29 <sipa> good
 21 2015-11-30 15:11:46 <btcdrak> BlueMatt: https://www.reddit.com/r/Bitcoin/comments/3uugeu/bip65_is_66_on_the_way_to_first_activation/cxhvupi?context=3
 22 2015-11-30 20:30:05 <jtimon> sdaftuar: what do you mean in https://github.com/bitcoin/bitcoin/pull/6312/files#r46195041 isn't it made in https://github.com/bitcoin/bitcoin/pull/6312/files#diff-7ec3c68a81efff79b6ca22ac1f1eabbaR644 https://github.com/bitcoin/bitcoin/pull/6312/files#diff-7ec3c68a81efff79b6ca22ac1f1eabbaR972 ?
 23 2015-11-30 20:31:06 <sdaftuar> ah i think i missed that
 24 2015-11-30 20:31:17 <sdaftuar> thanks
 25 2015-11-30 20:32:29 <sdaftuar> (comment redacted)
 26 2015-11-30 20:34:44 <jtimon> sdaftuar: thanks
 27 2015-11-30 21:34:05 <ploopkazoo> can someone eli5 how a hypothetical very large block size would cause problems? if, for example, the size were raised to 1GB, would 1GB blocks magically appear even though there aren't 1GB of transactions?
 28 2015-11-30 21:35:07 <Prattler> they could appear if malicious miner wanted it. You can create transactions in  your own block for free, if you want to.
 29 2015-11-30 21:35:53 <Prattler> this is, of course, hypothetical, haven't been such attacks so far, except by Luke-Jr perhaps
 30 2015-11-30 21:38:52 <ploopkazoo> how is a malicious miner putting transactions in their own block different from any given node making transactions?
 31 2015-11-30 21:39:33 <Prattler> miner's transactions are going into the blockchain and utxo, whereas a regular node has no such power (wihout paying fees)
 32 2015-11-30 21:40:16 <ploopkazoo> ah
 33 2015-11-30 21:40:33 <sipa> ploopkazoo: every node in the network has the process the transactions that miners put into blocks; at some point, the costs for running them may disincentivize people from actually running them
 34 2015-11-30 21:41:06 <ploopkazoo> so if there were no block size limit, a large pool owner could just generate terabytes of valid transactions and put them in their own block to massively inconvenience everyone?
 35 2015-11-30 21:41:14 <sipa> yes
 36 2015-11-30 21:41:26 <Prattler> For example, hypothetically a miner could offer a "backup data on blockchain". They would offload their costs to the network full nodes, profit themselves and destroy bitcoin.
 37 2015-11-30 21:41:55 <sipa> would they do so? maybe not, it is controversial whether there are incentives for that, but there is no need why full nodes would accept that
 38 2015-11-30 21:42:32 <Prattler> ploopkazoo, not only inconvenience, but they would be earning profit themselves and causing financial damage to all full nodes. In theory. Maybe..
 39 2015-11-30 21:42:35 <Prattler> Without any limit.
 40 2015-11-30 21:42:39 <sipa> unfortunately, apart from the trust question, the system works _better_ the more centralized it is
 41 2015-11-30 21:42:56 <ploopkazoo> what are the core devs' opinions on timing and amount of block size limit increase?
 42 2015-11-30 21:43:17 <sipa> there is a conference held in hong kong next week about the topic
 43 2015-11-30 21:43:31 <jouke> This saturday even :)
 44 2015-11-30 21:44:05 <sipa> my personal opinion is that we should merge any proposed change which is uncontroversial
 45 2015-11-30 21:44:46 <ploopkazoo> is there any data on what percentage of full nodes support BIP 101?
 46 2015-11-30 21:45:06 <Prattler> ploopkazoo, xtnodes.com . Some are stealth BIP 101 nodes though.
 47 2015-11-30 21:45:14 <gmaxwell> ploopkazoo: we've seen considerable and clear degregation of the system ever at current load levels; so we much act with great caution. IMO dicussion about the block size parameter is a distraction from far more significant and severe issues that we face.
 48 2015-11-30 21:45:50 <jouke> ploopkazoo: https://data.bitcoinity.org/bitcoin/block_version/7d?c=block_version&r=hour&t=a
 49 2015-11-30 21:45:55 <ploopkazoo> gmaxwell: which issues?
 50 2015-11-30 21:46:24 <ploopkazoo> I haven't really been paying attention to Bitcoin for several months now
 51 2015-11-30 21:46:45 <tulip> ploopkazoo: given that today a single block can take a minute to verify, 1GB blocks are clearly going to cause problems.
 52 2015-11-30 21:46:50 <gmaxwell> ploopkazoo: Fungibility-- specifically in terms of the incredible amounts of coin blacklisting going on, and the ongoing failure of decenteralization as more and more users stop running nodes and instead use centeralized APIs.
 53 2015-11-30 21:47:42 <Prattler> gmaxwell, shouldn't it be easier to mix coins as there's more users and more tx capacity on the network?
 54 2015-11-30 21:47:43 <gmaxwell> As well as the centeralization of the mining ecosystem; which has transitioned much most strongly to centeralized physical control of hardware and not just mining pool centeralization as we had in the past.
 55 2015-11-30 21:47:43 <ploopkazoo> I was unaware that blacklisting was happening at any notable rate
 56 2015-11-30 21:48:51 <Prattler> should be easier to implement blacklisting with 1 kB limit vs 1 MB limit, for example
 57 2015-11-30 21:49:36 <Prattler> 10 kB vs 1 MB let's say
 58 2015-11-30 21:49:51 <gmaxwell> Prattler: all of these attacks focus on centeralized chokepoints. When parties are driven by costs to depend on centeralized APIs, as they are already, then pressure to blacklist needs only be applied at those places-- and thats what we're actually seeing now.
 59 2015-11-30 21:50:27 <ploopkazoo> gmaxwell: centeralized physical control of hardware meaning operations like the multi-petahash Chinese mining warehouses?
 60 2015-11-30 21:51:18 <gmaxwell> Prattler: 1MB is at the level of a half million transactions/day; that is enough that it isn't a visible factor in blacklisting.  An important insight is that at either extreme the system doesn't work.
 61 2015-11-30 21:52:08 <gmaxwell> ploopkazoo: Yes, for example. (thoug chinese operations are just one of the better known bits of consolidation)
 62 2015-11-30 21:53:06 <gmaxwell> Today block size plays into that in serveral ways. One is that delays in processing and propagating blocks yield non-linear gains to those who hold more hashpower, making them more profitable, allowing them to acquire even more hashpower while difficuly rises push the rest out.
 63 2015-11-30 21:53:31 <Prattler> gmaxwell, who would be doing the blacklisting at 10 MB block limit let's say? Full nodes runners, miners? If you could elaborate please, wanna understand the point. What's the choke point?
 64 2015-11-30 21:53:32 <gmaxwell> And this is a long term trend that we've seen; which appears to have been greatly amplified by the raise of the soft limit from 250k to 750k, unfortunately.
 65 2015-11-30 21:53:46 <tulip> Prattler: services.
 66 2015-11-30 21:54:05 <ploopkazoo> what do block size and blacklisting have to do with each other?
 67 2015-11-30 21:54:06 <Prattler> services can do that today, what's the difference 1 MB vs 10 MB?
 68 2015-11-30 21:54:37 <Prattler> I don't see the argument for services.
 69 2015-11-30 21:54:38 <gmaxwell> Prattler: there are very few 'full node' runners today relative to the past. It appears to be impossible to find single ordinary merchants that do their own bitcoin payment processing, instead everyone depends on a small number of services.
 70 2015-11-30 21:54:52 <gmaxwell> Prattler: increased node costs have made it impratical for people to go around the services.
 71 2015-11-30 21:54:53 <sipa> ploopkazoo: the harder it is to run a full node and use it to validate yiur own transactions, the more people are incentivzed to just pay one service to do it for them
 72 2015-11-30 21:55:05 <gmaxwell> And even large commercial entities are depending on third party APIs instead of running their own nodes.
 73 2015-11-30 21:56:04 <gmaxwell> Prattler: additionally, there are several large miners talking about varrious kind of blacklisting schemes... which are only viable at the mining level as a result of centeralization there which appears to be in part driven by propagation effects.
 74 2015-11-30 21:56:05 <Prattler> they're not doing that for hardware costs, but for customer service and convenience. So 1 MB or 10 MB doesn't matter at all.
 75 2015-11-30 21:56:59 <tulip> convenience for the service is related to how difficult it is for them to bother with their own node, if it's expensive and time consuming they will outsource it to their own and their users detriment.
 76 2015-11-30 21:57:02 <Prattler> propagation times are a problem, agreed. But I really see that as the only problem. Still don't understand services.
 77 2015-11-30 21:58:03 <ploopkazoo> if nodes that blacklist transactions from addresses they don't like are a vast minority, what is the issue? that eventually as individuals without agendas stop running full nodes, blacklisters will become a majority?
 78 2015-11-30 21:58:13 <gmaxwell> Prattler: I'm not sure if you've run a node at commercial scale, it takes effort; and many bitcoin companies do not consider it their domain of expertise; any cost at all is a considerable friction. And it's become completely implausable to run a full node at home or on a low end VPS for many people.
 79 2015-11-30 21:58:44 <sipa> ploopkazoo: the number of nodes is not relevant
 80 2015-11-30 21:58:55 <gmaxwell> (e.g. just running Bitcoin Core blows out the comcast monthly transfer caps, in regions where they've started enforcing those)
 81 2015-11-30 21:58:56 <sipa> ploopkazoo: how much economic activity that relies on them does
 82 2015-11-30 21:59:04 <ploopkazoo> aah
 83 2015-11-30 22:00:51 <gmaxwell> Prattler: why would they use it? then you could just steal their coins. The need for trust implies a strong centeralizing force.
 84 2015-11-30 22:00:51 <ploopkazoo> how much economic activity relies on blacklist nodes?
 85 2015-11-30 22:00:51 <Prattler> Hell, if you're worried about it, you should run a full node service yourself and provide it to customers. Problem solved.
 86 2015-11-30 22:00:51 <Prattler> There would be no barrier of entry for companies to offer full node, wallet, etc services. So that's no way centralized.
 87 2015-11-30 22:00:51 <tulip> ploopkazoo: if everybody is relying on a remote service for all of their information and storage, it's not up to the user who does blacklisting, it's done on their behalf.
 88 2015-11-30 22:00:56 <gmaxwell> And no one can opt out of what mining does.
 89 2015-11-30 22:01:33 <Prattler> Users need to connect to the blockchain somehow. They'd pay you to be their connection, as now they're paying someone else. It's a free market competition.
 90 2015-11-30 22:01:36 <ploopkazoo> wait so, are "blacklist nodes" nodes with a differing protocol that reject transactions from some massive blacklist, or normal nodes that are a part of some service with blacklisting at a higher level that doesn't directly affect the network?
 91 2015-11-30 22:02:13 <tulip> they both have the same effect ultimately.
 92 2015-11-30 22:02:25 <Prattler> Again, I agree about the mininig, the faster blocks propagate, the better for everyone.
 93 2015-11-30 22:02:49 <gmaxwell> ploopkazoo: you're the only person in here who used that term (blacklist nodes) but whats common right now is blacklisting at a higher level; what some miners are talking about is blacklisting at other levels.
 94 2015-11-30 22:02:50 <ploopkazoo> tulip: if I understand correctly, the former wouldn't really have any affect on people unless they became a majority
 95 2015-11-30 22:03:48 <sipa> ploopkazoo: if you can get 5 services today to implement a particular blacklist it would already affect a majority of bitcoin users, i believe
 96 2015-11-30 22:04:08 <tulip> ploopkazoo: not really, you don't have to completely wipe out a behaviour to make it unfeasible, simply making it uncomfortable enough to make people go with the desired flow of perceived legitimately is enough.
 97 2015-11-30 22:04:10 <Prattler> miners cannot blacklist, or if they do, that's the 51% attack, correct?
 98 2015-11-30 22:04:27 <tulip> miners have free choice of the transactions they include, majority or no.
 99 2015-11-30 22:04:58 <Prattler> if one miner doesn't want my tx, some other miner will. Only way to censor a tx is do a 51% attack.
100 2015-11-30 22:04:59 <gmaxwell> Prattler: there is no "the 51% attack" usually when people say "the 51% attack" they refer to replacing a chain with another that has conflicting transactions.
101 2015-11-30 22:05:02 <ploopkazoo> but excluded transactions could then be confirmed by a different miner in subsequent blocks, right?
102 2015-11-30 22:05:07 <ploopkazoo> ah
103 2015-11-30 22:05:46 <ploopkazoo> what are some examples of services that implement blacklists?
104 2015-11-30 22:05:53 <gmaxwell> Right now it takes only 2-3 parties in physical control of hashpower to be a supermajority. And technically only about 33% hashpower is required to change the economics for everyone else and make them operate at a loss (see the selfish mining paper)
105 2015-11-30 22:06:00 <Prattler> gmaxwell, how does a miner censor a transaction that's already in the blockchain? Invalide the block and build on the previous block. No other way.
106 2015-11-30 22:06:00 <tulip> ploopkazoo: like I said, you don't have to eliminate something to make it undesirable, simply obstructing something to a high enough degree will turn people away.
107 2015-11-30 22:06:35 <gmaxwell> Prattler: by prefering blocks that don't contain it. And if you are at least a third of the hashpower and do this, it will be profitable for you and force the miners including the transaction to operate at a loss.
108 2015-11-30 22:06:37 <Prattler> That's what I mean by 51% attack.
109 2015-11-30 22:06:55 <gmaxwell> and if you are rolling your income back into more hashpower that means you will grow and they will shrink.
110 2015-11-30 22:07:10 <Prattler> ok, so that's selfish mining attack or smth. Dunno how you call it.
111 2015-11-30 22:07:20 <gmaxwell> (or if it's multiple parties making up the 30%, the colluding side will grow and the rest will shrink)
112 2015-11-30 22:08:06 <gmaxwell> In any case, miners themselves censoring is a near term future risk that exists only because of incredible centeralization which is amplified through node operating costs and propagation effects.
113 2015-11-30 22:08:10 <gmaxwell> Prattler: Do you mine?
114 2015-11-30 22:08:19 <Prattler> not at the moment
115 2015-11-30 22:08:39 <gmaxwell> If you were, would you be in control of your transaction selection?
116 2015-11-30 22:09:28 <gmaxwell> Am I the only person active in this channel right now that mines? Am I the only person in this channel active right now whos software independantly selects the transactions that go into their blocks?
117 2015-11-30 22:09:33 <Prattler> I'd delegate my hashpower to a pool which policies I supported.
118 2015-11-30 22:10:27 <ploopkazoo> gmaxwell: what do you mine with?
119 2015-11-30 22:10:52 <gmaxwell> ploopkazoo: SP20s with my own transaction selection (on P2Pool)
120 2015-11-30 22:11:37 <Prattler> I would solo mine if had great confidence I wouldn't suffer from block propagation rates. So there needs to be headers-first or thin blocks or smth and well tested out solutions. Hopefully they will come.
121 2015-11-30 22:12:49 <gmaxwell> sadly, p2pool has implemented efficient propagation for years and when it had enough hashrate to measure had easily the lowest orphan rate of any pool.
122 2015-11-30 22:13:21 <Prattler> yes, I used p2pool 2 years ago and it was great!
123 2015-11-30 22:13:44 <sipa> so why didn't p2pool become succesful?
124 2015-11-30 22:14:18 <ploopkazoo> gmaxwell: what exactly is transaction selection in a non-malicious sense? don't you just include all valid transactions?
125 2015-11-30 22:15:19 <gmaxwell> sipa: Three reasons, in my expirence (dunno which had the most effects);  (1) it's a pain in the ass to get started with, largely because step 1 is start your own full node,  (2) Many pieces of hardware came out which were incompatible due to high latency, p2pool forked to be more compatible, but even more crappy hardware was released,  (3) pervasive misunderstanding mining as a race, strongly drives
126 2015-11-30 22:15:25 <gmaxwell> many miners to the largest pools they can find.
127 2015-11-30 22:16:45 <gmaxwell> ploopkazoo: sure, More or less: valid, ordered by feerate... and subject to some minimal behavior based filtering for common DOS attacks (e.g. dust payments to those well known private keys).
128 2015-11-30 22:17:52 <gmaxwell> I used to mine with a patch that deprioritized address reuse; but I got tired of maintaining it.
129 2015-11-30 22:19:05 <gmaxwell> (it resulted in more equitable sharing of space; e.g. some party that self identified as a single party making a lot of transactions at once; it would use their self-identification to give them a fair share; at the cost of some fees to me.)
130 2015-11-30 22:32:27 <waxwing> what decides when estimatefee switches to an estimate rather than -1.0? (i'm asking for regtest; i know it can work since i had an estimate coming out at one point)
131 2015-11-30 22:37:26 <tulip> waxwing: it means it doesn't have enough information to make an informed decision.
132 2015-11-30 22:37:57 <waxwing> tulip: yes, i know. that's not my question.
133 2015-11-30 22:38:43 <tulip> waxwing: right, sorry.
134 2015-11-30 22:43:17 <Luke-Jr> Prattler: I would appreciate if you didn't imply-slander me, thanks.
135 2015-11-30 22:44:10 <Prattler> Luke-Jr, did you not use the blockchain to store information?
136 2015-11-30 22:44:16 <Prattler> non-financial information
137 2015-11-30 22:44:20 <Luke-Jr> Prattler: nope
138 2015-11-30 22:44:33 <Luke-Jr> in fact, I'm one of the more vocal devs against that
139 2015-11-30 22:44:51 <tulip> it's hard to imagine a worse place to try to store information than Bitcoins block chain.
140 2015-11-30 22:47:26 <gmaxwell> waxwing: sorry I don't know the exact threshold, but the way ir works is watching mempool transactions to see when they get confirmed. So presumably there must be a mempool.
141 2015-11-30 22:47:48 <sipa> waxwing: ask morcos :)
142 2015-11-30 22:48:27 <waxwing> right. i guess it can still have an estimate after mempool is cleared out though, if there were txs in it earlier? seems like must be as when i queried it a while back pretty sure it was empty.
143 2015-11-30 22:48:35 <waxwing> but anyway, very edgy edge case i know :)
144 2015-11-30 22:48:45 <gmaxwell> it carries cached data across restarts.
145 2015-11-30 22:49:09 <waxwing> k, makes sense
146 2015-11-30 22:50:24 <morcos> waxwing: for fee estimates it has to average at least 1 tx per block roughly over the last 500 blocks , so you'll need a bare minimum of 500 txs i think
147 2015-11-30 22:50:51 <waxwing> morcos: thanks, i'll try that
148 2015-11-30 22:51:09 <morcos> 500 that have been included in a block that is
149 2015-11-30 22:51:19 <morcos> and were previously in your mempool
150 2015-11-30 22:52:43 <morcos> but yes the data is saved in fee_estimates.dat so you could use that from mainnext and have estimates in regtest i think
151 2015-11-30 22:54:40 <waxwing> morcos: ah, nice idea, thanks
152 2015-11-30 22:59:18 <Prattler> Luke-Jr, I did some education on the subject and learned something knew, I was wrong. Sorry!