1 2014-12-19 00:02:00 <Luke-Jr> wumpus: did BE get merged already?
2 2014-12-19 00:02:54 <gmaxwell> BlueMatt: we need the anti-idiotic-censorship version of dnsseed. I'm tired of randomly not being able to get to sipa's website.
3 2014-12-19 00:04:55 <Luke-Jr> gmaxwell: I haven't had issues since configuring it to be less aggressive crawling
4 2014-12-19 00:05:28 <gmaxwell> his issues haven't seemed to be crawling related. It's just that the dnsseed name resolves to hosts sometimes that end up on malware lists.
5 2014-12-19 00:05:37 <gmaxwell> I believe opendns still blocks it as we speak, for example.
6 2014-12-19 00:05:52 <hearn> hah
7 2014-12-19 00:05:56 <hearn> another reason not to use DNS, i guess
8 2014-12-19 00:06:07 <gmaxwell> So I'd previously though we should a v2 type seed under another domain that just stupidly xors the ips it returns.
9 2014-12-19 00:06:23 <gmaxwell> it's not being intentionally blocked, its just automation as far as I can tell.
10 2014-12-19 00:06:28 <Luke-Jr> oh
11 2014-12-19 00:07:11 <Luke-Jr> hm! I wonder if my problems could have been trying to connect to a honeypot IP
12 2014-12-19 00:07:24 <gmaxwell> hearn: dns has some scaling and privacy advantages, due to caching in the dns hierarchy. Otherwise it stinks. (And I'd love if the seeds could return signed results for example)
13 2014-12-19 00:07:48 <hearn> signed or just SSLd
14 2014-12-19 00:08:14 <gmaxwell> well I'd like a bad dns seed to leave evidence of it, but even ssl would be an improvement in that particular respect.
15 2014-12-19 00:08:40 <gmaxwell> But it means the operator of the server gets pretty strong visiblity into whos using the software; which we consider generally undesirable (at least for bitcoin core)
16 2014-12-19 00:09:15 <gmaxwell> I looked into trying to pack some signatures into dns but the amount of dns tampering that goes on in recursive resolvers seems too great.
17 2014-12-19 00:09:28 <Luke-Jr> DNSSEC?
18 2014-12-19 00:10:21 <gmaxwell> Luke-Jr: also gets stripped by resolvers. (just packing some signature data into txt records is likely more robust than dnssec)... seems to be getting better though.
19 2014-12-19 00:57:40 <Luke-Jr> what would be thoughts on an optional (at compile and run time) fork-isolated SWIG interface for CNodePolicy so users can drop in Python/Ruby/Perl scripts to control that behaviour? anything else that might benefit from scripting?
20 2014-12-19 01:04:12 <gmaxwell> while I'm supportive of the concept, optional compile time only is more configurations that would need tesitng that likely wouldn't get it.
21 2014-12-19 01:11:29 <average> this is crazy, I've been looking for a bitcoin-paid gig and can't find any
22 2014-12-19 01:11:51 <moa> http://it.slashdot.org/story/14/12/18/2346238 might be relevant for some
23 2014-12-19 01:11:52 <average> I've received some offers, but mostly just gambling/casino/betting
24 2014-12-19 01:12:10 <average> I'm kinda annoyed I can't find any bitcoin-paid gig, it's so annoying
25 2014-12-19 01:22:28 <Luke-Jr> gmaxwell: Travis is nice.
26 2014-12-19 01:36:14 <BlueMatt> gmaxwell: yea, we've gone around and around on better dnsseeds....anyone care to implement?
27 2014-12-19 01:36:26 <BlueMatt> not gmaxwell, this is a really good beginners project
28 2014-12-19 01:36:33 <BlueMatt> (at least the bitcoin core part)
29 2014-12-19 01:36:45 <BlueMatt> (we need a bitcoin-good-beginners-project@ ml)
30 2014-12-19 01:42:23 <gmaxwell> hearn: I think there is some broken implementation flooding getaddrs now for third party nodes. I noticed while testing some address discovery changes that my test address got announced even though my host never announced it.
31 2014-12-19 01:42:47 <BlueMatt> was only a matter of time before someone did that
32 2014-12-19 01:42:52 <gmaxwell> I've been unable to find the source. It's moderately obnoxious... technically were robust to that, but it certantly makes things slower.
33 2014-12-19 01:43:51 <gmaxwell> I guess with 13 never run bitcoin IP addresses I can figure out precisely which node is doing it, if it is only a single node.
34 2014-12-19 01:45:07 <gmaxwell> (assign each reachable node an index, have each test IP connect to nodes when index&(1<<tester) ... see which bitpattern gets announced involuntarily)
35 2014-12-19 02:05:19 <hearn> BlueMatt: it's done already
36 2014-12-19 02:05:21 <hearn> BlueMatt: https://github.com/mikehearn/httpseed
37 2014-12-19 02:05:40 <hearn> supports serving seed data over DNS, HTTP with signed protocol buffers, also JSON, XML and HTML
38 2014-12-19 02:06:12 <hearn> also can restrict results (when using http) using a service flag bitmask
39 2014-12-19 02:06:22 <hearn> total lines of code: 570. not bad, i think
40 2014-12-19 02:07:09 <hearn> it doesn't do a whole lot of testing of peers though. it will probably include some peers that are behind. will fix that tomorrow and let it loose on the main network.
41 2014-12-19 02:07:20 <BlueMatt> nice
42 2014-12-19 02:07:24 <BlueMatt> yea, sounds good
43 2014-12-19 02:09:08 <hearn> i'd like to move SPV clients to using HTTP + signed data over time. i don't think the minor IP obfuscation DNS provides is worth much, given that anyone can collect random IPs of random users by just running a regular node anyway. governments can just examine netflow data to find bitcoin users if they care.
44 2014-12-19 02:13:44 <gmaxwell> hearn: governments are the only or always most interesting threat, also be mindful of selective partioning power.
45 2014-12-19 02:16:16 <average> BlueMatt: hey I'll implement that
46 2014-12-19 02:16:40 <average> oh , looks like someone already did it
47 2014-12-19 02:16:45 <BlueMatt> nono
48 2014-12-19 02:16:52 <BlueMatt> just mask out dnsseeds
49 2014-12-19 02:17:02 <BlueMatt> maybe a TXT or oher record with a signature over results
50 2014-12-19 02:17:05 <average> that's how it is these days, people are like "oh look, there's something useful i could implement" and 10min later turns out someone else did it
51 2014-12-19 02:17:15 <BlueMatt> and mask the values with an XOR mask or something simple
52 2014-12-19 02:17:26 <BlueMatt> hearn: implemented something very different
53 2014-12-19 02:18:21 <hearn> average: there's tons of things to implement ...
54 2014-12-19 02:19:21 <average> hearn: like what
55 2014-12-19 02:19:21 <hearn> average: the bitcoin world is not lacking for fun, small tasks :)
56 2014-12-19 02:19:30 <hearn> average: pick a skill, then i'll tell you some ideas
57 2014-12-19 02:19:34 <BlueMatt> average: like the things I just said 10 seconds ago?
58 2014-12-19 02:19:53 <BlueMatt> the stuff I said was a good beginner's get-into-bitcoin-core project is not related to what hearn just did
59 2014-12-19 02:20:00 <BlueMatt> well, related, but not the same
60 2014-12-19 02:21:25 <hearn> i'm not sure hacking DNS would count as a beginners project.
61 2014-12-19 02:22:05 <BlueMatt> XOR ip addresses coming back from dnsseeds with a static mask? sure it is!
62 2014-12-19 02:22:13 <BlueMatt> not really hacking dns at all
63 2014-12-19 02:23:13 <hearn> rollout? serving it via BIND as your seed requires? avoiding random validation errors from misc DNS stacks that don't like invalid IP addresses in the response ... ?
64 2014-12-19 02:23:36 <hearn> i really don't think it's worth trying to mangle DNS into having more features. it just wasn't designed for this.
65 2014-12-19 02:23:38 <BlueMatt> meh
66 2014-12-19 02:23:54 <BlueMatt> dnsseeds serving the results will upgrade themselves, I'm not worried about that
67 2014-12-19 02:24:08 <BlueMatt> do and dns stacks block 0.0.0.0/255.255.255.255 in a response?
68 2014-12-19 02:24:12 <BlueMatt> any
69 2014-12-19 02:24:15 <hearn> it's not the seeds that is the problem, it's the clients needing to know whether they are supposed to use the magic xor trick or not
70 2014-12-19 02:24:27 <BlueMatt> well you put it under a different subdomain
71 2014-12-19 02:24:31 <gmaxwell> hearn: huh? you just do that via a different subdomain.
72 2014-12-19 02:25:27 <hearn> yeah, exactly, so at that point you're basically doing a new protocol that clients have to be upgraded to use, parallel to the existing one. may as well switch to a more robust format whilst doing it
73 2014-12-19 02:25:48 <BlueMatt> robust format like what?
74 2014-12-19 02:25:49 <hearn> at any rate, stuff that requires lots of coordination between a bunch of people isn't really a beginners project
75 2014-12-19 02:25:57 <BlueMatt> you cant do http or you're adding a new phone-home feature
76 2014-12-19 02:26:28 <BlueMatt> if it were implemented reasonably in bitcoin core, I'd wager a bet at least two/three of the dnsseeds would have support within a few weeks
77 2014-12-19 02:26:31 <BlueMatt> and thats enough to rollout
78 2014-12-19 02:26:48 <gmaxwell> (well be more specific about 'you' .. phone home features are not something I consider desirable in Bitcoin core)
79 2014-12-19 02:27:05 <gmaxwell> Other software can do what it likes, of course.
80 2014-12-19 02:27:08 <hearn> it already "phones home" when talking to the existing seeds. that's pretty fundamental to p2p networking.
81 2014-12-19 02:27:21 <BlueMatt> well, dns is nice because it has this built-in anonymity network
82 2014-12-19 02:27:26 <BlueMatt> where the seed only hears about your isp
83 2014-12-19 02:27:28 <BlueMatt> not you
84 2014-12-19 02:28:06 <gmaxwell> hearn: it generally doesn't. It only polls dns seeds when it cant connect fast, and the results are cached and they're all required to have non-zero ttls... and even when a request goes all the way up, they see the recursive resolver, not the user.
85 2014-12-19 02:28:19 <Luke-Jr> I find it a bit disturbing that virtually all the big mining rigs sold do phone-home
86 2014-12-19 02:28:32 <hearn> a seed can always return one of its own IPs and find you when you connect to it, if it wanted to. meanwhile, with dns the requests and responses are all unencrypted and cannot easily have any metadata attached
87 2014-12-19 02:28:42 <hearn> like e.g. node keys for a future authd/crypted version of p2p
88 2014-12-19 02:28:57 <gmaxwell> Luke-Jr: that you can turn it off on the spondoolies may be my one contribution to their feature set.
89 2014-12-19 02:29:27 <BlueMatt> hearn: even if a seed returned /only/ its ip address, bitcoin core would not always connect to it
90 2014-12-19 02:29:38 <BlueMatt> (of course this is bitcoin core running from scratch, not ever been run before)
91 2014-12-19 02:29:57 <BlueMatt> and this is also why we need more dnsseeds
92 2014-12-19 02:30:02 <BlueMatt> to be more robust in this regard
93 2014-12-19 02:31:00 <moa> is v0.10 rc yet?
94 2014-12-19 02:31:11 <hearn> ACTION -> bed
95 2014-12-19 02:31:15 <BlueMatt> http://bitcoin010rc.yet
96 2014-12-19 02:31:19 <BlueMatt> someone go built it!
97 2014-12-19 02:31:19 <gmaxwell> moa: why do you ask?
98 2014-12-19 02:31:36 <moa> gmaxwell: just wondered ... nothing nefarious
99 2014-12-19 02:31:40 <moa> random thought
100 2014-12-19 02:40:42 <s1w> is yet even a tld? :P
101 2014-12-19 02:40:54 <moa> not yet
102 2014-12-19 05:23:13 <jcrubino> is there a server to nslookup testnet peers?
103 2014-12-19 05:35:35 <jcrubino> how can I lookup over the network testnet peers?
104 2014-12-19 06:46:50 <wumpus> Luke-Jr: I haven't even put up my BE code as a pull yet, but you help it along by reviewing/testing #5490
105 2014-12-19 06:47:24 <wumpus> Luke-Jr: if you really want to test on a BE device, that'd be cool and I could send my private tree for that, but no guarantees with that :)
106 2014-12-19 07:03:46 <wumpus> seems to work fine though; it passes all the tests, it could sync the testnet chain up to ~90% (after that I stopped it), it could also take part on the main chain as a normal node
107 2014-12-19 07:03:54 <wumpus> there's still an issue with DNS seeding
108 2014-12-19 07:05:04 <wumpus> the rest is cleanups and autoconf-isms for endian detection
109 2014-12-19 08:03:13 <jonasschnelli> DNS Seeds: Are all seeds based on sipa/bitcoin-seeder?
110 2014-12-19 08:08:59 <Luke-Jr> jonasschnelli: IIRC jgarzik's is a static BIND nameserver
111 2014-12-19 08:09:41 <jonasschnelli> Luke-Jr: but his ones seems not to be in the chainparams.cpp?
112 2014-12-19 08:09:47 <average> lots of discussions about DNS these days, eh ?
113 2014-12-19 08:09:51 <wumpus> question about build system: where does WORDS_BIGENDIAN get defined?
114 2014-12-19 08:10:03 <wumpus> I see it is used in crypto/common.h, but it's referenced nowehere
115 2014-12-19 08:10:42 <Luke-Jr> wumpus: autotools
116 2014-12-19 08:10:46 <jonasschnelli> wumpus is it not defined in config.h?
117 2014-12-19 08:10:58 <wumpus> Luke-Jr: but how? what sets it? it's not correctly set
118 2014-12-19 08:11:37 <Luke-Jr> hmm
119 2014-12-19 08:11:46 <wumpus> ok this is weird; in my x86 bitcoin build I see a #define WORDS_BIGENDIAN in bitcoin-config.h
120 2014-12-19 08:11:52 <Luke-Jr> not sure, I think I actually have my own endian-detection code in BFGMiner, but i forget why
121 2014-12-19 08:11:53 <wumpus> in my mipsbe build, no such thing appears
122 2014-12-19 08:12:16 <wumpus> ... you'd guess it would be the other way around, though it ends up undefined in both cases
123 2014-12-19 08:13:17 <wumpus> OH doh, I've commented out the AC_C_BIGENDIAN([AC_MSG_ERROR("Big Endian not supported")])
124 2014-12-19 08:13:27 <jonasschnelli> wumpus: did you had a look at AC_C_BIGENDIAN? https://www.gnu.org/software/autoconf/manual/autoconf-2.60/html_node/C-Compiler.html
125 2014-12-19 08:13:28 <wumpus> probably should be replaced by the non-error-throwing variant
126 2014-12-19 08:13:29 <Luke-Jr> >_<
127 2014-12-19 08:14:13 <Luke-Jr> https://bugzilla.redhat.com/show_bug.cgi?id=449944
128 2014-12-19 08:14:31 <wumpus> it was sabotaging my build so I just commented it out, I can be stupid like that sometimes :-)
129 2014-12-19 08:18:05 <wumpus> that solved it.
130 2014-12-19 08:29:06 <wumpus> Luke-Jr: conclusion there appears to be 'it's buggy if you use AC_C_BIGENDIAN with parameters'
131 2014-12-19 08:29:16 <wumpus> I've just removed the parameters, so it should be ok
132 2014-12-19 08:33:36 <wumpus> when it's not horribly broken, autotools can be pretty neat
133 2014-12-19 08:37:21 <moa> open source
134 2014-12-19 08:38:57 <Luke-Jr> everything can be neat when not horribly broken
135 2014-12-19 08:38:59 <Luke-Jr> except systemd.
136 2014-12-19 08:39:21 <wumpus> Luke-Jr: though in principle we shouldn't need that define at all, as long as there's endian.h
137 2014-12-19 08:39:30 <Luke-Jr> wumpus: there isn't, on Windows
138 2014-12-19 08:39:33 <Luke-Jr> IIRC
139 2014-12-19 08:39:54 <wumpus> so suppose I need to write one in compat/..h
140 2014-12-19 08:40:08 <Luke-Jr> shouldn't need to
141 2014-12-19 08:40:24 <wumpus> oh?
142 2014-12-19 08:40:32 <Luke-Jr> does AC_C_BIGENDIAN fail if it's missing?
143 2014-12-19 08:40:38 <Luke-Jr> hm, maybe that was why I hand-rolled it
144 2014-12-19 08:40:41 <wumpus> I don't think so
145 2014-12-19 08:40:47 <wumpus> it works on windows
146 2014-12-19 08:41:01 <Luke-Jr> ok, then not sure why we'd need an endian.h
147 2014-12-19 08:41:03 <wumpus> in crypto/common.h we actually do hand-roll then if endian.h is not there
148 2014-12-19 08:41:17 <wumpus> because htobe16 and such
149 2014-12-19 08:41:34 <wumpus> nice functions that swap the bytes for you without having to call bswap16/32/64 which also doesn't exist on every platform
150 2014-12-19 08:41:59 <wumpus> *conditionally* needs to be in that sentence
151 2014-12-19 08:42:49 <Luke-Jr> oh, maybe that was why I hand-rolled it.. I'm checking like 4 different byteswap methods :D
152 2014-12-19 08:43:05 <wumpus> but I'm going to move that from crypto/ to compat, and just implement those functions if they don't exist
153 2014-12-19 08:44:09 <wumpus> if they exist, you of course want to use the platform's ones because they would use special instructions or compiler intrinsics
154 2014-12-19 08:44:44 <Luke-Jr> for sym in bswap_ __builtin_bswap __bswap_ __swap swap OSSwapInt; do for headerfile in '' byteswap.h endian.h sys/endian.h libkern/OSByteOrder.h; do
155 2014-12-19 08:44:50 <Luke-Jr> âº
156 2014-12-19 08:45:16 <Luke-Jr> maybe I should make a .m4 file of this we can just copy?
157 2014-12-19 08:46:04 <wumpus> well the code already exists in bitcoin's config in another form
158 2014-12-19 08:46:25 <wumpus> for the crypto common
159 2014-12-19 08:47:12 <Luke-Jr> not that git grep found for me, but ok.
160 2014-12-19 09:29:29 <jonasschnelli> gmaxwell: regarding https://github.com/bitcoin/bitcoin/pull/5503 existing VINs: so this would mean only support for existing VINs which are unspent wtx?
161 2014-12-19 09:32:34 <jonasschnelli> IMO the VINs must be signable to calculate the correct fee
162 2014-12-19 10:36:31 <fanquake> When commits are labelled as MOVEONLY, they should be completely identical, line for line code movements right? Or am I thinking too pedantically?
163 2014-12-19 11:29:45 <wumpus> generally, yes, although we don't care about spaces and such
164 2014-12-19 11:30:14 <wumpus> and sometimes you need small context-specific changes to be able to move things around in the first place, i.e. header changes and such
165 2014-12-19 11:30:44 <wumpus> I don't make a fuss out of those
166 2014-12-19 11:30:51 <wumpus> the important part is that there are no code changes
167 2014-12-19 11:31:04 <wumpus> no slightly different logic etc
168 2014-12-19 11:31:30 <wumpus> they should be easy to replicate and check
169 2014-12-19 11:32:15 <fanquake> Yep, was thinking line for line identical would be a little too far. (impossible in some cases)
170 2014-12-19 11:33:09 <wumpus> yes
171 2014-12-19 11:33:54 <fanquake> Just wanted to clarify before commenting.
172 2014-12-19 13:05:10 <wumpus> Luke-Jr: https://github.com/bitcoin/bitcoin/pull/5510
173 2014-12-19 13:14:17 <wumpus> I've cleaned it up to build system changes + a series of independent fixes
174 2014-12-19 13:31:14 <rubensayshi> is it 'safe' to store a BIP39 mnemonic without futher protection/encryption when it is used with a passphrase by a user? ie for a server storing it for usage in a webwallet (like bc.info)
175 2014-12-19 14:12:24 <sipa> wumpus: i wonder whether we can rely on any in-memory representation of floating point numbers?
176 2014-12-19 14:13:23 <sipa> ACTION reads ieee 754
177 2014-12-19 14:13:29 <wumpus> sipa: right now I'm assuming that floating point numbers have the same endianness as integers, and that they have standard IEE 754 format
178 2014-12-19 14:14:07 <wumpus> bitcoin will not run on any platforms that do not satisfy those requirements, not after the BE changes either
179 2014-12-19 14:14:08 <sipa> wumpus: maybe adding a simple unit test with a bunch of floating point constants, serialized, and compared with hardcoded binary form?
180 2014-12-19 14:14:14 <wumpus> sipa: good idea
181 2014-12-19 14:14:40 <wumpus> I have a testcase serialize_floats() with //TODO to remind me of that
182 2014-12-19 14:15:09 <wumpus> btw src/txmempool.cpp performs a cardinal sin: it serializes a long
183 2014-12-19 14:15:23 <wumpus> that's why travis is failing right now
184 2014-12-19 14:15:47 <sipa> i really like the serialization changes
185 2014-12-19 14:16:10 <sipa> it was pretty crazy to just define serialization for int/short/long and just assuming their sizes are known
186 2014-12-19 14:16:22 <wumpus> yes, regardless of endian this is an improvement
187 2014-12-19 14:16:23 <wumpus> indeed
188 2014-12-19 14:19:41 <sipa> wumpus: problem with the #ifdef's with shortcuts is that we really need to make sure both cases are tested
189 2014-12-19 14:20:15 <wumpus> sipa: I'm fine with removing the shortcuts, I've just left that open in case people would complain that Im making things slower
190 2014-12-19 14:20:41 <wumpus> but a travis for big-endian would be nice! :-)
191 2014-12-19 14:21:05 <sipa> i'll benchmark changing blockheader.GetHash() to SerializeHash(*this)
192 2014-12-19 14:21:20 <sipa> if it doesn't matter there, it probably doesn't matter anywhere
193 2014-12-19 14:37:27 <jgarzik> Luke-Jr, My seed is dnspark.net's farm
194 2014-12-19 14:56:15 <bsm117532> So looking through the code, I see a few mentions of improving the handling of time (e.g. GetAdjustedTime) and possibly using NTP rather than median peer time. What is the status of this work and where do the lead devs want this to go? I ran into RADclock the other day, which may be a neat way to embed a high-precision network clock, independent of the system clock.
195 2014-12-19 14:56:50 <sipa> NTP is centralized; using it as an optional and configurable extra time source, sure
196 2014-12-19 14:57:03 <sipa> but if you can do that, why didn't you just configure your system time to use NTP?
197 2014-12-19 14:57:29 <bsm117532> That's the impression I got...that devs have no interest in measuring time. That's not what I got reading the code.
198 2014-12-19 14:57:51 <sipa> the comments in the code referring to this are over 4 years old, i think
199 2014-12-19 14:57:54 <sipa> we should update those
200 2014-12-19 14:58:30 <bsm117532> I like this one: "Never go to sea with two chronometers; take one or three."
201 2014-12-19 14:58:47 <sipa> that comment has been in the code since i first saw it, i think
202 2014-12-19 14:59:14 <bsm117532> And I like the idea of adding an NTP clock source, how it gets *used* is another matter. Clearly mean peer time should not be totally removed.
203 2014-12-19 14:59:26 <sipa> in fact, that comment was in 0.1.5
204 2014-12-19 15:00:19 <sipa> i think gmaxwell has some opinions about time handling
205 2014-12-19 15:00:31 <sipa> i'm not very worried - we don't rely on very accurate clocks anyway
206 2014-12-19 15:00:33 <bsm117532> So to my question: what timing-related things do people want to see? Or is the answer "don't touch that"?
207 2014-12-19 15:02:34 <wumpus> my answer would be "don't touch that" unless you have explicit permission from gmaxwell :)
208 2014-12-19 15:03:23 <wumpus> that NTP comment is really old; artforz actually once implemented NTP client in bitcoind, but it wasn't regarded necessary
209 2014-12-19 15:03:32 <wumpus> in general I'd like to avoid dependencies on other network services
210 2014-12-19 15:04:03 <bsm117532> wumpus: I was thinking of embedding ntp, rather than depending on an external service.
211 2014-12-19 15:04:08 <wumpus> eh
212 2014-12-19 15:04:29 <wumpus> it would still depend on ntp servers right?
213 2014-12-19 15:04:33 <bsm117532> Yes.
214 2014-12-19 15:04:35 <wumpus> thats what I mean
215 2014-12-19 15:04:47 <wumpus> we just removed the dependency on external 'what is my ip' servers
216 2014-12-19 15:05:05 <sipa> well, i'm sure we could replace the "use mean time of peers" by something that uses something like ntp, used inside the p2p protocol between bitcoin nodes
217 2014-12-19 15:05:11 <wumpus> oh, sure
218 2014-12-19 15:05:13 <sipa> but i'm not sure we want that
219 2014-12-19 15:05:16 <bsm117532> Frankly I'm very surprised that everyone here is so anti-time. the financial world is extremely dependent on it. Bills become due, interest gets paid, etc, all on time.
220 2014-12-19 15:05:43 <bsm117532> there are undoubtedly timelock vulnerabilities if your clock is wrong.
221 2014-12-19 15:05:59 <sipa> bsm117532: and we already have a network clock with an accuracy of ~hours
222 2014-12-19 15:06:00 <wumpus> you could propose a P2P change, though I don't think it will get a lot of attention unless there are clear advantages
223 2014-12-19 15:06:31 <sipa> bsm117532: and it relies on network nodes in general having a clock themselves that has around ~1 hour of accuracy
224 2014-12-19 15:06:53 <bsm117532> Given that the accuracy of NTP is ~milliseconds...
225 2014-12-19 15:07:02 <sipa> using NTP means extra requirements on nodes, without improving the result: the "blockchain clock" won't get any more accurate as a result
226 2014-12-19 15:07:31 <sipa> if you have another service built on top of bitcoin that needs more accurate time, sure, go ahead and use it
227 2014-12-19 15:08:31 <bsm117532> gmaxwell what's your time-related wishlist?
228 2014-12-19 15:08:50 <gmaxwell> bsm117532: that people like you stop thinking NTP solves anything thats interesting to bitcoin?
229 2014-12-19 15:08:53 <gmaxwell> :)
230 2014-12-19 15:09:01 <bsm117532> hahaa
231 2014-12-19 15:09:49 <gmaxwell> NTP accuracy is milliseconds, if your network is totally symetric, the servers are honest, their servers are honest, and NTP hadn't _YET AGAIN_ made everyone's time a whole second off because it inserted a false leapsecond, on account of being so fragile that it fails randomly.
232 2014-12-19 15:11:58 <gmaxwell> I like time. But for bitcoin itself precision is not very important, and a quest for precision can introduce vulerabilities that actually matter. I would like there to exist some cryptographically stronger time services, and I'm slowly on working on stuff to create some things for that; though thats largely external to bitcoin itself.
233 2014-12-19 15:13:56 <gmaxwell> bsm117532: if you were to make all nodes depend on ntp, a network attacker could pretty trivially partition the network; because NTP (as its actually deployed) is completely unauthenticated and doesn't have stronger features like modling the local oscillators worst case error to limit how much you can trick it (and even if it did worst case error from typical hardware is pretty huge. :( )
234 2014-12-19 15:14:54 <bsm117532> Oh I agree. Hence not depending on it totally.
235 2014-12-19 15:15:29 <wumpus> indeed, decentralized time synchronization is interesting, it's just that bitcoin doesn't need it so in that narrow scope it's not interesting
236 2014-12-19 15:16:16 <wumpus> and this -dev channel only has a very narrow focus
237 2014-12-19 15:16:22 <wumpus> would be more of a #bitcoin-wizards topic maybe
238 2014-12-19 15:16:24 <gmaxwell> There is just nothing that we do that has any strong dependance on it at all. Though times on the network are in practice accurate to within a second, there is nothing in bitcoin that needs them anywhere near that accurate. I had though about changing the precision of the time messages and including a sane dicipline algorithim, but it would increase fingerprinting.
239 2014-12-19 15:16:31 <sipa> interesting how bitcoin v0.1.5 contains a comment 'todo: get time from ntp servers'
240 2014-12-19 15:17:30 <bsm117532> I kind of think of it as a problem someone else should solve. A financial system needs it, but shouldn't re-invent the wheel, nor totally eschew time measurement (as bitcoin is trying to do).
241 2014-12-19 15:17:40 <bsm117532> Well wumpus I am asking about specific code contributions.
242 2014-12-19 15:18:04 <gmaxwell> bsm117532: you keep speaking in generalities "A financial system needs it" ... they also need oxygen. And?
243 2014-12-19 15:18:17 <bsm117532> let me be really specific. block timestamps are allowed to be non-monotonic, correct? What advantages does that confer?
244 2014-12-19 15:18:22 <wumpus> we have doxygen!
245 2014-12-19 15:19:20 <sipa> bsm117532: i think you look at it the wrong way; clocks are something bitcoin uses; not something it provides
246 2014-12-19 15:19:33 <gmaxwell> bsm117532: it prevents an attack where a moderate hashpower miner forces everyones time forward, and resulting reorg when people try to prevent it. If you have some application which needs a 'monotonic time' from blocks, you can simply run a rolling maximum over the timestamps. The constraint would purely reduce available information.
247 2014-12-19 15:19:39 <sipa> bsm117532: why increase requirements on that it uses without getting a better outcome?
248 2014-12-19 15:19:53 <sipa> bsm117532: if another part of a financial system needs an accurate clock, then make it use one
249 2014-12-19 15:20:39 <gmaxwell> Bitcoin itself cannot provide one. (At least not one with high precision)
250 2014-12-19 15:20:46 <sipa> bsm117532: bitcoin does not and cannot provide an accurate clock (if you're talking about the ~second range), simply due to propagation delays across the planet alone
251 2014-12-19 15:21:16 <bsm117532> sipa: ping times can be accurately measured too.
252 2014-12-19 15:21:25 <sipa> so?
253 2014-12-19 15:21:46 <sipa> that measures latecny, not global time
254 2014-12-19 15:22:01 <gmaxwell> bsm117532: that doesn't solve the problem. One way ping times cannot be measured. The internet is not symmetrical. And every host isn't directly connected to every other host, and intermediate hosts could be dishonest.
255 2014-12-19 15:22:13 <sipa> i'm really not sure what problem you are solving, or what better outcome you think you can get
256 2014-12-19 15:22:19 <wumpus> if you need ntp, then use ntp? bitcoin is not meant as a swiss knife of everything that is remotely interesting to have
257 2014-12-19 15:22:27 <sipa> to me it sounds like a "inaccurate clocks are ugly; this must be fixed, because... because..."
258 2014-12-19 15:23:01 <gmaxwell> sipa: do be mindful of precision vs accuracy. :) This is more imprecise not inaccurate. :)
259 2014-12-19 15:23:17 <bsm117532> sipa: yes it's exactly that. Then I saw some comments in the code along the same lines so I brought it up.
260 2014-12-19 15:23:22 <gmaxwell> (we do somewhat depend on accurate but not precise time, since the inflation schedule is tied to it)
261 2014-12-19 15:23:28 <sipa> so let's remove the comments
262 2014-12-19 15:24:06 <gmaxwell> But the accuracy we need is something you can set with an almanaic and a sundial.
263 2014-12-19 15:24:13 <Belxjander> okay...I have managed to get a bitcoind built from 0.10 sources cloned off git...
264 2014-12-19 15:24:53 <Belxjander> How would I use the older torrent'ed blockchain image?
265 2014-12-19 15:25:49 <bsm117532> So look, you guys are going to get a PR from me sooner or later. But every single thing I've brought up, you don't like. (and I agree with much of your reasoning) But the philosophy seems to be to not improve anything. It's almost as though the code is too fragile and everyone is afraid of breaking something. (FWIW I totally get the "what problem are you solving" arguments)
266 2014-12-19 15:25:59 <bsm117532> So I ask you? What would you most like to see?
267 2014-12-19 15:26:31 <gmaxwell> You to actually answer the "what are you solving" question?
268 2014-12-19 15:26:40 <bsm117532> ;-)
269 2014-12-19 15:26:55 <sipa> Belxjander: https://github.com/bitcoin/bitcoin/blob/0.10/doc/bootstrap.md
270 2014-12-19 15:27:02 <gmaxwell> Some PR that twiddled around something where that question can't be answered is just going to be closed out of hand.
271 2014-12-19 15:27:03 <sipa> bsm117532: yes; if it ain't broken, don't fix it
272 2014-12-19 15:27:12 <wumpus> comment removed
273 2014-12-19 15:27:25 <sipa> bsm117532: and yes, we are afraid of breaking things
274 2014-12-19 15:27:33 <Belxjander> sipa:Thank you
275 2014-12-19 15:27:45 <gmaxwell> bsm117532: many years ago I did invent an approach for a decenteralized time service that used bitcoin like consensus; though it requires participants to have additional hardware, and isn't super pratical. (I should probably update it, I know a _lot_ more about timekeeping now) ... It's not something Bitcoin itself has any use for, but you may personally find it interesting: http://people.xiph.org/~g
276 2014-12-19 15:27:51 <gmaxwell> reg/decentralized-time.txt
277 2014-12-19 15:28:01 <sipa> bsm117532: not that i think this shouldn't be touched at all, but there are costs (risks, review time, ...) and benefits (afaik for what you're trying to do: none)
278 2014-12-19 15:28:04 <hearn> bsm117532: bitcoin effectively already uses NTP time
279 2014-12-19 15:28:07 <bsm117532> gmaxwell, sipa agreed. I'm not going to make a PR without a well-thought-out "what this is solving".
280 2014-12-19 15:28:15 <hearn> bsm117532: most operating systems will sync themselves via NTP these days
281 2014-12-19 15:28:53 <wumpus> indeed
282 2014-12-19 15:29:11 <bsm117532> gmaxwell: I've read that.
283 2014-12-19 15:31:44 <bsm117532> One of my thoughts behind timing measurements is that bitcoin is now seeing difficulty drops, and if those fluctuations become extreme, this could be a problem. The solution to this involves more accurately measuring the hashrate, which means more accurately measuring time.
284 2014-12-19 15:32:09 <bsm117532> But I don't think I'll convince anyone that this is needed until it actually happens.
285 2014-12-19 15:33:01 <sipa> i'm indeed not convinced; pretty much all work around "more accurately tracking hash rate" (and this is something that people have actually worked around in decent amounts in altcoins) hasn't been convinced at all
286 2014-12-19 15:33:12 <sipa> *convincing
287 2014-12-19 15:33:20 <bsm117532> Most of the work in altcoins has been utter bullshit on this topic.
288 2014-12-19 15:33:30 <sipa> oh sure
289 2014-12-19 15:33:31 <bsm117532> A lot of random spaghetti thrown at the wall, to see what sticks.
290 2014-12-19 15:33:36 <sipa> but not all of it
291 2014-12-19 15:35:33 <gmaxwell> bsm117532: the difficulty dropping isn't "flucations" mining has just reached a profitability equlibrium for many parties.
292 2014-12-19 15:35:40 <bsm117532> In the absence of an interesting obviously-needed idea, I'll likely implement this and put it out there as a PR. If hashrate starts fluctuating wildly, I can point to it and it can be quickly incorporated...
293 2014-12-19 15:36:19 <bsm117532> gmaxwell: agreed. There is an argument that this will never be needed for bitcoin itself, and it may be correct.
294 2014-12-19 15:36:24 <sipa> bsm117532: you do realize that changing the retargetting code is a hard fork of the worst kind?
295 2014-12-19 15:36:33 <sipa> bsm117532: as in: change every piece of bitcoin software on the planet
296 2014-12-19 15:36:50 <bsm117532> Yes
297 2014-12-19 15:37:27 <bsm117532> Note: "in the absence of an interesting obviously-needed idea"
298 2014-12-19 15:54:56 <sipa> wumpus: replacing Hash(begin, end) in BlockHeader by SerializeHash slows GetHash down by 3% here
299 2014-12-19 15:58:29 <sipa> wumpus: 3300 cpu cycles to 3400 cycles
300 2014-12-19 15:58:33 <sipa> per header
301 2014-12-19 16:00:03 <gmaxwell> sipa: try an O3 compile?
302 2014-12-19 16:00:49 <wumpus> sipa: we'll take that for simpler code
303 2014-12-19 16:05:11 <sipa> gmaxwell: nearly no different (in both cases)
304 2014-12-19 16:05:22 <sipa> 3292 and 3384 cycles
305 2014-12-19 19:00:26 <cfields> sipa: does this help make up some of the difference in ^^? https://github.com/theuni/bitcoin/commit/94a9d60952ab75b17bbb56595810ad2030a9d09f
306 2014-12-19 20:28:04 <sipa> wumpus, gmaxwell: ugh, with -O3 -flto it's 4500 cycles...
307 2014-12-19 20:28:11 <sipa> cfields: will try
308 2014-12-19 20:34:20 <sipa> wumpus, gmaxwell: my former measurement was wrong (I used CFLAGS=-O3 instead of CPPFLAGS); the gap is much smaller at O3
309 2014-12-19 20:34:33 <sipa> around 2%
310 2014-12-19 20:35:32 <sipa> not that much either
311 2014-12-19 20:42:30 <sipa> cfields: less than 0.3% speedup, in both cases
312 2014-12-19 20:42:49 <cfields> bleh, ok
313 2014-12-19 20:42:58 <cfields> i figured it was all the instantiation slowing it down. guess not
314 2014-12-19 20:44:25 <sipa> i expect that all that gets inlined already (at -O3 at least, which i used for the benchmarks)
315 2014-12-19 20:44:28 <sipa> let me benchmark your change again at -O2
316 2014-12-19 20:47:01 <gmaxwell> Well thats why I suggested O3, to get things inlined.
317 2014-12-19 20:57:26 <sipa> cfields: so either my measurement has some weird periodic and systemic biases, but it seems your change slowed the existing code down a tiny bit, and made the SerializeHash(*this) version slightly faster at -O2, so they're only 1.1% apart anymore
318 2014-12-19 20:59:17 <sipa> i don't understand how it can possibly affect the first
319 2014-12-19 21:01:34 <cfields> odd, i don't see how it could possibly be slower either
320 2014-12-19 21:02:47 <sipa> ACTION compiles and measures again
321 2014-12-19 21:04:37 <sipa> meh
322 2014-12-19 21:04:51 <sipa> these numbers don't make sense, even though they seem statistically significant
323 2014-12-19 21:05:04 <cfields> back the other way this time?
324 2014-12-19 21:05:06 <sipa> but we're talking about differences of 5ns per header
325 2014-12-19 21:05:11 <sipa> ACTION stops caring
326 2014-12-19 21:05:27 <cfields> heh
327 2014-12-19 21:05:36 <sipa> (averages and minima of 100 runs of 100k headers hashed each time)
328 2014-12-19 21:06:02 <sipa> at a locked CPU speed, with nothing else but a terminal and an ssh client running
329 2014-12-19 21:06:30 <gmaxwell> set the process to RT priority and pin it to a particular cpu? and turn off interrupts on that cpu?
330 2014-12-19 21:06:41 <gmaxwell> :P
331 2014-12-19 21:06:55 <gmaxwell> we can worry when it shows up in a profile.
332 2014-12-19 21:07:11 <sipa> ACTION thinks
333 2014-12-19 21:07:24 <sipa> i don't we hash the same block header more than like 10 times during processing
334 2014-12-19 21:07:43 <sipa> ;;blocks
335 2014-12-19 21:07:44 <gribble> 335003
336 2014-12-19 21:08:08 <sipa> ;;calc [blocks]*10*1300/1000000000
337 2014-12-19 21:08:09 <gribble> 4.355039
338 2014-12-19 21:08:15 <sipa> hmm, 4s difference in total
339 2014-12-19 21:08:45 <gmaxwell> it's certantly not the long pole in the tent. also, we could probably get 3% out of the hash just twiddling things in the implementation.
340 2014-12-19 21:08:54 <sipa> or turning on -O3
341 2014-12-19 21:19:19 <sipa> gmaxwell, wumpus, cfields: short summary, changing the code, cfield's optimization or -O2 vs -O3, together they have no more effect than 4%
342 2014-12-19 21:19:34 <sipa> -flto, on the other hand, slows it down by 30%
343 2014-12-19 21:19:56 <cfields> wha?
344 2014-12-19 21:20:01 <sipa> yes, slows down
345 2014-12-19 21:20:23 <cfields> old gcc?
346 2014-12-19 21:20:26 <kanzure> fundrawtransaction is a neat idea https://github.com/bitcoin/bitcoin/pull/5503
347 2014-12-19 21:20:30 <gmaxwell> hm. lto usd to make a measurable improvement. I wonder what channged.
348 2014-12-19 21:20:32 <sipa> 4.82
349 2014-12-19 21:20:35 <sipa> 4.8.2
350 2014-12-19 21:20:56 <sipa> gmaxwell: i prefer the btc version of lto over the usd one
351 2014-12-19 21:21:15 <kanzure> after looking at fundrawtransaction i have forgotten how to do this without fundrawtransaction
352 2014-12-19 21:21:20 <sipa> gmaxwell: this is microbenchmark
353 2014-12-19 21:21:52 <sipa> kanzure: there was 1) createrawtransaction 2) ??? 3) signrawtransaction 4) sendrawtransaction
354 2014-12-19 21:21:58 <gmaxwell> ACTION bash microbenchmark; microbenchmark bad
355 2014-12-19 21:22:11 <kanzure> sipa: right.. but the ??? part seems to be "implement your own coin selection"?
356 2014-12-19 21:22:17 <sipa> kanzure: yup!
357 2014-12-19 21:22:18 <gmaxwell> hm? the old procedure is listunspent ponder createrawtransaction
358 2014-12-19 21:22:23 <kanzure> oh right, listunspent
359 2014-12-19 21:22:32 <sipa> still, requires your own coin selection
360 2014-12-19 21:24:10 <sipa> gmaxwell: even 40% slowdown
361 2014-12-19 21:24:38 <sipa> maybe it just ends up being able to inline more, and doing it, resulting in worse code cache?
362 2014-12-19 21:24:50 <sipa> ACTION tries -O2 -flto
363 2014-12-19 21:24:52 <kanzure> now i have to decide if i want to test this patch, backport the patch into an old tree, or live with master.
364 2014-12-19 21:25:00 <cfields> sipa: you made sure to give -Ox in the link-line?
365 2014-12-19 21:25:03 <gmaxwell> hm. wouldn't it be nice if you could say "createraw [] {dest:10} ; fundraw hex limit=5; signraw anyonecanpay" then pass it to someone wlse who can fundraw; signraw; sendraw?
366 2014-12-19 21:25:03 <sipa> yes
367 2014-12-19 21:25:23 <cfields> (i only ask because -Ox semantics are different for lto, since the optims happen later)
368 2014-12-19 21:25:29 <sipa> cfields: i'm aware
369 2014-12-19 21:25:42 <sipa> ./configure --without-gui --disable-wallet CPPFLAGS="-g0 -O2 -flto" LDFLAGS="-g0 -O2 -flto"
370 2014-12-19 21:25:45 <cfields> ok
371 2014-12-19 21:28:12 <cfields> sipa: hmm. You're looking for CXXFLAGS there. I think that's doing something different than what you're after
372 2014-12-19 21:28:17 <cfields> notably leaving -g on
373 2014-12-19 21:28:51 <cfields> CPPFLAGS = c pre-processor. CXXFLAGS=c++ compile flags
374 2014-12-19 21:29:08 <sipa> i think you are right, but that it doesn't matter
375 2014-12-19 21:29:18 <cfields> by using CPPFLAGS, you're leaving the default flags on in addition to yours
376 2014-12-19 21:29:19 <sipa> as the preprocessor flags are passed to the same binaries
377 2014-12-19 21:29:31 <sipa> also: (no debugging symbols found)
378 2014-12-19 21:29:33 <cfields> a quick test shows that -g wins out over -g0
379 2014-12-19 21:30:17 <sipa> isn't it just last one specified?
380 2014-12-19 21:30:20 <cfields> (it depends on the order, but my test shows -g coming last)
381 2014-12-19 21:30:22 <cfields> yes ^^
382 2014-12-19 21:39:52 <kanzure> gmaxwell: https://github.com/bitcoin/bitcoin/pull/5503#issuecomment-67701462
383 2014-12-19 21:39:59 <kanzure> (re: fundmany)
384 2014-12-19 21:40:46 <sipa> what the hell would that do?
385 2014-12-19 21:40:59 <sipa> fund multiple transactions at once?
386 2014-12-19 21:41:07 <kanzure> batch coin selection
387 2014-12-19 21:41:26 <sipa> batch what?
388 2014-12-19 21:41:35 <kanzure> sorry, i thought this would be more obvious, but i'm working from prior bitcoin-dev logs, so i figured i should write this down on the issue instead
389 2014-12-19 21:42:03 <sipa> i don't see what is there to batch, but maybe i'm missing something
390 2014-12-19 21:42:17 <sipa> maybe you're assuming it does something else then me (i haven't checked the code)
391 2014-12-19 21:42:23 <kanzure> you can have many unfunded transactions and want to plan output spending all at once
392 2014-12-19 21:42:57 <sipa> oh
393 2014-12-19 21:43:04 <sipa> that's so obvious, why did i miss it?
394 2014-12-19 21:43:05 <kanzure> instead of planning individually, which might get into some weirdo local minima or something
395 2014-12-19 21:43:44 <gmaxwell> I don't see the advantage there, actually. Write one transaction, not multiple. Or merge them before funding.
396 2014-12-19 21:44:01 <kanzure> in my case i have multiple unfunded transactions that are not related to each other
397 2014-12-19 21:44:10 <gmaxwell> so? merge them.
398 2014-12-19 21:44:27 <kanzure> that could compromise privacy
399 2014-12-19 21:44:33 <gmaxwell> the txout is what someone gets paid. it wouldn't change the txout.
400 2014-12-19 21:44:41 <kanzure> that *does* compromise privacy, rather
401 2014-12-19 21:44:50 <gmaxwell> kanzure: doesn't follow for me, the joint coin selection (and shared coin pool) almost certantly does already.
402 2014-12-19 21:45:06 <kanzure> i am not implementing coinjoin. i was actually routing old comments you made to me about batched coin selection.
403 2014-12-19 21:45:26 <gmaxwell> yea, batching is good, but I don't see why it's useful at the funding stage.
404 2014-12-19 21:45:38 <kanzure> funding chooses different unspents, right?
405 2014-12-19 21:46:05 <gmaxwell> E.g. batching done as create merge fund makes sense. But batching that doesn't merge the transactions is of reduced value. (doesn't save on the creation of change outputs, for example)
406 2014-12-19 21:46:51 <kanzure> if you know the full set of transactions you are making (for the moment) then you can make better decisions about which unspents to use when funding each transaction in the set
407 2014-12-19 21:47:03 <kanzure> i agree that you don't save on change addresses
408 2014-12-19 21:47:18 <sipa> or it could use one's transaction change output in another input
409 2014-12-19 21:47:31 <kanzure> deliberately? or unintentionally ?
410 2014-12-19 21:47:50 <sipa> deliberately
411 2014-12-19 21:48:26 <sipa> imagine you have 2 coins, and need to send 3 transactions; the normal model of fund -> lock -> spend -> unlock doesn't work with a batch
412 2014-12-19 21:48:49 <sipa> but it seems perfectly fine (oh wait, malleability) to do this for multiple transactions at once
413 2014-12-19 21:48:54 <sipa> never mind
414 2014-12-19 21:49:20 <kanzure> that's an okay argument for saying "this function should *not* use the created change addresses as inputs in the other transactions in the batch" :)
415 2014-12-19 21:49:41 <gmaxwell> kanzure: in any case, I think a real batch (e.g. result in a single transaction) is just a lot more interesting, as it can radically reduce the amount of transaction data you need.
416 2014-12-19 21:50:00 <sipa> well i can imagine not wanting to mix certain transactions
417 2014-12-19 21:50:02 <kanzure> "result in a single transaction" methinks we might have a different definition of batch
418 2014-12-19 21:50:06 <gmaxwell> and most of that savings comes from having fewer total signatures (as the fewest signatures a transaction can have is one)
419 2014-12-19 21:50:23 <sipa> in a perfect system, where there was no address reuse and much better prviacy overall, you'd merge everything you got
420 2014-12-19 21:50:25 <gmaxwell> sipa: where that happens you probably don't want to mix the walllet.
421 2014-12-19 21:50:53 <gmaxwell> (also a merged up transaction looks superficially like a coinjoin in any case)
422 2014-12-19 21:50:53 <kanzure> my use case is offline signing of withdrawals from a service
423 2014-12-19 21:50:53 <sipa> like what if you're paying to two competitors, who each have public static addresses?
424 2014-12-19 21:51:08 <kanzure> (without reimplementing coin selection)
425 2014-12-19 21:51:22 <gmaxwell> kanzure: great but why are you not batching the withdrawls? (analogous to sendmany)
426 2014-12-19 21:51:23 <kanzure> (i mean, i could reimplement coin selection, but only if i have to)
427 2014-12-19 21:52:24 <kanzure> what is your definition of batch here?
428 2014-12-19 21:53:03 <gmaxwell> logically doing what a sendmany does, if you ignore the offline and having to know upfront who you'll be paying.
429 2014-12-19 21:53:16 <gmaxwell> It's a preexisting norm in bitcoin that services pay people with sendmanys.
430 2014-12-19 21:56:09 <kanzure> sipa's answer sounds like a good reason to me for not using a single transaction
431 2014-12-19 21:57:14 <gmaxwell> It's not.
432 2014-12-19 21:57:30 <sipa> well it's the result of a broken system
433 2014-12-19 21:57:44 <gmaxwell> If you're trying to be private, you already failed.. because you'll end up e.g. using coins paid to the same address to sign for each of your seperate transactions already.
434 2014-12-19 21:58:18 <sipa> hmm, agree
435 2014-12-19 21:58:21 <sipa> indeed
436 2014-12-19 21:58:26 <gmaxwell> (or on prior transactions which spent coins which paid to the same addresses as any of the coins in your new ones)
437 2014-12-19 21:58:42 <sipa> yeah, you can't prevent linkage
438 2014-12-19 21:58:46 <sipa> when using one wallet
439 2014-12-19 21:59:13 <gmaxwell> Already past history from address reuse and co-spending is incredibly deanonymizing unless you assume people are widely performing coinjoins. (in which case, a sendmany also mostly looks like a coinjoin)
440 2014-12-19 21:59:30 <gmaxwell> You can reduce the leakage, and we do some,, and could do more. But right. Cannot be prevented.
441 2014-12-19 22:01:57 <kanzure> okay, sounds like you would have to track which inputs you are using to a degree that would involve lots of work and, likely rejection during review anyway
442 2014-12-19 22:02:33 <kanzure> e.g., a flag to tell fundmany not to select coins from the same transaction, or even something more aggressive about looking at transaction history, which quickly becomes infeasible, and besides you don't want it to croak on failure even if you have the right funds but "not enough privacy" or w/e
443 2014-12-19 22:02:43 <kanzure> okay. thanks.
444 2014-12-19 22:02:57 <sipa> kanzure: so, solution, if you want this: implement multiwallet
445 2014-12-19 22:03:15 <kanzure> right, i am trying to decide if i do want this at all
446 2014-12-19 22:03:37 <kanzure> specifically my question is "whether or not i feel there is a qualitative difference between a single giant transaction, and a series of transactions that could be linked together by some careful analysis"
447 2014-12-19 22:03:56 <sipa> the point is that individual tracking requires micromanagement
448 2014-12-19 22:04:02 <gmaxwell> There is certantly a postive advantage: the single transaction can be _much_ smaller than the total of many smaller ones.
449 2014-12-19 22:04:51 <kanzure> well, i was thinking in terms of "privacy benefits of many smaller transactions", and whether or not the "benefit" is greater than the benefit of not implementing my own coin selection or the benefit of not paying for many tiny individual transactions
450 2014-12-19 22:05:44 <gmaxwell> e.g. 89 bytes per marginal output all seperate vs 32 bytes per marginal output.
451 2014-12-19 22:06:51 <gmaxwell> kanzure: the seperate transactions will pretty reliably be linkable if there is any address reuse at all, and somewhat linkable even if not (if jagged coins allow for reliable change following)
452 2014-12-19 22:07:59 <kanzure> oh right, forward-looking change reuse after-the-fact