1 2015-01-07 00:00:09 <starsoccer> well as an example if I was mining a block
2 2015-01-07 00:00:15 <starsoccer> what would the coinbase transaction be
3 2015-01-07 00:00:26 <starsoccer> and was mining to a multi-signature addy
4 2015-01-07 00:32:43 <michagogo> starsoccer: it would be just like any other transaction paying to a multisig address
5 2015-01-07 00:33:14 <michagogo> (P2SH address, really)
6 2015-01-07 01:14:12 <cfields> Luke-Jr: https://github.com/bitcoin/bitcoin/pull/5611 for the spurious travis failure
7 2015-01-07 01:14:17 <cfields> (thanks sipa for the help)
8 2015-01-07 01:15:32 <gmaxwell> wtf is rand() on window?!!?!
9 2015-01-07 01:15:38 <gmaxwell> er windows
10 2015-01-07 01:17:32 <cfields> gmaxwell: seems to be on par with: guess how many fingers i'm holding up behind my back
11 2015-01-07 01:19:32 <gmaxwell> All the common low quality non-cryptographic RNGs people normally use have long periods. Weird.
12 2015-01-07 01:21:08 <cfields> gmaxwell: worth noting that travis and i are both using wine to run the tests
13 2015-01-07 01:21:31 <gmaxwell> ah, perhaps wine is helpfully stupid.
14 2015-01-07 01:21:43 <cfields> hope so
15 2015-01-07 01:22:06 <cfields> i stuck it in a quick bash while loop. usually hit at < 10 iterations
16 2015-01-07 01:33:53 <Arnavion> Windows builds aren't linked to the Windows CRT anyway, yes? So rand() would be whatever your cross-compiler implements it to be
17 2015-01-07 01:46:37 <cfields> Arnavion: the binary ends up with an entry for rand coming from msvcrt.dll, so no, looks like it comes in at runtime
18 2015-01-07 01:47:03 <Arnavion> Ah, okay
19 2015-01-07 01:47:20 <cfields> that's how it looks to me, anyway. I could certainly be wrong there
20 2015-01-07 02:43:28 <jakesyl_insomnia> yo
21 2015-01-07 03:12:22 <kkode> I've been looking at main.cpp on github and im trying to understand what this syntax means >>= here: nSubsidy >>= halvings;
22 2015-01-07 03:16:38 <iwilcox> C(++) questions belong elsewhere really. It's just shorthand for nSubsidy = nSubsidy >> halvings;
23 2015-01-07 03:17:49 <justanotheruser> Wasn't that changed?
24 2015-01-07 03:18:10 <justanotheruser> from the original I mean
25 2015-01-07 03:18:36 <justanotheruser> nSubsidy >>= (nHeight / 210000);
26 2015-01-07 03:19:14 <justanotheruser> Yes, it was softforked to fix bitcoins inflationary nature and simulated goldmine finding
27 2015-01-07 03:28:18 <kkode> iwilcox: thanks!
28 2015-01-07 03:33:12 <guest213123123> every so often a number of 100k+ butcoin nodes pops up. whwat is it based on?
29 2015-01-07 03:41:36 <astuuu> hiya, folks! tis a fine day today
30 2015-01-07 03:41:40 <SubCreative> indeeed
31 2015-01-07 03:41:57 <astuuu> more debugging for me today. here we go
32 2015-01-07 03:50:47 <dgenr8> how about using the world's biggest bloom filter to prevent address reuse? it wouldn't add much to storage requirements
33 2015-01-07 04:02:26 <blockbits> Can't wait until we have 20MB blocks. I've developed a easy to use web front-end for people to upload files to the blockchain, using scriptsigs to store data. they can retrieve files by simply pasting any TX. I've put aside a few hundreds thousand dollars to pay mining pools to mine my non-standard tx's for free. I was hoping we can increase the block size to 200MB... please make it as big as possible, my data storage busin
34 2015-01-07 04:04:14 <abracadabra> seriously?
35 2015-01-07 04:04:21 <abracadabra> ACTION thinks blockbits is pulling my leg
36 2015-01-07 04:04:31 <blockbits> yes, I was insipred by this tx I saw here in the logs. webbtc.com/tx/e6ff83a41715a87dad0b181febfaee2845e2a4334c3ce8bcb6ec697a6cfed5ed
37 2015-01-07 04:04:43 <kanzure> can you just stick to one channel please :/
38 2015-01-07 04:08:53 <blockbits> you'd never belive how easy it is to pay ghash.io and other pools money to mine whatever you want... I already have contacts with big farms in china... The chinese will do anything for a buck!! Hoping we can incentivize cetnralization as much as possible -- ASIC cartels in asia have worked out really well. These people are easy to pay off.
39 2015-01-07 04:10:05 <blockbits> blockstream will have no problem paying miners to mine their sidechain and ignore others... And I should be able to move forward with my data storage business easily.
40 2015-01-07 04:11:25 <dgenr8> at ~2 bytes/address it would be less than 10% of the UTXO set size. this is for a .1% false-positive rate, very back-of-envelope
41 2015-01-07 04:20:35 <harding> dgenr8: doesn't the expected false positives inherient in a bloom filter make it unsuitable for blocking transactions reusing addresses? I mean, what if you discover you want to pay somebody whose address is accidentally blocked?
42 2015-01-07 04:21:55 <iwilcox> The Bitstamp thing seems to be priceless marketing for anti-re-use.
43 2015-01-07 04:22:21 <dgenr8> harding: payee's software would have rejected that address before providing it and generated a new one. theoretically.
44 2015-01-07 04:23:33 <dgenr8> but yeah, it could have become invalid due to new blocks
45 2015-01-07 04:23:55 <dgenr8> so addresses would need to be really fresh, indeed
46 2015-01-07 04:24:34 <dgenr8> although that's not specific to the bloom filter idea, but any anti-reuse scheme
47 2015-01-07 04:25:38 <dgenr8> on third hand, practically speaking, it's specific to the bloom filter idea ;) since a true collision ain't gonna happen
48 2015-01-07 04:29:40 <blockbits> has there ever been a serious discussion about consuming dust UTXOs as mining fees to prevent spam?
49 2015-01-07 04:29:49 <blockbits> i'm new.
50 2015-01-07 04:45:31 <harding> dgenr8: you probably don't need to prevent address reuse completely to encourage most people to move off of it. For example, a relay rule that only allows one instance of an address in the mempool. When payers start to complain "I couldn't pay you because your address was already in use," payees will be incentivized to use separate addresses for each invoice.
51 2015-01-07 04:46:28 <u1m> anyone know an api for mixing coins?
52 2015-01-07 05:15:08 <melik> astuuu: awh i thought it was a built-in feature :/
53 2015-01-07 05:15:26 <justanotheruser> melik: why not just write a function that converts the value to int?
54 2015-01-07 05:15:50 <justanotheruser> https://en.bitcoin.it/wiki/Proper_Money_Handling_(JSON-RPC)
55 2015-01-07 05:16:25 <melik> thats what im doing right now
56 2015-01-07 05:16:50 <melik> irb(main):012:0> (4.213434 * 100000000).to_i => 421343400
57 2015-01-07 05:18:26 <melik> seems bizarre that the bitcoind RPC interface does not allow you to represent bitcoin in ints
58 2015-01-07 05:18:39 <melik> isnt that how its already stored in the DB, 64 bit ints?
59 2015-01-07 05:20:07 <melik> would be nice if we could just give have a switch/option in bitcoin.conf
60 2015-01-07 05:21:10 <justanotheruser> make a pull request :P
61 2015-01-07 05:24:54 <Arnavion> I'd load it into a bigdecimal class as a string before multiplying by 1e8
62 2015-01-07 05:26:23 <melik> that definitely works Arnavion, its one of my options at the moment
63 2015-01-07 05:26:48 <melik> i dont want to do the math with a float, thats for sure
64 2015-01-07 05:27:00 <Arnavion> You could do it with the bigdecimal
65 2015-01-07 06:59:09 <melvster> http://gavintech.blogspot.cz/2015/01/looking-before-scaling-up-leap.html
66 2015-01-07 06:59:33 <melvster> "Looking before the Scaling Up Leap" -- by gavinandresen
67 2015-01-07 06:59:39 <melvster> is this being discussed someplace?
68 2015-01-07 07:01:49 <melvster> or is there a BIP
69 2015-01-07 07:03:15 <midnightmagic> melvster: /w 37
70 2015-01-07 07:03:35 <midnightmagic> woops. Apologies, that was a spurious tab-completion and nothing to do with anything.
71 2015-01-07 07:16:57 <justanotheruser> melvster: I don't like that the "solution" only allows bitcoin to grow at the speed computers become cheaper
72 2015-01-07 07:22:03 <Emcy> Seems fine to me
73 2015-01-07 07:22:18 <Emcy> the other option is meddling with the system
74 2015-01-07 07:22:51 <justanotheruser> both options are meddling with the system
75 2015-01-07 07:22:57 <justanotheruser> increasing the block size is a hardfork though
76 2015-01-07 07:29:45 <Emcy> how is leaving it alone meddling with the system?
77 2015-01-07 07:30:14 <Emcy> if theres a solid research foundation that upping blosize isnt gonna put joe average nodes out of business then do it
78 2015-01-07 07:31:14 <Emcy> but considering residential internet is looking more metered every year, and neutrality in the core might not be around much longer, that might never actually be the case
79 2015-01-07 07:31:29 <justanotheruser> Emcy: increasing the block size isn't leaving it alone?
80 2015-01-07 07:31:39 <Emcy> in which case the best course of action is probably to forget my worries with my friend Jack
81 2015-01-07 07:32:20 <Emcy> i should probably read it before commenting
82 2015-01-07 07:32:25 <Emcy> ayy lmao
83 2015-01-07 07:34:00 <justanotheruser> wat
84 2015-01-07 07:35:03 <Emcy> https://www.bing.com/images/search?q=ayy%20lmao&go=&form=QBIL&qs=n
85 2015-01-07 07:35:23 <Emcy> i wonder if gav will ever look at some sort of algorithmic blocksize thing, or if thats a good idea
86 2015-01-07 07:35:43 <Emcy> hes pretty set on automated fees
87 2015-01-07 07:36:02 <Emcy> specifically for the reason that centralised fee policy is centralised, and thats bad
88 2015-01-07 07:36:18 <Emcy> well so is running around doing hardfocksa because the blocks are full
89 2015-01-07 09:10:25 <tiyoT> anyone have experienced in Coinbase API callback parameters?? im looking for confirmation parameters
90 2015-01-07 09:10:27 <tiyoT> so, if i receive transaction, i need to wait until 3 confirmation before doing next action.
91 2015-01-07 09:12:45 <tiyoT> i want to know the parameter that i need to wait the 3 confirmation for the coinbase api.
92 2015-01-07 11:41:30 <Eliel> I've got a transaction that gets rejected by bitcoind sendrawtransaction command with error code -25 and empty reject reason. I'm at a loss on how to debug. Any ideas?
93 2015-01-07 11:45:06 <mhanne> Eliel: throw it in http://webbtc.com/relay_tx and see if that gives you a better error
94 2015-01-07 11:45:16 <justanotheruser> Eliel: your transactino is invalid
95 2015-01-07 11:45:33 <sipa> Eliel: try 0.10, it should give more information
96 2015-01-07 11:46:59 <Eliel> justanotheruser: Yes, that is obvious. What I'm interested in is figuring out why.
97 2015-01-07 11:47:24 <Eliel> sipa: I'll try that.
98 2015-01-07 12:04:22 <wumpus> yes, in 0.10 the reporting for invalid transaction reasons should be improved
99 2015-01-07 12:04:45 <wumpus> or rather, is improved
100 2015-01-07 12:09:10 <bedeho> is a bitcoin transaction which spends all funds to fees, and as a result has no outputs or outputs with value=0, valid?
101 2015-01-07 12:09:58 <Luke-Jr> an output with value==0 is valid
102 2015-01-07 12:10:05 <Luke-Jr> not sure about whether you need it or not
103 2015-01-07 12:10:29 <Luke-Jr> (pretty sure you do though)
104 2015-01-07 12:11:04 <Luke-Jr> but I can't think of any legit use case for this
105 2015-01-07 12:11:40 <sipa> bedeho: note tgat it will be nonstandard to bitcoin core, and won't be relayed
106 2015-01-07 12:11:47 <sipa> but it is valid in blocks
107 2015-01-07 12:12:01 <sipa> you need an output though
108 2015-01-07 12:12:07 <Luke-Jr> sipa: if the output is OP_RETURN it might be
109 2015-01-07 12:12:29 <sipa> unsure
110 2015-01-07 12:12:34 <michagogo> bedeho: no outputs is invalid
111 2015-01-07 12:12:50 <Luke-Jr> at least, I think I've seen some in practice (although that isn't a good metric)
112 2015-01-07 12:12:56 <bedeho> I see, so just outputs with value=0, and all inputs to fees is both valid in blocks and is relayed by core?
113 2015-01-07 12:13:33 <michagogo> Definitely valid, yes -- but if sipa's right it won't be relayed by default
114 2015-01-07 12:13:35 <Luke-Jr> bedeho: relay policy is subjective node-to-node. you shouldn't assume it's anything. if you have a use case, it can be adapted to fit
115 2015-01-07 12:14:13 <bedeho> All: thank you
116 2015-01-07 12:39:48 <petertodd> sipa, Luke-Jr: a tx with a single 0-valued OP_RETURN output is valid; my dust-b-gone creates them and I specifically added support to bitcoin core to enable that
117 2015-01-07 12:40:10 <sipa> ok
118 2015-01-07 12:40:35 <Luke-Jr> heh, I guess that's one use case
119 2015-01-07 12:42:00 <petertodd> example: fc8a305eb6aaa7031c9c3c54609613df1e56fefe1136ad28e542f0f1675719ae
120 2015-01-07 12:52:27 <dabura667> sipa are you here?
121 2015-01-07 12:52:55 <sipa> who knows
122 2015-01-07 12:53:10 <dabura667> I'm not sure if you remember this discussion we had early October https://bitcointalk.org/index.php?topic=819424.msg9162125#msg9162125
123 2015-01-07 12:54:28 <sipa> i do
124 2015-01-07 12:55:09 <dabura667> I wanted to ask you would this solution be viable if the implementation never derived more than one key per branch? ie. it would derive m/0/0/0 then the second key would be m/0/1/0... they aren't the same direct parent... so if, for instance, someone who had the A and R + someone who had m/0/0/0 privkey and m/0/1/0 privkey would they be able to collude and
125 2015-01-07 12:55:09 <dabura667> solve for r and a?
126 2015-01-07 12:55:47 <dabura667> instead of m/0/0/0 -> m/0/0/1 like current BIP32
127 2015-01-07 12:56:26 <sipa> i can't imagine that that matters
128 2015-01-07 12:56:38 <sipa> A and R?
129 2015-01-07 12:57:04 <dabura667> me neither... but I'm trying to solve it using A, R, m/0/0/0 and m/0/1/0
130 2015-01-07 12:57:17 <dabura667> ok, so basically it's a obfuscation of BIP32
131 2015-01-07 12:58:12 <dabura667> instead of having the MPK be added to a pubkey derived from some index, it's added to a pubkey derived from an index that is also pultiplied to another pubkey that is derived from a second master private key.
132 2015-01-07 12:58:56 <dabura667> a = privkey, r = Hash(a), a and r together are used to generate keys.
133 2015-01-07 12:59:59 <tiyoT> anyone have experienced in Coinbase API callback parameters??
134 2015-01-07 13:00:09 <sipa> tiyoT: ask them
135 2015-01-07 13:00:37 <dabura667> s(n) = H(n,A); t(n) = H(n,R)... Rn = t(n)*R..... Xn = s(n)*A + Rn
136 2015-01-07 13:02:26 <tiyoT> sipa: im trying using coinbase API for our hot wallet, i need to detect if the transaction have receive 1 confirmation, to give me a calback
137 2015-01-07 13:02:42 <sipa> tiyoT: so ask them, not here
138 2015-01-07 13:03:05 <tiyoT> i need this in JSON format, https://blockchain.info/tx/ca2d6a33214edf56e57d71f047b37e4706f208329c96ba5da2e9b9480436af73 (to detect once tx got 1 confirmation)
139 2015-01-07 13:03:29 <tiyoT> thats a more general question..
140 2015-01-07 13:04:02 <sipa> if you're using a third party api, you depend on them; ask them
141 2015-01-07 13:06:46 <tiyoT> im in their channel, no respond so far. thats why i came here asking whether someone have experienced in them.
142 2015-01-07 13:10:17 <sipa> dabura667: how do you derive the second level?
143 2015-01-07 13:18:50 <jonasschnelli> sipa, logdb: Do you think it's an overkill to fopen, load-entries, append-frames, fclose on every wallet interaction?
144 2015-01-07 13:19:14 <jonasschnelli> sipa, because you initially held the wallet-file permanently open (in init.cpp)
145 2015-01-07 13:22:59 <dabura667> https://www.irccloud.com/pastebin/OPaRuAhP
146 2015-01-07 14:14:26 <paveljanik> compiling main.cpp on a small system is a tragedy...
147 2015-01-07 14:16:09 <paveljanik> 4 minutes of CPU time now on my arm dev board
148 2015-01-07 14:16:15 <paveljanik> :-)
149 2015-01-07 14:17:22 <paveljanik> link phase now!
150 2015-01-07 14:31:56 <Luke-Jr> wumpus: btw, to make things cleaner/easier, I've been branching my 0.10-targetted stuff off a common parent commit so it merges cleanly into master and 0.10; so unless you prefer cherry-pick, you can also just merge the relevant commit straight
151 2015-01-07 14:36:39 <wumpus> Luke-Jr: ok, thanks
152 2015-01-07 14:46:08 <jrick> BlueMatt: I'm seeing continual disconnects and reconnects from a DNSSeed:42 peer to my btcd node
153 2015-01-07 14:46:36 <jrick> only just now noticed the bug, not sure who is at fault (whether dnsseed, or bitcoinj, or btcd)
154 2015-01-07 14:49:01 <wumpus> paveljanik: and that's why you use cross compilation
155 2015-01-07 14:49:03 <michagogo> Hm. How come with UPNP, we set not only whether or not to include it, but also whether or not to make it on by default at configure time?
156 2015-01-07 14:49:33 <wumpus> michagogo: because different distributions have different policies on that
157 2015-01-07 14:49:51 <wumpus> eg, you may want to distribute a bitcoind that has UPNP support, but doesn't use it by default
158 2015-01-07 14:50:00 <michagogo> wumpus: hmm?
159 2015-01-07 14:50:06 <michagogo> And that's not the case with any other features?
160 2015-01-07 14:50:29 <michagogo> I would think that there would be plenty of other defaults that distributors may want to change
161 2015-01-07 14:50:29 <wumpus> like what?
162 2015-01-07 14:51:09 <paveljanik> wumpus, of course, but trying to compile directly is also interesting ;-)
163 2015-01-07 14:51:23 <Luke-Jr> also because bitcoind has traditionally been built with UPnP disabled by default, and Bitcoin-Qt with it enabled by default
164 2015-01-07 14:51:26 <wumpus> michagogo: I supppose the same could be done for the wallet
165 2015-01-07 14:51:55 <wumpus> michagogo: that's another feature that can both be enabled/disabled at compile time and at run time
166 2015-01-07 14:52:39 <wumpus> then again, with multiwallet, disabling the wallet at run time will just be the N=0 case, so I'm not sure it's a good idea
167 2015-01-07 14:53:12 <michagogo> I mean, we have many different knobs. Fee stuff, cache, thread count, connection count, etc
168 2015-01-07 14:53:28 <michagogo> Seems weird to me to be setting a "default" at configure time
169 2015-01-07 14:53:42 <wumpus> but yes, UPnP is the odd duck out here, because some people deeply hate it from a security perspective, but without it we'd have a lot less connectable nodes
170 2015-01-07 14:53:53 <michagogo> I mean, distros usually include stuff like configs, don't they?
171 2015-01-07 14:54:23 <michagogo> If they want to change a default, what's wrong with doing that in the default config they ship?
172 2015-01-07 14:54:31 <wumpus> Luke-Jr: yes, it's mostly due to historical decisions
173 2015-01-07 14:54:36 <wumpus> I wouldn't worry about it
174 2015-01-07 14:55:34 <Luke-Jr> michagogo: shipping a default config for bitcoind isn't very practical
175 2015-01-07 14:56:08 <Luke-Jr> since it's per-user etc
176 2015-01-07 14:56:20 <wumpus> right, a system-wide bitcoind could have a default config though
177 2015-01-07 14:57:29 <wumpus> per-user bitcoind should certainly not look for configuration in other places than the user's homedir
178 2015-01-07 15:01:45 <michagogo> I thought I saw somewhere that shipped it with a default config and had an install script that randomized a password or something
179 2015-01-07 15:01:49 <michagogo> Can't seem to find it again, though
180 2015-01-07 15:02:36 <wumpus> that's probably one of the init scripts that runs a system-wide bitcoind
181 2015-01-07 15:02:56 <wumpus> it's one way of running it
182 2015-01-07 15:04:37 <michagogo> So what happens if a distributor wants to change any other default? Or is UPNP specifically something special that is expected to be especially controversial?
183 2015-01-07 15:05:10 <wumpus> Luke-Jr: #2629 is failing travis with a weird error
184 2015-01-07 15:05:36 <Luke-Jr> 2629 is .. not mine and merged? O.o
185 2015-01-07 15:06:22 <wumpus> eh, #5542, sorry
186 2015-01-07 15:06:33 <sipa> the keys are like right next to eachother
187 2015-01-07 15:06:56 <Luke-Jr> XD
188 2015-01-07 15:07:22 <wumpus> travis is using that number, and I assumed it matches the pull #, but it doesn't
189 2015-01-07 15:07:53 <Luke-Jr> isn't that from before #5611 ?
190 2015-01-07 15:08:24 <michagogo> wumpus: pretty sure that's just a serial number for builds in the project
191 2015-01-07 15:08:44 <wumpus> michagogo: and travis is hanging my browser with some javascript loop
192 2015-01-07 15:08:50 <Luke-Jr> repushed, maybe that will pick up on #5611 being merged
193 2015-01-07 15:09:11 <michagogo> wumpus: that's probably the live log following
194 2015-01-07 15:09:18 <wumpus> so I couldn't go to the github tab to check...
195 2015-01-07 15:09:20 <Luke-Jr> grr, Travis won't do it
196 2015-01-07 15:09:33 <sipa> won't do what?
197 2015-01-07 15:09:34 <michagogo> Luke-Jr: hm? it seems to be doing it
198 2015-01-07 15:09:36 <Luke-Jr> changing the commithash with a single --amend
199 2015-01-07 15:09:39 <michagogo> https://travis-ci.org/bitcoin/bitcoin/builds/46201643
200 2015-01-07 15:09:41 <Luke-Jr> sipa: redo the builds
201 2015-01-07 15:09:52 <sipa> if the commit id changes, it rebuilds
202 2015-01-07 15:09:59 <sipa> afaik
203 2015-01-07 15:10:00 <wumpus> I wish travis had a lighter version of the site
204 2015-01-07 15:10:08 <Luke-Jr> sipa: right, it wasn't. I just forced it to :P
205 2015-01-07 15:10:16 <Luke-Jr> ok, https://travis-ci.org/bitcoin/bitcoin/builds/46201686
206 2015-01-07 15:10:26 <sipa> Luke-Jr: what didn't?
207 2015-01-07 15:10:43 <Luke-Jr> sipa: the commit id didn't change
208 2015-01-07 15:10:49 <Luke-Jr> sipa: the bug/fix was in master
209 2015-01-07 15:10:50 <sipa> ah, yes :)
210 2015-01-07 15:10:55 <sipa> travis doesn't do merges
211 2015-01-07 15:11:02 <Luke-Jr> yes it does :P
212 2015-01-07 15:11:07 <sipa> huh?
213 2015-01-07 15:11:10 <michagogo> wait, weird
214 2015-01-07 15:11:32 <sipa> no, it builds the tip commit of the PR, nothing else
215 2015-01-07 15:11:33 <sipa> afaik
216 2015-01-07 15:11:38 <Luke-Jr> sipa: no, it merges :P
217 2015-01-07 15:11:51 <Luke-Jr> it's building Commit 11ba82d
218 2015-01-07 15:12:00 <wumpus> sipa: AFAIK too
219 2015-01-07 15:12:04 <Luke-Jr> commit 11ba82d3a0fbb3d01e586d38741b8e0f8c34203b (origin-pull/5542/merge)
220 2015-01-07 15:12:10 <michagogo> https://github.com/bitcoin/bitcoin/pull/5542 linked to https://travis-ci.org/bitcoin/bitcoin/builds/46201643 when I refreshed
221 2015-01-07 15:12:13 <sipa> ah
222 2015-01-07 15:12:45 <michagogo> now I refreshed again and it's linking to https://travis-ci.org/bitcoin/bitcoin/builds/46201686 again
223 2015-01-07 15:13:30 <jgarzik> hearn, Are tech details of this "hub and spoke" strawpay thing published anywhere?
224 2015-01-07 15:14:07 <jgarzik> hearn, BitPay designed something else with payment channels, which permits instant, secure payments to any number of 3rd parties
225 2015-01-07 15:14:29 <jgarzik> sounds like they could be combined, and maybe we could learn something from strawpay.
226 2015-01-07 15:15:30 <hearn> jgarzik: AFAIK not really. they have done an integration with multibit (classic)
227 2015-01-07 15:15:46 <hearn> jgarzik: and i think it's either already geared off the payment protocol, or will be. i think they are/were looking for investors
228 2015-01-07 15:16:00 <hearn> jgarzik: but i have never been able to play with their code. they just pop up with bug fixes and improvements from time to time
229 2015-01-07 15:16:04 <jgarzik> hearn, sigh. so hard to get details :)
230 2015-01-07 15:16:18 <hearn> i guess you/we could email them and ask for a real demo :)
231 2015-01-07 15:16:24 <hearn> i'm not sure they're aware you guys are doing something similar
232 2015-01-07 15:16:37 <jgarzik> hearn, nobody is :)
233 2015-01-07 15:16:44 <jgarzik> (until now)
234 2015-01-07 15:43:50 <kaliuseruser> Hi! Is this the channel for asking for help ?
235 2015-01-07 15:44:59 <jonasschnelli> Depends. What help?
236 2015-01-07 15:50:04 <kaliuseruser> I'm looking for a way to download only the new blocks, for example to get only blocks that were created yesterday without downloading the whole blockchain.
237 2015-01-07 15:51:10 <wumpus> you could help testing the pruning pull, it accomplishes that
238 2015-01-07 15:51:52 <wumpus> (ie it allows you to set a maximum amount of disk space that will be used, and it will only retain the newest blocks up to that amount)
239 2015-01-07 15:53:35 <earlz> what is the status of 0.10?
240 2015-01-07 15:53:58 <wumpus> rc1 has been released, rc2 will be shortly
241 2015-01-07 15:54:03 <hearn> wumpus: you'd still have to download all of them, however
242 2015-01-07 15:54:09 <hearn> kaliuseruser: you'd need a special tool for that.
243 2015-01-07 15:54:17 <earlz> awesome, so it's pretty close then?
244 2015-01-07 15:54:33 <sipa> earlz: maybe, help test it :)
245 2015-01-07 15:54:45 <earlz> any specific areas needed?
246 2015-01-07 15:56:14 <wumpus> Luke-Jr: #5542 still not passing travis
247 2015-01-07 15:59:33 <Luke-Jr> hm
248 2015-01-07 16:02:25 <michagogo> kaliuseruser: what do you need the blocks for?
249 2015-01-07 16:02:52 <michagogo> Are you looking to validate transactions/get the utxo set?
250 2015-01-07 16:03:30 <Luke-Jr> wumpus: reordered the commits so the first two can be merged in case you don't want to wait for figuring out this problem with the qt/boost stuff
251 2015-01-07 16:04:02 <jonasschnelli> what is the ThreadFlushWalletDB (flush wallet every 500ms)? Is this in case bitcoind has been killed or crashed?
252 2015-01-07 16:05:15 <wumpus> jonasschnelli: yes
253 2015-01-07 16:05:18 <Luke-Jr> too bad I can't just run a travis instance here to prioritise these
254 2015-01-07 16:05:43 <wumpus> Luke-Jr: could it be because your stuff is based on an old commit, which fails the travis tests?
255 2015-01-07 16:05:57 <Luke-Jr> wumpus: no, since it's merging with master
256 2015-01-07 16:06:21 <wumpus> Luke-Jr: ok. Although the error seemed to be unrelated with your changes (ie, something with the comparison tool)
257 2015-01-07 16:06:30 <kaliuseruser> so from the responses I can understand there is no way to download only the new blocks alone ?
258 2015-01-07 16:06:36 <Luke-Jr> wumpus: eh? I saw bitcoin-qt failing to build
259 2015-01-07 16:06:46 <wumpus> Luke-Jr: ok
260 2015-01-07 16:07:18 <michagogo> kaliuseruser: why do you need/want to do that?
261 2015-01-07 16:07:19 <wumpus> kaliuseruser: sure, you probably just have to write your own tool, e.g. based on python-bitcoinlib and pynode skeleton or bitcoinj
262 2015-01-07 16:07:57 <michagogo> The answer to "can I do this" can have two different ways of answering.
263 2015-01-07 16:07:58 <Luke-Jr> kaliuseruser: if you mean having a working bitcoin node, then no
264 2015-01-07 16:08:15 <michagogo> First, there's the technical: is doing this exact thing possible
265 2015-01-07 16:08:17 <Luke-Jr> kaliuseruser: the blocks from the last <x> days don't give you the information you need for a node
266 2015-01-07 16:08:41 <michagogo> But then there's the more general, "is doing this thing what it think it is?"
267 2015-01-07 16:09:07 <wumpus> but as you can't validate the blocks without their context, using that information will be insecure
268 2015-01-07 16:10:43 <kaliuseruser> I'm NOT trying to run a node, just want blocks of last x days only,
269 2015-01-07 16:10:51 <sipa> what do you want them for?
270 2015-01-07 16:10:53 <michagogo> kaliuseruser: what for?
271 2015-01-07 16:11:10 <sipa> there may be easier ways to accomplish what you want to do
272 2015-01-07 16:11:23 <michagogo> Do we still have that line in the topic?
273 2015-01-07 16:11:28 <michagogo> Yep
274 2015-01-07 16:12:32 <jonasschnelli> collected miner fees are also mature after 50 blocks like to block reward?
275 2015-01-07 16:12:37 <michagogo> No
276 2015-01-07 16:12:40 <michagogo> 100
277 2015-01-07 16:12:48 <jonasschnelli> 100. sry. yes.
278 2015-01-07 16:12:48 <michagogo> (Same as reward, though)
279 2015-01-07 16:13:01 <bedeho> Question: How does the paying side of a payment channel, e.g. in a p2p market, avoid being fooled into repeatedly opening payment channels and thus loosing a transaction fee?
280 2015-01-07 16:13:02 <michagogo> Yes, because it's all part of the same transaction
281 2015-01-07 16:13:10 <gmaxwell> jonasschnelli: they're indistinguishable to the system; it's just the outputs that mature.
282 2015-01-07 16:13:11 <jonasschnelli> huh, this makes wallet test complex. :)
283 2015-01-07 16:13:25 <jonasschnelli> s/test/tests
284 2015-01-07 16:13:29 <paveljanik> cfields, do you already have some trivial branch open?
285 2015-01-07 16:13:32 <michagogo> The coinbase transaction is one transaction that combines block reward and fees
286 2015-01-07 16:13:34 <paveljanik> git grep exectuable
287 2015-01-07 16:13:47 <jonasschnelli> michagogo, gmaxwell thanks
288 2015-01-07 16:14:20 <sipa> jonasschnelli: hmm, that shouldn't complicate things; they're part of the same output
289 2015-01-07 16:14:30 <sipa> not sure how you'd test one without testing the other
290 2015-01-07 16:14:58 <kaliuseruser> michagogo: I want to create a bootstrap.dat file of blocks of last x days.
291 2015-01-07 16:15:00 <michagogo> paveljanik: are you concerned merely about wasting Travis time? Fixing that shouldn't break other patches, I assume
292 2015-01-07 16:15:20 <michagogo> kaliuseruser: do you already have a synced node?
293 2015-01-07 16:15:28 <paveljanik> michagogo, I do not want to waste reviewers time.
294 2015-01-07 16:16:08 <jonasschnelli> sipa, yes. Right. But i write a rpc test where i create random tx and check the rpc balance agains internal calculated balance... so i need to keep track of which hight a tx was sent and which node did mine the block, etc.
295 2015-01-07 16:16:20 <kaliuseruser> michagogo: If had a synced node it would have been easy to do that
296 2015-01-07 16:16:53 <sipa> kaliuseruser: the bootstrap creation tool allows specifying a range, and afaik it doesn't have to start at 0
297 2015-01-07 16:16:57 <jonasschnelli> sipa, btw: logdb runs smooth now on master... cool stuff!
298 2015-01-07 16:17:16 <michagogo> kaliuseruser: right. So AFAIK there isn't a tool that will download arbitrary blocks from the network
299 2015-01-07 16:17:28 <kaliuseruser> sipa: but it needs the blocks of that range to be in the hard drive,
300 2015-01-07 16:17:32 <michagogo> But there's plenty of libraries out there that you could use to make that
301 2015-01-07 16:17:38 <sipa> kaliuseruser: yes, it needs working full node locally
302 2015-01-07 16:17:39 <michagogo> (Someone mentioned a couple above)
303 2015-01-07 16:17:50 <michagogo> sipa: not quite, only the block data
304 2015-01-07 16:17:58 <kaliuseruser> what about some Web APIs
305 2015-01-07 16:18:11 <sipa> michagogo: it requires RPCs to know block hashes; won't work without a working node :)
306 2015-01-07 16:18:17 <michagogo> Also, iirc it technically does require that you start from 0
307 2015-01-07 16:18:28 <michagogo> sipa: Uh, right.
308 2015-01-07 16:18:31 <michagogo> Oops
309 2015-01-07 16:18:47 <sipa> kaliuseruser: also note that as of 0.10.0, bootstrap.dat will be much less needed
310 2015-01-07 16:18:52 <michagogo> sipa: I think maybe I was thinking "it looks directly at block files now"
311 2015-01-07 16:19:09 <sipa> it does
312 2015-01-07 16:19:17 <michagogo> I know
313 2015-01-07 16:19:42 <sipa> kaliuseruser: it's still useful for bulk transfer/storage or for external tools
314 2015-01-07 16:20:15 <Magicking_> Btw, anyone know a link where I could direct download a copy of the testnet blockchain ?
315 2015-01-07 16:20:52 <michagogo> sipa: but as I was saying, even though it lets you specify a start range (I think I added that before it was split into 2 steps, and was very surprised that it worked because I don't know Python), it actually does require you to start from 0 because it checks that the genesis block hash is in the list for some reason
316 2015-01-07 16:21:03 <sipa> oh
317 2015-01-07 16:21:21 <michagogo> No idea why that's the case, but you need to comment out that line if you want to start elsewhere
318 2015-01-07 16:21:45 <michagogo> Magicking_: I don't know if anyone publishes it, but you can get it by running a node
319 2015-01-07 16:21:54 <kaliuseruser> michagogo: so I guess I have to have the whole blockchain after all, are you sure about that ?
320 2015-01-07 16:22:00 <michagogo> kaliuseruser: no
321 2015-01-07 16:22:11 <michagogo> If you want to make a partial bootstrap, you have 2 choices
322 2015-01-07 16:22:21 <michagogo> Either you can have a local node
323 2015-01-07 16:22:27 <sipa> kaliuseruser: you still haven't said what you need it for
324 2015-01-07 16:22:34 <sipa> kaliuseruser: you want a partial bootstrap, but for what?
325 2015-01-07 16:22:35 <Magicking_> michagogo: yeah already doing that but thank anyway :(
326 2015-01-07 16:22:37 <michagogo> OR you can write a script that will connect to the network and download those blocks
327 2015-01-07 16:22:58 <michagogo> Magicking_: if you want to speed it up, try v0.10.0rc1
328 2015-01-07 16:23:25 <Magicking_> Ok, ty
329 2015-01-07 16:23:46 <michagogo> You can build yourself, or grab the bins from bitcoin.org/bin
330 2015-01-07 16:24:23 <Magicking_> I'll grab it from github, ty
331 2015-01-07 16:24:28 <kaliuseruser> what about relying on an external node with an API
332 2015-01-07 16:25:04 <michagogo> kaliuseruser: that would probably also work, I guess
333 2015-01-07 16:25:14 <michagogo> if the API doesn't mind you making many requests
334 2015-01-07 16:25:35 <michagogo> Though again, you'll probably need to write a script to get them and write them in the proper format
335 2015-01-07 16:26:10 <sipa> kaliuseruser: if you find a third party that's willing to give them to you - go ahead and use it (but here is not really the place to discuss that)
336 2015-01-07 16:26:11 <kaliuseruser> yeah the format is also another problem I guess, how do you convert the raw format (json) to .dat format
337 2015-01-07 16:26:32 <sipa> 'raw format'?
338 2015-01-07 16:26:34 <gmaxwell> kaliuseruser: You aren't going to get effective help in here if you don't describe what you're doing. We're not google, we're people-- subject matter experts in this space, and we can only give effective advice if we actually understand what you're looking to do.
339 2015-01-07 16:29:28 <bedeho> I bravely resubmit my question: How does the paying side of a payment channel, e.g. in a p2p market, avoid being fooled into repeatedly opening payment channels and thus loosing a transaction fee?
340 2015-01-07 16:32:03 <gmaxwell> bedeho: sounds like your question is specific to a particular usage, and not something that can be answered generically.
341 2015-01-07 16:32:12 <iwilcox> Would someone who understands CWalletTx and CMerkleTx kindly help me understand the three situations under which walletnotify gets called in https://github.com/bitcoin/bitcoin/blob/ec20fd74b89272a4f53337ccdf7683a7f52bab11/src/wallet.cpp#L628 ? Someone asked in #bitcoin yesterday why they were seeing not just 0 confs and 1 conf but low-tens-of-confs in callbacks too.
342 2015-01-07 16:32:30 <gmaxwell> bedeho: There is nothing about payment channels themselves that prevents that.
343 2015-01-07 16:33:22 <iwilcox> Whoops, sorry about the long link.
344 2015-01-07 16:39:32 <bedeho> gmaxwell: so to be spesific, something like storj, or these other decentralized drop box type initiatives, planning to use this channels to pay for disk space will be open to this attack then?
345 2015-01-07 16:39:32 <helo> is bitcoind supposed to exit when disk is out of space, or is that only -qt?
346 2015-01-07 16:40:00 <sipa> helo: bitcoind will quit as well
347 2015-01-07 16:40:05 <gmaxwell> bedeho: that sounds like a not-great idea.
348 2015-01-07 16:40:35 <bedeho> doing the attack, or using the payment channel?
349 2015-01-07 16:41:01 <helo> with bitcoind i just got "ERROR: Write : Serialize or I/O error - CAutoFile::write : write failed" when out of disk, and it didn't exit
350 2015-01-07 16:41:17 <sipa> hmm
351 2015-01-07 16:41:18 <helo> at a89b8371d6243242c2
352 2015-01-07 16:41:35 <sipa> ah, that's an I/O error, not a disk space check failure
353 2015-01-07 16:41:51 <helo> right
354 2015-01-07 16:42:16 <helo> i suppose it had already reserved the space for the blocks?
355 2015-01-07 16:42:39 <helo> there are a few UpdateTips that succeeded during that same timeframe
356 2015-01-07 16:52:26 <wumpus> it does a periodical disk space check, so it would have quit as part of that
357 2015-01-07 16:52:37 <wumpus> though of course in principle it shouldn't continue after such an error
358 2015-01-07 16:53:10 <gmaxwell> Hm. if it had already reserved space it shouldn't be able to fail, no?
359 2015-01-07 16:53:16 <sipa> indeed
360 2015-01-07 16:53:34 <gmaxwell> maybe that was while it was reserving space?
361 2015-01-07 16:53:44 <sipa> though the amount checked for when doing database writes (not block writes) is pretty ad-hoc
362 2015-01-07 16:54:35 <wumpus> or the OS is being 'intelligent'' and not really allocating the pages
363 2015-01-07 16:56:02 <gmaxwell> Hm. I didn't think our prealloc resulted in sparse files.
364 2015-01-07 16:56:10 <sipa> it shouldn't
365 2015-01-07 16:56:15 <gmaxwell> If it does that would defeat some of the anti-fragmentation benefits.
366 2015-01-07 16:56:28 <sipa> the OS would already need to go do a comparison check to see that we're only writes zeroes to pages
367 2015-01-07 16:56:31 <sipa> *sectors
368 2015-01-07 16:57:28 <gmaxwell> In my day you had to seek to create them, who knows what these wipppersnapper OSes do these days.
369 2015-01-07 17:12:53 <hearn> bedeho: what do you mean "tricked into repeatedly opening a channel"
370 2015-01-07 17:13:02 <hearn> (i mean, precisely. i can guess)
371 2015-01-07 17:14:16 <paveljanik> ACTION hides...
372 2015-01-07 17:14:49 <bedeho> hearn: well consider storj for example, so you ask for pieces of some file, then the attack can claim to have said pieces, and quotes a very good price per piece, only to leave you high and dry when channel has been created. This can be repeated time and time again, by just having a fresh IP (Tor?), and quoting a good price each time.
373 2015-01-07 17:15:16 <hearn> does storj even use micropayments? i thought it was some web based thing
374 2015-01-07 17:15:22 <bedeho> hehe
375 2015-01-07 17:15:46 <hearn> the idea is the server proves that it has the data you want
376 2015-01-07 17:15:51 <bedeho> under the hood, they do, thats how they pay folks to transfer data, but this applies to lots of projects, like coinffeine etc.
377 2015-01-07 17:16:04 <hearn> yes, if you're dealing with a randomly chosen peer then they can stiff you to the level of one micropayment.
378 2015-01-07 17:16:15 <hearn> i don't think coinffeine uses payment channels either :)
379 2015-01-07 17:16:21 <bedeho> they do
380 2015-01-07 17:16:42 <hearn> the point of micropayments is, if this happens, you didn't lose much money and your app can just stop and say "Error -4" or something equally helpful
381 2015-01-07 17:16:50 <bedeho> a variation which has the same basic issue as far as I can see, and most/all applications of such channels would seem to suffer from this
382 2015-01-07 17:17:06 <hearn> the issue is not with payment channels. the issue is when your counterparty doesn't provide the service you paid them for
383 2015-01-07 17:17:13 <hearn> it can happen for any kind of payment
384 2015-01-07 17:18:09 <bedeho> the problem is that setting up a channel has a cost, and you can be tricked into paying this cost forever. I am not talking about being tricked to provide service without payment, I am talking about paying the contract transaction fee.
385 2015-01-07 17:18:15 <hearn> using micropayments means the amount you lose is reduced, but obviously if you have a stupid program that uses an algorithm like "pick a random computer, send it some money, see what happens" then yes you are vulnerable to being sybilled
386 2015-01-07 17:19:24 <bedeho> I am not explaining this very well
387 2015-01-07 17:19:26 <hearn> tx fees are not very large and the entity you're setting up the tx with doesn't get them, right? you broadcast the tx to the public network. any miner could claim them. i don't think that seems like a major risk next to simple non-delivery
388 2015-01-07 17:20:33 <bedeho> for a market it is a huge problem, because different providers compete on price, so a malicious attacker can always ensure to get picked by quoting the best price, and then you loose the tx fee, and of course loose time waiting
389 2015-01-07 17:20:50 <bedeho> the point is not that it is profitable for the attacker, the point is that it is a costless debilitating attack
390 2015-01-07 17:20:56 <sipa> so the problem is your application can be tricked into wasting money on fees
391 2015-01-07 17:21:00 <bedeho> yes
392 2015-01-07 17:21:09 <bedeho> not that it can, it will
393 2015-01-07 17:21:11 <sipa> that's a problem - but it's not specific to payment channels
394 2015-01-07 17:21:21 <teward> #bitcoin pointed me here, i'm setting up a private test network via the regtest network. Everything's got static IPs so there's no router on this, it's just a private network of two computers - the master computer has blocks on it, and is listening on 59000. the slave computer has no blocks, correctly connects to the master, but doesn't grab the 115 blocks on the master node. I'm not sure how to get the thing to sync, any ideas?
395 2015-01-07 17:22:06 <sipa> both running bitcoin core?
396 2015-01-07 17:22:13 <bedeho> sipa: I am not trying to criticize payment channels, I am trying to understand if they are indeed even usable in the manner most people think they may be, and multiple projects presently attempt to
397 2015-01-07 17:22:38 <Luke-Jr> wumpus: Travis is finally happy with 5542
398 2015-01-07 17:22:49 <sipa> bedeho: i'm sure there are many use cases for which they are useful; doesn't mean they'll solve every problem
399 2015-01-07 17:23:02 <hearn> bedeho: that's a DoS attack, right?
400 2015-01-07 17:23:03 <sipa> an application that can be tricked into spending money sounds dangerous, no matter what :)
401 2015-01-07 17:23:18 <hearn> bedeho: there are simple solutions to many such problems - ID verify your partners and ban people who misbehave
402 2015-01-07 17:23:27 <bedeho> hearn: a payment channel will always be used in a context where price is relevant, so so long as there are multiple suppliers of the good in question, a malicious would-be-supplier can force users to keep wasting fees forever
403 2015-01-07 17:23:30 <hearn> bedeho: of course often in the crypto world people don't like such solutions :)
404 2015-01-07 17:23:34 <bedeho> :D
405 2015-01-07 17:24:17 <hearn> bedeho: but this is an attack that doesn't seem to have much purpose, beyond annoying people? and it can be easily detected by client software
406 2015-01-07 17:24:29 <hearn> bedeho: there are lots of DoS attacks on the bitcoin network that boil down to "waste people's resources pointlessly" already
407 2015-01-07 17:24:59 <hearn> teward: it should sync! the slave node is running in regtest mode, right?
408 2015-01-07 17:25:04 <bedeho> fair enouhg, but waist peoples bitcoin seems like a serious problem :(
409 2015-01-07 17:25:08 <gmaxwell> teward: versions of relevant software?
410 2015-01-07 17:25:27 <sipa> bedeho: yes, it looks like a serious problem; but i'd say that that's a problem with the application
411 2015-01-07 17:25:52 <hearn> bedeho: bear in mind, txns with a fee of ~0.5 cents work pretty well on the current network. it's hardly going to bankrupt anyone. like i said - non delivery risk seems a bigger problem because then the attacker gets to keep the micropayment.
412 2015-01-07 17:26:33 <hearn> bedeho: and there isn't much you can do about that except accepting that occasionally you might lose some money, and blacklisting entities that steal your money so others don't trade with them.
413 2015-01-07 17:26:47 <bedeho> sipa: but do you agree that this then severly limits the use cases for such channels, can you imagine lots of uses where this is not the case?
414 2015-01-07 17:26:53 <hearn> bedeho: this is ignoring wizardly tech like TC
415 2015-01-07 17:27:05 <bedeho> TC?
416 2015-01-07 17:27:23 <sipa> trusted computing, i'd guess
417 2015-01-07 17:27:47 <hearn> yeah
418 2015-01-07 17:27:48 <sipa> bedeho: maybe
419 2015-01-07 17:28:14 <sipa> bedeho: anything with identities (like specific service providers you connect to) doesn't have this problem
420 2015-01-07 17:28:34 <sipa> and i'm sure payment channels are useful there - probably more than in fully peer-to-peer settings
421 2015-01-07 17:28:38 <hearn> well, it can have this problem, but they only get to scam you once :)
422 2015-01-07 17:28:42 <bedeho> but then why use a channel like this?
423 2015-01-07 17:28:54 <teward> gmaxwell: hearn: 0.9.3, which is latest stable - but i figured it out
424 2015-01-07 17:29:10 <teward> gmaxwell: hearn: i forgot that this system was installed *without* internet access, so the internet time servers weren't there
425 2015-01-07 17:29:40 <hearn> bedeho: service providers can fail to provide service without being a DoS attacker. consider the case of a wifi hotspot that's selling access per kilobyte of transfer.
426 2015-01-07 17:29:40 <teward> gmaxwell: hearn: had 07:00 today instead of 12:27 today, so blocks:REJECTED due to time delta between actual and system clock
427 2015-01-07 17:29:45 <teward> working now
428 2015-01-07 17:29:48 <teward> ACTION feels stupid
429 2015-01-07 17:29:55 <teward> gmaxwell: hearn: i shoulda checked the debug log first xD
430 2015-01-07 17:29:57 <hearn> bedeho: now the user walks out of range, or the hotspot loses power, or its internet connection dies through no fault of its own.
431 2015-01-07 17:30:05 <hearn> teward: right, debug logs always useful :)
432 2015-01-07 17:30:35 <gmaxwell> teward: we should probably promote that error to be visbile in some of the info rpcs.
433 2015-01-07 17:30:39 <hearn> bedeho: if you're using micropayments, you minimise your exposure to this sort of thing. i think you're being rather absolutist if you feel like a single relatively detectable DoS attack makes something useful
434 2015-01-07 17:30:52 <hearn> bedeho: it's sort of like saying the web is useless because a malicious web server can put you into a redirect loop
435 2015-01-07 17:31:25 <teward> gmaxwell: right, that wouldn't hurt, for some point in the latest dev branch, maybe the next version after
436 2015-01-07 17:31:35 <teward> gmaxwell: 'course, from -qt it'd never be seen :)
437 2015-01-07 17:31:46 <teward> (and the REJECT is never echoed back through the net, hence why wireshark on the master didn't see it)
438 2015-01-07 17:31:50 <teward> anyways, sorry to bug you all
439 2015-01-07 17:31:52 <hearn> er, *useless rather
440 2015-01-07 17:33:52 <bedeho> hearn: what about the following fix, you do not negotiate price up front with any supplier, but rather get N (large) suppliers to join the channel, channel is confirmed, you do price competition inside the channel only. This way attacker has no way of consistently getting picked alone and wasting your fee. ?
441 2015-01-07 17:34:22 <bedeho> I know tx fee scales with size, but it is very modest, right?
442 2015-01-07 17:35:06 <sipa> define 'modest' ?
443 2015-01-07 17:35:18 <sipa> i expect that over time they will tend to be pretty much linear in their size
444 2015-01-07 17:35:57 <bedeho> oh, I thought there was like a super large fixed cost, and then a little bit per kb or something
445 2015-01-07 17:36:26 <sipa> there is a minimum for the transaction to be relayed across the network
446 2015-01-07 17:36:38 <hearn> bedeho: i thought your attack assumed the attacker could assume unlimited identities?
447 2015-01-07 17:37:17 <hearn> bedeho: btw bitcoinj payment channels don't let you open a channel with no payments on it. you must always send at least enough money to make it worth closing the channel, and can choose to send more. so then it becomes a standard non-delivery of service issue.
448 2015-01-07 17:37:30 <BlueMatt> jrick: how often?
449 2015-01-07 17:37:38 <bedeho> hearn: yes, attacker can always get fresh IP costless, but is still a small part of total swarm, so there will be lots of honest suppliers by random uniform sampling?
450 2015-01-07 17:37:47 <hearn> bedeho: simple rule of thumb - in a network without identities, or any way to blacklist identities, *any* form of misbehaviour you can't defend against automatically becomes a problem
451 2015-01-07 17:38:00 <gmaxwell> teward: IIRC qt tells you explicitly.
452 2015-01-07 17:38:00 <hearn> bedeho: that's a very strong constraint. in practice most systems get most of the way and then fudge the rest.
453 2015-01-07 17:38:33 <hearn> bedeho: if that's your threat model then who cares? if you connect to a node that is broken/DoSing you, just reconnect to another one that's probably honest and carry on.
454 2015-01-07 17:38:37 <jrick> BlueMatt: right now it's reconnecting about every 15 seconds
455 2015-01-07 17:38:43 <jrick> before it was faster, perhaps there's a backoff
456 2015-01-07 17:39:02 <jrick> it was like 2-3 seconds earlier
457 2015-01-07 17:39:04 <BlueMatt> ummmmm....ok, I think this is the result of updating the bitcoinj library and getting new shit with it
458 2015-01-07 17:39:08 <BlueMatt> thats still crazy
459 2015-01-07 17:39:14 <BlueMatt> should be like 10 minutes or something
460 2015-01-07 17:39:18 <bedeho> hearn: yes, but I dont know if you are an attacker before you neglect to pay up after the channel has been confirmed, AFTER I have already lost the tx fee
461 2015-01-07 17:39:21 <BlueMatt> can you pm me which ip it is?
462 2015-01-07 17:39:26 <jrick> sure
463 2015-01-07 17:39:30 <bedeho> sorry, not pay up, but supply service
464 2015-01-07 17:40:13 <hearn> bedeho: yes, so? you already said that this behaviour is rare, in your threat model, so you can just say ok, damn, lost the tx fee, but as long as losses due to bizarre motiveless DoS fraud < cost(identities+blacklisting), you're still winning
465 2015-01-07 17:44:20 <bedeho> hearn: my suggestion was just to find a way try to create ONE channel which was very likely to have some honest suppliers in it, and hence not waste fee. I see no other way of avoiding reliable inclusion in a channel with a fraudster. If suppliers compete on price before being included in the channel, then a fraudster can give articifially good terms to take up ALL spots in your channel, and then screw you, every
466 2015-01-07 17:44:20 <bedeho> time. That was my point. I dont know if that makes sense, but it seems either way that this is indeed an issue, which was my main question, albeit not a very serious one from your perspective.
467 2015-01-07 17:45:05 <bedeho> thank you for taking the time to respond anyway!
468 2015-01-07 17:45:13 <hearn> i think your solution would work, but it's a solution to a rather unlikely problem
469 2015-01-07 17:45:41 <hearn> and, unless you have TC or some other way to know the behaviour of your trading partner in advance, you will always have the non-delivery-of-service issue, which means you need a way to identify and kick out abusers from the marketplace anyway
470 2015-01-07 17:46:04 <hearn> and seeing as you need that solution, you can use it to solve the behaviour you are concerned about as well
471 2015-01-07 17:46:33 <hearn> but hey, if you're making an app that uses payment channels and are worried about the 0.3 cent fee or whatever it is now, go right ahead and implement that :)
472 2015-01-07 17:49:17 <bedeho> hearn: well thanks for your optimism, I will file it as a non-problem for the time being then.
473 2015-01-07 17:49:45 <hearn> if you're really building some kind of fully p2p decentralised marketplace, i think you will have plenty of issues on your plate to deal with first :)
474 2015-01-07 17:59:29 <bedeho> I am, but this is indeed the most serious problem, believe it or not :D
475 2015-01-07 18:01:58 <xabbix__> What stops attackers from choking up the network by compiling and running thousands of modified nodes that are set to connect to thousands of full nodes as described here: http://bitcoin.stackexchange.com/a/12932/2976
476 2015-01-07 18:02:55 <xabbix__> in theory I just need to start 125 nodes with this modified bitcoin-core to do some damage, right?
477 2015-01-07 18:03:19 <gmaxwell> xabbix__: there is no real motivation to do so, it won't interrupt existing connections; it won't interrupt private or whitelisted interconnections, it won't interupt alternative transport protocols (p2pool and bluematt's relay network).
478 2015-01-07 18:04:04 <gmaxwell> xabbix__: I've been working on a daemon that people can run which will automatically detect and ban massve multiconnectors, though I don't consider it super urgent.
479 2015-01-07 18:05:14 <xabbix__> Well I agree it won't interrupt existing connections, but if I run enough nodes eventually almost all existing connections will disconnect and won't be able to reconnect.. Whitelisted/private connections are pretty rare I assume so you'll be left with only a few functioning full nodes.. not sure about p2pool and bluematt's relay network since I don't really understand how it works.
480 2015-01-07 18:06:20 <gmaxwell> xabbix__: 'rare' ... when talking about security its usually not helpful to talk about things like random chance.
481 2015-01-07 18:07:00 <gmaxwell> They are be rare in terms of total edges in the network graph, but they're likely quite common between nodes that are most sensitive (major merchants and miners, for example)
482 2015-01-07 18:07:51 <xabbix__> ok, thanks.
483 2015-01-07 18:11:39 <hearn> xabbix__: yeah it's a working DoS attack at least against SPV wallets that don't connect for very long e.g. mobile
484 2015-01-07 18:13:03 <xabbix__> Looks like a pretty cheap attack as well, 200 VPS servers will cost ~$2000
485 2015-01-07 18:13:52 <hearn> you don't need lots of servers.
486 2015-01-07 18:15:00 <hearn> it's something we've discussed for a long time. solving it is hard and requires a whole lotta upgrades to both implementations and the protocol.
487 2015-01-07 18:15:33 <xabbix__> default incoming connection limit is 125, so if I change MAX_OUTBOUND_CONNECTIONS to be 10000 for example, I'll need in theory 125 servers to occupy all nodes (I'm ignoring the fact that running nodes already have some other nodes connected to them)
488 2015-01-07 19:03:57 <ajweiss> i imagine such a large scale attack would attract a lot of attention very quickly
489 2015-01-07 19:04:37 <gmaxwell> ajweiss: people have tried things like it before with it basically not even being noticed.
490 2015-01-07 19:05:03 <phantomcircuit> it should be noted that there are a handful of modified nodes on the network which can support substantially more than 125 connections
491 2015-01-07 19:05:19 <ajweiss> massive multiconnecting, or malicious massive multiconnecting?
492 2015-01-07 19:06:02 <gmaxwell> ajweiss: hard to distinguish! seemingly the latter.
493 2015-01-07 19:06:24 <ajweiss> interesting, must not have been very effective
494 2015-01-07 19:08:17 <phantomcircuit> hard to say
495 2015-01-07 19:14:09 <ajweiss> i wonder how many merchants, miners, exchanges, companies and individuals with a lot of money tied up do their own monitoring of the health of the p2p network...
496 2015-01-07 19:24:45 <michagogo> xabbix__: I think I tried playing with it once, and found that it wouldn't make more then 800-900 connections
497 2015-01-07 19:24:54 <michagogo> Something about file descriptors or something
498 2015-01-07 19:25:09 <ajweiss> select maxes out at 1024
499 2015-01-07 20:30:32 <ajweiss> so it looks to me like if block download timeouts need a backoff, the same would need to happen to ping timeouts
500 2015-01-07 20:30:54 <ajweiss> since ping replies get backed up behind blocks and there's a hard timeout at 20m
501 2015-01-07 20:36:22 <gmaxwell> ajweiss: ideally it would be better if we were distinguishing block in flight (e.g. tarpit) vs sending nothing.
502 2015-01-07 20:36:38 <sipa> ?
503 2015-01-07 20:39:06 <Luke-Jr> gmaxwell: we want to ban/disconnect on tarpit too..?
504 2015-01-07 20:39:46 <sipa> what is tarbit?
505 2015-01-07 20:39:54 <gmaxwell> Luke-Jr: after some limit, but if its not even sending anything we can be more agressive.
506 2015-01-07 20:40:17 <gmaxwell> sipa: e.g. a tarpit is a peer that is sending block data but very slowly; as opposed to not sending anything at all.
507 2015-01-07 20:41:06 <Luke-Jr> sipa: in the TCP sense, a tarpit is a peer that refuses to let you close/reset an established connection
508 2015-01-07 20:42:01 <ajweiss> i don't see the benefit, a hopeless transfer is a hopeless transfer, no?
509 2015-01-07 20:42:15 <gmaxwell> ajweiss: the benefit of what?
510 2015-01-07 20:42:34 <ajweiss> if we're gettin 'em slower than they're makin 'em, it just isn't gonna work out regardless
511 2015-01-07 20:42:49 <ajweiss> distinguishing tarpit v. nothing
512 2015-01-07 20:42:57 <gmaxwell> ajweiss: thats not true. ::sigh:: as I said the other day, a _single_ block taking longer than average is fine.
513 2015-01-07 20:43:27 <gmaxwell> And it's preferable to give up early if we can safely do so, which is why distinguishing makes sense.
514 2015-01-07 20:44:01 <ajweiss> i briefly considered something like that, but that looked like monkeying around in the network stack too much
515 2015-01-07 20:44:06 <teward> gmaxwell: you mean bitcoin-qt? If that's the case it never said that anywhere
516 2015-01-07 20:44:17 <teward> gmaxwell: responding to the time delta issue i had earlier
517 2015-01-07 20:44:20 <teward> (it never said that)
518 2015-01-07 20:44:55 <ajweiss> ideally we'd see it's an incoming block and track the incoming data rate as it comes, but i'm not sure if it'd be worth retrofitting the network stuff
519 2015-01-07 20:45:02 <gmaxwell> ajweiss: if you were hyper agressive at killing connections right at the limit of the average time, its possible for a network with adequate capacity to simply stop working all on its own when chance synchronization causes delays and a storm of repeated transmissions that aren't successful. (though it's unlikely unless things really are right at the limit)
520 2015-01-07 20:45:26 <gmaxwell> ajweiss: yea probably not worth doing that right now. Though we could tell by virtue of responses to pings.
521 2015-01-07 20:45:36 <ajweiss> yeah but i'm not arguing for average, we have a hard max, no?
522 2015-01-07 20:45:52 <ajweiss> i suppose that will go away in future, but for now...
523 2015-01-07 20:46:20 <gmaxwell> ajweiss: A maximum will not go away while I'm still involved with Bitcoin.
524 2015-01-07 20:46:59 <gmaxwell> That isn't the point I'm making. Just assume for a minute that all blocks are the same size, and that the network has just enough capacity to handle that.
525 2015-01-07 20:47:24 <gmaxwell> ajweiss: if there is just a blurp in one part of the network where the capacity goes too low, then the whole thing can collapse.
526 2015-01-07 20:47:46 <gmaxwell> Their a theoretical weakness but one that ought to be mitigated.
527 2015-01-07 20:48:22 <ajweiss> sure
528 2015-01-07 20:48:45 <gmaxwell> s/Their/It's/
529 2015-01-07 20:48:57 <ajweiss> that mitigation will also involve adjusting the ping stuff too
530 2015-01-07 20:49:15 <gmaxwell> Indeed. It's a really good spot there.
531 2015-01-07 20:49:59 <ajweiss> incidentally, under severe bandwidth constraints i also saw where it would get into connect -> timeout no messages in 60s disconnect loops
532 2015-01-07 20:51:21 <gmaxwell> yes, I'm not actually too concerned about that in that once you're up you're up. Many tcp stacks fail after 2 minutes in connect in any case.
533 2015-01-07 20:52:02 <ajweiss> yeah and my tests used trickle, which will act differently there anyway
534 2015-01-07 20:54:44 <gmaxwell> ajweiss: so it's funny, there was previously a PR that decreased the ping timeout to 1 minute. I was pretty unhappy about that, but didn't think of the head of line blocking on block transmission... Wumpus argued for 20 minutes. I was happy with 5. I guess we dodged a bullet on that. :-/
535 2015-01-07 20:55:01 <ajweiss> hahaha yeah
536 2015-01-07 20:55:05 <ajweiss> i wasn't expecting it