1 2014-02-17 00:44:22 <ibtc> Is there any set time for the next release?
2 2014-02-17 00:58:37 <gmaxwell> when the did -blockmaxsize= get increased? my nodes here were just choking with >1s gbt latency trying to mine a 750k block.
3 2014-02-17 01:00:13 <maaku> andytoshi: "Next, because Mt. Gox would not notice the withdrawals, they could request that the withdrawal
4 2014-02-17 01:00:14 <maaku> be reprocessed, and Gox would automatically do so."
5 2014-02-17 01:00:27 <maaku> ^^ change the first "they" to "the customer" (pronoun overload)
6 2014-02-17 01:01:07 <upb> äo/l andy
7 2014-02-17 01:01:35 <sipa> gmaxwell: recently
8 2014-02-17 01:02:56 <andytoshi> thx maaku
9 2014-02-17 01:04:43 <gmaxwell> https://blockchain.info/block-index/468173/0000000000000000ea0e035185296a8aa9288bd0bbe3f0298330beda173fdd71 < some pretty interesting utxo cleanup txn in this block.
10 2014-02-17 01:06:34 <gmaxwell> several tx with almost 600 txin.
11 2014-02-17 01:06:41 <maaku> andytoshi: also "This can also cause the available balance display to be incorrect" <-- I would clarify this to make certain to the reader that only the display is affected, not the actual spendable balance
12 2014-02-17 01:10:07 <andytoshi> maaku: i will add after that sentence, "To be clear, this is purely a display bug; there is no loss (or even potential loss) of funds."
13 2014-02-17 01:43:06 <maaku> andytoshi: sounds good
14 2014-02-17 01:44:51 <btiefert> I just wrote a quit perl script that counts how many unique client/versions my bitcoind has peered with. I should be able to provide some meaningful demographics soon.
15 2014-02-17 01:45:04 <btiefert> quick* perl script.
16 2014-02-17 01:47:27 <maaku> so the SIGHASH_ALL normative/canonical ID would allow coinbase transactions to have the same "ntxid", correct?
17 2014-02-17 01:48:10 <maaku> I can't think of any problems this causes at the moment, but it's a hidden gotcha
18 2014-02-17 01:50:45 <gmaxwell> there are a lot of hidden gotchas on ntxid.
19 2014-02-17 02:14:31 <davvblack> Is there a style guide for the reference client? Or rather, does it adhere to something particular?
20 2014-02-17 02:25:28 <Luke-Jr> davvblack: imitate what's there, makes a good general rule
21 2014-02-17 02:30:19 <andytoshi> someone is asking on #bitcoin how git HEAD handles spends of invalidated change
22 2014-02-17 02:30:51 <davvblack> Doesn't the current head get confused? And show the value twice?
23 2014-02-17 02:31:50 <davvblack> Part of the hotfix is to make unconfirmed change unspendable
24 2014-02-17 02:32:00 <davvblack> which kind of sidesteps the issue
25 2014-02-17 02:36:01 <gmaxwell> davvblack: it doesn't make it unspendable, there is an option so you can choose and it defaults to on.
26 2014-02-17 02:36:32 <gmaxwell> It also makes it not spend change which is already doomed (where a conflicting txid has been confirmed) which prevents the problem from snowballing once it has happened.
27 2014-02-17 03:46:12 <ajoul> so much trouble to install and run bitcoind
28 2014-02-17 03:46:30 <ajoul> my fucking balls are about to explode, I think something is wrong with my hardware because neither my windows or ubuntu can run this shit
29 2014-02-17 03:46:39 <ajoul> I was having problem running openCL on my computer too
30 2014-02-17 03:46:45 <ajoul> so much bullshit mate
31 2014-02-17 03:46:48 <ajoul> anyone can help?
32 2014-02-17 03:49:22 <ibtc> ajoul running bitcoind on windows is as simple as just starting bitcoind.exe
33 2014-02-17 03:49:58 <davvblack> What problem are you having specifically?
34 2014-02-17 04:51:47 <Moon_Man> How do I start bitcoin on osx with the -rescan flag?
35 2014-02-17 05:06:16 <toffoo> Moon_Man type this in Terminal: /Applications/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt -rescan
36 2014-02-17 05:09:10 <Moon_Man> toffoo: Cool, it's working. Is it normal for the process to become unresponsive? It's using a ton of CPU.
37 2014-02-17 05:09:38 <Moon_Man> And how long would it usually take?
38 2014-02-17 05:10:42 <toffoo> yes. i think at least a few hours, depends how fast your system is
39 2014-02-17 05:11:56 <Moon_Man> toffoo: Alright, I'll leave it overnight. So if it becomes unresponsive i just leave it alone?
40 2014-02-17 05:12:03 <Moon_Man> Don't try and quit the process and start again?
41 2014-02-17 05:12:29 <toffoo> right, just leave it
42 2014-02-17 05:12:36 <Moon_Man> Gotcha.
43 2014-02-17 05:12:39 <Moon_Man> Thakns
44 2014-02-17 05:12:43 <Moon_Man> Thanks*
45 2014-02-17 06:29:17 <michagogo> cloud|Moon_Man: a rescan will appear to just hang, yes
46 2014-02-17 06:29:31 <michagogo> cloud|But the time it takes should be on the order of minutes
47 2014-02-17 06:29:33 <michagogo> cloud|Not hours
48 2014-02-17 06:49:18 <agentOrange> hey steve!
49 2014-02-17 06:49:59 <Lasseter> lol
50 2014-02-17 07:35:42 <freewil> can someone update the link in the github description on bitcoin/bitcoin to use ssl
51 2014-02-17 07:51:14 <wumpus> freewil: sure
52 2014-02-17 07:52:47 <freewil> wumpus: thanks
53 2014-02-17 08:24:33 <Datavetaren> @gmaxwell: Why not canonicalize/normalize signatures on relayed traffic? Wouldn't that be a good half step towards a 100% solution? Or is it too risky?
54 2014-02-17 08:35:46 <maaku> Datavetaren: that's worse than doing nothing. you''d be actively breaking other people's protocols
55 2014-02-17 08:36:40 <maaku> that may even be what initially got us in this mess (someone accidentally not preserving round-trip serialization during relay)
56 2014-02-17 08:39:20 <Datavetaren> Maaku: How can it be worse by _only_ converting (r, -(s mod N)) into (r, (s mod N)) (leaving everything else unchanged)? If I understand correctly, the bitcoind client broadcasts canoncalized signatures (r, (s mod N)); never the negative.
57 2014-02-17 08:39:47 <sipa> Datavetaren: there are more bitcoin clients
58 2014-02-17 08:40:00 <maaku> Datavetaren: because you'd be mallating other people's transactions
59 2014-02-17 08:40:11 <maaku> that's exactly what's causing headaches for so many people right now
60 2014-02-17 08:40:43 <Datavetaren> maaku: Mallaebility is already a problem and has to be dealt with already. This is just steering towards a path where malleability will be eliminated (long term)
61 2014-02-17 08:41:11 <sipa> it will be eliminates long term
62 2014-02-17 08:41:34 <Datavetaren> sipa: Yes, I know... there are few items left on the list to be implemented. 1 and 6.
63 2014-02-17 08:41:50 <maaku> but not by purposefully mutating people's transactions.
64 2014-02-17 08:42:06 <maaku> not relaying is safer than not mutating
65 2014-02-17 08:42:08 <sipa> but making the experience worse for large part of the ecosystem in the short term may have worse repercussions
66 2014-02-17 08:42:58 <Datavetaren> maaku: But you can always have "evil" nodes that could mutate relayed transactions anyway; so it's a problem that you just have to be aware with.
67 2014-02-17 08:43:39 <wumpus> mutating the relayed transactions to canonical form would effectively be a DoS against some clients, on a much larger scale than the current one
68 2014-02-17 08:44:22 <maaku> Datavetaren: yes but you deal with the problem by making it hard to get non-canonical transactions on the chain, then making it impossible (soft-fork)
69 2014-02-17 08:44:32 <maaku> you *don't* go about mutating other people's transactions
70 2014-02-17 08:44:35 <maaku> that does harm
71 2014-02-17 08:44:54 <wumpus> the solution would be to forbid the non-canonical forms but *after* all clients creating them are fixed
72 2014-02-17 08:46:14 <Datavetaren> wumpus, maaku: Ok, you've convinced me. It sounds that the current approach is the better one.
73 2014-02-17 08:46:57 <wumpus> (on the other hand some may be too slow, mtgox never fixed their DER padding even though they knew 0.8 started rejecting it)
74 2014-02-17 08:48:00 <Datavetaren> wumpus: I know, but hopefully custom bitcoin nodes will learn a lesson and be more reactive next time. I understand that bitcoin core dev is trying to push custom wallets to stay in sync with the new rules.
75 2014-02-17 08:48:53 <Datavetaren> wumpus: MtGox got wacked because they just didn't care (spending immature coins, etc.) and then ignoring the DER encoding.
76 2014-02-17 08:49:03 <wumpus> yes it should be documented in a BIP what the canonical form is so wallets can prepare
77 2014-02-17 08:50:16 <maaku> wumpus: I think the sad reality is that we can't wait for all wallets to be fixed
78 2014-02-17 08:51:39 <Datavetaren> maaku: That's reality, but hopefully custom wallets will be more reactive next time. Important changes (like enforcing DER encoding) should also be broadcasted somehow so anyone with custom wallets become aware. Ideally on CNN, but that's not going to happen anytime soon :)
79 2014-02-17 08:52:44 <wumpus> Datavetaren: releasing a BIP and posting on the mailing list should be enough
80 2014-02-17 08:53:10 <maaku> Datavetaren: hopefully people will take it more seriously after this experience
81 2014-02-17 08:53:28 <Datavetaren> wumpus: I know it should be enough, but unfortunately it isn't.
82 2014-02-17 08:54:05 <maaku> the 0.8 change was well announced, and people even did some sleuthing to track down the offenders (e.g. blockchain.info) and get them to change their code
83 2014-02-17 08:54:05 <wumpus> Datavetaren: why not?
84 2014-02-17 08:54:14 <wumpus> maaku: exactly
85 2014-02-17 08:54:51 <Datavetaren> wumpus: I fear that most custom wallets clone the bitcoin source code and then "forget" about it; they don't read the github comments every day.
86 2014-02-17 08:55:22 <wumpus> Datavetaren: they should read the mailing list, it is general and spans implementations
87 2014-02-17 08:55:37 <wumpus> obviously they don't need to follow all github comments
88 2014-02-17 08:55:53 <Datavetaren> maaku, wumpus: Well, after this experience I think all custom clients will be more careful. Especially the big ones.
89 2014-02-17 08:55:56 <maaku> I don't follow all the github comments
90 2014-02-17 08:56:10 <maaku> but if you're writing wallet software, you should be on the bitcoin-development list, period
91 2014-02-17 08:56:12 <sipa> Datavetaren: if most wallets cloned bitcoind, we wouldn't have non-der pushes ever
92 2014-02-17 08:56:22 <maaku> it'd be irresponable not to
93 2014-02-17 08:56:50 <sipa> my experience is quite the opposite: people hate reading code, so they reimplement everything
94 2014-02-17 08:57:01 <sipa> even the parts that don't need reimplementation
95 2014-02-17 08:57:06 <Datavetaren> maaku: Yes, you just proved MtGox was irresponsible, or they did read didn't care :)
96 2014-02-17 08:57:57 <wumpus> they see reimplementing as a way of learning, which is okay, but it doesn't mean that you should use your own 'educational' version in production... certainly not for an exchange :p
97 2014-02-17 08:58:00 <Datavetaren> sipa: I certainly didn't. There are some problematic aspects in the bitcoin client (SelectCoins() is not particularily efficient), but I made my changes so it is relatively easy to merge in changes.
98 2014-02-17 09:00:16 <Datavetaren> Anyway, thanks for chatting with you all. Need to get back to "normal" work :)
99 2014-02-17 09:43:31 <Aurigae> hi guys, what does make vs make -f ?
100 2014-02-17 09:44:46 <wumpus> try: man make
101 2014-02-17 09:45:39 <Aurigae> i just want to know what it does, im currently setting up a multi qt client node. I have compiled all the clients yesterday but had dependency conflicts, so i have to do it all again, each qt client seems to have different build commands
102 2014-02-17 09:45:58 <Aurigae> currenltly fiddleing with namecoin
103 2014-02-17 09:46:38 <Aurigae> i thought to remember the command for ubuntu 12.04 is "make -f upnp=-" to build without upnp
104 2014-02-17 09:46:54 <Aurigae> google isnt that cooperative right now
105 2014-02-17 09:47:38 <wumpus> google is always uncoorporative if you try to search for -x, as it will interpret -x as 'exclude x'
106 2014-02-17 09:47:46 <wumpus> that's why I suggested the man page
107 2014-02-17 09:47:51 <Aurigae> i now operators very will
108 2014-02-17 09:47:58 <Aurigae> "-x" wourld solve that
109 2014-02-17 09:48:22 <Aurigae> brackets tell google to search exactly whats in brackets
110 2014-02-17 09:49:18 <Aurigae> ill get there, its just a lot time for searching xd
111 2014-02-17 09:51:09 <Aurigae> got it ..
112 2014-02-17 09:51:12 <Aurigae> The way to specify the name of the makefile is with the `-f' or `--file' option (`--makefile' also works). For example, `-f altmake' says to use the file `altmake' as the makefile.
113 2014-02-17 09:51:26 <Aurigae> http://www.chemie.fu-berlin.de/chemnet/use/info/make/make_9.html
114 2014-02-17 10:04:37 <Aurigae> http://pastebin.com/0jwTwHft recompiled namecoind but still same problem - namecoind running but cant connect to server on ./namecoind getinfo or any other command
115 2014-02-17 10:04:51 <Aurigae> cant even stop it
116 2014-02-17 10:05:41 <Aurigae> solved, lol
117 2014-02-17 10:05:45 <Aurigae> ...
118 2014-02-17 10:06:02 <Aurigae> added too much nodes to the conf
119 2014-02-17 10:21:25 <anddam> when is approximately 0.9.0 likely to be released?
120 2014-02-17 10:21:43 <anddam> released-ly
121 2014-02-17 10:21:49 <michagogo> cloud|anddam: When someone says "Okay, I think we're ready" and others agree
122 2014-02-17 10:21:51 <anddam> make it more adverbish-ish
123 2014-02-17 10:22:04 <anddam> Okay, I think we're ready
124 2014-02-17 10:22:05 <sipa> "soon, but not too soon"
125 2014-02-17 10:22:17 <michagogo> cloud|Also, there will be at least an 0.9.0rc2
126 2014-02-17 10:22:24 <sipa> we already had 0.9.0rc1, but the malleability issues slow things down a bit now
127 2014-02-17 10:22:32 <michagogo> cloud|^
128 2014-02-17 10:25:12 <akakak> Is blockchain.info undergoing maintenance?
129 2014-02-17 10:25:35 <jeremias> don't know really
130 2014-02-17 10:28:16 <michagogo> cloud|akakak: not afaik. Why?
131 2014-02-17 10:29:07 <akakak> was having some connectivity issues. I looked at their block, looks like they had some downtime.
132 2014-02-17 10:29:18 <akakak> ...not sure if it's over.
133 2014-02-17 10:29:35 <jeremias> they announced some downtime earlier
134 2014-02-17 10:30:25 <akakak> I'm guessing they are implementing the new normalized ID index
135 2014-02-17 10:36:22 <Aurigae> hi, why is the symlink to /dev/null in this tut? http://www.wikihow.com/Clear-Bash-History, isnt it enough to just rm ~/.bash_history ?
136 2014-02-17 10:37:11 <wumpus> Aurigae: symlinking is a crude way to prevent bash history from being re-created
137 2014-02-17 10:38:07 <gmaxwell> though you could just turn it off... there are a bunch of parameters to control history, its size, etc.
138 2014-02-17 10:38:28 <Aurigae> ACTION is squeezing google once again :) thx guys
139 2014-02-17 10:38:36 <wumpus> indeed that's why I said 'crude way', it's not the official way but people have been doing it for very long
140 2014-02-17 11:47:58 <waxwing> (possibly a crazy question): is it possible to encumber a utxo so it can only be spent to a particular address?
141 2014-02-17 11:48:39 <shaileshg> Hi, in case of escrow using multi-sig (2 out of 3), can bitcoin owner spend his bitcoins if merchant has signed it, but escrow provider hasn't?
142 2014-02-17 11:49:08 <shaileshg> moreover, can it lead to double spending?
143 2014-02-17 11:49:08 <waxwing> shaileshg, yes, 2 of 3 means any 2 of the 3
144 2014-02-17 11:49:46 <shaileshg> waxwing: user can't sign the spending.. so it has to be escrow provider and merchant (2 out of 3)
145 2014-02-17 11:50:29 <shaileshg> but my question is if the transaction is not completed (i.e. escrow provider hasn't yet signed it).. can user spend that bitcoin meanwhile anywhere else?
146 2014-02-17 11:50:48 <shaileshg> or does his inputs get blocked
147 2014-02-17 11:50:56 <waxwing> shaileshg, oh i see. answer should be yes.
148 2014-02-17 11:50:57 <shaileshg> for the aforementioned transaction
149 2014-02-17 11:51:27 <anddam> that's just cute https://github.com/bitcoin/bitcoin/issues/3689
150 2014-02-17 11:51:41 <anddam> and totally troll
151 2014-02-17 11:51:46 <waxwing> until a tx is broadcast, another tx can be created and broadcast instead. but if you're talking about a utxo in a msig address, obviously the alternative also has to have the proper combination of sigs
152 2014-02-17 11:53:35 <shaileshg> waxwing: I am not talking about utxo (correct me if i m wrong).. let user A wants to pay to merchant B using escrow C.. he uses output of previous transactions to pay the merchant.. but need 2 signs of B & C before B can redeem bitcoins..
153 2014-02-17 11:53:52 <shaileshg> lets say it takes 7 days for A to tell C to release payment to B
154 2014-02-17 11:54:27 <shaileshg> Can A spend his bitcoins (he used in aforementioned txn) meanwhile?
155 2014-02-17 11:54:34 <anddam> while querying the daemon using after applying PR #2802 I'm stumbling into error https://github.com/bitcoin/bitcoin/issues/2522
156 2014-02-17 11:54:36 <shaileshg> if not, how do you ensure / check it
157 2014-02-17 11:54:56 <shaileshg> if yes, how to implement escrow service
158 2014-02-17 11:55:15 <waxwing> shaileshg, if A has spent 1BTC into the multisig first, then the escrow (C) is waiting for the merchant (B) to send the goods
159 2014-02-17 11:55:25 <shaileshg> right..
160 2014-02-17 11:55:39 <waxwing> at that point the 1BTC is a utxo in the msig address,
161 2014-02-17 11:55:45 <anddam> I see that's been patched by commiting a lower default max_open_file option in leveldb
162 2014-02-17 11:55:52 <shaileshg> hmm
163 2014-02-17 11:55:54 <waxwing> it can only be spent with 2 of the 3 signatories
164 2014-02-17 11:56:06 <waxwing> signatures rather
165 2014-02-17 11:56:14 <shaileshg> okay.. and it will be mined in the blockchain?
166 2014-02-17 11:56:22 <shaileshg> i.e. registered
167 2014-02-17 11:56:28 <anddam> why am I getting "LevelDB read failure: IO error: " if that's supposedly been fixed?
168 2014-02-17 11:57:16 <waxwing> not sure your question shaileshg
169 2014-02-17 11:57:28 <waxwing> example: https://blockchain.info/address/3ADuJrz6TcXwb36N8GYAmPxiwT4RqMRdfG
170 2014-02-17 11:57:30 <shaileshg> waxwing: lets say B doesn't ship the goods.. then what would happen.. can A get back his bitcoins
171 2014-02-17 11:57:35 <waxwing> yes
172 2014-02-17 11:57:39 <shaileshg> how
173 2014-02-17 11:57:46 <waxwing> if C is convinced that B defaulted
174 2014-02-17 11:57:52 <sipa> waxwing: no, you cannot limit what an output can be spent to
175 2014-02-17 11:58:02 <waxwing> he signs a transaction to send the bitcoins to A
176 2014-02-17 11:58:09 <waxwing> and A also has to sign it
177 2014-02-17 11:58:13 <waxwing> sipa, thanks
178 2014-02-17 11:58:19 <sipa> waxwing: google for coincovenant if you want to hear about exotic ideas that would allow this
179 2014-02-17 11:58:20 <waxwing> i guessed so but i had to ask :)
180 2014-02-17 11:58:38 <waxwing> sipa, i kind of also guessed that :)
181 2014-02-17 11:58:54 <waxwing> sipa, thanks very much for the "link"
182 2014-02-17 12:00:15 <shaileshg> waxwing: C has to create new transaction for sending bitcoins to A?
183 2014-02-17 12:00:48 <shaileshg> If so, how does C gets the bitcoins which were supposed to be received by B as the transaction would have B's address in the output
184 2014-02-17 12:01:22 <waxwing> the transaction to send out from the 3... address hasn't been fixed at the point where the escrow is set up
185 2014-02-17 12:01:38 <shaileshg> ohh.. okay
186 2014-02-17 12:01:46 <waxwing> think of the multisig address like other addresses: you put money into it, then, later, whoever controls it can spend money out of it
187 2014-02-17 12:01:59 <shaileshg> right.. p2sh
188 2014-02-17 12:02:00 <shaileshg> ?
189 2014-02-17 12:02:07 <waxwing> the difference is that 2 different pubkeys(people) have to decide *together* to spend out of it
190 2014-02-17 12:02:11 <waxwing> yes p2sh
191 2014-02-17 12:02:22 <waxwing> sorry i may have violently missed the point; i thought you were talking about p2sh
192 2014-02-17 12:03:22 <shaileshg> here.. which two parties pubkeys are to be used to decide *together*, out of A, B & C
193 2014-02-17 12:03:47 <shaileshg> if i m missing some basic things.. any link detailing escrow kind of payments and how to form such transaction would be gr8
194 2014-02-17 12:04:20 <waxwing> any 2 of the 3, if you set it up that way
195 2014-02-17 12:04:38 <waxwing> in general it can be M of N, but N>3 is nonstandard i think
196 2014-02-17 12:04:52 <sipa> within P2SH, N can be up to 15or so
197 2014-02-17 12:05:05 <shaileshg> hmm.. okay
198 2014-02-17 12:05:25 <waxwing> there's not much documentation, i started from https://gist.github.com/gavinandresen/3966071
199 2014-02-17 12:06:16 <shaileshg> waxwing: okay. thanks :)
200 2014-02-17 12:08:43 <waxwing> sipa, i think only eligius is allowing N>3, maybe i'm wrong or not up to date there
201 2014-02-17 12:09:45 <sipa> in bare multisig, yes
202 2014-02-17 12:10:07 <shaileshg> and 2 in the createmultisig is M out of N (3).. ?
203 2014-02-17 12:14:42 <waxwing> sipa, what is clothed multisig? :)
204 2014-02-17 12:14:53 <waxwing> shaileshg, yes M=2 N=3 i nthat example
205 2014-02-17 12:16:26 <sipa> waxwing: P2SH
206 2014-02-17 12:16:54 <sipa> in bare multisig (so actually putting the M-of-N script in the scriptPubKey), there is a limit of N <= 3
207 2014-02-17 12:17:05 <sipa> if it's wrapped inside P2SH, there is no such limit
208 2014-02-17 12:20:43 <waxwing> sipa, ah ok that's another layer of my lack of knowledge .. is gavin's 2 of 3 example bare multisig?
209 2014-02-17 12:21:17 <sipa> no
210 2014-02-17 12:21:25 <sipa> you can't create those with bitcoind
211 2014-02-17 12:34:43 <Aurigae> is there an easy way to prevent nmap scans on my server?
212 2014-02-17 12:48:11 <buhbuh> Anyone knows if sipa's secp256k1 implementation is used in bitcoind ?
213 2014-02-17 12:55:20 <wumpus> buhbuh: not by default, currently
214 2014-02-17 12:56:35 <wumpus> buhbuh: it should be possible to use it, and in time the plan is to switch over
215 2014-02-17 13:20:14 <buhbuh> wumpus: thanks. Sipa's implementation looks really good. I wonder what's the performance relative to OpenSSL, and if use of AVX(2) has been explored.
216 2014-02-17 13:23:35 <sipa> buhbuh: up to 6x
217 2014-02-17 13:23:43 <sipa> on x86_64
218 2014-02-17 13:28:26 <buhbuh> sipa: waouw. nice. Congrats on the job! With which 'field' implementation ?
219 2014-02-17 13:28:56 <sipa> the assembly one (5x64_asm)
220 2014-02-17 13:29:05 <buhbuh> I was reading the glv 'splitk' function.
221 2014-02-17 13:29:07 <sipa> i did not write the assembly code, by the way
222 2014-02-17 13:29:29 <sipa> i also didn't come up with that optimization or the constants involved; Hal Finney did
223 2014-02-17 13:29:39 <buhbuh> Isn't it possible to pre-compute n/2 as well ?
224 2014-02-17 13:30:17 <sipa> probably (not looking at the code now), but this method is called exactly once in a verification
225 2014-02-17 13:30:24 <buhbuh> And also, I do not know for sure but there might be an addition of n/2 too much.
226 2014-02-17 13:30:38 <buhbuh> I guess to round up to the nearest integer.
227 2014-02-17 13:31:04 <sipa> yeah
228 2014-02-17 13:31:25 <buhbuh> Oh really ? I thought the endomorphism was used quite often to spped up multiplies.
229 2014-02-17 13:31:35 <buhbuh> I need to read more...
230 2014-02-17 13:32:24 <sipa> it's used exactly once to transform p*Q + n*G into p1*Q + p2*Q' + n*G
231 2014-02-17 13:32:35 <sipa> where p1 and p2 are 128-bit numbers only
232 2014-02-17 13:32:43 <sipa> and Q' is Q*lambda
233 2014-02-17 13:32:45 <buhbuh> yes, correct.
234 2014-02-17 13:33:37 <buhbuh> meaning once per point multiplication, right ?
235 2014-02-17 13:33:58 <sipa> we only do one point multiplication
236 2014-02-17 13:34:02 <sipa> in a verification
237 2014-02-17 13:34:06 <buhbuh> per verification.
238 2014-02-17 13:34:08 <buhbuh> yep
239 2014-02-17 13:34:18 <buhbuh> anyway, it's a detail.
240 2014-02-17 13:34:41 <buhbuh> How about AVX(2), any idea if it could speed things up ?
241 2014-02-17 13:34:51 <sipa> i don't know anything about that, tbh
242 2014-02-17 13:34:52 <buhbuh> ...further ?
243 2014-02-17 13:35:24 <buhbuh> I mean this: http://en.wikipedia.org/wiki/Advanced_Vector_Extensions
244 2014-02-17 13:35:55 <buhbuh> Also, one thing I did not look into yet is modular reduction.
245 2014-02-17 13:36:30 <buhbuh> Is it taking advantage of the special form of the moduli ?
246 2014-02-17 13:36:33 <sipa> yes
247 2014-02-17 13:37:08 <buhbuh> :) You guys did it by the book, eh !
248 2014-02-17 13:37:35 <sipa> i was inspired a bit by the ed25519 implementations :)
249 2014-02-17 13:37:54 <buhbuh> Ahhh. That will explain.
250 2014-02-17 13:38:17 <sipa> where there is one that uses 5 64-bit limbs to represent field elements
251 2014-02-17 13:38:22 <sipa> which seemed very useful here
252 2014-02-17 13:38:32 <sipa> as it means much fewer reductons
253 2014-02-17 13:38:35 <buhbuh> Then you discarded it ?
254 2014-02-17 13:38:37 <sipa> no
255 2014-02-17 13:39:26 <buhbuh> yes, it is a very useful representation.
256 2014-02-17 13:39:45 <buhbuh> The W-NAF thingy earns you maybe 30-35%.
257 2014-02-17 13:39:55 <andytoshi> sipa: i have as a course project this semester to investigate batch ecdsa verification, fingers crossed
258 2014-02-17 13:39:59 <buhbuh> And the GLV mmaybe 25%.
259 2014-02-17 13:40:25 <buhbuh> But the big win comes from the 5 x 64 representation I suppose.
260 2014-02-17 13:40:31 <sipa> buhbuh: with GLV it;s around 6x as fast as openssl, without GLV it's more like 4.5x
261 2014-02-17 13:40:35 <sipa> andytoshi: cool
262 2014-02-17 13:40:45 <sipa> andytoshi: i still don't understand how it can be useful for us
263 2014-02-17 13:40:52 <buhbuh> Batch verification is nice. But dangerous :)
264 2014-02-17 13:41:02 <sipa> andytoshi: as you get an exponential blowup in combinations to test per added signature
265 2014-02-17 13:41:11 <sipa> as you only know R.x, not the full point R
266 2014-02-17 13:41:17 <sipa> so there are 2 possibilities for R.y
267 2014-02-17 13:41:21 <andytoshi> right, yeah
268 2014-02-17 13:41:40 <buhbuh> Change the protocol to send R.
269 2014-02-17 13:41:47 <andytoshi> lol, that would be nice..
270 2014-02-17 13:42:00 <sipa> buhbuh: if we'd do that, we can just drop ecdsa altogether
271 2014-02-17 13:42:06 <buhbuh> It's a student project, right ?
272 2014-02-17 13:42:25 <buhbuh> sipa: oh no, that curve is too nice.
273 2014-02-17 13:42:35 <andytoshi> buhbuh: sure, but the point is for it to be useful
274 2014-02-17 13:42:43 <sipa> buhbuh: i didn't say changing the curve :p
275 2014-02-17 13:42:45 <andytoshi> buhbuh: we can keep the same curve, just use a different sig algo
276 2014-02-17 13:43:01 <andytoshi> say, one which can be batch-verified, and has an actual security proof, and is nonmalleable...
277 2014-02-17 13:43:06 <andytoshi> and faster
278 2014-02-17 13:43:10 <andytoshi> and simpler
279 2014-02-17 13:43:23 <buhbuh> sipa: I see. Right. The curve yes, ECDSA, no. That would fly.
280 2014-02-17 13:43:33 <sipa> can schnorr be batch-verified?
281 2014-02-17 13:43:37 <sipa> from my reading, it cannot
282 2014-02-17 13:44:21 <andytoshi> sipa: eddsa can be, that's essentially schnorr.. you may be right
283 2014-02-17 13:44:21 <buhbuh> andytoshi: they are reported attack against batch verifications.
284 2014-02-17 13:44:41 <andytoshi> because 'essentially' means he changed the compression and encoding
285 2014-02-17 13:45:26 <andytoshi> buhbuh: cite?
286 2014-02-17 13:46:02 <buhbuh> let me see...
287 2014-02-17 13:46:24 <buhbuh> I stumbled upon it when implementing it for our beloved curve.
288 2014-02-17 13:46:51 <buhbuh> Was recommending randomization. Which basically nullifies the benefits.
289 2014-02-17 13:47:42 <buhbuh> Maybe this one: https://eprint.iacr.org/2012/582.pdf
290 2014-02-17 13:48:34 <buhbuh> + ref 1 and 2.
291 2014-02-17 13:48:40 <andytoshi> thx buhbuh, i'll check these out
292 2014-02-17 13:49:20 <buhbuh> But in +principle+ batch verification fully applies to our business.
293 2014-02-17 13:49:57 <buhbuh> In +practice+ both the R problem, and the described attacks+recommended wortkaround would appear to make it useless.
294 2014-02-17 13:50:26 <andytoshi> cool, this is great to know nonetheless
295 2014-02-17 13:55:25 <buhbuh> Did I read somewhere that for our beloved curve, n is congruent to 1 mod 6 )
296 2014-02-17 13:55:39 <buhbuh> -) + ?
297 2014-02-17 13:55:57 <buhbuh> Any way to take advantage of that ?
298 2014-02-17 14:24:48 <UukGoblin> WAT
299 2014-02-17 14:25:06 <UukGoblin> gox will keep relying on a new-transaction-id?
300 2014-02-17 14:25:15 <UukGoblin> which will be maintained by blockchain? :-O
301 2014-02-17 14:25:18 <UukGoblin> sounds rather crazy
302 2014-02-17 14:36:38 <helo> when a customer opens a ticket saying "i didn't get the bitcoin i withdrew", apparently they feel that they absolutely must have some long string they can send the user as "proof" to appease them
303 2014-02-17 14:36:59 <helo> why they don't just send the customer a copy of the transaction itself, i do not know
304 2014-02-17 14:37:14 <sipa> humans do not like long hexadecimal strings
305 2014-02-17 14:38:02 <helo> for that matter, there should be an option for the customer to download the tx payload in some way that bitcoin-qt (or other wallet) can see
306 2014-02-17 14:42:29 <wumpus> not sure it's a good idea, that would bypass network relaying restrictions and give the user a transaction that will probably never confirm
307 2014-02-17 14:43:34 <wumpus> and if it is confirmed the user will see it in his own wallet anyway, so you could refer to it by (n)txid without sending the payload
308 2014-02-17 14:46:29 <wumpus> but if desirable it could be implemented as a bitcoin URI extension for example bitcoin:tx=<tx payload>
309 2014-02-17 14:50:09 <helo> it seems at least better than getting some txid variant (verifiable only through blockchain.info) of a tx that will never confirm
310 2014-02-17 14:50:27 <andytoshi> wumpus: if the tx will never confirm, they can bring it here and we can say "gox fucked up", then they can go to gox and say "the devs told me XYZ"
311 2014-02-17 14:50:48 <andytoshi> then the next time they shutter, we will have logs which show the kinda stuff gox was putting into transactions
312 2014-02-17 15:06:47 <wumpus> a client could then show the transaction information and give the option to import it into the wallet (if sent to any receiving addresses in the wallet)
313 2014-02-17 15:08:45 <oleganza> hey there. Who is interested in blind ECDSA signatures to be used in blockchain?
314 2014-02-17 15:10:05 <oleganza> the idea is to lock the funds in (lets say) 5-of-9 multisig tx with 9 friends (who will later authenticate you in person or over the phone), but to NOT reveal the transaction that they will sign
315 2014-02-17 15:10:31 <oleganza> so they sign something and will never be able to find on the blockchain if they really signed some tx or not.
316 2014-02-17 15:11:32 <kjj> I think a bunch of people would be interested in blind ECDSA signatures in general, but not for anything blockchain related
317 2014-02-17 15:11:32 <kjj> like I said, a bunch of people
318 2014-02-17 15:13:32 <oleganza> kjj: how about that http://oleganza.com/blind-ecdsa-draft-v1.pdf
319 2014-02-17 15:14:14 <oleganza> kjj: the idea is to avoid having all secrets at once on a single machine. So SSSS or other kinds of 2-factor auth are no go.
320 2014-02-17 15:14:25 <oleganza> also, see discussion here: https://bitcointalk.org/index.php?topic=440572.0
321 2014-02-17 15:16:39 <shesek> oleganza, does it matter if they sign the tx themselves, or provide you with something that allows you to do it yourself?
322 2014-02-17 15:17:07 <shesek> oh, "the idea is to avoid having all secrets at once on a single machine"... didn't see that. never mind
323 2014-02-17 15:17:19 <oleganza> shesek: they must provide something tied to the hash of my intended transaction
324 2014-02-17 15:17:47 <oleganza> so if someone stole all my keys, they still can't do anything.
325 2014-02-17 15:22:54 <shesek> oleganza, I was thinking about having each friend provide a pubkey, and using your_pubkey*friend_pubkey for each key in the multisig
326 2014-02-17 15:23:04 <shesek> without revealing your pubkey to them
327 2014-02-17 15:23:33 <shesek> then, they could provide you with the private key which'll allow you to construct the multisig private keys
328 2014-02-17 15:24:01 <shesek> without your public key, they can't know what's the actual public keys used in the multisig and see what funds it has
329 2014-02-17 15:24:09 <shesek> and without your private key, they can't spend
330 2014-02-17 15:24:18 <shesek> but that doesn't work with "avoid having all secrets at once on a single machine"