1 2014-03-04 00:07:16 <jaychristopher> Whats the easiest way to delete a 0 conf transaction from bitcoind wallet?
2 2014-03-04 00:08:00 <gmaxwell> jaychristopher: wait until the next release and zapwallet.
3 2014-03-04 00:08:05 <sipa> with 0.9, start with -zapwallettxes
4 2014-03-04 00:08:23 <jaychristopher> thats a command?
5 2014-03-04 00:08:29 <sipa> a command line flag
6 2014-03-04 00:08:47 <gmaxwell> makes it purge out all the transactions and relearn them from the blockchain.
7 2014-03-04 00:08:56 <jaychristopher> oh interesting
8 2014-03-04 00:09:07 <jaychristopher> can i run that on -qt?
9 2014-03-04 00:09:11 <jaychristopher> from command line
10 2014-03-04 00:09:22 <sipa> why not just something that removes unconfirmed transactions, btw?
11 2014-03-04 00:09:26 <sipa> no need for a rescan...
12 2014-03-04 00:09:32 <sipa> and most likely what you want
13 2014-03-04 00:09:54 <jaychristopher> agreed, id rather not rescan
14 2014-03-04 00:09:57 <sipa> (jaychristopher: not a question to you - just asking aloud why we don't have that)
15 2014-03-04 00:10:59 <gmaxwell> Sounds fantastic to me. Arguably it could be automatic.
16 2014-03-04 00:11:49 <jaychristopher> second time I've had this problem, but been 2 years since last time
17 2014-03-04 00:22:53 <jaychristopher> Btw, Thanks zipa
18 2014-03-04 00:23:09 <jaychristopher> sipa
19 2014-03-04 00:23:10 <jaychristopher> lol
20 2014-03-04 00:23:10 <jaychristopher> sorry
21 2014-03-04 00:26:13 <olalonde> mornin'
22 2014-03-04 00:31:29 <jaychristopher> Ah gmaxwell - i saw you answered too and now i see that it's not part of this version huh
23 2014-03-04 00:31:35 <jaychristopher> thats why it's not working
24 2014-03-04 00:32:25 <sipa> in 0.8.6, you can use -salvagewallet
25 2014-03-04 00:32:32 <sipa> but that's a very rough tool
26 2014-03-04 00:32:42 <sipa> it removes everything except your private keys, and rebuilds from there
27 2014-03-04 00:32:56 <sipa> so it loses address book, transactions, timestamps, ...
28 2014-03-04 00:34:07 <gmaxwell> I still have a wallet that -salvagewallet throughly corrupts.
29 2014-03-04 00:35:15 <sipa> :o
30 2014-03-04 00:36:27 <gmaxwell> my main testnet wallet.. run it through salvage wallet and it goes from like 200k BTC balance to 50 BTC, and unlock doesn't work anymore.
31 2014-03-04 00:36:41 <gmaxwell> No one else seems to have reported this, however.
32 2014-03-04 00:37:47 <edcba> haha
33 2014-03-04 00:38:30 <edcba> i have a completly borked wallet
34 2014-03-04 00:51:22 <GMP> gmaxwell: -salvagewallet have dangerous feature: new wallet have priv keys missing in original wallet. if you salvage 50 btc and send 1btc, then delete salvaged wallet, 49 btc (change) is lost forever!!!
35 2014-03-04 00:51:42 <gmaxwell> yes, it gets a new keypool.
36 2014-03-04 00:52:21 <jaychristopher> so i should send the entire balance to a safe address right away just in case? :)
37 2014-03-04 00:53:50 <GMP> or, maybe, add some warning somewhere
38 2014-03-04 00:54:33 <gmaxwell> maybe we should hide salvage ... it's really intended to be a last resort rescue option.
39 2014-03-04 00:55:22 <jaychristopher> I just backed up the wallet file and am running salvage - then will transfer full balance immediately to see what happens.
40 2014-03-04 00:55:50 <gmaxwell> make sure you don't transfer it to a key you just got from that wallet. :P
41 2014-03-04 01:01:26 <mhanne> hi olalonde! nice to see you here, i wanted to ask you about the blproof thing..
42 2014-03-04 01:01:42 <mhanne> is the server supposed to generate a new tree whenever the balance table changes, or in intervals like once a day?
43 2014-03-04 01:02:09 <gmaxwell> mhanne: you shouldn't update it constantly or you exacerbate the substition problem.
44 2014-03-04 01:02:25 <gmaxwell> My expectation was that it would get used once a day.
45 2014-03-04 01:02:29 <olalonde> mhanne: hi :) happy to help
46 2014-03-04 01:02:39 <gmaxwell> but other people may have better thoughts.
47 2014-03-04 01:02:53 <olalonde> mhanne: this is not really specified... I'm not really sure what would be best. I guess once a day would be good for now. Eventually it would be nice to have shorter intervals but we would need a way for clients to verify their root.json automatically
48 2014-03-04 01:03:24 <gmaxwell> mhanne: basically you need to make sure that the service is not giving one tree to one user, and a different tree to another user.
49 2014-03-04 01:03:32 <olalonde> right now.. root.json must be verified manually so the interval should not be too short to let users take the time to make sure the root.json is correct
50 2014-03-04 01:03:41 <mhanne> substitution problem? you mean that different people can verify they are shown the same root?
51 2014-03-04 01:04:08 <mhanne> that would be hard if it's too often i guess
52 2014-03-04 01:04:09 <olalonde> this could be probably automated by having a trusted third party server that fetches root.json for you and sends it back to you
53 2014-03-04 01:04:18 <olalonde> mhanne: yes
54 2014-03-04 01:04:25 <gmaxwell> mhanne: e.g. say the bank like thing has two customers with 100 coins each. But it's fractional and only owns 100 coins. It gives each user a different root, which shows that all 100 belong to that user.
55 2014-03-04 01:05:08 <gmaxwell> can also be addressed by commitming to the root in the blockchain. or a bunch of other ways. but the criticality of addressing it just depends on how often the updates happen.
56 2014-03-04 01:05:19 <mhanne> yea, that's one thing, they need to be compared by different people
57 2014-03-04 01:05:44 <mhanne> putting it in the blockchain could help yea
58 2014-03-04 01:06:11 <mhanne> but the other way, if you don't update often, the tree doesn't match the user's balance and you can't verify it automatically
59 2014-03-04 01:06:35 <mhanne> (without either trusting the exchange to truthfully report the changes since the root was generated, or have the user think about it)
60 2014-03-04 01:08:13 <olalonde> gmaxwell: if it is committed to the blockchain, then wouldn't users need to verify they are given the same transaction?
61 2014-03-04 01:09:06 <olalonde> one easy to do it would be to use your browser in incognito mode, preferably behind a VPN/proxy and fetch the root.json file
62 2014-03-04 01:09:19 <olalonde> for now...
63 2014-03-04 01:09:21 <gmaxwell> olalonde: to be uber fun with it you commit to it in the coins that you use in the assets side of the proof. To be more realistic, you just have some very well known coin asscoiated with the service.
64 2014-03-04 01:09:31 <olalonde> eventually that process will probably be automated by the extension
65 2014-03-04 01:09:49 <olalonde> gmaxwell: right
66 2014-03-04 01:10:41 <olalonde> mhanne: are you planning to implement the scheme on your website?
67 2014-03-04 01:12:58 <mhanne> yes, in fact i already have some code working.. that's the other thing i wanted to ask you.. i first started by just extending the code that generates bitcoin merkle trees, and make it carry along the value. i was surprised to find you build the tree in a completely different way. is there a particular reason?
68 2014-03-04 01:14:44 <olalonde> mhanne: what do you mean? there are 2 formats that the tool outputs for partial trees... one format is for debugging purposes (using --human flag) and the other one is a JSON format
69 2014-03-04 01:15:18 <olalonde> mhanne: the complete tree is in a different format because it's just meant for use internally, it is not supposed to be shared with anyone... I was lazy so I just output the internal representation (an array)
70 2014-03-04 01:16:26 <olalonde> mhanne: internally, all trees are represented as an array to simplify things a bit. but the ouput of the partial tree is in a different format because an array would be too big
71 2014-03-04 01:17:16 <olalonde> mhanne: when the tool loads a partial tree, it transforms the json representation into an array
72 2014-03-04 01:17:35 <olalonde> mhanne: not sure if I understood your question
73 2014-03-04 01:18:12 <mhanne> sorry, i'm probably misunderstanding something..
74 2014-03-04 01:18:27 <mhanne> https://gist.github.com/mhanne/9338371 this is the code i was using at first
75 2014-03-04 01:18:59 <mhanne> i didn't really understand how you do it, but your way of building the tree seems a lot more fancy
76 2014-03-04 01:19:03 <olalonde> mhanne: you're writing an alternative implementation?
77 2014-03-04 01:19:41 <mhanne> yes.. i've also ported some of your code in the meantime.. but it still didn't help me see what's going on :P
78 2014-03-04 01:19:45 <olalonde> ok, let me have a look. my Ruby is a bit rusty
79 2014-03-04 01:20:42 <mhanne> it basically just loops over all hashes two at a time, hashing them together and adding them to the end of the array
80 2014-03-04 01:21:59 <olalonde> sounds right
81 2014-03-04 01:22:05 <olalonde> actually smarter then what I did eheh
82 2014-03-04 01:22:14 <olalonde> I put the leafs at the end of the array
83 2014-03-04 01:22:52 <olalonde> I didn't know what a merkle tree was before doing this -_-
84 2014-03-04 01:23:38 <olalonde> the complete tree representation is not specified because it is just used internally to extract partial trees
85 2014-03-04 01:24:05 <olalonde> once you got your complete tree, you need a function to extract a partial tree for a given leaf
86 2014-03-04 01:24:17 <olalonde> you can just duplicate your array and remove all irrelevant nodes
87 2014-03-04 01:24:25 <mhanne> well, tbqh. i didn't come up with this myself either ;)
88 2014-03-04 01:24:43 <mhanne> but i was under the impression that that's the way merkle trees are grown in bitcoin-land
89 2014-03-04 01:25:01 <olalonde> yes, I believe it is
90 2014-03-04 01:25:27 <olalonde> after you removed the nodes, then you got an array with a bunch of null values and relevant nodes
91 2014-03-04 01:25:27 <olalonde> my implementation is not very idiomatic
92 2014-03-04 01:26:06 <olalonde> you need to convert that array representation to a node graph that you can serialize to JSON
93 2014-03-04 01:26:32 <olalonde> each node has the following properties: left, right, value, hash. you start at the root node and build the tree
94 2014-03-04 01:27:34 <olalonde> maybe would have been easier to stick to the array representation...
95 2014-03-04 01:27:54 <olalonde> but its not optimal because you could end up with a huge array with bunch of null values everywhere
96 2014-03-04 01:28:56 <mhanne> ah ok
97 2014-03-04 01:29:12 <mhanne> so you want to keep the current json format
98 2014-03-04 01:29:47 <mhanne> fair enough, i was just confused, thought maybe it offered some advantage i didn't see
99 2014-03-04 01:31:28 <mhanne> i'll try to get my version compatible, but probably won't have time before the weekend..
100 2014-03-04 01:35:26 <olalonde> mhanne: here is how the serialized version of a partial tree should look like https://gist.github.com/olalonde/9338482#file-gistfile1-json
101 2014-03-04 01:35:48 <olalonde> yes, I think it's better to keep this format for publishing the files.. internally you can use arrays
102 2014-03-04 01:36:30 <mhanne> alright, thank you :)
103 2014-03-04 01:37:15 <olalonde> the problem with arrays is that it's not very optimized if you have a bunch of empty nodes in the middle of the array... the object representation doesn't care about empty nodes
104 2014-03-04 01:37:31 <olalonde> mhanne: no problem, keep me updated on progress :) I'll link to your implementation
105 2014-03-04 01:38:58 <olalonde> mhanne: this might help you https://github.com/olalonde/blind-liability-proof/blob/master/lib/tree.js#L226 (array to object representation function)
106 2014-03-04 01:40:49 <olalonde> https://github.com/olalonde/blind-liability-proof/blob/master/lib/tree.js#L65 functions to get left/right indexes for a given index .. yours should be a bit different since your leafs are at the beginning of the array
107 2014-03-04 01:41:07 <olalonde> back to work, good luck :)
108 2014-03-04 01:41:39 <mhanne> ah, great
109 2014-03-04 01:42:08 <mhanne> i actually have half of your tree class ported by now... now i'm not sure if i shouldn't just finish it that way
110 2014-03-04 01:43:11 <mhanne> but yea it seems to be easy enough to convert too
111 2014-03-04 01:46:35 <warren> wumpus: https://github.com/bitcoin/bitcoin/pull/3383#issuecomment-36453324 wangbus wants to finish this PR, but someone needs to explain what exactly would be acceptable for the separate balances in RPC and UI.
112 2014-03-04 01:47:06 <warren> wumpus: I'm guessing the watch-only shouldn't mix into real balances for existing RPC commands, and we want new RPC for watch-only?
113 2014-03-04 01:47:18 <warren> wumpus: and for qt UI we want unconfirmed and confirmed?
114 2014-03-04 01:47:49 <gmaxwell> I think for everything we want confirmed/unconfirmed/watched
115 2014-03-04 01:48:07 <warren> oh, you don't want watched to have confirmed/unconfirmed of its own?
116 2014-03-04 01:48:14 <gmaxwell> oh
117 2014-03-04 01:48:15 <gmaxwell> maybe.
118 2014-03-04 01:48:21 <gmaxwell> No opinion.
119 2014-03-04 01:48:26 <gmaxwell> I misunderstood your cmment there.
120 2014-03-04 01:50:03 <warren> Luke-Jr: sipa: anyone else have an opinion on what is desired for watch-only RPC and qt UI?
121 2014-03-04 01:50:52 <gmaxwell> conf unconf wconf wunconf sounds fine to me. ... maybe someone would complain about figure bloat. The GUI could hide the latter two if you're not watching anything.
122 2014-03-04 01:51:18 <warren> gmaxwell: which RPC commands in particular should have variants?
123 2014-03-04 01:51:20 <Luke-Jr> warren: that PR is totally broken and should not be merged in any form.
124 2014-03-04 01:51:40 <warren> Luke-Jr: I'm going based on what wumpus said earlier, please comment in the PR
125 2014-03-04 01:52:28 <Luke-Jr> warren: I already did
126 2014-03-04 01:52:32 <warren> Luke-Jr: if it no longer causes confusion with mixing, do you have any concerns beyond encouraging resuse?
127 2014-03-04 01:52:34 <warren> reuse?
128 2014-03-04 01:52:56 <Luke-Jr> you mean if it only shows receives?
129 2014-03-04 01:53:11 <warren> Luke-Jr: no
130 2014-03-04 01:53:21 <Luke-Jr> then what doy uo mean "mixing"?
131 2014-03-04 01:53:39 <warren> Luke-Jr: confusion of "real" and "watched" coins in the same balance, I think people agree they don't want that.
132 2014-03-04 01:53:55 <Luke-Jr> warren: that's the smallest of the problems with it
133 2014-03-04 01:54:10 <warren> Luke-Jr: I am not too concerned about the reuse issue because we already have that, and we need HD
134 2014-03-04 01:54:17 <Luke-Jr> the big problems are 1) showing "sent" transactions that are entirely unrelated to the added addresses
135 2014-03-04 01:54:22 <Luke-Jr> and 2) encouraging address reuse
136 2014-03-04 01:54:39 <Luke-Jr> warren: we don't have ANYTHING encouraigng reuse right now
137 2014-03-04 01:55:18 <Gerendon> Hiring a programmer proficient in Ruby for a blockchain parser. PM for more information.
138 2014-03-04 01:56:20 <Luke-Jr> the *only* "use case" proposed for this, is one that we already support easier
139 2014-03-04 01:57:18 <warren> Gerendon: try #bitcoin-ruby
140 2014-03-04 01:57:36 <Gerendon> warren: thank you
141 2014-03-04 01:58:30 <warren> Luke-Jr: how is #1 a problem?
142 2014-03-04 01:58:54 <Luke-Jr> warren: uh, how is it *not*?
143 2014-03-04 01:59:00 <Luke-Jr> everything about #1 is a bug
144 2014-03-04 01:59:27 <warren> Luke-Jr: if it doesn't effect any balances and it is informational only its still a problem?
145 2014-03-04 01:59:50 <Luke-Jr> rephrased: when it is used, it adds transactiosn that have *nothing* to do with the wallet or address, to your wallet
146 2014-03-04 02:00:16 <warren> concrete example?
147 2014-03-04 02:01:44 <Luke-Jr> warren: import an address used by Joe. When he receives, that shows up in your wallet. Now when he spends bitcoins at some random time in the future entirely unrelated to the address (which is only used to receive of course), his transaction now shows up in your wallet as "send" even though you are not watching any of the addresses nor have anything to do with it
148 2014-03-04 02:02:34 <papes11> helix coin is now having bounties up guys!
149 2014-03-04 02:04:27 <papes11> Helixcoin is now doing bounties. Please join #thehelixcoin
150 2014-03-04 02:04:38 <SomeoneWeird> :|
151 2014-03-04 02:39:19 <warren> Luke-Jr: how is it entirely unrelated if an input from that address is involved?
152 2014-03-04 02:39:43 <warren> Luke-Jr: as long as the unrelated part doesn't effect a balance within the wallet I don't see how this is an issue.
153 2014-03-04 02:46:23 <warren> Luke-Jr: perhaps it can be considered as "known" but disregarded in a similar manner as a conflicted tx?
154 2014-03-04 02:46:41 <warren> except for the watch-only balance effected by the spent input
155 2014-03-04 02:47:31 <warren> Luke-Jr: err ... the wallet is already effect in weird ways if you import one address that contributed to a larger tx with unrelated inputs, how is this any different?
156 2014-03-04 02:51:20 <flound1129> how can this be:
157 2014-03-04 02:51:39 <flound1129> $ bitcoind getbalance -> 0.00248484
158 2014-03-04 02:51:40 <flound1129> $ bitcoind getbalance "" -> 1.65183409
159 2014-03-04 03:06:44 <gmaxwell> flound1129: because "" is not "*"
160 2014-03-04 03:07:22 <gmaxwell> also in current releases immature coins are counted inconsistently.
161 2014-03-04 03:40:56 <gmaxwell> [OT] https://www.gitorious.org/gnutls/gnutls/commit/6aa26f78150ccbdf0aec1878a41c17c41d358a3b GNU TLS, basically the same bug as OSX in certificate validation.
162 2014-03-04 03:41:56 <copumpkin> news at 11: fucked-up control flow is easy to get wrong
163 2014-03-04 03:42:08 <copumpkin> (news at 10:42)
164 2014-03-04 03:42:08 <flound1129> can I do a sendmany from *?
165 2014-03-04 03:42:41 <The_Fly> if my bitcoind saw a tx, but it never showed up in a block and there's no public (blockchain.info etc.) record of it... has it either just fallen out of mempools and failed to propagate or could there be a doublespend at work
166 2014-03-04 03:43:01 <gmaxwell> copumpkin: more of a statement about the total lack of testing in basically all SSL libraries, alas.... and the fundimental difficulty of testing it.
167 2014-03-04 03:43:10 <maaku> The_Fly: either one? check for yourself
168 2014-03-04 03:43:13 <The_Fly> i have a very low threshold on zeroconf txs anyway so it's not really an issue, i also block withdrawals until all user txs confirm at least once as a measure
169 2014-03-04 03:43:21 <The_Fly> maaku: how can i check
170 2014-03-04 03:43:26 <maaku> see if the inputs are spent
171 2014-03-04 03:43:35 <The_Fly> i can't getrawtransaction on it
172 2014-03-04 03:44:13 <gmaxwell> then it's completely spent. (I don't think there is any other case where that doesn't work) to double check do a gettxout
173 2014-03-04 03:45:26 <The_Fly> gettxout returns nothing
174 2014-03-04 03:45:34 <maaku> gettxout on what parameters?
175 2014-03-04 03:45:59 <The_Fly> the exact ammount was sent a second time, so i think the user just sent again, which confuses me because his first tx was credited
176 2014-03-04 03:46:18 <The_Fly> i do check the inputs for confs, they must have at least one
177 2014-03-04 03:46:51 <The_Fly> maaku: oh do i need includemempool?
178 2014-03-04 03:48:07 <maaku> The_Fly: for each input, check for it with gettxout (you'll get nothing if it's spent)
179 2014-03-04 03:48:44 <The_Fly> checking the inputs of the tx which is stuck at 0 confs?
180 2014-03-04 03:48:51 <maaku> *spent or chained 0 conf
181 2014-03-04 03:48:58 <The_Fly> i am stuck at even querying that tx
182 2014-03-04 03:48:59 <maaku> es
183 2014-03-04 03:49:01 <maaku> yes
184 2014-03-04 03:49:44 <maaku> I'm confused. You have a transaction in your bitcoind that is not yet in the blockchain, yes?
185 2014-03-04 03:49:49 <The_Fly> correct
186 2014-03-04 03:50:15 <maaku> But somehow you don't have that transaction? ("<The_Fly> i am stuck at even querying that tx")
187 2014-03-04 03:50:33 <The_Fly> ./bitcoind getrawtransaction 2f60b5cbf2e4873382949e720c7941eeec3f1017583623b145f222187d8e57e5
188 2014-03-04 03:50:36 <The_Fly> error: {"code":-5,"message":"No information available about transaction"}
189 2014-03-04 03:51:23 <maaku> so how did you get that txid in the first place?
190 2014-03-04 03:51:32 <The_Fly> *shrugs*
191 2014-03-04 03:51:54 <The_Fly> user looks legit, i have their oauth on g+ and know what project they're connected with
192 2014-03-04 03:52:16 <The_Fly> they sent the funds (exact same value) again, 10 mins later roughly
193 2014-03-04 03:52:36 <The_Fly> it's not hugely important, i might just have to completely remove zero-conf deposits
194 2014-03-04 03:53:22 <The_Fly> i *do* set tight limits on them, as i said, including disallowing subsequent withdrawal until all user deposit txs confirm at least once
195 2014-03-04 03:53:28 <maaku> yes, you should remove zero-conf deposits anyway
196 2014-03-04 03:53:42 <The_Fly> i know, i wanted it for fluidity
197 2014-03-04 03:54:10 <maaku> i won't pounce on you for that this time
198 2014-03-04 03:54:13 <maaku> what i'm saying is, it doesn't sound like 2f60b5cbf2e4873382949e720c7941eeec3f1017583623b145f222187d8e57e5 ever was a transaction
199 2014-03-04 03:54:27 <The_Fly> it appears in listtransactions
200 2014-03-04 03:55:11 <The_Fly> thanks for not pouncing maaku, i do know it is a security hole, hence the tight guards around it
201 2014-03-04 03:55:33 <The_Fly> i was just doing a bit of db auditing, and if this came up again it would mean a user could not withdraw
202 2014-03-04 03:55:58 <The_Fly> since i would deny it on account that they had a stuck tx (in the current implementation)
203 2014-03-04 03:56:04 <The_Fly> hm, that might also have to go...
204 2014-03-04 03:56:06 <maaku> ok well getrawtransaction won't pull from the wallet
205 2014-03-04 03:56:17 <maaku> but if it's in the wallet it should be in the mempool
206 2014-03-04 03:57:04 <The_Fly> box has been rebooted since
207 2014-03-04 03:57:06 <The_Fly> perhaps
208 2014-03-04 03:57:14 <The_Fly> so, it's gone?
209 2014-03-04 03:58:47 <The_Fly> actually im probably going to leave things the way they are, in the case of a double spend i would block any withdrawal (say the user makes a prize, wants to cash out)
210 2014-03-04 03:58:52 <The_Fly> so i dont think im at risk
211 2014-03-04 03:58:57 <maaku> well it would be re-added to the mempool if there wasn't another conflicting transaction
212 2014-03-04 03:59:03 <The_Fly> ./bitcoind gettxout 2f60b5cbf2e4873382949e720c7941eeec3f1017583623b145f222187d8e57e5 1 true ?
213 2014-03-04 03:59:04 <maaku> so you can assume that was the case
214 2014-03-04 03:59:21 <maaku> i assume the one you received 10 min later was a mutated version of the same
215 2014-03-04 04:00:57 <The_Fly> what do you mean? it's from the same address, same value, different time (so different txid)
216 2014-03-04 04:02:14 <The_Fly> listtransactions -> http://pastebin.com/9pH5N6Jn
217 2014-03-04 04:02:44 <maaku> The_Fly: there is no time in transactions
218 2014-03-04 04:02:59 <maaku> it has a different txid because some aspect of the transaction is different
219 2014-03-04 04:03:27 <The_Fly> ah sorry
220 2014-03-04 04:03:48 <maaku> this is the classic example of a mutated transaction
221 2014-03-04 04:03:53 <maaku> (and why you don't accept them)
222 2014-03-04 04:04:01 <maaku> the txid associated with a transaction is not final until it hits the chain
223 2014-03-04 04:04:02 <The_Fly> its the only one ive had
224 2014-03-04 04:04:05 <maaku> this confuses the wallet
225 2014-03-04 04:04:42 <The_Fly> i accept zeroconf on the grounds that they cannot withdraw
226 2014-03-04 04:04:50 <The_Fly> if it fails to hit the chain
227 2014-03-04 04:05:07 <The_Fly> but there are non-malicious reasons this could happen, so that is again bad practice?
228 2014-03-04 04:05:57 <The_Fly> mutated == malicious?
229 2014-03-04 04:06:34 <The_Fly> (yes i have been following the gox story :P)
230 2014-03-04 04:09:46 <The_Fly> it's odd that he moved the funds to 1CfqARw9zMmwWK9svSzcFSGJC3ktjpQ8ir first
231 2014-03-04 04:10:26 <The_Fly> wait, no, that was the deposit address i issued.
232 2014-03-04 04:11:00 <maaku> no, mutated does not mean malicious
233 2014-03-04 04:11:10 <maaku> it could have been anybody between him and the miner
234 2014-03-04 04:11:13 <maaku> and even accidental
235 2014-03-04 04:12:00 <The_Fly> you mean the tx was broken during relay?
236 2014-03-04 04:12:10 <maaku> not broken
237 2014-03-04 04:12:31 <maaku> the hash from which you get the txid covers bits which anyone can change in certain ways without invalidating the transaction
238 2014-03-04 04:12:57 <The_Fly> right
239 2014-03-04 04:13:13 <The_Fly> i think i see what happened, he's sent two to the same address
240 2014-03-04 04:13:21 <The_Fly> i automatically issue a new address every tx
241 2014-03-04 04:13:38 <maaku> no, no, if he did that you would have seen two confirmed transactions
242 2014-03-04 04:13:43 <maaku> what happened was he sent one tx
243 2014-03-04 04:14:07 <maaku> and, somewhere along the way, some bits of it were changed and when it hit the blockchain it had a different hash
244 2014-03-04 04:14:25 <maaku> but it's the same transaction
245 2014-03-04 04:14:56 <maaku> and all it did was confuse applications which accept zero-conf transactions (like yours) into crediting his account twice
246 2014-03-04 04:15:37 <The_Fly> http://pastebin.com/raw.php?i=kuWPX1ep
247 2014-03-04 04:15:51 <The_Fly> any way to explain the timestamp i have in my db though
248 2014-03-04 04:16:13 <The_Fly> i do realise zero conf is terrible, granted, but isn't my no-withdrawl safeguard enough?
249 2014-03-04 04:16:31 <The_Fly> as in, in his state he would not be able to get any funds out until there is a manual audit
250 2014-03-04 04:17:30 <The_Fly> so im covered
251 2014-03-04 04:17:37 <The_Fly> (if it was malicious)
252 2014-03-04 04:17:55 <The_Fly> in his case since it was accidental, yes it's an annoyance for the user
253 2014-03-04 04:18:01 <The_Fly> but hopefully very rare...
254 2014-03-04 04:18:18 <maaku> i don't know what kind of business you run
255 2014-03-04 04:18:42 <maaku> but if it is an exchange, for example, he could use the double-counted balance for a leveraged position
256 2014-03-04 04:18:58 <The_Fly> yes for sure, i would turn instant deposit OFF in that case
257 2014-03-04 04:19:07 <maaku> generally you shouldn't let the user do *anything* with funds that have no confirmation
258 2014-03-04 04:19:18 <The_Fly> absolutely, i agree
259 2014-03-04 04:19:29 <The_Fly> i just wanted flexibility in this system
260 2014-03-04 04:19:42 <The_Fly> it's currently built for a very low-risk project
261 2014-03-04 04:19:55 <maaku> the timestamp is just the localtime when your node saw the transaction
262 2014-03-04 04:20:07 <maaku> in the first case when you saw it on the network, in the second when you saw it in the blockchain
263 2014-03-04 04:20:23 <The_Fly> ok, i see
264 2014-03-04 04:20:36 <The_Fly> same tx, came in twice, once mutated
265 2014-03-04 04:21:14 <The_Fly> hmmm if only i could write a test vector for this
266 2014-03-04 04:21:36 <The_Fly> the long term goal is to make wallet software that provides some kind of assurance (if i license it)
267 2014-03-04 04:21:38 <radiator> Hi, is anyone working on a decentralized exchange ?
268 2014-03-04 04:21:49 <The_Fly> maaku: but for now it is just in-house
269 2014-03-04 04:21:53 <maaku> The_Fly: speaking of test vecotrs, make sure you handle a reorg properly
270 2014-03-04 04:22:26 <maaku> in a related attack, the first transaction can get a single confirm, then is reorg'd away, and the second transaction accepted
271 2014-03-04 04:22:46 <The_Fly> maaku: yes, if miners collude this can be pulled off right?
272 2014-03-04 04:22:49 <maaku> you need to recognize they are double spends of each other
273 2014-03-04 04:23:06 <maaku> it coudl even be accidental although this is less likely
274 2014-03-04 04:23:35 <The_Fly> waiting for more confs reduces risk of reorg
275 2014-03-04 04:24:07 <The_Fly> actually i do it in a bracketed fashion, so i accpet 0.1 btc or less 0conf, 1btc or less 1conf, 2btc or less 2 conf etc. etc.
276 2014-03-04 04:24:12 <The_Fly> user configurable
277 2014-03-04 04:24:22 <The_Fly> so they can adjust to their desired risk profile
278 2014-03-04 04:24:48 <The_Fly> i am tempted to just say 3 confs for everything now, and then the only thing which would hurt me is hardfork
279 2014-03-04 04:24:57 <The_Fly> which i dont know how to detect
280 2014-03-04 04:25:13 <The_Fly> but i shut down my box when i get a bitcoind alert... heh
281 2014-03-04 04:25:52 <The_Fly> (i mean client configurable, customers who use this wallet software)
282 2014-03-04 04:26:56 <The_Fly> lol http://pastebin.com/raw.php?i=kuWPX1ep "Another blockchain reorg of six or more blocks before July 1, 2013"
283 2014-03-04 04:27:08 <The_Fly> * http://betsofbitco.in/item?id=1408
284 2014-03-04 04:27:20 <maaku> The_Fly: be sure to also shut down if the block rate significantly slows down
285 2014-03-04 04:27:33 <The_Fly> oh yeah?
286 2014-03-04 04:27:46 <The_Fly> that would happen if mining was to grind to a halt?
287 2014-03-04 04:27:53 <maaku> that's a locally detectable indication that you are on a fork, or a 51% attack started
288 2014-03-04 04:28:18 <The_Fly> thanks maaku, all good information
289 2014-03-04 04:28:24 <maaku> could be caused by lots of things - network partition, accidental bug, explicit attack
290 2014-03-04 04:28:44 <The_Fly> what is a good threshold, i guess i can statistically look at the blockchain
291 2014-03-04 04:28:56 <The_Fly> and distribution of blocktime deltas
292 2014-03-04 04:29:25 <maaku> you should be able to figure it out mathmatically - since block finding is a Poisson process
293 2014-03-04 04:29:56 <maaku> I'm feeding my daughter right now so it's hard to break out a pencil & paper
294 2014-03-04 04:29:57 <The_Fly> ok nice math challenge for me :)
295 2014-03-04 04:30:03 <The_Fly> maaku: that's ok
296 2014-03-04 04:30:15 <The_Fly> feeding her is much more important lol
297 2014-03-04 04:30:40 <maaku> basically just decide what false positive rate you want (how often you can accept your service shutting down & sending you an email/sms under normal circumstances)
298 2014-03-04 04:31:04 <maaku> and how quickly you want to react (how many blocks of history to consider)
299 2014-03-04 04:31:04 <The_Fly> it's a poisson process, is that the case under rapidly increasing/decreasing network hashrate
300 2014-03-04 04:31:12 <The_Fly> and when diff changes
301 2014-03-04 04:31:26 <maaku> yes it is, it is just the rate that changes
302 2014-03-04 04:31:48 <maaku> but you shouldn't have to model that, just assume 10 min
303 2014-03-04 04:32:28 <maaku> gmaxwell would probably have more input on filter problems like this
304 2014-03-04 04:33:54 <The_Fly> ok, im interested to discuss this futher at some point, for now the basic implementation i have is quite robust (apart from this double deposit case ive found, which risk can be mitigated by value-bracketed min confirmation limits)
305 2014-03-04 04:34:23 <The_Fly> and withdrawal hold on stuck 0conf tx
306 2014-03-04 04:34:28 <The_Fly> hold/block
307 2014-03-04 04:34:54 <The_Fly> then the only relevant issues beyond this are 51% attack detection/prevention, as you mentioned
308 2014-03-04 04:35:46 <The_Fly> and reorgs (covered in the client-configurable settings, e.g. they can set a hard minconfs of 3 for all deposits)
309 2014-03-04 04:36:16 <The_Fly> for my stupid website https://the-million-bitcoin-homepage.com/
310 2014-03-04 04:36:21 <The_Fly> selling valueless pixels
311 2014-03-04 04:36:39 <The_Fly> i think i can tolerate zeroconf-related failures :P
312 2014-03-04 04:38:22 <The_Fly> although in the case of prize funds it would act as a gradual drain unless the limit is set quite low, so i might move to requiring 1 conf when i inject prize money (anyway thats offtopic)
313 2014-03-04 04:38:33 <The_Fly> thanks again maaku , i really appreciate your help & time
314 2014-03-04 04:55:48 <The_Fly> well at least i audit my database and transaction processing system, unlike karpeles :P
315 2014-03-04 04:56:43 <radiator> The_Fly: please, dont mention that name in here
316 2014-03-04 04:57:30 <The_Fly> okay
317 2014-03-04 05:05:55 <Luke-Jr> warren: there is no from address
318 2014-03-04 05:34:43 <rasmuzen> hi
319 2014-03-04 05:36:26 <rasmuzen> I'm trying to create a giant table of all utxos that are associated with scriptpubkeys (and the scriptpubkey they're associated with, of course)
320 2014-03-04 05:37:13 <rasmuzen> is there some way I can process the transactions that are downloaded by bitcoind to create such a table?
321 2014-03-04 05:37:39 <rasmuzen> jcorgan: CodeShark: hey :P
322 2014-03-04 05:38:59 <justanotheruser> rasmuzen: I think there is a blockchain parser on bitcointalk
323 2014-03-04 05:40:34 <rasmuzen> thanks
324 2014-03-04 05:41:12 <rasmuzen> justanotheruser: do you know if it would be possible to do such a thing using just the rpc api?
325 2014-03-04 06:01:58 <dansmith_btc> rasmuzen, can you iterate over each tx with gettransaction check if it is unspent with gettxout and finally get its script with decoderawtx?
326 2014-03-04 06:06:34 <anton000> just clarifying in getrawtransaction <txid> 1
327 2014-03-04 06:07:03 <anton000> the returned "value" entry for each vout is in bitcoins already and not satoshi?
328 2014-03-04 06:09:32 <anton000> nvm... lol checked on blockchain
329 2014-03-04 08:55:06 <paveljanik> --help for discover should state --discover=<n>
330 2014-03-04 08:55:42 <michagogo> cloud|paveljanik: feel free to correct it
331 2014-03-04 08:59:35 <paveljanik> will try...
332 2014-03-04 09:13:50 <Lightsword> does anyone know of any reference code for how to manage generation transaction pool payouts similar to how eligius works?
333 2014-03-04 09:15:07 <paveljanik> michagog|cloud: done
334 2014-03-04 09:15:11 <paveljanik> o, sorry
335 2014-03-04 09:37:39 <paveljanik> and now ACKed. Thanks. 10minutes from my github registration. Good.
336 2014-03-04 09:37:40 <paveljanik> ;-)
337 2014-03-04 09:38:29 <wumpus> paveljanik: yes, documentation improvements are really easy to ACK, we need more of them :)
338 2014-03-04 09:58:53 <wumpus> anyone with advice here? https://github.com/bitcoin/bitcoin/issues/3748 submitter has a conflicted transaction and wants to reissue it, but is unsure how
339 2014-03-04 09:59:55 <Diablo-D3> wumpus: just make another one
340 2014-03-04 10:00:03 <Diablo-D3> the conflicted one can never be valid
341 2014-03-04 10:00:39 <Diablo-D3> wumpus: the way Ive always interpreted those, its effectively an accidental double spend attempt
342 2014-03-04 10:00:39 <wumpus> are you really sure? I'm afraid to cause gox-like issues
343 2014-03-04 10:00:55 <Diablo-D3> heh, afaict, gox never had gox-like issues
344 2014-03-04 10:01:01 <Diablo-D3> gox had magicaltux stealing $400m issues
345 2014-03-04 10:01:21 <wumpus> usually when reissuing the advice is to spend at least one input, but how to actually do that using bitcoind I don't know
346 2014-03-04 10:02:43 <Persopolis> if it's conflicted, could it not mean the other version of this tracsaction went through and therefore another should NOT be created to replace it? but i don't know
347 2014-03-04 10:03:04 <wumpus> Persopolis: right, that's also an option, that's why I'm not rushing to answer
348 2014-03-04 10:03:30 <wumpus> tho ,"walletconflicts":[]
349 2014-03-04 10:03:50 <wumpus> I'd interpret that as 'there is no direct duplicate'
350 2014-03-04 10:03:57 <Diablo-D3> Persopolis: thats the way Ive always interpreted it
351 2014-03-04 10:04:00 <Diablo-D3> its not the first time its come up
352 2014-03-04 10:04:41 <wumpus> well there are multiple ways in which a transaction can become conflicted, one is that a malleated duplicate made it into a block, in which case you *don't* want to reissue
353 2014-03-04 10:05:02 <wumpus> another is that the person spent unconfirmed change and the intermediate transaction was malleated, causing the transaction to be 'orphaned'
354 2014-03-04 10:05:18 <Persopolis> so is there a way for him to check outputs he was spending with this transaction and see if anything on blockchain spent that output?
355 2014-03-04 10:05:45 <wumpus> another one is a double-spend attempt (from a wallet backup, for example)
356 2014-03-04 10:05:54 <wumpus> so... yeah :-)
357 2014-03-04 10:06:47 <Diablo-D3> wumpus: yeah it sounds like its either a wallet backup and he tried to issue a tx before the chain completed updating, or he has the wallet running concurrently thus breaking shit
358 2014-03-04 10:28:46 <koshii> Is this a good place to ask kind of newbie bitcoin dev questions (as in, not core dev, but building things with Bitcoin) ?
359 2014-03-04 10:29:40 <Diablo-D3> koshii: that'd be better for #bitcoin I think
360 2014-03-04 10:29:44 <koshii> OK
361 2014-03-04 10:29:47 <Diablo-D3> but everyone is asleep anyhow
362 2014-03-04 10:29:52 <koshii> Thanks.
363 2014-03-04 10:40:47 <michagogo> cloud|12:01:24 <wumpus> usually when reissuing the advice is to spend at least one input, but how to actually do that using bitcoind I don't know
364 2014-03-04 10:41:04 <michagogo> cloud|wumpus: `bitcoind help createrawtransaction`
365 2014-03-04 10:45:54 <Garnenya> hello here
366 2014-03-04 10:46:03 <Garnenya> I have question about bitcoin
367 2014-03-04 10:46:47 <Garnenya> which libdb developers are using and why it's not the newest libdb-5?
368 2014-03-04 10:48:34 <sipa> Garnenya: libdb has bad compatibility properties
369 2014-03-04 10:49:24 <sipa> Garnenya: if you have a bitcoind linked against bdb 5.1, you're not able to open your wallet file using 4.8 anymore
370 2014-03-04 10:49:54 <sipa> that is why release binaries use the earliest still-commonly-available bdb version
371 2014-03-04 10:51:43 <Garnenya> sipa: does it means that if i will move wallet.dat on PC where is only libdb 4.8 i won't be able to open it?:x
372 2014-03-04 10:52:23 <michagogo> cloud|Garnenya: yes, if BDB 5.1 has touched that wallet
373 2014-03-04 10:52:34 <Garnenya> I see...
374 2014-03-04 10:52:41 <Garnenya> thanks for answer:)
375 2014-03-04 10:53:22 <michagogo> cloud|Garnenya: it's theoretically possible to downgrade, using db5.1_dump and db4.8_load, IIRC
376 2014-03-04 10:53:43 <michagogo> cloud|But I haven't done it myself, so I can't guarantee that works
377 2014-03-04 10:55:33 <sipa> downgrading manually is possible yes
378 2014-03-04 10:57:36 <Garnenya> uh-huh... useful :) hmmm.. what about wallet on Windows? i haven't digged about this matter myself yet... but what lib is using windows for making wallet.dat? is it possible to move that file on linux wallet with no harm?
379 2014-03-04 10:58:04 <michagogo> cloud|Garnenya: windows and linux both use bdb
380 2014-03-04 10:59:49 <Garnenya> 4.8? or 5.1?
381 2014-03-04 11:00:11 <Diablo-D3> 4.8 iirc
382 2014-03-04 11:00:24 <Garnenya> kthx
383 2014-03-04 11:17:38 <wumpus> michagogo|cloud: that's not really useful in this case is it, if I have to explain to every newbie how to use raw transactions ...
384 2014-03-04 11:43:03 <CodeShark> I realized from our earlier conversation on a generalized multisig policy that nested m-of-n is fundamentally related to the theory of symmetric functions
385 2014-03-04 11:44:10 <CodeShark> Sm,n = x1 x2 x3 ⦠xm + x1 x2 x3 ⦠x_{m-1} x_{m+1} + ...
386 2014-03-04 11:44:45 <CodeShark> the symmetric polynomial where each term is at most linear in each variable
387 2014-03-04 11:45:45 <CodeShark> over the field {0,1}
388 2014-03-04 11:46:27 <CodeShark> finding the simplest representation using solely m-of-n as a primitive amounts to finding the shortest expression only using the symmetric polynomials
389 2014-03-04 11:46:45 <CodeShark> the two problems are isomorphic
390 2014-03-04 11:50:45 <CodeShark> I believe the expression in terms of the symmetric polynomials is actually nique
391 2014-03-04 11:50:47 <CodeShark> *unique
392 2014-03-04 11:51:03 <sipa> where is n?
393 2014-03-04 11:53:23 <CodeShark> the symmetric polynomial Sm,n(x1, x2, x3, â¦, xm) is the sum of all products of exactly m variables
394 2014-03-04 11:54:07 <CodeShark> it has the interesting feature over the field {0,1} that it is 0 if fewer than m of the x's are 1
395 2014-03-04 11:54:29 <CodeShark> it is 1 when exactly m of the x's are 1
396 2014-03-04 11:55:02 <CodeShark> err, sorry
397 2014-03-04 11:55:13 <CodeShark> I meant Sm,n(x1, x2, x3, â¦, xn)
398 2014-03-04 11:55:22 <CodeShark> we form m-tuple products
399 2014-03-04 11:55:29 <CodeShark> and sum over all such terms
400 2014-03-04 11:56:05 <CodeShark> every polynomial function has a unique representation in terms of the symmetric polynomials
401 2014-03-04 11:56:17 <CodeShark> it's an important theorem in galois theory :)
402 2014-03-04 11:56:52 <CodeShark> over the field {0,1}, it's even simpler since higher powers than 1 are idempotent
403 2014-03-04 11:57:02 <CodeShark> so we only need to consider the exponents 0 and 1
404 2014-03-04 11:58:56 <CodeShark> since any truth table over a finite set of boolean variables can be represented as a polynomial over {0,1}, there must be a unique representation in terms of the symmetric polynomials
405 2014-03-04 12:00:13 <CodeShark> so I think the only issue that remains is the ordering of the variables
406 2014-03-04 12:00:50 <t7> ACTION googles symmetric polynomials
407 2014-03-04 12:02:38 <CodeShark> actually, the theorem states that every symmetric polynomial has a unique representation in terms of the elementary symmetric polynomials
408 2014-03-04 12:04:39 <CodeShark> in general, the function we'd be dealing with would not be symmetric - so the problem then becomes splitting it into nested symmetric functions
409 2014-03-04 12:07:05 <CodeShark> hmm, in our particular application, satisfaction really just means that at least one of the terms is 1, so + corresponds to inclusive or rather than exclusive or
410 2014-03-04 12:08:43 <CodeShark> I'm sure this problem's been studied to death :p
411 2014-03-04 12:09:54 <CodeShark> inclusive or is equivalent to 1-of-n
412 2014-03-04 12:10:47 <CodeShark> so we can first factor the polynomial if we can, then treat each factor as a 1-of-n over a set of products
413 2014-03-04 12:16:17 <CodeShark> a single term is n-of-n
414 2014-03-04 12:16:54 <Xeno-Genesis> Does anyone know of some web service API providing sendrawtransaction facilities through an HTTP request, similar to http://blockchain.info/pushtx, but that actually works for P2SH?
415 2014-03-04 12:17:41 <CodeShark> so for instance, x1 x2 + x1 x3 factors into x1 (x2 + x3) which leads us to 2of(x1, 1of(x2, x3))
416 2014-03-04 12:19:27 <CodeShark> now what happens when you can't factor? say x1 x2 + x1 x3 + x3 x4
417 2014-03-04 12:22:46 <airbreather> x1 x2 + x1 x3 + x3 x4, you'd have to pick, right? either x1(x2 + x3) + (x3 x4) or (x1 x2) + x3(x1 + x4)... couldn't you just always factor out the lowest term?
418 2014-03-04 12:23:17 <CodeShark> let's count the number of m-of-n operations we must perform in each case
419 2014-03-04 12:23:58 <airbreather> at least, when the number of m-of-n operations is tied for the lowest
420 2014-03-04 12:24:09 <TD> sipa: it seems that we need to fix the mining code to compare < nMinRelayFee otherwise the fee drop is useless. concur?
421 2014-03-04 12:24:59 <CodeShark> the two forms you gave are equivalent up to a permutation in the x's, airbreather :)
422 2014-03-04 12:25:58 <airbreather> so, the policy would accept or reject them both the same?
423 2014-03-04 12:26:09 <CodeShark> so we can have a canonical sorting of the variables and a well-defined rule in the order of operations
424 2014-03-04 12:26:48 <CodeShark> for instance, we can put terms containing fewer factors on the left
425 2014-03-04 12:28:05 <CodeShark> in expanded form, we have 1of(2of(x1, x2), 2of(x1, x3), 2of(x3, x4))
426 2014-03-04 12:29:50 <CodeShark> not sure what exactly we're optimizing for
427 2014-03-04 12:30:48 <CodeShark> the three forms we just gave require exactly four m-of-n operations, but the expanded form doesn't nest more than two levels deep
428 2014-03-04 12:30:53 <airbreather> hmm... I see, rote factorization like what I did doesn't reduce below 4 yeah
429 2014-03-04 12:31:29 <CodeShark> so perhaps we really can't do any better than that
430 2014-03-04 12:32:30 <CodeShark> on the other hand, what you did reduces the number of variables in any given layer to at most two
431 2014-03-04 12:32:56 <CodeShark> whereas the expanded form requires three at a single level
432 2014-03-04 12:33:36 <sipa> TD: i think the fee drop is useless in any case
433 2014-03-04 12:33:47 <CodeShark> which is more efficient for our purposes seems to depend entirely on the computational model we apply
434 2014-03-04 12:33:55 <CodeShark> the virtual machine
435 2014-03-04 12:34:02 <sipa> TD: it will just result in more transactions not confirming
436 2014-03-04 12:34:42 <CodeShark> a stack machine would probably do better with fewer operands and more nesting
437 2014-03-04 12:34:56 <CodeShark> whereas a register machine might be the exact opposite
438 2014-03-04 12:35:54 <Persopolis> are you talking about using logic simplification like karnaugh maps? not following where you are heading :)
439 2014-03-04 12:36:40 <CodeShark> in a way, yes
440 2014-03-04 12:37:07 <Persopolis> i mean what is your goal?
441 2014-03-04 12:37:42 <CodeShark> to construct the most efficient bitcoin script in terms of required computational resources to evaluate a nested m-of-n expression
442 2014-03-04 12:37:50 <michagogo> cloud|Xeno-Genesis: there are a few places I know where you can push a raw tx
443 2014-03-04 12:38:27 <michagogo> cloud|In addition to bc.i, they exist at (among others) webbtc, coinbin, and eligius
444 2014-03-04 12:38:33 <CodeShark> or to construct the shortest possible script
445 2014-03-04 12:38:38 <CodeShark> might be a better goal
446 2014-03-04 12:38:58 <CodeShark> the smallest possible script in terms of number of bytes in the script
447 2014-03-04 12:39:05 <Persopolis> Xeno-Genesis - is running your own bitcoind instance not an option with RPC?
448 2014-03-04 12:40:07 <Xeno-Genesis> Thank you michagogo|cloud
449 2014-03-04 12:40:52 <Xeno-Genesis> Persopolis, I have some clients that are demoing my technology, and I rather have them install only our command-line software, without dependencies.
450 2014-03-04 12:41:36 <Xeno-Genesis> Persopolis, I can assume theyll have curl on their systems, but not an up-to-date bitcoind, electrum, or similar.
451 2014-03-04 12:41:48 <CodeShark> run the bitcoind on your own servers, then :)
452 2014-03-04 12:42:29 <Persopolis> Xeno-Genesis - just watch out for running foul of web based api calls not being construed as DoS - many of the providers will see repeated rapid api calls as a DoS
453 2014-03-04 12:42:43 <michagogo> cloud|Xeno-Genesis: also, you could theoretically find a bunch of peers, connect to them, send the tx, and disconnect
454 2014-03-04 12:43:00 <CodeShark> actually, you only need to connect to one :)
455 2014-03-04 12:43:33 <Xeno-Genesis> michagogo|cloud, That will be availalbe soon with the SPV library. I wish to use something patchy for now until SPV support is done.
456 2014-03-04 12:43:59 <michagogo> cloud|CodeShark: true, but that one may not relay
457 2014-03-04 12:43:59 <Xeno-Genesis> Persopolis, The demo is run manually, I will never send more than a couple of transactions per minute.
458 2014-03-04 12:44:04 <michagogo> cloud|michagogo|cloud: SPV library?
459 2014-03-04 12:44:16 <Xeno-Genesis> michagogo|cloud, Yes, that speaks Bitcoin P2P protocol.
460 2014-03-04 12:44:20 <michagogo> cloud|Xeno-Genesis:*
461 2014-03-04 12:44:32 <michagogo> cloud|Xeno-Genesis: you don't need a full implementation
462 2014-03-04 12:44:43 <michagogo> cloud|Just a socket and a few messages
463 2014-03-04 12:44:51 <CodeShark> just a handshake and a tx message, really
464 2014-03-04 12:44:53 <Persopolis> ver / verack
465 2014-03-04 12:44:53 <Xeno-Genesis> michagogo|cloud, No, just connect to a peer, deliver the TX, disconnect. I get it.
466 2014-03-04 12:45:09 <CodeShark> send version, receive verack, send tx, disconnect
467 2014-03-04 12:45:23 <michagogo> cloud|Xeno-Genesis: right - you can easily put the ~4-5 messages you need in your code
468 2014-03-04 12:45:40 <CodeShark> then connect to another node and grab the mempool and see if your transaction is there :)
469 2014-03-04 12:45:56 <Xeno-Genesis> WebBTC is cool.
470 2014-03-04 12:46:02 <Xeno-Genesis> Ill try it.
471 2014-03-04 12:48:20 <michagogo> cloud|CodeShark: or connect to a handful, send to one or two
472 2014-03-04 12:48:35 <michagogo> cloud|See if the others inv it
473 2014-03-04 12:48:37 <CodeShark> yeah, that's the right way to do it
474 2014-03-04 12:49:03 <CodeShark> but managing more than one connection at a time requires either multithreading or async i/o :_)
475 2014-03-04 12:49:40 <CodeShark> and if he's looking for a service that essentially does what sendrawtransaction does, I'm guessing he's not looking to do that
476 2014-03-04 12:49:47 <michagogo> cloud|Yeah
477 2014-03-04 12:49:57 <michagogo> cloud|True.
478 2014-03-04 12:57:02 <Persopolis> btw how does the code distinguish nodes from one another - i assume it's not purely network address
479 2014-03-04 13:01:24 <michagogo> cloud|Persopolis: what exactly do you mean?
480 2014-03-04 13:03:00 <Persopolis> so if I have multiple bitcoid clients running on private network and connecting to other nodes through NAT... what do the multiple nodes look like to the external nodes - does it see them as one node? or is there some way it distinguishes them from a single node trying to connect to it multiple times
481 2014-03-04 13:03:26 <jgarzik> Persopolis, the internal nodes become invisible
482 2014-03-04 13:03:50 <jgarzik> Persopolis, Network only knows nodes and what they relay.
483 2014-03-04 13:04:07 <jgarzik> oh, sorry, I thought you were building a DMZ
484 2014-03-04 13:04:30 <jgarzik> Persopolis, if it's just multiple nodes behind a NAT, with -no- DMZ, it looks like multiple nodes on the same IP address
485 2014-03-04 13:05:09 <Persopolis> indeed - does this create a problem?
486 2014-03-04 13:10:50 <jgarzik> Persopolis, for the network? no. for you? maybe.
487 2014-03-04 13:12:34 <Persopolis> ah ConnectNode refuses connection from same address by the looks of it - so your internal nodes will probably end up connecting to differing external nodes
488 2014-03-04 13:13:15 <Persopolis> maybe not - I think i misread that...
489 2014-03-04 13:14:45 <Persopolis> bummer - that's not so good
490 2014-03-04 13:21:58 <Persopolis> ideally the nodes should be added based on some sort of unique id generated by the node - that way they can be distinguished from one another
491 2014-03-04 13:22:15 <sipa> why?
492 2014-03-04 13:23:40 <Persopolis> if a service provider doesn't want to expose those servers through a DMZ, they end up with a single point of failiure
493 2014-03-04 13:25:55 <jgarzik> Persopolis, it is a single point failure for the network at large, to have a bunch of nodes on the same network
494 2014-03-04 13:26:39 <sipa> the reason for avoiding the same subnet is to make sybil attacks harder
495 2014-03-04 13:26:51 <sipa> as it means the attacker has to control many networks
496 2014-03-04 13:27:38 <Persopolis> jgarzik - come on - not really a problem for the network... but it is a problem for a service provider if they can only run a single instance of bitcoind
497 2014-03-04 13:28:46 <jgarzik> Persopolis, yes, it is a problem for the network if measures are not taken, think about it
498 2014-03-04 13:29:15 <Persopolis> jgarzik out of the entire network, how many node do you think would be run out of the same subnet
499 2014-03-04 13:29:48 <Persopolis> not a large percentage... so this is not a network resilience issue - this is a system resilience issue for the provider
500 2014-03-04 13:29:51 <jgarzik> Persopolis, mostly irrelevant to the security discussion of many nodes clustered on a single network
501 2014-03-04 13:30:02 <jgarzik> Persopolis, locally, you can run as many as you want
502 2014-03-04 13:31:02 <Persopolis> jgarzik the point is to try and avoid service providers having a single point failure
503 2014-03-04 13:31:32 <Persopolis> but i think there is a way to satisfy both
504 2014-03-04 13:32:33 <Persopolis> you can currently specifiy connect=<ip>, adding a flag to say if <ip> not aviable then switch to any
505 2014-03-04 13:33:22 <Persopolis> that way a provider can have primary server with no connect switch, a secondary server with connect=primary server + switch to connect to any if primary not avail
506 2014-03-04 13:34:27 <Persopolis> how does that sound?
507 2014-03-04 13:36:58 <jgarzik> Persopolis, like I said, locally, you may run however many you want. The point I was trying to make is that the network will try to avoid clusters of nodes, for very important reasons.
508 2014-03-04 13:37:23 <jgarzik> Persopolis, a big provider running multiple nodes is just fine
509 2014-03-04 13:38:21 <Persopolis> jgarzik - but currently they are limited to having one interface with outside network - i'm just proposing a simple way to work around that
510 2014-03-04 13:38:36 <sipa> heh?
511 2014-03-04 13:39:19 <jgarzik> sipa, NAT -> single IP address, I presume he means
512 2014-03-04 13:39:57 <sipa> so?
513 2014-03-04 13:41:44 <Persopolis> thats where my question started sipa - i asked if that was a problem - jgarzik saod it might be a problem if the external nodes see my internal nodes as a single node
514 2014-03-04 13:42:02 <Persopolis> which looking through the code looks like they would
515 2014-03-04 13:43:14 <sipa> why do you want incoming connections?
516 2014-03-04 13:43:41 <Persopolis> i didn't say that
517 2014-03-04 13:43:47 <sipa> then it doesn't matter
518 2014-03-04 13:43:53 <sipa> you can make outgoing connections all you want
519 2014-03-04 13:44:54 <Persopolis> let me just elaborate afresh.. Service provider has 2 nodes behind NAT - Nodes A and B - they connect to an external node X - X sees A and B as just one node because they have the same IP
520 2014-03-04 13:45:46 <sipa> no it does not
521 2014-03-04 13:45:55 <Persopolis> lol
522 2014-03-04 13:45:55 <sipa> they're two independent connections
523 2014-03-04 13:46:07 <epscy> they would have to be on different ports to get incoming connections right?
524 2014-03-04 13:46:35 <epscy> actually they should be on different ports anyway if the NAT does upnp
525 2014-03-04 13:46:38 <epscy> i think
526 2014-03-04 13:46:43 <sipa> yes, but it's about outgoing connections, so that doesn't matter
527 2014-03-04 13:47:15 <Persopolis> when I look at the code, I can only see network address of being used to distinguish nodes
528 2014-03-04 13:47:30 <sipa> where precisely?
529 2014-03-04 13:48:16 <Persopolis> can't recall precisely now - but was looking at things like ConnectNode and FindNode
530 2014-03-04 13:48:42 <sipa> ah, hmm
531 2014-03-04 13:48:59 <sipa> but you'd probably be using -addnode if you want to connect to a specific external node anyway
532 2014-03-04 13:49:07 <sipa> wait
533 2014-03-04 13:49:09 <sipa> nevermind
534 2014-03-04 13:49:13 <Persopolis> =D
535 2014-03-04 13:50:56 <sipa> Persopolis: for outgoing connections, you're right
536 2014-03-04 13:51:11 <sipa> Persopolis: but i doubt that X will care about the address of the connections of A and B
537 2014-03-04 13:51:17 <sipa> if it does, that's probably a bug
538 2014-03-04 13:52:06 <Persopolis> I suspect it will reuse FindNode function :S
539 2014-03-04 13:52:34 <Persopolis> e.g. to store node stats
540 2014-03-04 13:52:37 <Persopolis> version etc
541 2014-03-04 13:52:55 <sipa> why?
542 2014-03-04 13:53:10 <sipa> can you please look at the code or test this first?
543 2014-03-04 13:55:33 <Persopolis> sipa - yes of course - but please remeber I'm asking in here to get guidance - i've only been messing with the code for a few days - it takes me 10 times longer to even locate the right area to look at
544 2014-03-04 13:57:11 <Persopolis> and I've looked once and repeated my understanding here to confirm if it was right...
545 2014-03-04 14:10:44 <TD> sipa: why blocks are not full
546 2014-03-04 14:11:08 <TD> sipa: besides, relatively speaking if all transactions drop their fee together, it should make no difference to how many transactions confirm
547 2014-03-04 14:11:42 <TD> BlueMatt: is gavin around?
548 2014-03-04 14:12:36 <sipa> TD: if all of them do, sure
549 2014-03-04 14:12:55 <sipa> unless miners don't want to mine them anymore :)
550 2014-03-04 14:13:12 <sipa> (which probably won't happen for a while)
551 2014-03-04 14:13:42 <TD> at any rate, the mining code still needs adjustment
552 2014-03-04 14:13:56 <jgarzik> TD, relatively speaking, if all transactions drop their fee together, it certainly could make a great deal of difference how many transactions confirm, if miners dislike that fee adjustment
553 2014-03-04 14:14:15 <jgarzik> it always makes a difference when you change the economics on a wide scale
554 2014-03-04 14:16:11 <TD> miners could all simultaneously decide they want more fees and go on strike tomorrow, regardless of any fee drop
555 2014-03-04 14:16:17 <TD> that's the nature of the system
556 2014-03-04 14:16:52 <TD> i worry more about users "going on strike"
557 2014-03-04 14:21:21 <jgarzik> TD, I don't, right now
558 2014-03-04 14:21:39 <jgarzik> TD, my public nodes have seen ever-increasing client traffic, both volume and node count
559 2014-03-04 14:21:50 <jgarzik> TD, anecdotal evidence points to same
560 2014-03-04 14:22:38 <TD> doesn't mean much - perhaps growth would be 2x as fast if transactions were cheaper. (i doubt that, but the point holds)
561 2014-03-04 14:23:03 <TD> anyway, miners are free to adjust upwards if they don't like the pro-growth hints in the source code
562 2014-03-04 14:38:59 <TD> oh FFS