1 2015-05-08 00:50:07 <phantomcircuit> hmm
2 2015-05-08 00:50:52 <phantomcircuit> seems like block validation time isn't linear with block size/transaction count if the utxo doesn't fit in memory
3 2015-05-08 00:51:24 <phantomcircuit> ie there's a cliff beyond which 1-->20MB isn't a 20x increase but more like a 200x increase
4 2015-05-08 01:03:02 <amiller> theres a bunch of addr spam on the network, for addresses on port 256, and whose last octet is 85
5 2015-05-08 01:03:04 <amiller> i think it looks like someone is doing the "active" mobile client deanoymization technique from this paper: http://dl.acm.org/citation.cfm?id=2660379
6 2015-05-08 01:04:10 <phantomcircuit> amiller, http://arxiv.org/pdf/1405.7418.pdf same paper?
7 2015-05-08 01:04:35 <amiller> yeah same paper, the point is just that there are a few things you can do by spamming bogus addresses on the network, and these seem to be bogus addresses
8 2015-05-08 01:04:37 <phantomcircuit> amiller, is that the "eclipse" attack?
9 2015-05-08 01:04:44 <amiller> no its not the eclipse attack
10 2015-05-08 01:04:59 <gmaxwell> Bitcoin core won't pay any attention to those; but perhaps some other wallet will?
11 2015-05-08 01:05:29 <gmaxwell> ('those' meaning port 256)
12 2015-05-08 01:06:00 <phantomcircuit> gmaxwell, iirc it will but only after trying everybody else on port 8333
13 2015-05-08 01:06:25 <gmaxwell> phantomcircuit: correct it only consiers not 8333 if its persistantly unable to connect on 8333 (e.g. firewalled off)
14 2015-05-08 01:06:36 <amiller> gmaxwell, by "not pay any attention", does that include storing/relaying?
15 2015-05-08 01:06:47 <gmaxwell> BlueMatt: did bitcoinj ever gain an ability to find peers by anything other than "trust whatever dns seeds give it"?
16 2015-05-08 01:07:05 <gmaxwell> amiller: oh this is wrt a fingerprint attack?
17 2015-05-08 01:08:18 <amiller> gmaxwell, im not sure what the cause is, just that bogus addresses flying around would be a consequence of several kinds of attacks, among them is this fingerprint attack
18 2015-05-08 01:08:48 <gmaxwell> could just be broken software too, 256 sounds like a nice value for uninitilized memory
19 2015-05-08 01:09:09 <amiller> another one is trying to crash (old) nodes by filling up some unbounded buffer that is involved in avoid retransmission of addrs
20 2015-05-08 01:09:17 <gmaxwell> amiller: current versions of core will not have varrious countermeasures; e.g. limiting unsolicited address pushes and not letting inbound hosts stuff us with addresses.
21 2015-05-08 01:09:19 <amiller> right, or possibly just misconfiguration
22 2015-05-08 01:10:10 <gmaxwell> the retrainsmit limiter thing takes forever++ to fill use much memory; there are much more interesting DOS attacks against older nodes.
23 2015-05-08 01:10:21 <gmaxwell> I'd rate that possiblity somewhat lower.
24 2015-05-08 01:23:40 <jgarzik> block chain - still a fast torrent ;p Progress: 1.1%, dl from 44 of 50 peers (10.08 MB/s), ul to 1 (16 kB/s) [0.00]
25 2015-05-08 01:25:47 <belcher> dont we use headers first now?
26 2015-05-08 01:31:18 <phantomcircuit> belcher, there's still a bit of a bias towards the torrent since nearly all of the seeds are on 1gbps networks
27 2015-05-08 01:34:06 <BlueMatt> gmaxwell: not sure, I hacked up some code to do it, but I never really finished it, and i dont know if anyone else took it up
28 2015-05-08 01:38:08 <jgarzik> belcher, yes
29 2015-05-08 01:38:22 <jgarzik> belcher, I'm the torrent maintainer so I'm a bit retarded
30 2015-05-08 01:39:00 <jgarzik> belcher, People using >= 0.10 should use the internal download (headers-first)
31 2015-05-08 01:45:47 <gruez> so just wondering...
32 2015-05-08 01:46:20 <gruez> couldn't we shorten bitcoin addresses by omitting the leading zeros during base58 encoding?
33 2015-05-08 01:47:10 <sipa> gruez: in theory, sure, but the way base58 works now is that you don't need to know the length of the decoded data in advance
34 2015-05-08 01:48:17 <gmaxwell> gruez: expoential cost.. stripping off 4 characters would require seconds of grinding.... which would likely further encourage reuse.
35 2015-05-08 01:49:07 <gruez> i was thinking of doing this rather than firstbits for "shortened" addresses
36 2015-05-08 01:49:20 <gruez> because of the problems with firstbits
37 2015-05-08 01:50:10 <gmaxwell> doesn't address the other ones--- e.g. that shorter addresses are easiler to make visual lookalike ones; (or the above mentioned reuse)
38 2015-05-08 01:50:40 <gruez> got it.
39 2015-05-08 08:30:13 <jonasschnelli> does anyone see why this travis job faild: https://travis-ci.org/bitcoin/bitcoin/jobs/61674227
40 2015-05-08 08:30:18 <jonasschnelli> Is it because of https://travis-ci.org/bitcoin/bitcoin/jobs/61674227#L1376?
41 2015-05-08 08:36:51 <jonasschnelli> for a new wallet design: what if the wallet wouldn't store the whole wtx. Instead it could only store the txid, unspent outpoint (incomming)? "Megatransaction" are increasing.
42 2015-05-08 08:37:32 <s1lver> or if one was to reduce the blocktime
43 2015-05-08 08:37:38 <phantomcircuit> jonasschnelli, that seems reasonable
44 2015-05-08 08:38:00 <phantomcircuit> iirc the only thing the wallet actually needs is the output script and value
45 2015-05-08 08:39:29 <jonasschnelli> right. Let me think through this a bit more.
46 2015-05-08 08:44:05 <Diablo-D3> gmaxwell, phantomcircuit: so whats the status on large blocks
47 2015-05-08 08:47:41 <michagogo> phantomcircuit: and txid
48 2015-05-08 08:47:57 <michagogo> (And vout, of course)
49 2015-05-08 08:49:57 <wumpus> jonasschnelli: be careful with only storing the txid, remember mutability, you need to be able to detect whether they conflict
50 2015-05-08 08:50:27 <jonasschnelli> wumpus: that is a good point.
51 2015-05-08 08:50:56 <wumpus> also, be careful around reorganizations, if you no longer hhave the whole transaction (certainly one you created yourself) you cannot retransmit it
52 2015-05-08 08:54:50 <wumpus> (however, a strategy like "keep the full transaaction until it's 100 deep in the block chain" may be acceptable in practice)
53 2015-05-08 09:00:05 <wumpus> on the other hand, instinctively it feels safer to me to just retain them. For transactions that matter to me, I'd rather be a pack rat than come to the conclusion that some data was deleted I need for some reason later.
54 2015-05-08 09:02:32 <jonasschnelli> wumpus: right. I also came to the point where i think keeping the whole wtx makes most sense. The size of the wallet can grow to large. The performance issues could be solved by caching at certain point in time.
55 2015-05-08 09:04:05 <wumpus> well, yes, and the size of the wallet is only a significant issue because it's all stored in memory
56 2015-05-08 09:06:47 <wumpus> e.g. as we discussed before, the output script and value is enough for output selection, so that is the minimum you need to keep hot in memory (a wallet-utxo, so to say)
57 2015-05-08 11:16:36 <volante> is the iblt stuff likely to be implemented soon, or is it worth looking into other solutions.. like i was thinking it would be good if you could pull parts of blocks from multiple peers concurrently (kind of how bittorrent works)
58 2015-05-08 11:18:47 <jonasschnelli> volante: bitcoin core 0.10 does download blocks in parallel
59 2015-05-08 11:19:15 <volante> i mean, downloading parts of 1 block in parallel
60 2015-05-08 11:19:52 <jonasschnelli> volante: download of parts of a block makes no sense IMO
61 2015-05-08 11:19:59 <volante> for example, if blocks were 20MB, then you might get 5MB chunks from 4 different peers at once
62 2015-05-08 11:20:22 <volante> why wait for 1 slow peer to send it to you?
63 2015-05-08 11:21:11 <wumpus> there's a practical problem there: blocks don't come with a tree of subblock hashes, so unlike bittorrent you can only verify when the 'file' is complete, and you still have no clue what part is corrupted
64 2015-05-08 11:21:21 <wumpus> oh wait maybe the merkle tree
65 2015-05-08 11:22:09 <jonasschnelli> you could. But your chunk based download would have significant impact and i'm not sure if it would be that much faster (complete sync).
66 2015-05-08 11:22:32 <jonasschnelli> volante: download is not the (only) bottleneck.
67 2015-05-08 11:23:01 <volante> i'm more thinking for the case of when you're already synced and you want to get the latest block as fast as possible. for example, a miner.
68 2015-05-08 11:23:21 <wumpus> isn't IBLT better in any way there?
69 2015-05-08 11:23:57 <volante> wumpus: i think so, thats why i'm wondering if it's actually happening. because if not then maybe an interim measure might help.
70 2015-05-08 11:24:24 <wumpus> the concept is to not request the transactions that have already passed your node, that's superior to simply distributing the load
71 2015-05-08 11:24:59 <volante> the other benefit to chunking blocks is that you could validate each chunk independently, so you could begin validating before you receive the whole thing. (and as you said before, the merkle branch works well for proving the integrity of the chunks)
72 2015-05-08 11:25:04 <wumpus> interim solution is just extra work, let's just go for the better solution
73 2015-05-08 11:25:41 <wumpus> you can't do that. block transactions need to be validated in order
74 2015-05-08 11:25:51 <wumpus> there's no parallelism there
75 2015-05-08 11:26:34 <volante> could you validate some of them and then postpone ones that refer to inputs that you don't have yet?
76 2015-05-08 11:27:14 <wumpus> well in practice we already parallelize validation with mulitple script validation threads
77 2015-05-08 11:27:52 <wumpus> by just pipelining
78 2015-05-08 11:29:04 <volante> yeah i agree about iblt being better. i only suggest this because it's something i would be willing to work on. i don't feel like i can do anything to help with IBLTs, that looks really complicated and it sounds like gavin is handling that. :)
79 2015-05-08 11:29:06 <wumpus> I could see a slight possible latency optimization if you could start validating when not the entire block is received yet, but that will only help in the steady state not during sync
80 2015-05-08 11:29:20 <volante> maybe there's something more useful i could do instead of this
81 2015-05-08 11:29:49 <jonasschnelli> volante: how about testing some PRs?
82 2015-05-08 11:33:15 <volante> jonasschnelli: should i only do testing on issues that have had their code ack'd, or before that?
83 2015-05-08 11:34:10 <jonasschnelli> volante: before and after. Depending on how deep you can test the PR. Multiple acks helps.
84 2015-05-08 11:34:43 <jonasschnelli> volante: testing is one of the main bottleneck in the direction of more feature
85 2015-05-08 11:35:40 <volante> is there a documented workflow? (maybe a silly question :))
86 2015-05-08 11:36:20 <jonasschnelli> volante: maybe this: https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md?
87 2015-05-08 11:36:39 <jonasschnelli> but not actually a workflow.
88 2015-05-08 12:09:38 <wumpus> <volante> jonasschnelli: should i only do testing on issues that have had their code ack'd, or before that? <- independent of that - you should ACK when you are convinced that the change does what it is suposed to do and you found no problems in reviewing
89 2015-05-08 12:10:08 <wumpus> waiting for others to ACK first would create a chicken-and-egg problem
90 2015-05-08 12:43:17 <jonasschnelli> wumpus: did you remove the '-reindex' help message by purpose? https://github.com/bitcoin/bitcoin/commit/fc44231cb72afae2fffe0fac64e236a1d33b90e6
91 2015-05-08 12:43:23 <jonasschnelli> https://github.com/bitcoin/bitcoin/commit/fc44231cb72afae2fffe0fac64e236a1d33b90e6#diff-c865a8939105e6350a50af02766291b7L282
92 2015-05-08 14:46:03 <jgarzik> ACTION wakes up
93 2015-05-08 15:08:56 <notplato> My client is not mining, but running at over 20% of my cpu for the last couple minutes. Anyone else see this?
94 2015-05-08 15:09:40 <notplato> It's got 79 connections and is up to date with the blocks.
95 2015-05-08 15:10:42 <temujin> i've had a similar issue, but only on testnet
96 2015-05-08 15:10:43 <temujin> i've had a similar issue, but only on testnet
97 2015-05-08 15:11:16 <temujin> 35% CPU constantly on one box, all others exactly the same idle at 2% CPU
98 2015-05-08 15:11:17 <temujin> 35% CPU constantly on one box, all others exactly the same idle at 2% CPU
99 2015-05-08 15:12:59 <notplato> temujin: Thanks. I'm restarting the client.
100 2015-05-08 15:19:31 <temujin> can someone shed some light on gavin's UTXO memory blog post? i was under the impression the entire UTXO set was _not_ held in memory
101 2015-05-08 16:00:17 <gavinandresen> sipa gmaxwell : http://gavinandresen.ninja/utxo-uhoh Was there a bitcoin-wizards discussion of how to fix this that I missed?
102 2015-05-08 16:08:56 <sipa> gavinandresen: in RAM it's around 3.5 GB in RAM now
103 2015-05-08 16:09:07 <sipa> and sure, you don't need 100% in ram
104 2015-05-08 16:09:33 <sipa> but if you want to make hard guarantees about latency for lookup, you sort of do
105 2015-05-08 16:11:09 <Luke-Jr> sipa: eh, you mean /if/ it were in RAM? my bitcoin-qt certainly isn't hitting 3.5 GB of memory use
106 2015-05-08 16:11:48 <sipa> gavinandresen: and ram is O(1), but disk databases aren', so even if only some fraction grows in size, once it starts exceeding what fits in ram, you get an additional at least O(log n) scaling cost for access
107 2015-05-08 16:12:56 <sipa> Luke-Jr: see #6102
108 2015-05-08 16:13:13 <sipa> let's you do a full in-ram sync from scratch if need be
109 2015-05-08 16:13:40 <sipa> gavinandresen: admittedly, this is an issue without larger blocks too
110 2015-05-08 16:14:32 <gavinandresen> sipa: Iâll be editing the post, exponential growth is bound by the block size....
111 2015-05-08 16:14:59 <sipa> gavinandresen: the only incentive-compatible solution i know, is a consensus rule that limits the utxo set size growth (for example, makes your transaction count as more bytes for block sizes when it creates more outputs than it consumes
112 2015-05-08 16:15:29 <gavinandresen> sipa: yes, I tweeted âI think we need a new consensus ruleâ
113 2015-05-08 16:15:40 <sipa> gavinandresen: another is the STXO commitments idea which avoids the need for full nodes to have the utxo set available (but needs third party services that index it)
114 2015-05-08 16:17:59 <stonecoldpat> am i right in thinking, that utxo is used for transactions that are stored in mempool as well?
115 2015-05-08 16:18:09 <stonecoldpat> or only for transactions on the blockchain
116 2015-05-08 16:18:21 <Luke-Jr> heh, almost like adding back in the bdb locks limit (although more deterministically of course) :P
117 2015-05-08 16:18:25 <helo> stonecoldpat: only blockchain
118 2015-05-08 16:18:44 <Luke-Jr> (and also counted differently, of course)
119 2015-05-08 16:19:58 <stonecoldpat> ok, so when i chain transactions (two transactions not on the chain) - insteado of using utxo - will it just use mempool instead?
120 2015-05-08 16:20:11 <sipa> no
121 2015-05-08 16:20:20 <sipa> they get apllied one by one to the utxo set
122 2015-05-08 16:20:43 <sipa> actually, no, they operate on a temporary per-block cache for changes
123 2015-05-08 16:20:57 <sipa> so they'll cancel eachother out before ever hitting the main cache
124 2015-05-08 16:21:08 <sipa> and certainly before hitting disk
125 2015-05-08 16:23:43 <stonecoldpat> ok, so i send tx1, that is stored in memopool and then once a block comes, remove from mempool and add to block. then i send tx2, that is stored in mempool, i send tx3 and we use the mempool to verify that these are chained, eventually both are removed from mempool and added to block. is that correct? I need to look at the code (doing that now), but intuitively id think its more expensive
126 2015-05-08 16:23:43 <stonecoldpat> to store a transaction in mempool than to store the outputs in utxo
127 2015-05-08 16:25:52 <sipa> yes
128 2015-05-08 16:26:02 <sipa> in the mempool we need to keep full transactions
129 2015-05-08 16:26:29 <gavinandresen> Post updated; upper limit on running a 20MB block node at todayâs RAM prices would be something like $10,000/year (1MB is 1/20âth that).
130 2015-05-08 16:26:50 <sturles> How is the size distribution of outputs in the utxo set? I have collected a lot of dust spam over the years, and Bitcoin Core will never select those outputs in new transactions.
131 2015-05-08 16:27:56 <sturles> At leas one scamcoin, possibly more, use some proof-of-utxo-space-in-bitcoin scheme for coin generation. How much is wasted on purposes like that?
132 2015-05-08 16:28:01 <stonecoldpat> 20mb as an example, transactions are moved to utxo more quickly, requiring less ram, (im not familiar with the code, so please correct if im wrong)
133 2015-05-08 16:28:01 <stonecoldpat> so the link gavin posted about utxo becoming too big, the counter argument I would state, bitcoins going to get more popular and this will lead to more transactions (regardless of blocksize), if we keep a small blocksize 1mb, then we need to keep transactions in mempool longer due to the backlong which should require more ram (not sure if theres an upper limit?), otherwise if we make it
134 2015-05-08 16:28:50 <gavinandresen> stonecoldpat: a memory-limited mempool will be implemented soon.
135 2015-05-08 16:28:58 <sipa> so: the mempool is not relevant, we can just limit its size
136 2015-05-08 16:32:46 <GAit> sipa: fee/age drop strategy?
137 2015-05-08 16:33:05 <Luke-Jr> gavinandresen: upper limit measured how? even 1 MB allows for infinite UTXO set growth over infinite time
138 2015-05-08 16:33:09 <gavinandresen> sipa : I apologize for not looking at the UTXO trends sooner, but all of the arguments against raising the block size are like a gish gallop : http://rationalwiki.org/wiki/Gish_Gallop
139 2015-05-08 16:33:35 <gavinandresen> Luke-Jr: measured in how many extra dollars to I need to spend per year
140 2015-05-08 16:34:48 <sipa> petertodd: better talk here than on twitter
141 2015-05-08 16:35:11 <sipa> gavinandresen: well, thanks for looking at it now :)
142 2015-05-08 16:39:06 <stonecoldpat> if mempool gets limited, will that not just lead to more traffic on the network?
143 2015-05-08 16:39:57 <stonecoldpat> if its a slider then i broadcast every time i get dropped, if its just "full" then its more a race to get in
144 2015-05-08 16:42:08 <instagibbs> stonecoldpat: yeah it's a bit more complicated at first glance, which is why I think RBF-style fee discrimination is going to have to happen in some regard. Maybe a mixture of age/fee
145 2015-05-08 16:42:43 <instagibbs> but unsure what sipa et al are thinking :)
146 2015-05-08 16:42:49 <stonecoldpat> so at the expense of a small blocksize and a limited mempool, we will just increase bandwidth requirements (which the smaller bocksize is supposed to be avoiding?)
147 2015-05-08 16:42:53 <dgenr8> I wonder if there is a way to scale by reducing redundancy somewhat ... ... ...
148 2015-05-08 16:43:36 <stonecoldpat> instagibbs: what is rbf-style? (sorry its getting late here and brain is dying)
149 2015-05-08 16:43:43 <sipa> replace by fee
150 2015-05-08 16:43:44 <sipa> replace by fee
151 2015-05-08 16:44:02 <instagibbs> stonecoldpat: I mean replace-by-fee, but doesn't necessitate intentionally propagating double-spends
152 2015-05-08 16:44:27 <instagibbs> replace-by-some-resource <--- something like this
153 2015-05-08 16:44:30 <stonecoldpat> instagibbs: ah okay, i was just about to say i didnt think it solved the problem by propagating double-spends, lol
154 2015-05-08 16:44:43 <dgenr8> perhaps my node only works on txid's starting with hex 0 or 1 ...
155 2015-05-08 16:45:00 <instagibbs> My personal belief is that stopping propagation of double-spends is impossible, but I'm no wizard. *shrug*
156 2015-05-08 16:47:45 <dgenr8> instagibbs: my 6000 data points say you're right. only 20% of respends of unconfirmed txes are unsuccessful. it's probably skewed that way by miner activity (and not necessarily nefarious)
157 2015-05-08 16:48:47 <instagibbs> dgenr8: do you have a write-up? I'm really interested in what's happening today, even though I have my suspcions about end-game
158 2015-05-08 16:52:57 <dgenr8> instagibbs: respend success% plotted by the time measured between first tx1 seen, and respend tx2 seen http://i.imgur.com/0bYXrjn.png . only 20% of hash power strictly respects first-seen today
159 2015-05-08 16:55:00 <GAit> dgenr8: wow
160 2015-05-08 16:55:40 <jgarzik> instagibbs, Ultimately it is pointless to attempt to secure 0-conf transactions - because that is the point of bitcoin itself
161 2015-05-08 16:55:51 <jgarzik> instant+secure will not happen at Layer 1
162 2015-05-08 16:55:52 <jgarzik> instant+secure will not happen at Layer 1
163 2015-05-08 16:56:10 <jgarzik> therefore argumentation to scale bitcoin up to VISA levels is nuttery
164 2015-05-08 16:56:15 <GAit> +1
165 2015-05-08 16:56:53 <Luke-Jr> s/bitcoin/the blockchain/ âº
166 2015-05-08 16:56:58 <Apocalyptic> jgarzik, it certainly is
167 2015-05-08 16:57:17 <Diablo-D3> bitcoin isnt evne really meant for this
168 2015-05-08 16:57:30 <Diablo-D3> it was meant to replace "slow" transactions like ACH
169 2015-05-08 16:58:24 <dgenr8> Diablo-D3: although 90% of nodes have a tx within 2.5s. that is impressive.
170 2015-05-08 16:58:42 <Diablo-D3> dgenr8: sure, but it takes about an hour to fully confirm a tx
171 2015-05-08 16:59:10 <Diablo-D3> an hour vs 3 business days (which may be up to 6 real days) is a pretty good improvement
172 2015-05-08 16:59:25 <instagibbs> jgarzik: My opinion is that in a healthy Bitcoin ecosystem, it's obviously impossible to stop. Can't stop signal getting to miners, and miners should be anon as possible, unable to be punished.
173 2015-05-08 16:59:26 <Diablo-D3> it'd be enough to massively improve the financial health of the global economy
174 2015-05-08 17:02:26 <Luke-Jr> instagibbs: miner anonymity is somewhat impractical
175 2015-05-08 17:02:43 <Luke-Jr> even if Bitcoin were to be anonymous someday, miners have huge electric use
176 2015-05-08 17:02:52 <dgenr8> jgarzik: if you relax "instant" to "quick" the statement isn't so obvious
177 2015-05-08 17:02:56 <instagibbs> Never said the mining scene was healthy :)
178 2015-05-08 17:03:05 <rfreeman_w> use farming ganja as cover for bitcoin mining operation ;o
179 2015-05-08 17:03:15 <Diablo-D3> rfreeman_w: heh fuck that
180 2015-05-08 17:03:18 <Diablo-D3> move to colorado
181 2015-05-08 17:03:18 <instagibbs> Luke-Jr: I'm talking about my pure fantasy vision of 100% decentralized and unicorns.
182 2015-05-08 17:03:27 <Diablo-D3> use ganja farming to offset winter heating costs
183 2015-05-08 17:03:58 <sipa> dgenr8: if "quick" means ~seconds, it is
184 2015-05-08 17:05:14 <dgenr8> sipa: it is very interesting to quantify it. but today i'm curious about scaling ... do you have thoughts on if it's possible to partition work within the network?
185 2015-05-08 17:10:59 <dgenr8> jgarzik: "quick" is just as desirable for larger transactions as it is for coffee. also, even if coffee worked, bitcoin would never get anywhere near all the business.
186 2015-05-08 17:12:43 <offbase> if hitting the max block size will bring bitcoin down, why do we even have one?
187 2015-05-08 17:14:32 <Luke-Jr> offbase: because not having one will bring bitcoin down more permanently
188 2015-05-08 17:16:04 <offbase> Luke-Jr: how does that attack work? someone makes a huge block and what happens?
189 2015-05-08 17:18:47 <temujin> offbase: everyone has to hold that huge block. also if the attacker is extra devious, they'd make sure all the outputs are unspent forever, further raising the size of the UTXO set
190 2015-05-08 17:39:29 <StephenM347> didn't bitcoin used to have an even smaller limit than 1 MB?
191 2015-05-08 17:39:30 <StephenM347> didn't bitcoin used to have an even smaller limit than 1 MB?
192 2015-05-08 17:39:45 <gruez> no?
193 2015-05-08 17:39:46 <gruez> no?
194 2015-05-08 17:40:06 <gruez> the network limit is 1mb, the limit that bitcoin core will create is 250k
195 2015-05-08 17:41:05 <StephenM347> The default block size limit is 750 kb, I thought I had read somewhere that the limit used to be like 50 kb or something
196 2015-05-08 17:51:30 <gmaxwell> gruez: thats not correct anymore; bitcoin core's default is 750k. its been repeadily increased over time.
197 2015-05-08 17:52:03 <gruez> ah ok
198 2015-05-08 17:58:27 <stonecoldpat> sipa: with a mempool limit, would you drop old transactions that have not been accepted yet, or just refuse a transaction getting in?
199 2015-05-08 18:00:46 <dgenr8> is blockstream working on a payment channel network implementation? is bitpay? and if so, will fees be charged?
200 2015-05-08 18:04:06 <gavinandresen> stonecoldpat: it would probably be: add transaction to the mempool. If mempool at limit, drop lowest fee-paying transaction. Which might be the one you just added. And maybe keep track of which peer sent you each transaction, and if that peer is still connected send a ârejectâ message with the txid you dropped.
201 2015-05-08 18:05:35 <gavinandresen> stonecoldpat: ⦠with probably a separate pool for free transactions, where lowest-priority is droppedâ¦.
202 2015-05-08 18:05:51 <gmaxwell> dgenr8: not yet; /now/ looking into it. (well lightning network, not payment channels); as far as fees go not sure the nature of your question; it's not interesting unless its a IMO decenteralized system which would preclude being able to charge fees just for creating it... (if you are willing to trust a single source, might as well hand over your coins; the marginal benefit from trustlessness if the
203 2015-05-08 18:05:57 <gmaxwell> re is just a single server or whatever wouldn't be worth the development)
204 2015-05-08 18:09:45 <dgenr8> it would be sublime if blockstream could proclaim that its entire business model is to hold bitcoin and increase its value by making bitcoin better.
205 2015-05-08 18:13:40 <helo> high value is not necessarily "better bitcoin". e.g. a short-term pump
206 2015-05-08 18:14:32 <gmaxwell> dgenr8: some of our biggest investors own a /lot/ of bitcoin; all our employees own bitcoin (we've structured our compensation to result in that even for people who it wasn't true for; w/ timelocked bitcoin grants). But it's hard to make a sustainable business out of that alone. Fortunately if Bitcoin grows there are tons of additional business oppturnities that result; and if you note the primary ex
207 2015-05-08 18:14:38 <gmaxwell> pertise of most nascent bitcoin businesses is not technical.
208 2015-05-08 18:21:27 <dgenr8> quite a lot can be "sustained" with a big enough value increase... and I confess to being an insane optimist in that regard. ... and it would completely assuage any conflict of interest doubts
209 2015-05-08 18:48:34 <jgarzik> gmaxwell, Disagree on that last point RE single-server. It is a net win for both users and BitPay to go from BitPay-current to a BitPay-run payment channel system where BitPay does not hold merchant funds at all + all the benefits of payment channels.
210 2015-05-08 18:48:50 <jgarzik> Obviously in the context of the current debate that is insufficient from decentralization perspective
211 2015-05-08 18:48:56 <jgarzik> it is nonetheless a step forward
212 2015-05-08 18:49:38 <jgarzik> Net trust in BitPay is reduced and provability of intermediate steps is increased
213 2015-05-08 18:50:03 <gmaxwell> jgarzik: My personal take; other people might find value in it.
214 2015-05-08 18:50:26 <bedeho> dgenr8: It is a very inefficient sort of insentive. General asset appreciation of btc is a huge spillover which blockstream cannot capture, given its (presumably) small stake in total btc supply. Trying to borrow tons of money to buy a larger share of btc means you have to adjust any return by risk adjusted interest on this capital, so that also will likely not work well.
215 2015-05-08 18:51:28 <bedeho> jgarzik: Is that the approach of the impulse proposal?
216 2015-05-08 18:51:51 <gmaxwell> jgarzik: at least in the context of blockstream we're taken a conscious decision to avoid outright centeralized things wherever possible; I don't begrudge other people exploring differnet paths, they have their place too (and usually much easier to do well).
217 2015-05-08 18:53:48 <jgarzik> bedeho, Impulse is "payment channels as UTXO" concept
218 2015-05-08 18:54:10 <jgarzik> bedeho, Wallet holds open a number of payment channels. When paying for something, you instantly pay using already-open channels.
219 2015-05-08 18:54:11 <jgarzik> bedeho, Wallet holds open a number of payment channels. When paying for something, you instantly pay using already-open channels.
220 2015-05-08 18:54:33 <bedeho> all channels are with bitpay?
221 2015-05-08 18:54:50 <jgarzik> bedeho, the protocol is open, does not require bitpay
222 2015-05-08 18:55:08 <bedeho> ok, but both parties need open channels with same "server", e.g. bitpay?
223 2015-05-08 18:55:43 <jgarzik> bedeho, main issue becomes where you get your TX outputs from -- user and bitpay can agree on merchants (Starbucks, Walmart) , a less trusted scenario, or get TX outputs from bitpay, a more trusted scenario
224 2015-05-08 18:55:54 <jgarzik> bedeho, yes
225 2015-05-08 18:56:08 <jgarzik> bedeho, you can also have clearinghouse hubs, vendor neutral
226 2015-05-08 18:57:34 <gmaxwell> dgenr8: it doesn't assuage conflict of interest though; because short term bitcoin growth is potentially at odds with just long term. Not to mention other factors.
227 2015-05-08 18:58:04 <bedeho> jgarzik: so if X wants to pay Y, and both have open channels - as payors, with some central party, then X pays sentral server, and then server and Y do reverse payment by doing the new locktime trick?
228 2015-05-08 18:58:48 <bedeho> bitpay does not need to open channels and put its own funds, right? cause interest on that would seem to make it unsustainable for scaling
229 2015-05-08 19:00:04 <jgarzik> bedeho, if the merchant receives BTC, the payment channel transaction may send the BTC straight to the merchant. BitPay provably does not hold funds in that scenario, which reduces BitPay's and the merchant's risk.
230 2015-05-08 19:03:44 <dgenr8> bedeho: all successful businesses have spillover. it's the value they provide to their stakeholders (owners, customers mainly). true, the insider held portion is less than your typical IPO. but the opportunity to reengineer world commerce is so enormous, the rules are different
231 2015-05-08 19:04:17 <jgarzik> hum... I wonder if there is some way to provably give out Starbucks payment addresses... without any pre-transaction network communication to Starbucks?
232 2015-05-08 19:04:21 <jgarzik> surely some HD magic
233 2015-05-08 19:04:58 <jgarzik> publicly signed seed, each tx hashes in a customer id, and then communicates the tx and id
234 2015-05-08 19:05:01 <gmaxwell> BlueMatt: last version I tested on arm was 84a05b843b8ab704266289de67c9779ad733a196
235 2015-05-08 19:05:14 <sipa> jgarzik: sure, the problem is how to do it provably and without privacy loss
236 2015-05-08 19:05:23 <jgarzik> goal: public Starbucks seed, privacy of TXs
237 2015-05-08 19:05:39 <jgarzik> right, the customer id is some random nonce generated by customer
238 2015-05-08 19:05:56 <jgarzik> payment cannot be found without that? <thinking aloud>
239 2015-05-08 19:06:21 <jgarzik> i.e. incorporate that nonce into the HD derivation
240 2015-05-08 19:06:57 <jgarzik> payee would need to have that nonce value to notice the payment
241 2015-05-08 19:07:06 <bedeho> dgenr8: regualr value to costumers is not a spillover, it is consumer surplus - and is fine, the spillover are the unpriced benefits blockstream creates for people it cannot do bargains with to finance its investments. In this case, their small btc stake makes that the rule, not the exception. But yeah, ofcs. I hope they do great stuff :)
242 2015-05-08 19:07:30 <sipa> the correct solution imho is let the customer choose the nonce, put it in the payment message, encrypt the payment with a paymentrequest-provided encryption key, and send it to a mailbox service, where the receiver can anonimously pick it up and broadcast the transactio
243 2015-05-08 19:07:31 <sipa> the correct solution imho is let the customer choose the nonce, put it in the payment message, encrypt the payment with a paymentrequest-provided encryption key, and send it to a mailbox service, where the receiver can anonimously pick it up and broadcast the transactio
244 2015-05-08 19:07:35 <sipa> jgarzik:
245 2015-05-08 19:07:44 <jgarzik> sipa, right, that's what I'm suggesting :)
246 2015-05-08 19:09:19 <Adlai> this sounds remarkably similar to the "reusable" address proposal
247 2015-05-08 19:11:11 <sipa> Adlai: except 0 blockchain overhead, and guaranteed secure sidechannel information (for refund address or memos)
248 2015-05-08 19:12:01 <sipa> jgarzik: i vaguely heard some thing about something like this from hearn, involved "subspace", but never looked into it
249 2015-05-08 19:20:12 <dgenr8> gmaxwell: i can't be the only one who doesn't want to wonder, when core devs suggest bitcoin doesn't need something because another solution is better
250 2015-05-08 19:25:31 <jgarzik> dgenr8, this is the binary thinking which I've been criticizing
251 2015-05-08 19:25:49 <jgarzik> dgenr8, it's another one solution-or-another, it is a combination of solutions
252 2015-05-08 19:26:14 <dgenr8> this is not a technical issue
253 2015-05-08 19:27:09 <jgarzik> nope it's not
254 2015-05-08 19:27:10 <jgarzik> nope it's not
255 2015-05-08 19:28:46 <helo> are there harsh ban penalties for nodes that send invalid blocks?
256 2015-05-08 19:29:24 <jgarzik> er, *it's not one solution or another, it's a combination
257 2015-05-08 19:29:52 <jgarzik> simply raising block size absent other thinking might be short term necessary, but it is also long term poor signalling
258 2015-05-08 19:34:47 <sipa> helo: yes
259 2015-05-08 19:37:12 <dgenr8> jgarzik: if someone comes to the same conclusion as you, it's probably a good idea to credit them with more than "zero" thinking
260 2015-05-08 19:37:35 <gmaxwell> dgenr8: in my case; I've been saying this since 2011 at least; as is easily shown https://en.bitcoin.it/w/index.php?title=Scalability&action=historysubmit&diff=14273&oldid=14112
261 2015-05-08 19:39:54 <WeiJunLi> what are the ways of integrating a bitcoin wallet service without third parties?
262 2015-05-08 19:40:57 <helo> WeiJunLi: #bitcoin
263 2015-05-08 19:46:15 <sdaftuar> travis sadness: https://travis-ci.org/bitcoin/bitcoin/jobs/61800593. also eg here: https://travis-ci.org/bitcoin/bitcoin/jobs/61759720. anyone have any thoughts? from staring at code, it looks to me most likely to be a bug (race condition?) in the java test itself, but i need better debugging tools for this...
264 2015-05-08 19:47:48 <dgenr8> gmaxwell: i don't see how the appearance of conflict can be addressed without aligning the incentives
265 2015-05-08 19:48:13 <gavinandresen> sdaftuar: maybe BlueMatt can help. I think heâs currently the single-point-of-failure for the java tester tool
266 2015-05-08 19:49:10 <jgarzik> I keep meaning to build a domain-specific micro-language that permits easy description of various chain scenarios we want to test
267 2015-05-08 19:49:24 <jgarzik> and not in java
268 2015-05-08 19:50:47 <phantomcircuit> sdaftuar, the bitcoinj test cases do have bugs like that
269 2015-05-08 19:51:11 <phantomcircuit> try making a trivial change and trigger the tests again...
270 2015-05-08 19:51:12 <phantomcircuit> try making a trivial change and trigger the tests again...
271 2015-05-08 19:51:38 <sdaftuar> phantomcircuit: yeah that's what i have been doing, i'll try it again. before i was thinking the travis environment was flaky somehow
272 2015-05-08 19:51:46 <BlueMatt> gavinandresen: no, anyone can go build it pretty easily afaik
273 2015-05-08 19:51:59 <sdaftuar> but after looking at this particular error, it seems more likely to be an issue with the code itself, though i can't see how
274 2015-05-08 19:52:37 <gavinandresen> BlueMatt: great!
275 2015-05-08 19:52:47 <BlueMatt> thats been true for....6 months?
276 2015-05-08 19:53:14 <gavinandresen> BlueMatt: where are the docs for doing that? Iâm looking in src/qa/pull-tester and donât see anything
277 2015-05-08 19:53:36 <gavinandresen> ACTION looks in doc/ ....
278 2015-05-08 19:54:43 <sdaftuar> BlueMatt: any guesses on the travis issue i linked above?
279 2015-05-08 19:55:59 <hulkhogan_> bug in the comparison tool? doesnt look like its handling empty headers correctly
280 2015-05-08 19:56:29 <gavinandresen> BlueMatt: Iâm sure it is easy when you know how, but Iâm not finding any documentation on how in our source tree....
281 2015-05-08 19:56:55 <hulkhogan_> sdaftuar: quickfix: wrap those lines with try/catch
282 2015-05-08 19:58:54 <sdaftuar> hulkhogan_: actually changing the java testing framework that the pull-tester runs is going to be not-a-quick-fix for me, unfortunately. (though i have got my environment set up to run the tests locally, where it of course succeeds)
283 2015-05-08 19:59:27 <hulkhogan_> do you mind providing the logs for that (local), ie i686
284 2015-05-08 20:01:32 <hulkhogan_> looking for that tool..
285 2015-05-08 20:02:17 <hulkhogan_> tool is here or so: https://github.com/bitcoinj/bitcoinj/blob/master/core/src/test/java/org/bitcoinj/core/BitcoindComparisonTool.java
286 2015-05-08 20:02:27 <hulkhogan_> might need a patchup
287 2015-05-08 20:02:52 <sdaftuar> yep that is the tool, the exception is at line 311 i think
288 2015-05-08 20:04:36 <hulkhogan_> yea
289 2015-05-08 20:04:51 <hulkhogan_> trying to trace the test, its running the yml from bitcoin/bitcoin i guess right
290 2015-05-08 20:05:04 <hulkhogan_> ie https://github.com/bitcoin/bitcoin/blob/master/.travis.yml#L34-L35
291 2015-05-08 20:05:32 <sdaftuar> yes that's right... (you have a long rabbit hole to go :))
292 2015-05-08 20:05:33 <hulkhogan_> where's the invokation for bitcoinj..
293 2015-05-08 20:05:34 <hulkhogan_> where's the invokation for bitcoinj..
294 2015-05-08 20:05:47 <sdaftuar> there's a script in qa/pull-tester
295 2015-05-08 20:05:56 <hulkhogan_> well, it looks like a 32bit or fail-to-catch npe on block headers, not too deep
296 2015-05-08 20:06:01 <sdaftuar> run-bitcoind-for-test.sh i think
297 2015-05-08 20:06:24 <sdaftuar> which i think is invoked by make check-local
298 2015-05-08 20:07:07 <sdaftuar> if you run ./configure at the top level with the right options
299 2015-05-08 20:07:16 <hulkhogan_> yea
300 2015-05-08 20:07:59 <hulkhogan_> https://github.com/bitcoin/bitcoin/blob/master/Makefile.am#L195-L197
301 2015-05-08 20:08:03 <hulkhogan_> eh, how to check travis env..
302 2015-05-08 20:09:20 <hulkhogan_> i would guess cfield/s might have a clue
303 2015-05-08 20:11:10 <sdaftuar> hulkhogan_: i need to step away for a bit but will be back online later tonight; thanks for taking a look
304 2015-05-08 20:12:26 <hulkhogan_> sdaftuar: just trying to get a clean build, right?
305 2015-05-08 20:12:34 <hulkhogan_> sure
306 2015-05-08 20:13:16 <hulkhogan_> just need to know what build/ver travis uses, if its a bitcoinj issue then its easy to fix
307 2015-05-08 20:15:22 <hulkhogan_> by the way, even on the "passing builds" there are a flurry of exceptions in the log, so its probably a unmaintained build tool thats the issue, not your code
308 2015-05-08 20:15:38 <hulkhogan_> search: exception for that :)
309 2015-05-08 20:19:25 <hulkhogan_> last commit on comparison tool, dec 2014
310 2015-05-08 20:29:10 <hulkhogan_> made issue
311 2015-05-08 21:25:12 <BlueMatt> gavinandresen: its in bitcoinj
312 2015-05-08 21:41:07 <justanotheruser> Is createrawtransaction supposed to allow me to make invalid transactions?
313 2015-05-08 21:41:26 <sipa> that's inevitable
314 2015-05-08 21:41:36 <sipa> if you give it an incorrect input utxo
315 2015-05-08 21:42:04 <justanotheruser> oh, I thought it checked each input, nevermind :P