1 2014-10-25 07:11:13 <Luke-Jr> ACTION regrets pushing for signed message support :|
2 2014-10-25 07:16:33 <wumpus> why Luke-Jr?
3 2014-10-25 07:17:00 <Luke-Jr> wumpus: seems people are trying to use it to prove they *sent* bitcoins, which of course doesn't work
4 2014-10-25 07:18:08 <Luke-Jr> maybe the solution is to add a function to sign that scenario - but I'm not sure there's a good way to do that either
5 2014-10-25 07:18:19 <Luke-Jr> until HD wallets are implemented, anyway
6 2014-10-25 07:19:04 <wumpus> to prove that you sent bitcoins you'd say that giving the txid is enough? at least, if the merchant gives out a unique address for each order/customer
7 2014-10-25 07:19:51 <Luke-Jr> the txid is public
8 2014-10-25 07:19:57 <Luke-Jr> anyone can claim they sent it
9 2014-10-25 07:20:12 <Luke-Jr> of course, you don't need to prove it if they give you a unique address
10 2014-10-25 07:20:13 <wumpus> right - but the merchant knows?
11 2014-10-25 07:20:42 <wumpus> assuming no one else will listen in and just randomly pay your invoice
12 2014-10-25 07:20:44 <wumpus> :P
13 2014-10-25 07:21:10 <Luke-Jr> shrug, if they do, that's their problem
14 2014-10-25 07:21:23 <wumpus> right, so I don't really see the issue, its either paid or not paid
15 2014-10-25 07:21:33 <Luke-Jr> but the mode of operation "send 0.01 BTC to my sig address and I'll ship you X" is totally non-workable today
16 2014-10-25 07:21:45 <Luke-Jr> which is apparently what some n00bs are trying to do
17 2014-10-25 07:21:55 <wumpus> ugh, yes, that has always been unworkable
18 2014-10-25 07:23:10 <wumpus> and if it requires the customers to sign anything, it puts the burden on them and gives them extra work
19 2014-10-25 08:22:24 <lewellyn> Luke-Jr: is there a page describing, irrefutably, about sending and addresses and signing and etc.?
20 2014-10-25 08:22:42 <lewellyn> it's definitely something of a faq that ought to be addressed. :P
21 2014-10-25 08:23:04 <Luke-Jr> lewellyn: https://en.bitcoin.it/wiki/From_address - but it doesn't talk about signing
22 2014-10-25 08:23:16 <Luke-Jr> https://en.bitcoin.it/wiki/Address - but it also doesn't talk about signing
23 2014-10-25 08:23:28 <Luke-Jr> oh, that one does actually
24 2014-10-25 08:23:38 <Luke-Jr> "Proving you receive with an address"
25 2014-10-25 08:25:00 <lewellyn> yeah. nothing which would just end that thread. :P
26 2014-10-25 08:30:46 <Luke-Jr> lewellyn: maybe pointing out I wrote the sign message GUI they're using will help :p
27 2014-10-25 08:32:20 <lewellyn> unlikely.
28 2014-10-25 08:32:47 <lewellyn> i was thinking that maybe i could link such a page though, since it's not obvious on the forum that we've ever encountered each other.
29 2014-10-25 09:09:08 <b-itcoinssg> I noticed there was a hash of the commit on the Wuille et. al. sidechains paper, is it available on github?
30 2014-10-25 09:09:26 <sipa> no
31 2014-10-25 09:10:00 <sipa> the pdf is public.domain, though
32 2014-10-25 09:10:14 <b-itcoinssg> Hey Peiter, great work on the paper btw. what did the hash reference to?
33 2014-10-25 09:11:06 <phantomcircuit> b-itcoinssg, a git commit obviously
34 2014-10-25 09:11:22 <b-itcoinssg> ok
35 2014-10-25 09:12:00 <justanotheruser> why isn't there a 4c (push the next byte bytes) before the the 14 (bytes) in a transaction? It just goes 76a914 (DUP, HASH, num-bytes-to-push). 0x14 doesn't do anything
36 2014-10-25 09:12:47 <sipa> justanotheruser: opcodes 0-75 just push the following N bytes immediately
37 2014-10-25 09:13:12 <sipa> with N the opcode number
38 2014-10-25 09:13:19 <justanotheruser> oh, I just glanced at the "N/A" and assumed it meant no-op
39 2014-10-25 09:13:38 <justanotheruser> ok, makes sense, thanks
40 2014-10-25 12:31:11 <todam00n> can auxpow blocks be verified offline?
41 2014-10-25 12:31:27 <todam00n> assuming the parent blockchain is not available
42 2014-10-25 12:40:14 <btcdrak> sipa, wumpus, gavinandresen, petertodd, Luke-Jr, can you comment on this: http://blog.bettercrypto.com/?p=916 "We wonder why bitcoin developers and bitcoin foundation have been as usual utterly negligent about security so that this patch has NOT YET BEEN applied in bitcoin core software for like 18 months since January 2013."
43 2014-10-25 12:40:14 <wumpus> what patch?
44 2014-10-25 12:40:15 <sipa> btcdrak: using deterministic signing is good practice in ECDSA, but not doing it is hardly a critical vulnerability (btw: all cases known where the random nonce was weak were not bitcoin core, so it wouldn't have mattered)
45 2014-10-25 12:40:15 <sipa> btcdrak: we've been planning on using determnistic signing, but it means first getting rid of OpenSSL (or requiring a very recent version; iirc not even released yet)
46 2014-10-25 12:40:15 <wumpus> so should we patch openssl?!
47 2014-10-25 12:40:15 <wumpus> there is no release of openssl that has that code change, and we keep to released versions of openssl
48 2014-10-25 12:41:23 <sipa> i'll comment
49 2014-10-25 12:41:31 <wumpus> anyhow: much more will break if you don' thave a secure random number generator
50 2014-10-25 12:41:40 <btcdrak> sipa, wumpus, thanks for the explanation.
51 2014-10-25 12:41:53 <wumpus> really seems like a unpleasant person, btw
52 2014-10-25 12:42:34 <wumpus> OH NO THOSE STUPID BITCOIN DEVS WHY DON'T THEY THINK ABOUT SECURITY LOOK AT ME
53 2014-10-25 12:43:57 <btcdrak> wumpus, yeah. I dont like when people dump on OSS contributors like that. My immediate reaction to him was "why dont you have PR if it's so easy to fix". He doesnt even reference an open github issue.
54 2014-10-25 12:44:05 <wumpus> but sure, on the internet it's right to be a dick
55 2014-10-25 12:45:21 <btcdrak> maybe it would be good to have a ticket open regarding this though, that there are plans for deterministic signing and what steps are pending for that to happen (can use Github task lists features: https://github.com/blog/1375%0A-task-lists-in-gfm-issues-pulls-comments)
56 2014-10-25 12:45:34 <btcdrak> assuming there isnt a ticket there already :-P
57 2014-10-25 12:47:04 <wumpus> let's just get rid of the wallet, gets rid of this problem too
58 2014-10-25 12:50:31 <sipa> wtf
59 2014-10-25 12:51:48 <sipa> their comment plugin is broken
60 2014-10-25 12:51:55 <sipa> complains about a missing cookie
61 2014-10-25 12:53:15 <wumpus> hehe, big words about negligent developers but they can't even maintain a working website
62 2014-10-25 12:53:34 <sipa> ah, 2nd attempt and it works
63 2014-10-25 12:53:38 <sipa> "awaits moderation"
64 2014-10-25 12:54:49 <SomeoneWeird> hahah
65 2014-10-25 12:54:52 <SomeoneWeird> DENIED
66 2014-10-25 12:57:23 <sipa> http://0bin.net/paste/3dPMfTAu7SKH9zXo#fYE+deOWREwmuCEth3p3ZrLueyj0SMBDfcnjjOoamA7
67 2014-10-25 13:00:08 <wumpus> good post
68 2014-10-25 13:58:27 <b-itcoinssg> incase anyone wanted the sidechain paper on github https://github.com/bitcoinsSG/Wuille-et-al-2014
69 2014-10-25 17:12:32 <maaku> wumpus: you're getting paid to work on bitcoin. that automatically makes you part of the problem!
70 2014-10-25 17:17:43 <b-itcoinssg> what is the process involved in submitting a bip request?
71 2014-10-25 17:18:21 <b-itcoinssg> Do I just write one up on github, have the experts look at it and then ask them to submit it?
72 2014-10-25 17:19:37 <b-itcoinssg> no one here?
73 2014-10-25 17:44:48 <gmaxwell> b-itcoinssg: see BIP1
74 2014-10-25 17:45:37 <gmaxwell> b-itcoinssg: Why have you copied the sidechains paper to github like that? You realize this will falsely give people the impression that you are or represent the authors, right?
75 2014-10-25 17:46:13 <b-itcoinssg> gmaxwell: thanks for the info
76 2014-10-25 17:46:48 <b-itcoinssg> gmaxwell: I put it on there so that I or the public could add more descriptive additions to it, like graphs etc
77 2014-10-25 17:46:56 <therp> gmaxwell: at least for my part, my default assumption is not that random paper pdfs on github represent the authors.
78 2014-10-25 17:47:35 <gmaxwell> b-itcoinssg: the copy you have on there is a somewhat mangled conversion from the PDF, it's not a form sutiable for editing.
79 2014-10-25 17:47:58 <b-itcoinssg> gmaxwell: I have the authors made very explicit on the repo, what do you suggest I do?
80 2014-10-25 17:48:32 <b-itcoinssg> gmaxwell: I'm still working on it. It's not finished
81 2014-10-25 17:48:33 <kanzure> did you manually convert this to markdown?
82 2014-10-25 17:48:38 <kanzure> why did you bother?
83 2014-10-25 17:48:41 <b-itcoinssg> yes
84 2014-10-25 17:49:07 <kanzure> wouldn't it be better to just use the original latex infrastructure?
85 2014-10-25 17:49:39 <b-itcoinssg> I'm not familiar with the latex infrastructure
86 2014-10-25 17:50:20 <gmaxwell> OT for here in any case.
87 2014-10-25 17:50:43 <elichai2> petertodd, anyone got Peter Todd E-Mail? I just not always online here so it's hard to communicate...
88 2014-10-25 17:51:47 <b-itcoinssg> gmaxwell: Do you want to take it down?
89 2014-10-25 17:52:06 <b-itcoinssg> do you want me to take it down?*
90 2014-10-25 17:56:22 <b-itcoinssg> gmaxwell: you there?
91 2014-10-25 17:59:25 <b-itcoinssg> gmaxwell: ok it's deleted. It was only up for a few hours I doubt if anyone cloned it. So much for a day's work.
92 2014-10-25 18:01:04 <elichai2> ops, my message wasn't for Peter Todd, it was for everybody else lol
93 2014-10-25 18:06:11 <b-itcoinssg> elichai2: have you tried him on twitter? he was active a few minutes ago
94 2014-10-25 18:06:40 <elichai2> b-itcoinssg, my questions are a little more private for twitter :)
95 2014-10-25 18:07:30 <b-itcoinssg> i see :-)
96 2014-10-25 18:31:43 <b-itcoinssg> in a Bitcoin pubkey hash, [1][x] is x supposed to account for the 2^160 range in base58 form?
97 2014-10-25 18:32:25 <b-itcoinssg> I ask this because I would like to convert from base58 to another base
98 2014-10-25 18:34:33 <justanotheruser> b-itcoinssg: what do you mean [1][x]? There are 2^160 pkh' if thats what you mean
99 2014-10-25 18:34:47 <justanotheruser> oh, [1][x] as in an address?
100 2014-10-25 18:34:50 <b-itcoinssg> yes
101 2014-10-25 18:34:57 <justanotheruser> an address is a pubkeyhash plus a checksum
102 2014-10-25 18:35:07 <b-itcoinssg> so [3][x] for a script hash
103 2014-10-25 18:35:13 <justanotheruser> ya
104 2014-10-25 18:35:20 <b-itcoinssg> right
105 2014-10-25 18:35:33 <justanotheruser> b-itcoinssg: I think this would be useful to you https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses
106 2014-10-25 18:36:36 <b-itcoinssg> thanks, I have been reading that page and other related page on addresses, I wanted to verify something because I start writing something up
107 2014-10-25 18:37:27 <justanotheruser> b-itcoinssg: what do you want if not base 58?
108 2014-10-25 18:38:05 <b-itcoinssg> I want to convert it to a larger base for shorter address, well, at least human memory wise
109 2014-10-25 18:38:33 <b-itcoinssg> but I want to retain the type of address script vs. normal
110 2014-10-25 18:38:36 <justanotheruser> would be tricky using non-alphanumeric keys regarding human memory and usability
111 2014-10-25 18:38:39 <b-itcoinssg> so I would retain the 1
112 2014-10-25 18:38:45 <b-itcoinssg> or the 3
113 2014-10-25 18:39:08 <b-itcoinssg> but I wanted to verify if all that's left is to convert the trailing variables ie. [1][x] to another base
114 2014-10-25 18:39:25 <b-itcoinssg> trailing variables = whatever x contains
115 2014-10-25 18:41:41 <justanotheruser> b-itcoinssg: well you can easily have the same behavior in a different base
116 2014-10-25 18:42:04 <justanotheruser> also, the 1 isn't appended, it is part of what is converted to base 58
117 2014-10-25 18:42:23 <b-itcoinssg> ok, that was where I was a little unclear
118 2014-10-25 18:44:02 <b-itcoinssg> my largest concern would be to not loose the entropy for obvious reasons
119 2014-10-25 18:44:19 <justanotheruser> not obvious to me
120 2014-10-25 18:46:19 <b-itcoinssg> I woun't want to unintentionally convert something that is actually a big number to a smaller space
121 2014-10-25 18:46:44 <justanotheruser> if you do it right that shouldn't be a problem
122 2014-10-25 18:46:50 <b-itcoinssg> right
123 2014-10-25 18:47:02 <justanotheruser> with the current libraries, you can convert from base58 to 16 and 16 to your base
124 2014-10-25 18:48:20 <b-itcoinssg> well it seems even if I convert the whole string to a another base, and append the 1 or 3 to retain the address type it should be an issue if it memorable. an addition 1 or 3 shouldn't hurt too much if the concept is good enough
125 2014-10-25 18:48:56 <b-itcoinssg> right I'm converting to a larges base, something in the hundreds of thousauds
126 2014-10-25 18:49:17 <justanotheruser> o_O
127 2014-10-25 18:49:21 <b-itcoinssg> I did find some code for converting bases though
128 2014-10-25 18:49:25 <b-itcoinssg> that was helpful
129 2014-10-25 18:49:32 <justanotheruser> I don't have a hundred thousand options on my keyboard
130 2014-10-25 18:49:38 <b-itcoinssg> lol
131 2014-10-25 18:49:50 <justanotheruser> do you think im luke?
132 2014-10-25 18:49:59 <b-itcoinssg> lol
133 2014-10-25 18:51:26 <b-itcoinssg> it actually a much simpler concept, you'll understand when you see it. Let me post something up on bitcointalk, there's probably something obvious I'm overlooking anyway.
134 2014-10-25 19:37:01 <jgarzik> https://blog.conformal.com/btcsim-simulating-the-rise-of-bitcoin/
135 2014-10-25 19:37:21 <jgarzik> This seems to presume the bulk of ECDSA sig checking occurs after the "block" message is received
136 2014-10-25 19:39:21 <b-itcoinssg> 32 MB block for 270 tps ? should it be lower?
137 2014-10-25 19:40:17 <gribble> 224
138 2014-10-25 19:40:17 <justanotheruser> ;;calc 7*32
139 2014-10-25 19:40:24 <justanotheruser> close enough.
140 2014-10-25 19:41:49 <justanotheruser> 7 is an estimate anyways. looks like the 270tps estimate assumes 197 byte transactions
141 2014-10-25 19:42:06 <justanotheruser> jgarzik: does that matter much?
142 2014-10-25 19:42:20 <justanotheruser> it just lags the validation, it seems the speed should be the same
143 2014-10-25 19:42:35 <gmaxwell> transation rates here are much higher than that in my testing... but nodes are bandwidth limited long before being cpu limited.
144 2014-10-25 20:43:58 <Luke-Jr> btcdrak: if the random source is crap, then Bitcoin Core is vulnerable even if it implements deterministic ECDSA signatures
145 2014-10-25 20:59:00 <phantomcircuit> Luke-Jr, ditto everything that generates a private key
146 2014-10-25 20:59:15 <Luke-Jr> yep
147 2014-10-25 21:02:30 <gmaxwell> Derandomized DSA is certantly preferable in my view. But it's unsupported by released versions of openssl; and changing behavior has some of its own risks. (I'm surprised things haven't changed though the partially derandomized openssl code has been in beta for over a year)... at the same time the author of that page seems to be saying anything possible to attack Bitcoin in general, e.g. he also criticizes us for not using the ...
148 2014-10-25 21:02:36 <gmaxwell> ... NSA-magic-numbers NIST P-256 curve; ... I can't help but think that if we did use derandomized DSA he'd be making the technically correct criticism that we're violating the DSA specification.
149 2014-10-25 21:04:17 <Luke-Jr> ACTION wonders if anyone has proven the DDSA algo in OpenSSL isn't vulnerable to something
150 2014-10-25 21:04:40 <phantomcircuit> unlikely
151 2014-10-25 21:06:46 <Luke-Jr> deterministic signatures makes a *little* bit more sense once we have HD wallet support
152 2014-10-25 21:06:56 <Luke-Jr> then someone just needs to ensure their initial seed has entropy
153 2014-10-25 21:08:07 <Cryo> S=k.logW
154 2014-10-25 21:08:45 <Cryo> one of the few equations easy to remember :)
155 2014-10-25 21:10:42 <phantomcircuit> hmm
156 2014-10-25 21:11:50 <gmaxwell> Luke-Jr: IIRC the thing in the betaopenssl is hardned but not derandomized. Basically they do something that looks like a determinstic nonce generation, but then add a random value to it. In theory this is strictly superior, as it can be no less secure, so long as your random number source isn't somehow looking inside your deterministic-random function. ... but it loses the testability advantages.
157 2014-10-25 21:12:00 <Cryo> http://en.wikipedia.org/wiki/Ludwig_Boltzmann#Final_years awesome tombstone too.
158 2014-10-25 21:14:05 <Luke-Jr> Cryo: too small for me to read
159 2014-10-25 21:36:42 <Cryo> http://en.wikipedia.org/wiki/Ludwig_Boltzmann#mediaviewer/File:Zentralfriedhof_Vienna_-_Boltzmann.JPG at the top
160 2014-10-25 22:59:48 <elbasanli> hi
161 2014-10-25 23:00:20 <elbasanli> helooo are u there?