1 2013-07-03 00:01:36 <BW^-> hm, so MAX_OUTBOUND_CONNECTIONS is 8 by default, and the Keep-Alive message interval is hardcoded to 30 minutes (main.cpp:3946)
 2 2013-07-03 00:02:07 <BW^-> there are several usecases that would benefit from those being configurable.
 3 2013-07-03 00:02:14 <BW^-> to higher values.
 4 2013-07-03 00:02:21 <BW^-> em, the first one higher, the other one lower.
 5 2013-07-03 00:02:47 <gmaxwell> No, increasing outbound connections would not be beneficial.
 6 2013-07-03 00:03:52 <BW^-> gmaxwell: why not? what if you're in an unreliable network environment and all 8 of them go down without you knowing it - in this case it might take 30 minutes before you realize!
 7 2013-07-03 00:03:56 <BW^-> main.cpp:3961: // Except during reindex, importing and IBD, when old wallet
 8 2013-07-03 00:03:58 <BW^-> what's IBD?
 9 2013-07-03 00:04:11 <gmaxwell> and the keepalive interval will be 30 seconds, though it's mostly pointless because normal traffic is more often than that.
10 2013-07-03 00:04:57 <BW^-> gmaxwell: is it 30 seconds?
11 2013-07-03 00:05:04 <BW^-> main.cpp:3946: if (pto->nLastSend && GetTime() - pto->nLastSend > 30 * 60 && pto->vSendMsg.empty()) {
12 2013-07-03 00:05:15 <gmaxwell> BW^-: _will be_
13 2013-07-03 00:05:18 <BW^-> ah
14 2013-07-03 00:05:22 <BW^-> gmaxwell: a pending commit?
15 2013-07-03 00:05:26 <gmaxwell> BW^-: but your mental model for how it works is incorrect.
16 2013-07-03 00:05:45 <gmaxwell> BW^-: TCP will notice that the connection went down in two minutes and tear it down.
17 2013-07-03 00:06:03 <BW^-> gmaxwell: only if the socket has FD_KEEPALIVE or alike set?
18 2013-07-03 00:06:19 <BW^-> gmaxwell: TCP was specifically designed for connections to survive *long* network downtimes
19 2013-07-03 00:06:28 <gmaxwell> And this works reliably, I interupt the network on my host 2-6 times per day and its always connected within a couple of minutes of being back online.
20 2013-07-03 00:08:23 <BW^-> aha nice anyhow that it's going down to a lower value (30sec) in a future version
21 2013-07-03 00:08:23 <BW^-> gmaxwell: if it's a sensitive application, connecting to more than 8 peers would decrease the possibility of connecting to a broken peer further also, wouldn't it?
22 2013-07-03 00:09:10 <BW^-> i mean, if you're in a situation where you absolutely need it to work, then you would want to counteract a scenario of being connected to broken peers only..
23 2013-07-03 00:09:22 <BW^-> that's a bit theoretical of course also..
24 2013-07-03 00:09:40 <gmaxwell> BW^-: Go do the math. say you have a 1% chance of a broken peer. 1%^8 is 1e-16.
25 2013-07-03 00:09:41 <BW^-> though for instance, over Tor connections can freeze-die
26 2013-07-03 00:10:43 <gmaxwell> On the flip side??? more than a handfull of hosts turning that up "for good measure" could utterly run the network out of listening sockets. If you want more connections: listen.
27 2013-07-03 00:11:38 <gmaxwell> we've run very close to running out of sockets a couple times in the past, tor nodes in particular get a ton of inbounds. And with multibit soon to be promoted over bitcoin-qt for desktop systems its likely to get a lot worse.
28 2013-07-03 00:11:40 <BW^-> gmaxwell: hm. good points both.     re listening more - that welcomes simple bitcoin clients that want to listen only and don't broadcast anything though, so would increase possibility of peers broken for your purpose?
29 2013-07-03 00:12:12 <BW^-> hmhm interesting
30 2013-07-03 00:12:20 <gmaxwell> BW^-: exponentiation is a marvelous thing.
31 2013-07-03 00:14:52 <phantomcircuit> there really needs to be a pretty significant change in the network structure to make that less of a problem
32 2013-07-03 00:15:15 <phantomcircuit> actually i think the default max could be increased significantly now
33 2013-07-03 00:15:20 <phantomcircuit> recent network changes
34 2013-07-03 00:15:28 <phantomcircuit> networking code changes*
35 2013-07-03 00:15:38 <BW^-> in the current version, there is no logic that ensure that bitcoind always has some number of outbound connections, is it?
36 2013-07-03 00:16:03 <BW^-> i mean, i see logics that check the number of inbound + outbound ones available and opening outbound ones if it's too low, and declining inbound ones if it's too high
37 2013-07-03 00:16:11 <phantomcircuit> BW^-, yeah there is it tries to maintain 8 outbound connections
38 2013-07-03 00:16:20 <gmaxwell> BW^-: no, it maintains 8 outbound connections.
39 2013-07-03 00:16:59 <gmaxwell> Your peers choose to connect to you, allowing someone to isolate you would be a significant security problem.
40 2013-07-03 00:18:50 <BW^-> gmaxwell,: yeah
41 2013-07-03 00:18:59 <BW^-> gmaxwell,phantomcircuit: where in the code is the logic for that? just curious
42 2013-07-03 00:19:08 <BW^-> searching for MAX_OUTBOUND_CONNECTIONS in net.cpp shows to places that don't look related to this to me
43 2013-07-03 00:19:43 <phantomcircuit> ThreadOpenConnections
44 2013-07-03 00:19:46 <phantomcircuit> or something liek that
45 2013-07-03 00:21:46 <BW^-> phantomcircuit: ah
46 2013-07-03 00:41:20 <BW^-> how do SPV nodes respond to blockchain download requests (ie 'getblocks', 'getheaders', 'getdata')?
47 2013-07-03 00:42:16 <BW^-> even if pointless in the bigger picture, there could be some use in having logics for a "pre-confirmation", consisting of that you get gossipped back to you a transaction you commited to the network?
48 2013-07-03 00:42:36 <BW^-> i mean, that does show that there are at least a number of other peers that do agree that your transaction is valid
49 2013-07-03 00:43:40 <phantomcircuit> BW^-, they dont
50 2013-07-03 00:43:42 <BW^-> which is a quite strong hint that your transaction is valid - compared with just blindly shooting away a transaction and presuming it's valid, that is a quite strong indicator of probability of validity - even though of course 1-2 real confirmations is the only hard value
51 2013-07-03 00:44:04 <BW^-> phantomcircuit: you could find some peers to connect to and send to them, that are other peers than those your bitcoind are connected to
52 2013-07-03 00:44:04 <phantomcircuit> there's a bitfield in the version message that's used to show capabilities
53 2013-07-03 00:44:20 <BW^-> phantomcircuit: aha. what about?
54 2013-07-03 00:44:32 <phantomcircuit> you dont ask an spv node for getblocks because they dont set the network node flag
55 2013-07-03 00:44:45 <BW^-> aha
56 2013-07-03 00:45:25 <BW^-> phantomcircuit: ah right, "1  NODE_NETWORK  This node can be asked for full blocks instead of just headers"
57 2013-07-03 00:45:51 <BW^-> phantomcircuit: ah right, and if a SPV node gets a 'getheaders' then it should indeed be able to respond as well as any node :)
58 2013-07-03 00:46:34 <phantomcircuit> BW^-, right but if they get a getblock request they can just ignore it
59 2013-07-03 00:46:55 <BW^-> exactly - right noted.
60 2013-07-03 00:54:15 <jgarzik> evenin'
61 2013-07-03 00:55:06 <jgarzik> change? change?   can anybody spare someone testnet3 coins?  mmyipXKsbZVyRBzKa3uKmw3WWU1jkaoM92
62 2013-07-03 01:35:05 <jgarzik> thanks
63 2013-07-03 01:35:12 <jgarzik> have testnet coins
64 2013-07-03 02:10:52 <imd23> hi
65 2013-07-03 02:11:16 <imd23> I need help in multi sig transactions
66 2013-07-03 02:11:34 <imd23> The problem is I am building a kind of a escrow system
67 2013-07-03 02:11:43 <imd23> and this multi sign transaction would be awesome
68 2013-07-03 02:12:53 <phantomcircuit> imd23, your clients will probably need to be able to use multisig transactions also
69 2013-07-03 02:12:58 <phantomcircuit> which mostly they wont be able to do
70 2013-07-03 02:14:01 <imd23> but because the seller (of btc's) doesn't know the other party who is selling (the buyer of btcs) after we match them, and we want to do the transaction automatically, i can't think of a way without asking/emailing the seller to do the transaction because he need to do it to 2 address (our /the escrow/ and the buyer of btcs)
71 2013-07-03 02:14:48 <imd23> is there a way to overcome this? because we want the highest  security for everyone, and if there is a way we don't "own" the bit coins, better.
72 2013-07-03 02:15:56 <imd23> we are building the system, which will be an online system, so.
73 2013-07-03 02:20:26 <BW^-> phantomcircuit: what about?
74 2013-07-03 02:21:23 <phantomcircuit> imd23, that completely ignores the fundamental issue with escrow, dispute resolution
75 2013-07-03 02:23:02 <phantomcircuit> the escrow agent *must* be able to make that decision
76 2013-07-03 03:28:36 <imd23> phantomcircuit
77 2013-07-03 03:28:44 <imd23> i want dispute resolution
78 2013-07-03 03:30:16 <imd23> but I want 2 things, that I don't know if they are possible: #1 us, the mediator, be able to decide to which place to go (back to the seller of the btcs or the buyer) and #2 we only can decide, but not get the coin it self.
79 2013-07-03 03:32:30 <walch> imd23: where would the funds go if the mediator could't get enough information to decide either way?
80 2013-07-03 03:35:32 <imd23> walch: obviously i am missing something, but i don't know why. Could you elaborate what you mean by "can't get enough info"?
81 2013-07-03 03:35:43 <imd23> *i don't know what
82 2013-07-03 03:37:10 <walch> imd23: I assume that if both the seller and buyer both claim that the other is in the wrong, then it's up to the mediator to decide who is telling the truth. in some cases though, it would be very hard to tell either way
83 2013-07-03 03:37:28 <walch> I'm more curious how the escrow works than anything, as i've never had to use it before.
84 2013-07-03 03:39:59 <imd23> walch: yeah, it's that way.
85 2013-07-03 03:41:09 <imd23> walch: what I want / may not be possible, or may it be the default behavior of multi_sign in btw / is that we, the mediator, to only have the power of deciding where the btcs go in case of a problem, but NO having the option of spending them.
86 2013-07-03 03:42:19 <imd23> This will give more trust to the people who use the service, and if a potential hacker attack our servers, they can not spend the coins, but just decide... (i am thinking in worse scenario)
87 2013-07-03 03:42:30 <imd23> *worst case scenario
88 2013-07-03 03:43:27 <imd23> of course there is a lot more security we will develop in our service, encrypt everything in the db's etc.. but I need to know if this little case is possible, so I can consider it or throw it away.
89 2013-07-03 03:45:22 <walch> imd23: the only place I can find that deals with them is blockchain.info, and I'm not really sure how it works. their description is incredibly vague.
90 2013-07-03 03:45:41 <walch> their US$5 fee is a little on the heavy side too.
91 2013-07-03 03:46:02 <walch> I suppose you're pioneering with this one.
92 2013-07-03 03:47:10 <imd23> awesome :)
93 2013-07-03 04:42:04 <melvster> anyone know what's the favourite alt coin hashing algo these days?  sha256 / scrypt / other?
94 2013-07-03 04:43:38 <Luke-Jr> like legit altcoins or scamcoins?
95 2013-07-03 04:45:14 <walch> are there any altcoins that are anything but litecoin and bitcoin forks?
96 2013-07-03 04:45:31 <Luke-Jr> walch: you're implying litecoin has any originality
97 2013-07-03 04:45:52 <Luke-Jr> afaik ripple and microcash are the only non-bitcoin forks