1 2014-12-09 00:00:55 <sipa> also, clang is even faster
2 2014-12-09 00:04:36 <Luke-Jr> sipa: the output, or the compile time?
3 2014-12-09 00:04:45 <sipa> the generated code
4 2014-12-09 00:05:08 <sipa> Luke-Jr: to be clear: my benchmark is ecdsa verification time
5 2014-12-09 00:05:10 <Luke-Jr> like around the assembly?
6 2014-12-09 00:05:29 <Luke-Jr> or is it generating different code for the asm?
7 2014-12-09 00:05:40 <sipa> no, due to other parts of the code
8 2014-12-09 00:10:26 <Luke-Jr> I'm tempted to setup a few chroots to compare amd64 vs x32 performance
9 2014-12-09 00:10:35 <Luke-Jr> (in theory, x32 is supposed to be faster)
10 2014-12-09 00:13:04 <Luke-Jr> actually, I shouldn't need to compile much to test this, so might as well
11 2014-12-09 00:14:56 <Luke-Jr> wow, x32 stage3 hasn't been updated since May
12 2014-12-09 00:15:14 <Luke-Jr> ACTION wonders if the project has stagnated
13 2014-12-09 01:10:45 <sipa> wumpus: https://github.com/sipa/secp256k1/commit/c3557c58580f7bab7e08aea8c315891efa59b9b5
14 2014-12-09 01:12:01 <sipa> wumpus: it has 3 temp variables which are defined outside of the asm block (and may thus be allocated by the compiler inside the red zone), and references to them are substituted by relative memory addresses (typically relative to the stack or base pointer, which the asm code itself doesn't touch)
15 2014-12-09 01:12:20 <sipa> look for %1, %2 and %3 in the code
16 2014-12-09 01:20:01 <lechuga_> sipa: OT but does your blockstream bio imply you play discgolf?
17 2014-12-09 01:20:12 <sipa> no
18 2014-12-09 01:32:01 <gmaxwell> sipa plays ulitmate frisbee and pool-frisbee.
19 2014-12-09 01:32:50 <sipa> haha
20 2014-12-09 01:33:53 <lechuga_> :)
21 2014-12-09 01:48:36 <rusty> Gah! My "corpus" of transactions was from test-net. In other news, I am an idiot.
22 2014-12-09 03:45:28 <b-itcoinssg> question regarding sidechains; Does the Wuille et al. implementation require the sidechain to be secured only by sha256 hashing? and if so does a separate group of dedicated miners have to perform the proof of work or can you merge mine etc?
23 2014-12-09 04:00:30 <rusty> b-itcoinssg: there's an implementation?
24 2014-12-09 04:00:59 <b-itcoinssg> rusty: I meant the proposed implementation on the white paper.
25 2014-12-09 04:06:10 <rusty> b-itcoinssg: they mention the receiving sidechain evaluating the work, with the strong implication taht they're both using the same hashing algo. I expect we'll see merge mining and SHA256(SHA256()).
26 2014-12-09 04:08:58 <b-itcoinssg> rusty: right, so within that proposed implementation, there isn't a clear way to incorporate another proof of work for the sidechain right?
27 2014-12-09 04:09:29 <b-itcoinssg> rusty: I'm just trying to wrap my head around it, not a criticism per say.
28 2014-12-09 04:10:02 <rusty> b-itcoinssg: there's nothing stopping it either. The discussion paper is a long way from am actual BIP.
29 2014-12-09 04:10:17 <b-itcoinssg> rusty: i see
30 2014-12-09 04:11:19 <rusty> b-itcoinssg: as long as whatever rules go into the new bitcoin sidechain operator can understand the sidechain, it'd work. In practice, this probably means the sidechain has to look a lot like bitcoin.
31 2014-12-09 04:12:09 <rusty> b-itcoinssg: since bitcoin clients would have to evaluate the PoW for the sidechain, I think there'd be some pressure against other PoWs.
32 2014-12-09 04:14:07 <amiller> IMO there's gonna be equal interest in merge-mined sidechains and non-merge mine side chains with incompatible pow
33 2014-12-09 04:15:11 <amiller> the proposed implementation seems oblivious to whether it's merge mined or not
34 2014-12-09 04:15:15 <rusty> amiller: that may be true, but I expect that's going to be an interesting debate for every new pow.
35 2014-12-09 04:15:39 <amiller> probably
36 2014-12-09 04:17:22 <rusty> amiller: it's not detailed enough to tell. You need to know if it's merge mined, because you need to evaluate a tx proof. There are also many other possible variants (such as including the fee amount in the hash), but expect sidechains will just have carry a bitcoin-like merkle tree.
37 2014-12-09 04:18:27 <amiller> yeah, i guess there are a lot of possible variants
38 2014-12-09 04:18:31 <b-itcoinssg> amiller: With reference to non-merge mined; I may be reading it wrong, by doesn't the proposed implementation in the whitepaper only discuss scenarios where the proof of work is directly compatible i.e sha256. I understand, that as rusty pointed out, this is not set in hard stone and can/will be changed later. Just trying to clarify whether I'm reading the
39 2014-12-09 04:18:31 <b-itcoinssg> paper right.
40 2014-12-09 04:20:31 <amiller> i guess the options are: a) SHA2 merge mined, b) SHA2 but *not* merge mined, c) other than SHA2 and not merge mined
41 2014-12-09 04:20:56 <b-itcoinssg> amiller: ok
42 2014-12-09 07:20:09 <wumpus> cfields: no, nothing big happened, there were some small issues with travis and the build system, but apart from that the big problems (such as the 0.10 release) neatly waited until you were back
43 2014-12-09 07:20:15 <wumpus> cfields: :P
44 2014-12-09 07:50:07 <wumpus> sipa: I don't understand this gcc asm syntax, in eg secp256k1_fe_mul_inner, how does anything end up in %rsi?
45 2014-12-09 07:52:13 <wumpus> this must be due to "+S"(a) in the output operands at the end, but why does this choose %rsi?
46 2014-12-09 08:23:01 <berndj> wumpus, gcc inline assembler has register class constraints for inputs/outputs; i'm pretty sure 'S' is the register class consisting of just %rsi
47 2014-12-09 08:23:23 <wumpus> berndj: thanks
48 2014-12-09 08:25:28 <wumpus> berndj: couldn't find that in the gcc documentation but thanks to you providing the name for it I did now https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html#Machine-Constraints
49 2014-12-09 08:25:43 <wumpus> now it's time to write an ARM version, I suppose <:
50 2014-12-09 08:26:24 <berndj> 'S' seems to be something else in x86_64 :-/
51 2014-12-09 08:27:16 <berndj> it's %esi in x86 (32-bit)
52 2014-12-09 08:29:41 <wumpus> I only found "Intel 386âconfig/i386/constraints.md", nothing specific about x86_64?
53 2014-12-09 08:31:31 <berndj> *facepalm* i saw IA-64 right after i386 and brainfarted it into x86_64. sorry
54 2014-12-09 08:31:45 <wumpus> hehe yes those are easy to confuse
55 2014-12-09 08:40:51 <Cryo> mmm itanic
56 2014-12-09 10:16:25 <sipa> wumpus: S == rsi, D = rdi, d = rdx
57 2014-12-09 10:21:46 <b-itcoinssg> what is the cli or rpc command to list all address for which the core client has private keys for?
58 2014-12-09 10:54:50 <sipa> b-itcoinssg: re: sidechains: how the sidechain is mined is orthogonal to how the peg mechanism is secured; it can be independently mined or merged-mined (though the parent chain needs to understand its proof-of-work, and it's pretty unreasonable to add opcodes to bitcoin to understand Scrypt PoW)
59 2014-12-09 10:56:36 <sipa> b-itcoinssg: no such RPC afaik; you may get far with dumpwallet (which dumps all addresses including the private keys to a text file)
60 2014-12-09 10:56:44 <b-itcoinssg> sipa: that is what I gathered from your paper.
61 2014-12-09 10:57:24 <b-itcoinssg> sipa: so would you agree that the PoW for the side chain has to be sha256 ish ?
62 2014-12-09 10:57:43 <blur3d> what about listreceivedbyaddress with minconf=0 and includeempty=true
63 2014-12-09 10:57:49 <sipa> b-itcoinssg: s/has to be/will likely need to be/
64 2014-12-09 10:58:04 <b-itcoinssg> sipa: got it
65 2014-12-09 10:58:18 <sipa> b-itcoinssg: it all depends on exactly what gets accepted into bitcoin (if we're talking about sidechains to bitcoin)
66 2014-12-09 10:59:40 <b-itcoinssg> blur3d: I'll try that. thanks
67 2014-12-09 10:59:56 <blur3d> âTo get a list of accounts on the system, execute bitcoind listreceivedbyaddress 0 trueâ https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list#Listing_my_bitcoin_addresses
68 2014-12-09 11:00:07 <gmaxwell> Keep in mind that the sidechain pegging mechenism could be applied recursively.
69 2014-12-09 11:01:18 <b-itcoinssg> gmaxwell: can you explain that a little more?
70 2014-12-09 11:02:16 <gmaxwell> b-itcoinssg: a pegged sidechain could have pegged sidechains. So the proof interpertation doesn't have to necessairly be maximally flexible at the top.
71 2014-12-09 11:02:33 <b-itcoinssg> blur3d: That worked perfectly, thanks
72 2014-12-09 11:03:08 <b-itcoinssg> gmaxwell: ah I see
73 2014-12-09 11:03:32 <blur3d> b-itcoinssg: nps
74 2014-12-09 16:04:46 <jonasschnelli> sipa, why no default header count when requesting /rest/headers/<hash> ? could be 1 or 2000? but yes. it's luxury. :)
75 2014-12-09 16:05:01 <sipa> jonasschnelli: because aliasing
76 2014-12-09 16:05:36 <jonasschnelli> agreed
77 2014-12-09 16:05:38 <sipa> different URLs for the same data; better stick to one strict case; anything else just means more overhead to support later and unclarity about what the actual syntax is
78 2014-12-09 16:05:45 <sipa> and it can interfere with caching
79 2014-12-09 16:06:38 <jonasschnelli> okay... and the wording is also more clear, headers=plural (in case we would deliver 1 header)
80 2014-12-09 16:55:22 <sipa> cfields: seems secp256k1's configure incorrectly detects the availability of -lcrypto when compiling with -m32; any ideas?
81 2014-12-09 17:28:30 <Luke-Jr> sipa: https://github.com/bitcoin/secp256k1/pull/152 - also, please add it to #bitcoin-commits when you get a chance? ;)
82 2014-12-09 17:32:57 <sipa> Luke-Jr: i can do that? :o
83 2014-12-09 17:32:58 <Luke-Jr> sipa: don't you have admin on the repo?
84 2014-12-09 17:33:30 <Luke-Jr> https://github.com/bitcoin/secp256k1/settings/hooks
85 2014-12-09 17:33:33 <Luke-Jr> Add Service->IRC
86 2014-12-09 17:34:35 <sipa> Luke-Jr: can you rebase on top of 142 (and check that it still works there)
87 2014-12-09 17:34:57 <sipa> Luke-Jr: heh, i assumed it was through some bot of yours
88 2014-12-09 17:40:51 <Luke-Jr> sipa: fwiw, GitHub should *not* join the channel (it
89 2014-12-09 17:40:56 <Luke-Jr> (it does so every commit)
90 2014-12-09 17:47:12 <Luke-Jr> sipa: rebased x32 and fixups
91 2014-12-09 17:48:58 <sipa> added irc hook; let's see what happens
92 2014-12-09 18:18:40 <cfields> sipa: yea, i ran into that last night. taking a look today
93 2014-12-09 18:22:08 <cfields> sipa: as for why the objects are built twice for the lib, that was just a cheat to get it done. there's not currently a good way to split the consensus files for reuse in the other binaries (making a convenience lib out of it, i mean). I'm hoping it may end up that way eventually, but imo it's not a terrible burden as-is
94 2014-12-09 18:22:24 <sipa> right
95 2014-12-09 18:25:01 <cfields> also, it's kinda nice to have them separated so we can give different flags. there's a discussion in a PR somewhere about adding much stricter warnings to libs, which is a really good idea imo
96 2014-12-09 18:28:15 <sipa> yup
97 2014-12-09 21:24:49 <tdlfbx> Is the operator of bitcoinstats.com here? Can you tell me how this: http://bitcoinstats.com/network/propagation/ is measured? Are you just running a node and looking at the local clock? Or is this info extracted from the blockchain?
98 2014-12-09 21:27:10 <hearn> tdlfbx: local clock (i don't run it but i know the guy who does)
99 2014-12-09 21:27:46 <tdlfbx> hearn: Thanks!
100 2014-12-09 21:30:34 <tdlfbx> Any idea why the 90th percentile is so much larger than the 50th? I would have expected roughly that you can double the number of reached hosts by doubling the time.
101 2014-12-09 21:31:07 <hearn> latency distributions usually have long tails
102 2014-12-09 21:31:56 <tdlfbx> Can anything be done to reach all nodes quicker at the 90th percentile?
103 2014-12-09 21:32:31 <phantomcircuit> there are nodes running over satelite links and weird things
104 2014-12-09 21:32:33 <phantomcircuit> no
105 2014-12-09 21:32:33 <phantomcircuit> so
106 2014-12-09 21:33:52 <tdlfbx> A satellite link is ~500ms and that should be a minority. If 90th percentile was shifted by ~500ms I think "satellites" would be an explanation. But it's different by 5x the 50th percentile. (???)
107 2014-12-09 21:34:45 <phantomcircuit> tdlfbx, they're often much much worse than that
108 2014-12-09 21:34:46 <hearn> tdlfbx: the answer is we don't know why it's like that. latency tail analysis is something quite tricky even in well controlled systems, which bitcoin isn't
109 2014-12-09 21:35:06 <hearn> tdlfbx: to analyse why the latency tail is so large we'd need, at minimum, way more stats being exported over p2p
110 2014-12-09 21:35:26 <tdlfbx> ACTION has been contemplating adding "stats" to block headers...
111 2014-12-09 21:36:07 <hearn> to block headers?
112 2014-12-09 21:36:08 <tdlfbx> e.g. receipt times of the last 10 blocks, or something.
113 2014-12-09 21:36:13 <tdlfbx> yeah
114 2014-12-09 21:36:21 <hearn> that wouldn't make any sense. there's no need for this data to be in the block chain
115 2014-12-09 21:36:28 <hearn> you can just have a "stats?" message in p2p
116 2014-12-09 21:36:33 <tdlfbx> True.
117 2014-12-09 21:36:35 <hearn> then write a crawler for it
118 2014-12-09 21:39:19 <tdlfbx> It would be really interesting to find which nodes are causing the long tail, and see if anything can be done about it.
119 2014-12-09 21:39:39 <ajweiss> has anyone ever attempted to write down a "minimum network requirements" for bitcoin core?
120 2014-12-09 21:40:34 <tdlfbx> Not that I've seen, I've been asking a lot. There are a lot of arbitrary numbers in bitcoin. Alts have screwed with most of them, with little justification.
121 2014-12-09 21:42:23 <phantomcircuit> ajweiss, 1MB/10 minutes
122 2014-12-09 21:42:31 <phantomcircuit> actually
123 2014-12-09 21:42:36 <phantomcircuit> 1+MB/10 minutes
124 2014-12-09 21:42:42 <phantomcircuit> otherwise you'd potentially never catch up
125 2014-12-09 21:43:03 <ajweiss> yeah i've considered the implicit limit there
126 2014-12-09 21:43:20 <tdlfbx> In terms of bandwidth yeah but what's the impact of latency?
127 2014-12-09 21:44:03 <lechuga_> you can plug in latency and loss and determine when tcp will fail to achieve 1MB/10min
128 2014-12-09 21:45:30 <ajweiss> i suppose, but i've been under the impression that a lot of high latency links (satellite, radio, etc) do some monkeying with tcp to keep their pipes full even in the face of slow acks
129 2014-12-09 21:46:58 <ajweiss> i've seen t-mobile's network play weird games where i've gotten unrealistic icmp ping times for the first few pings, and then a stabilization at hundreds of ms more after a few rounds
130 2014-12-09 21:48:30 <phantomcircuit> tdlfbx, latency is technically meaningless as long as it's <10 minutes
131 2014-12-09 21:49:38 <phantomcircuit> (with the current tcp p2p protocol there is a practical bound on latency because single connection tcp bandwidth is limited by latency, but this is not a fundamental limit of the design)