1 2015-06-13 05:19:21 <kanzure> http://diyhpl.us/wiki/transcripts/bitcoin-sidechains-unchained-epicenter-adam3us-gmaxwell/
  2 2015-06-13 05:57:35 <phantomcircuit> wumpus, i dont understand why the mempool expiration patch is structured that way
  3 2015-06-13 05:58:07 <phantomcircuit> why expire at a known constant interval?
  4 2015-06-13 05:59:53 <wumpus> there's more disagreement on that
  5 2015-06-13 05:59:56 <wumpus> better  to reply there
  6 2015-06-13 06:08:37 <wumpus> my preference for mempool size management would be to cap at a maximum size in MB, and discard lowprio transactions when necessary. But there  have been other proposals, like storing the mempool in a database on disk so that it can be much larger.
  7 2015-06-13 06:09:04 <wumpus> unfortunately that github thread degenerated into silly word games, most of the serious discussion has been here
  8 2015-06-13 06:09:39 <phantomcircuit> gmaxwell, you have! you suggested "pool boy"
  9 2015-06-13 06:09:47 <gmaxwell> oh was this an old thread?
 10 2015-06-13 06:09:55 <phantomcircuit> yup
 11 2015-06-13 06:09:57 <gmaxwell> ah
 12 2015-06-13 06:10:24 <Luke-Jr> wumpus: too bad there's no simple way to tell the OS to just randomly discard the data in memory as needed. :p
 13 2015-06-13 06:10:36 <Luke-Jr> (it's possible I think, but not simple)
 14 2015-06-13 06:10:50 <wumpus> Luke-Jr: I think there is, some memory pressure flag
 15 2015-06-13 06:11:20 <wumpus> Luke-Jr: it's meant for caches and such; needs to be handled extremely carefully, though. i don't think discarding randomly is the way to go here, anyhow :)
 16 2015-06-13 06:11:43 <gmaxwell> lol
 17 2015-06-13 06:11:44 <gmaxwell> ouch
 18 2015-06-13 06:11:52 <gmaxwell> that would be not awesome.
 19 2015-06-13 06:12:24 <Luke-Jr> it would be interesting to observe at least
 20 2015-06-13 06:12:48 <wumpus> yes I meant the pool boy, the very old pull by jgarzik. It probably should be closed, but I kept it open in the hope it would become serious discussion at some point.
 21 2015-06-13 06:16:01 <wumpus> Luke-Jr: I've just found some articles on lwn about that feature, volatile ranges https://lwn.net/Articles/522135/ mempressure control https://lwn.net/Articles/531077/
 22 2015-06-13 06:25:02 <phantomcircuit> wumpus, if you can assume that dPriority doesn't need to be updated
 23 2015-06-13 06:25:12 <phantomcircuit> it should be easy enough to just remove the lowest priority transaction
 24 2015-06-13 06:25:15 <phantomcircuit> (s)
 25 2015-06-13 06:26:19 <Luke-Jr> oh right, we're still calculating priority/etc in CreateNewBlock :/
 26 2015-06-13 06:27:23 <phantomcircuit> Luke-Jr, does dPriority need to be recalculated?
 27 2015-06-13 06:27:36 <phantomcircuit> there's enough layers in calculating the final value i cant tell
 28 2015-06-13 06:29:54 <Luke-Jr> phantomcircuit: after certain events (new block, parent tx mined, etc)
 29 2015-06-13 06:30:32 <Luke-Jr> phantomcircuit: btw, note that there are like 3-4 places bitcoind independently implements the priority calculation, and most of them disagree..
 30 2015-06-13 06:30:49 <phantomcircuit> lolol
 31 2015-06-13 06:30:53 <phantomcircuit> of course there are
 32 2015-06-13 06:50:43 <wumpus> yes, I was talking of some measure of priority, not necessarily that used somewhere else (although it may make sense to synchronize them)
 33 2015-06-13 06:53:21 <phantomcircuit> wumpus, there's already a dPriority there
 34 2015-06-13 06:53:24 <phantomcircuit> easy enough to use
 35 2015-06-13 06:58:01 <wumpus> phantomcircuit: as usual, it is making sure that you get it right that is difficult, not so much the implementation itself
 36 2015-06-13 06:58:45 <phantomcircuit> wumpus, worst case you introduce a trivial dos issue
 37 2015-06-13 06:59:22 <wumpus> or non-trivial
 38 2015-06-13 07:00:56 <phantomcircuit> it's important that most nodes do something that's vaguely the same
 39 2015-06-13 07:01:12 <phantomcircuit> keeps the issue of older transactions being reintroduced to a minimum
 40 2015-06-13 07:08:07 <gmaxwell> phantomcircuit: I did worry a bit about things like tx expires but you can't effectiely rebroadcast because many nodes still have it.
 41 2015-06-13 07:25:26 <phantomcircuit> gmaxwell, it just seems to be asking for problems
 42 2015-06-13 07:28:09 <gmaxwell> well its good that things expire, because you know, finite state space requitements are wholesome and good.
 43 2015-06-13 07:30:23 <phantomcircuit> technically even with expiration it's not finite space...
 44 2015-06-13 07:35:37 <gmaxwell> well, no with timed exp not..
 45 2015-06-13 07:55:22 <phantomcircuit> gmaxwell, im not thinking of anything better than just dropping the transactions with low dPriority
 46 2015-06-13 07:55:32 <phantomcircuit> how dPriority is calculated is unspecified for this
 47 2015-06-13 08:48:37 <nonym> /nick nonym
 48 2015-06-13 09:36:34 <mjerr> Luke-Jr, as OP_20 does not exist, I can just use 20 directly, right?
 49 2015-06-13 09:37:30 <mjerr> hm, not? any easy way to push '20' to the stack though?
 50 2015-06-13 09:38:10 <Luke-Jr> mjerr: 0114 should do it I think (push 1 byte, value 0x14)
 51 2015-06-13 09:38:16 <mjerr> or should I use OP_PUSHDATA1 do it
 52 2015-06-13 09:38:23 <mjerr> ahh
 53 2015-06-13 09:38:25 <Luke-Jr> mjerr: (note multisig only effectively works up to 15)
 54 2015-06-13 09:39:13 <mjerr> so the 0x01-0x4b are for pushing that amount of following bytes to the stack?
 55 2015-06-13 09:39:48 <mjerr> so just a shortcut instead of OP_PUSHDATA1
 56 2015-06-13 09:39:52 <Luke-Jr> yes
 57 2015-06-13 09:40:02 <mjerr> perfect, understood that now at least :)
 58 2015-06-13 09:41:13 <Luke-Jr> note 0x00 (OP_FALSE) is also such a shortcut
 59 2015-06-13 09:41:20 <Luke-Jr> false is defined as a null bytearray ;)
 60 2015-06-13 09:42:46 <Luke-Jr> also, in case you wanted the /string/ '20' (implied by quotes?), you'd do 023230
 61 2015-06-13 09:44:26 <mjerr> ah, yea right, pushing 0 bytes on the stack hehe.. no i definitely want the number ;)
 62 2015-06-13 11:39:52 <wangchun> should we add /8MB/ or /20MB/ in our coinbase?
 63 2015-06-13 12:55:24 <Naphex> wangchun: add 100
 64 2015-06-13 14:47:00 <hidden> i have a question about walletnotify after looking at https://github.com/damonp/walletnotify, it seems walletnotify only calls twice? "The walletnotify script is hit twice for each transaction; when it first appears on the network (0 confirmations) and after the first confirmation. It is called for both receiving and sending transactions.", if so does it only work for 1 confirmation? can we make this more
 65 2015-06-13 15:15:32 <andytoshi> in libsecp256k1 random_scalar_order_test it seems like i get a lot of zeros awfully often
 66 2015-06-13 15:15:46 <andytoshi> like, numbers in [0, 2^128] show up like 1% of the time
 67 2015-06-13 17:00:19 <jgarzik> wumpus, poolman could be merged today, as long as requires-disable-wallet qualifier is in place
 68 2015-06-13 17:01:00 <jgarzik> and then try to convince the ever-energetic jonasschnelli to work on the wallet tidbit blocker
 69 2015-06-13 17:01:06 <jgarzik> ;p
 70 2015-06-13 17:02:06 <jgarzik> wumpus, the blocker is poolman over-zealously removes transactions which might trigger downstream wallet confusion
 71 2015-06-13 17:02:55 <jgarzik> e.g. it is easy to see a wallet transaction might be predicted as non-confirming and removed by poolman, yet still needed for wallet
 72 2015-06-13 18:26:57 <jonasschnelli> jgarzik: will take a close loot at it soon. It also needs some rpc tests.
 73 2015-06-13 18:56:37 <jgarzik> Updated BIP 100 draft: http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
 74 2015-06-13 18:56:54 <jgarzik> tweaks thesholds, dates, explains voting a bit more, adds new discussion section on miners
 75 2015-06-13 19:53:54 <wangchun> jgarzik: should i put "/BV8M/" or "BV8MB" or "BV8000000"?
 76 2015-06-13 19:57:41 <jgarzik> wangchun, still writing full specification this second - probably /BV$N/ where N is desired block size as a multiple of 1,000,000 bytes.  Example: /BV8/ to vote for 8,000,000 bytes.
 77 2015-06-13 19:59:15 <gmaxwell> jgarzik: 1MB precision is awful low. 100k or just bytes would be a lot better.
 78 2015-06-13 19:59:28 <contrapumpkin> yeah, I wanted to vote for 200k
 79 2015-06-13 20:00:23 <jgarzik> gmaxwell, ok, easily done
 80 2015-06-13 20:09:37 <jgarzik> gmaxwell, FYI note the new draft uses more conservative numbers and thresholds, e.g. hard fork 1MB into this new system, and limit remains 1MB until first vote.
 81 2015-06-13 20:10:04 <jgarzik> Higher %
 82 2015-06-13 20:12:06 <gmaxwell> Cool. Will read.
 83 2015-06-13 21:42:46 <prevara> anyone wanna trade
 84 2015-06-13 21:43:07 <chmod755> prevara is bosnian for scam
 85 2015-06-13 21:45:25 <Diablo-D3> no no no
 86 2015-06-13 21:45:30 <Diablo-D3> bosnian is bosnian for scam
 87 2015-06-13 21:46:58 <phantomcircuit> wangchun, miners are not the deciders of maximum blocksize, users are
 88 2015-06-13 21:47:00 <phantomcircuit> so
 89 2015-06-13 21:47:02 <phantomcircuit> no
 90 2015-06-13 21:48:01 <chmod755> who are 'users'?
 91 2015-06-13 21:48:30 <phantomcircuit> chmod755, people with bitcoins who run a full node
 92 2015-06-13 21:49:29 <chmod755> ok
 93 2015-06-13 21:52:40 <prevara> anyone wanna trade
 94 2015-06-13 21:55:20 <phantomcircuit> prevara, #bitcoin-otc
 95 2015-06-13 21:56:12 <chmod755> phantomcircuit, <chmod755> prevara is bosnian for scam
 96 2015-06-13 21:56:24 <phantomcircuit> chmod755, lolin
 97 2015-06-13 21:56:30 <phantomcircuit> that's genuinely clever
 98 2015-06-13 22:00:07 <chmod755> *worldwide *interested
 99 2015-06-13 22:00:49 <Luke-Jr> phantomcircuit: but exchanges can compel users
100 2015-06-13 22:04:05 <phantomcircuit> Luke-Jr, exchanges can equally be compelled by users
101 2015-06-13 22:04:20 <phantomcircuit> the assumption that exchanges have economic power seems... flawed
102 2015-06-13 22:04:57 <Luke-Jr> phantomcircuit: only if exchanges are divided
103 2015-06-13 22:05:20 <Luke-Jr> I suppose there's always p2p/otc transactions, but that appears to be illegal here in Florida :/
104 2015-06-13 22:14:48 <phantomcircuit> jgarzik, derped my comment
105 2015-06-13 22:18:00 <prevara> 19308.66 U / 0
106 2015-06-13 22:18:19 <phantomcircuit> ffs are there any ops around?
107 2015-06-13 22:34:20 <copumpkin> prevara: wtf, go away
108 2015-06-13 22:35:16 <copumpkin> gmaxwell?
109 2015-06-13 22:40:08 <Luke-Jr> !ops
110 2015-06-13 22:42:11 <midnightmagic> dang it.
111 2015-06-13 23:16:01 <Andrew> hi piople!)
112 2015-06-13 23:17:49 <Andrew> advise the most productive ASIC..
113 2015-06-13 23:19:51 <Luke-Jr> Andrew: #bitcoin-mining
114 2015-06-13 23:22:46 <Andrew> I search best ASIC chip for my project
115 2015-06-13 23:25:51 <Luke-Jr> err, answer in #bitcoin-mining
116 2015-06-13 23:25:51 <Luke-Jr> what project is that?
117 2015-06-13 23:28:09 <Andrew> I will be develop pcb for mining
118 2015-06-13 23:31:27 <btcbuyz> > anyone wann trade
119 2015-06-13 23:32:01 <phantomcircuit> jgarzik, https://github.com/pstratem/bitcoin/commit/9a555f1843e60af129bf47b2e771ab954b8bd78a
120 2015-06-13 23:32:12 <Luke-Jr> midnightmagic:
121 2015-06-13 23:32:16 <phantomcircuit> note: totally untested, but compiles
122 2015-06-13 23:34:09 <phantomcircuit> and passes tests
123 2015-06-13 23:34:10 <phantomcircuit> neat
124 2015-06-13 23:37:50 <gmaxwell> phantomcircuit: 16mb is pretty small, I think. It might be more useful to record how long things were in the mempool before they made in into a block and figure out what number would get virtually no failure.
125 2015-06-13 23:38:25 <gmaxwell> phantomcircuit: for load averaging reasons it really should be at least a day's worth, and ideally a weeks worth (though the latter would want mempool on disk)
126 2015-06-13 23:39:32 <gmaxwell> phantomcircuit: Also I think this scheme should imply a change to the relay logic: we shouldn't relay something that would immediately fall out of the list.
127 2015-06-13 23:42:44 <phantomcircuit> gmaxwell, very true
128 2015-06-13 23:45:15 <gmaxwell> some stickyness there would also avoid a flooding attack where you put a tx right at the bottom then it's bumped out by the next high fee txn, then you relay it again immediately.
129 2015-06-13 23:48:57 <phantomcircuit> gmaxwell, https://github.com/pstratem/bitcoin/commit/1c72b146615b749b8ba36ebdc217a7e2cd2e001c
130 2015-06-13 23:49:02 <phantomcircuit> simple enough
131 2015-06-13 23:50:05 <phantomcircuit> gmaxwell, and yeah 16MiB was fairly arbitrary, although i am not so sure that it's too small
132 2015-06-13 23:51:42 <gmaxwell> phantomcircuit: I think its too small because there is a huge 24 hour cycle in demand. It means that if you broadcast a txn that would make it in sometime later in the day when there was less demand, you'll fail... when otherwise it would be fine.
133 2015-06-13 23:53:28 <phantomcircuit> gmaxwell, i'll start dumping mempool sizes on a node and see what it looks like
134 2015-06-13 23:53:35 <gmaxwell> e.g. say a fee of "X" is enough to get you in eventually, if you pay at least X you'll get in, assuming no mempool limiter, so then we can consider the effect of the limiter on that value.  If the limiter is large enough that all estimates of X of limiter-size length return X then there is no impact.
135 2015-06-13 23:53:45 <phantomcircuit> 16MiB is quite a lot of memory to actually be using though
136 2015-06-13 23:53:56 <gmaxwell> phantomcircuit: relative to our overall usage? not really!
137 2015-06-13 23:54:10 <gmaxwell> I think it would be fine to make it configurable too.
138 2015-06-13 23:54:18 <phantomcircuit> if you drop dbcache to 4 it starts to be
139 2015-06-13 23:54:32 <phantomcircuit> yeah it should be configurable you're right
140 2015-06-13 23:55:14 <gmaxwell> If the limiter is shorter such that during some limiter-length windows the estimate of X would be much higher (e.g. peak hours) then effectively users must pay those higher values if they broadcast during that time, even if they're fine with the txn taking a while.
141 2015-06-13 23:56:51 <gmaxwell> in any case, maybe it really doesn't matter because miners will crank the number way up even if other nodes do not.