1 2014-01-28 00:03:52 <michagogo> cloud|1:11:50 <phantomcircuit> (i didn't say that)
2 2014-01-28 00:04:06 <michagogo> cloud|This channel's public logs disagree...
3 2014-01-28 00:04:16 <Luke-Jr> lol
4 2014-01-28 00:09:33 <phantomcircuit> michagogo|cloud, LIES
5 2014-01-28 00:24:06 <sipa> phantomcircuit: commented on your pullreq
6 2014-01-28 00:24:17 <phantomcircuit> sipa, yeah i noticed
7 2014-01-28 00:24:30 <phantomcircuit> im busy trying to build a smarter payment card processing system
8 2014-01-28 00:24:42 <phantomcircuit> which is basically impossible
9 2014-01-28 01:44:43 <Neozonz> Discx2|is it possible for rpcthreads to be busy?
10 2014-01-28 02:18:57 <sbrossie_> hey, i sent an email to http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development to submit a new bip around recurring payments (improvements for bip-0070 or new bip) but i am not seeing my email in the list. Is that because the list is moderated?
11 2014-01-28 02:24:09 <andytoshi> sbrossie_: you need to be subscribed to post messages
12 2014-01-28 02:24:20 <andytoshi> and you need to send mail from the address you subscribed from <.<
13 2014-01-28 02:24:42 <sbrossie_> i subscribed this morning and resent it afterwards but i still don't see it.
14 2014-01-28 07:05:59 <jspilman> does it make sense to put transactions on test-net as a way to unit test wallets?
15 2014-01-28 07:06:24 <jspilman> and then sort of catalog where they are and what they do?
16 2014-01-28 07:07:59 <jspilman> or is that supposed to be all done testnet-in-a-box?
17 2014-01-28 07:10:26 <jspilman> could also do a lot of interesting HD wallet test layouts to help test people's bip32 discovery code?
18 2014-01-28 07:13:41 <sipa> jspilman: that sort of tests are usually done in regtest mode
19 2014-01-28 07:14:07 <sipa> jspilman: there is a set of tests that start a network with 3 nkdes, and mine and create transactions
20 2014-01-28 07:14:46 <sipa> putting tests for bip32 recovery code sounds great to put there, but unfortunately limited to one client
21 2014-01-28 07:18:09 <sipa> ~oh, i missed the first part
22 2014-01-28 07:18:42 <sipa> yes, there actually is an extensive set of weird transactions in the testnet chain, protected by a chrckpoint even
23 2014-01-28 07:34:26 <jgarzik>
24 2014-01-28 07:34:26 <jgarzik> @@ -429,7 +429,7 @@ bool IsStandardTx(const CTransaction& tx, string& reason)
25 2014-01-28 07:34:26 <jgarzik> if (nDataOut > 1) {
26 2014-01-28 07:34:26 <jgarzik> // only one OP_RETURN txout is permitted
27 2014-01-28 07:34:26 <jgarzik> - reason = "mucho-data";
28 2014-01-28 07:34:27 <jgarzik> + reason = "printer-on-fire";
29 2014-01-28 07:34:29 <jgarzik> return false;
30 2014-01-28 07:34:31 <jgarzik> }
31 2014-01-28 07:34:35 <jgarzik>
32 2014-01-28 07:35:13 <jrmithdobbs> seconded
33 2014-01-28 07:39:16 <wumpus> hahahah
34 2014-01-28 07:39:37 <wumpus> yes, much better
35 2014-01-28 07:40:32 <jgarzik> A static string indicating one and only condition, is just that.
36 2014-01-28 07:40:39 <jgarzik> A static string indicating one and only one condition, is just that.
37 2014-01-28 07:47:11 <brisque> jgarzik: I'd be happier if it were lp0-on-fire.
38 2014-01-28 07:52:52 <sipa> jgarzik: no offence, but if you purely want a computer-identifiable string, it could as well be "error 42"
39 2014-01-28 07:53:27 <sipa> jgarzik: just making it an english string makes it be interpreted by people, and in my opinion, "mucho-data" just makes the system look not serious
40 2014-01-28 07:55:10 <sipa> unrelated, i doubt how usable it even is as a computer-identifiable string, as these reasons will likely evolve over time, and potentially even without related protocol changes
41 2014-01-28 07:55:27 <jgarzik> sipa, way too much engineer brainspace has been wasted on this topic :)
42 2014-01-28 07:55:48 <sipa> fair enough
43 2014-01-28 07:55:58 <sipa> but i don't want this in a release
44 2014-01-28 07:57:28 <wumpus> well I think the clearest hint to we needed to clarify the message was that people apparently misinterpreted it as a general 'too much data'
45 2014-01-28 07:58:09 <wumpus> even though the condition is very specific and rare
46 2014-01-28 07:58:58 <jgarzik> please stop. just stop. the bike shed has been repainted. :)
47 2014-01-28 07:59:15 <wumpus> sorry...
48 2014-01-28 08:02:16 <jrmithdobbs> time for kerosene?
49 2014-01-28 08:02:21 <jrmithdobbs> ;p
50 2014-01-28 08:04:20 <sipa> bikes are so 20th century
51 2014-01-28 08:04:25 <wumpus> yes I'd like my shed extra-crispy please
52 2014-01-28 08:05:56 <sipa> hmm, based on a stackexchange question
53 2014-01-28 08:06:07 <sipa> it seems you can import an invalid private key
54 2014-01-28 08:06:17 <wumpus> we were promised a spaceshipshed for the 21st century :(
55 2014-01-28 08:06:21 <sipa> (a number outside the valid range)
56 2014-01-28 08:07:00 <sipa> wumpus: btw, very good comment on bip32... there is a very good reason for internal vs external, but it's not mentioned anywhere
57 2014-01-28 08:07:17 <sipa> wumpus: it's so you can selectively reveal only incoming payments vs all
58 2014-01-28 08:07:31 <wumpus> interesting, it will just wrap around? or crash and do bad things if the forbidden 0 number is passed?
59 2014-01-28 08:07:58 <wumpus> that's indeed a good reason
60 2014-01-28 08:08:13 <sipa> 0 and n are actually invalid, i suppose it would fail to sign using those
61 2014-01-28 08:08:34 <sipa> but you can import a private key that is a number between n and 2**256
62 2014-01-28 08:08:47 <sipa> and i expect that that will just work, interpewting it mod n
63 2014-01-28 08:10:23 <wumpus> it's an input validation bug nevertheless
64 2014-01-28 08:10:29 <sipa> yup
65 2014-01-28 08:10:45 <sipa> CKey has an IsValid method iirc
66 2014-01-28 08:13:15 <wumpus> CKey::Check() at least, but it appears IsValid calls that
67 2014-01-28 08:14:42 <wumpus> CBitcoinSecret.SetSecret needs to check validity of the extracted private key
68 2014-01-28 08:15:08 <wumpus> SetString*
69 2014-01-28 08:16:16 <sipa> hmm
70 2014-01-28 08:16:18 <wumpus> hmm or maybe that's not the place... CBitcoinSecret::IsValid just checks that the ascii armoring is correct
71 2014-01-28 08:17:36 <sipa> right, i'm unsure about responsabilities
72 2014-01-28 08:17:38 <wumpus> well we can always just check the result of vchSecret.GetKey()
73 2014-01-28 08:17:54 <sipa> whether the base58 code should do domain level checking of the encoded data
74 2014-01-28 08:17:58 <wumpus> yes
75 2014-01-28 08:18:05 <wumpus> it probably shouldn't
76 2014-01-28 08:18:17 <wumpus> it's just all so over the place that I got confused
77 2014-01-28 08:19:00 <sipa> actually
78 2014-01-28 08:19:47 <sipa> why don't we use something similar like (or an extension of) IMPLEMENT_SERIALIZE to do base58 conversion?
79 2014-01-28 08:20:41 <sipa> it could move all this type-specific cobversion code to the types
80 2014-01-28 08:20:59 <CodeShark> why not just deal entirely in unsigned char vectors internally and have two specific functions: toBase58Check and fromBase58Check which are only used for UI?
81 2014-01-28 08:21:26 <sipa> good point
82 2014-01-28 08:21:46 <sipa> but the char vectors have no actual usage, as they are always just intermediary
83 2014-01-28 08:22:07 <sipa> each base58 encoded type has a corresponding domain level type anyway
84 2014-01-28 08:22:35 <CodeShark> I'm not really sure why we're relying on base58 for typing information
85 2014-01-28 08:22:35 <wumpus> adding serialization/deserialization logic to types themselves makes it impossible to contain the serialization logic , and can be confusing especially if they can be serialized in different ways
86 2014-01-28 08:22:49 <sipa> CodeShark: are we?
87 2014-01-28 08:22:52 <wumpus> we're not relying on base58 for typing information AFAIK
88 2014-01-28 08:22:57 <CodeShark> it seems if we want a serialized format for type data, we should develop a binary standard
89 2014-01-28 08:23:03 <Luke-Jr> CodeShark: you're good at hiding XD
90 2014-01-28 08:23:07 <wumpus> we first decodecheck then work on the decoded vector
91 2014-01-28 08:23:11 <CodeShark> base58 should only be for UI
92 2014-01-28 08:23:18 <sipa> CodeShark: absolutely agree
93 2014-01-28 08:23:32 <sipa> internally we don't use any base58 encoded data at all
94 2014-01-28 08:24:07 <sipa> afaik
95 2014-01-28 08:24:09 <wumpus> indeed, we don't do that already, we use the actual types such as CKey internally
96 2014-01-28 08:24:27 <wumpus> base58 is indeed used by RPC and the UI
97 2014-01-28 08:25:46 <CodeShark> ideally we should eventually move away from base58 as well and work on interoperability standards for application interfacing
98 2014-01-28 08:26:28 <sipa> sure base58 has no reason to exist in binary protocols
99 2014-01-28 08:26:40 <wumpus> that's happening already with the payment protocol AFAIK
100 2014-01-28 08:26:57 <sipa> correct, it encodes the output script directly
101 2014-01-28 08:27:08 <CodeShark> I prefer to think of base58 as a short-term solution as long as the only practical way to move this data between applications is the clipboard
102 2014-01-28 08:27:21 <sipa> that's probably fair
103 2014-01-28 08:28:04 <wumpus> which can store any kind of mime-typed data not just text :) but that doesn't make it easier for users generally
104 2014-01-28 08:28:18 <bitnumus> Hi, i'm trying to run bitcoind, but getting this error Unable to bind to 0.0.0.0:18333 on this computer. Bitcoin is probably already running.
105 2014-01-28 08:28:21 <bitnumus> nothing is running on that port
106 2014-01-28 08:28:39 <CodeShark> 18333?
107 2014-01-28 08:28:55 <Luke-Jr> CodeShark: testnet
108 2014-01-28 08:29:00 <bitnumus> uh huh
109 2014-01-28 08:29:11 <CodeShark> oh, right
110 2014-01-28 08:29:22 <Luke-Jr> bitnumus: my guess would be you're telling it to use the same port for p2p and RPC
111 2014-01-28 08:29:39 <bitnumus> Luke-Jr, i have no specific rpcport or anything set in config?
112 2014-01-28 08:29:58 <sipa> what are you setting?
113 2014-01-28 08:30:10 <bitnumus> daemon, rpcuser and pass
114 2014-01-28 08:30:24 <sipa> then it probably just already is running :)
115 2014-01-28 08:30:31 <bitnumus> its not hehe
116 2014-01-28 08:30:49 <Luke-Jr> bitnumus: not even another client?
117 2014-01-28 08:30:49 <sipa> ps ax | fgrep bitcoind
118 2014-01-28 08:30:55 <Luke-Jr> eg, Bitcoin-Qt
119 2014-01-28 08:31:04 <wumpus> anyway I'm going to add the key validity check in importprivkey method itself for now, it's most transparent
120 2014-01-28 08:31:14 <bitnumus> no, but i am trying to run it inside an emulated ARM container
121 2014-01-28 08:31:14 <sipa> wumpus: sgtm
122 2014-01-28 08:31:26 <bitnumus> maybe my networking is screwed, but it worked fine on another box
123 2014-01-28 08:31:28 <Luke-Jr> ._.
124 2014-01-28 08:31:36 <Luke-Jr> bitnumus: nc -l -p 18333
125 2014-01-28 08:33:36 <bitnumus> tried running bitcoind and it threw this > ERROR: CAddrman::Read() : open failed
126 2014-01-28 08:33:52 <bitnumus> and seems its stuck at > dumpaddr thread start
127 2014-01-28 08:33:58 <sipa> permission problem?
128 2014-01-28 08:34:06 <sipa> disk full?
129 2014-01-28 08:34:25 <bitnumus> no and no
130 2014-01-28 08:34:28 <bitnumus> argh
131 2014-01-28 08:34:49 <sipa> oh, if it crashed it may take a minute or so before the OS releases that tcp port
132 2014-01-28 08:35:00 <bitnumus> that could be the first issue i guess yea
133 2014-01-28 08:36:42 <bitnumus> ok, none testnet is working, let me try testnet again
134 2014-01-28 08:38:31 <bitnumus> Just stops here > Opened LevelDB successfully
135 2014-01-28 08:38:50 <bitnumus> same as before with the port error, but main net ran ok with this
136 2014-01-28 08:41:58 <bitnumus> seeing as it works ok on clean run, could be a wallet issue
137 2014-01-28 08:42:04 <bitnumus> no decent error messages though
138 2014-01-28 09:51:35 <bitnumus> ok, please dont flame :)
139 2014-01-28 09:51:47 <bitnumus> is the blockchain needed at all to broadcast transactions ?
140 2014-01-28 09:52:10 <brisque> no.
141 2014-01-28 09:52:23 <t7> blockchain is for confirming
142 2014-01-28 09:52:43 <bitnumus> hi t7 :)
143 2014-01-28 09:52:51 <bitnumus> so i take it there is no switch to stop the sync ?
144 2014-01-28 09:53:00 <brisque> no.
145 2014-01-28 09:53:05 <bitnumus> booo
146 2014-01-28 09:54:18 <stonecoldpat> well you can create the transaction and just not send it to the network
147 2014-01-28 09:54:28 <brisque> bitnumus: I thought you were referring to the technical side rather than from a copy of Bitcoin-QT. there's nothing stopping you from broadcasting a transaction by talking directly to a peer on the network, but the client itself won't know about recent transactions in order to spend them.
148 2014-01-28 09:57:26 <bitnumus> brisque, is a transaction is literally bounce off a wallet, this is the scenario
149 2014-01-28 09:57:28 <bitnumus> if*
150 2014-01-28 09:58:03 <bitnumus> so payment made from A to B, and B instantly sends it to C, does B need a copy of the chain ?
151 2014-01-28 09:58:25 <bitnumus> i was under the impression transactions weren't broadcast unless the chain was synced, maybe that was an older version
152 2014-01-28 09:59:25 <brisque> you can broadcast anything you want with a custom client. I don't see why you would want to do as you described. you can do things like that, but B would really be blind to what is happening on the network and extremely vulnerable.
153 2014-01-28 10:02:27 <bitnumus> only interested in bitcoind
154 2014-01-28 10:03:14 <brisque> then no. clients need to be synced.
155 2014-01-28 10:04:06 <bitnumus> it worked the other day, it wasn't synced, was 40blocks short yea it received and sent the coins
156 2014-01-28 10:04:14 <bitnumus> so is that a bug, or ?
157 2014-01-28 10:04:50 <wumpus> you can spend your unconfirmed coins, there was a discussion about that yesterday if you scroll back a bit
158 2014-01-28 10:05:42 <wumpus> you'll spend more on fees though as the fee estimation depends on the depth of the inputs in the chain
159 2014-01-28 10:05:45 <bitnumus> hmm, not enough scroll here it seems, any docs on this ?
160 2014-01-28 10:06:27 <brisque> bitnumus: bitcoinstats.com
161 2014-01-28 10:06:51 <bitnumus> ta
162 2014-01-28 10:06:59 <sipa> wumpus: not really
163 2014-01-28 10:07:24 <sipa> wumpus: either the transaction qualifies as free (which is rare now), or not
164 2014-01-28 10:07:30 <wumpus> sipa: hm I remember some issues about that, but I my be mistaken...
165 2014-01-28 10:07:34 <sipa> if it's not, the fee is just per kilobyte
166 2014-01-28 10:08:43 <wumpus> sipa: #1858
167 2014-01-28 10:08:55 <wumpus> if that isn't an issue, I'll just close it
168 2014-01-28 10:09:26 <sipa> wumpus: no, it's correct - the confirmations will impact whether a fee is required or not
169 2014-01-28 10:09:35 <sipa> but it won't impact what is considered a sufficient fee
170 2014-01-28 10:12:07 <wumpus> okay
171 2014-01-28 10:30:23 <TD> good morning all
172 2014-01-28 10:46:13 <wumpus> morning TD
173 2014-01-28 10:46:21 <TD> hi there
174 2014-01-28 10:53:46 <t7> do txs have a timeout ?
175 2014-01-28 10:53:51 <sipa> no
176 2014-01-28 10:54:50 <t7> would it be good if you could specify one ?
177 2014-01-28 10:55:01 <sipa> depends on the semantics
178 2014-01-28 10:55:18 <sipa> transactions becoming invalid after a particular time wouldn't work
179 2014-01-28 10:55:28 <sipa> but expiration from mempools is possible
180 2014-01-28 10:55:32 <sipa> just tricky
181 2014-01-28 11:09:12 <[Author]> fyi new testnet faucet http://faucet.luis.im/
182 2014-01-28 11:31:15 <t7> heheh
183 2014-01-28 16:17:01 <optimator> Is there a practical limit or hard maximum for txout in a transaction?
184 2014-01-28 16:18:07 <andytoshi> optimator: gavin answered you in the other channel. for reference he said >1MB can't fit in a block, >100kb is not standard
185 2014-01-28 16:18:38 <optimator> andytoshi: thanks!
186 2014-01-28 16:19:44 <Sp0tter> is there a way to limit the ram usage of bitcoind? it is using > 700M resident
187 2014-01-28 16:21:26 <jgarzik> optimator, andytoshi : and there are also sigop limits
188 2014-01-28 16:24:36 <gavinandresen> optimator: that would be an excellent question for bitcoin.stackexchange.com ....
189 2014-01-28 16:25:02 <Ademan> ugh, so I'm trying to build bitcoind from source from git, but it's trying to pull in wxwidgets... Am I building the wrong repo, or does bitcoind use wxwidgets for some non-GUI stuff?
190 2014-01-28 16:25:17 <jgarzik> Ademan, wrong version, at a minimum
191 2014-01-28 16:25:34 <jgarzik> Ademan, latest version uses git. git://github.com/bitcoin/bitcoin.git
192 2014-01-28 16:25:41 <jgarzik> er, latest version uses Qt
193 2014-01-28 16:25:42 <phantomcircuit> Ademan, bitcoin hasn't used wxwidgets in a very long time
194 2014-01-28 16:25:50 <phantomcircuit> so im assuming you're building an altcoin
195 2014-01-28 16:25:52 <Ademan> jgarzik: that's what I thought... huh...
196 2014-01-28 16:26:00 <Ademan> 'sec
197 2014-01-28 16:26:02 <optimator> gavinandresen: ok I'll take it there - thanks
198 2014-01-28 16:27:28 <Ademan> oh wow, yeah that was an ancient checkout of mine... I did a git pull but didn't notice it didn't merge what it pulled. Sorry folks!
199 2014-01-28 16:36:46 <michagogo> cloud|Ademan: yeah, you'll want to checkout either master or v0.8.6
200 2014-01-28 16:44:29 <sipa> Ademan: that must have been a *really* old checkout )
201 2014-01-28 16:45:24 <sipa> Qt was merged in sept 2011
202 2014-01-28 16:47:30 <Ademan> sipa: it must have been, I don't dev on this machine much but I couldn't imagine it was *that* old...
203 2014-01-28 16:49:01 <Ademan> if only I had tried mining that long ago...
204 2014-01-28 16:57:30 <Ademan> So has anyone taken a look at the technical aspects of ethereum? I still have yet to get an answer from the devs on how they plan to reconcile a turing complete language and per-cycle (after the first 16) fees...
205 2014-01-28 17:03:32 <oleganza> Hi there. Does anyone know if there's a way to combine two ECDSA signatures of the same hash in a third valid signature which can be verified by a combination of public keys involved in the source signatures?
206 2014-01-28 17:04:54 <oleganza> like, two guys sign the same document together and then combine their signatures in one which is verifieable with some DH-style public key derived from their keys
207 2014-01-28 17:13:34 <ThomasV> am I the only one to have problems with github.com (only web, git is fine)
208 2014-01-28 17:17:37 <TD> ThomasV: seems to be working ok for me
209 2014-01-28 17:21:22 <ThomasV> I get a 408
210 2014-01-28 17:21:30 <TD> 408? that's new
211 2014-01-28 17:21:45 <ThomasV> on this page for example: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
212 2014-01-28 17:22:17 <ThomasV> some pages work
213 2014-01-28 17:22:54 <TD> that page works for me. perhaps a regional issue
214 2014-01-28 18:12:13 <niston> is there a possibility to use bitcoin as a locator for other p2p services?
215 2014-01-28 18:18:29 <EasyAt> niston: What do you mean?
216 2014-01-28 18:18:36 <EasyAt> For peer discovery?
217 2014-01-28 18:18:40 <niston> yes.
218 2014-01-28 18:18:54 <BlueMatt> there are better ways of doing peer discovery
219 2014-01-28 18:18:58 <BlueMatt> like...far, far, far better
220 2014-01-28 18:19:27 <phantomcircuit> like scanning 0.0.0.0/0
221 2014-01-28 18:19:28 <niston> how does bitcoind do it?
222 2014-01-28 18:19:37 <niston> initial peer list?
223 2014-01-28 18:20:02 <phantomcircuit> magic
224 2014-01-28 18:20:21 <swulf--> dns seeds
225 2014-01-28 18:21:00 <niston> reading up https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery
226 2014-01-28 18:36:06 <jcorgan> lol, America = Freedom, nice touch
227 2014-01-28 18:37:47 <jcorgan> sorry, that was supposed to be in #bitcoin
228 2014-01-28 18:43:58 <orion> Hi. I am running bitcoin-qt 0.8.6 on FreeBSD 10.0. I am getting a major crash in the client when it tries to sync the chain:
229 2014-01-28 18:44:05 <orion> Assertion failed: (internal_key.size() >= 8), function ExtractUserKey, file ./db/dbformat.h, line 99.
230 2014-01-28 18:44:10 <orion> Does anyone know what could be going wrong?
231 2014-01-28 19:11:30 <justanotheruser> Is an M of N transaction M of N pubkeyhashes or M of N pubkeys? If it is M of N pubkeys, why isn't it M of N pubkeyhashes? That seems like it would make it significantly easier.
232 2014-01-28 19:11:49 <sipa> why is it easier?
233 2014-01-28 19:11:55 <sipa> you need to ask the receiver anyway?
234 2014-01-28 19:12:03 <sipa> 20 or 33 bytes doesn't make much difference, i hope
235 2014-01-28 19:12:08 <justanotheruser> sipa: because you can just give someone your address
236 2014-01-28 19:12:22 <justanotheruser> It is less complicated for the average user
237 2014-01-28 19:12:27 <justanotheruser> But is that a no?
238 2014-01-28 19:12:37 <sipa> i don't think the average user should use multisig transactions directly :)
239 2014-01-28 19:12:52 <sipa> indeed, CHECKMULTSIG requires the pubkeys
240 2014-01-28 19:12:56 <justanotheruser> sipa: I think they should if it is easy to understand
241 2014-01-28 19:14:55 <sipa> the process is easy enough; the difficulty part is coordination between the receivers
242 2014-01-28 19:15:42 <sipa> and even if it was pubkeyhashes, the receivers would still need to reveal the pubkeys when spending it
243 2014-01-28 19:15:47 <sipa> which again requires coordination
244 2014-01-28 19:16:04 <sipa> you can just as well do it in advance when setting up the multisig address
245 2014-01-28 19:30:20 <justanotheruser> sipa: yes, but I just think it is more user friendly to use addresses. Also, I assume it would save some space in the tx, right?
246 2014-01-28 19:31:49 <sipa> justanotheruser: imho, any time a user needs to see an address, we're doing it wrong
247 2014-01-28 19:31:51 <shesek> justanotheruser, not really, the tx funding the multisig is usually p2sh
248 2014-01-28 19:32:04 <shesek> so its already a single hash of everything
249 2014-01-28 19:32:14 <shesek> and the spending transaction would be about the same
250 2014-01-28 19:32:14 <sipa> the spending transaction would be significantly larger
251 2014-01-28 19:32:21 <justanotheruser> shesek: good point
252 2014-01-28 19:32:22 <sipa> as checkmultisig couldn't be usedf
253 2014-01-28 19:33:02 <justanotheruser> sipa: yes, I know that. That is why I'm saying there should be a checkmultisighash so it can be small
254 2014-01-28 19:33:15 <sipa> justanotheruser: that would require a hard fork
255 2014-01-28 19:33:29 <justanotheruser> sipa: or a soft fork with spv security I think
256 2014-01-28 19:33:44 <maaku> justanotheruser: simpler to add schnorr signatures
257 2014-01-28 19:34:02 <sipa> justanotheruser: not if it has similar semantics to checkmultisig now
258 2014-01-28 19:34:44 <justanotheruser> maaku: could you explain?
259 2014-01-28 19:35:09 <sipa> to do it as a softfork, you can only have an operation that either fails the check or has no effect at all
260 2014-01-28 19:35:14 <justanotheruser> sipa: even if it required a hard fork, would it not be better?
261 2014-01-28 19:35:21 <sipa> i don't see any advantage
262 2014-01-28 19:35:28 <gmaxwell> no it wouldn't, I also don't see any advantage.
263 2014-01-28 19:35:31 <sipa> i don't think we should encourage the use of addresses for this
264 2014-01-28 19:35:35 <sipa> for anything, really
265 2014-01-28 19:35:51 <maaku> schnorr is a different signature scheme system which allows you to construct public keys which can be signed by M-of-N different private keys
266 2014-01-28 19:36:09 <justanotheruser> sipa: layusers wouldn't have to deal with both their address and public key.
267 2014-01-28 19:36:21 <sipa> justanotheruser: layusers should not have to deal with either!
268 2014-01-28 19:36:25 <gmaxwell> one should absolutely never use some random address from another person for some purpose without knowing that that purpose is okay. What happens when you use an address that they have embeeded in a mtgox account or in a hardware device and cannot actually freely sign with?
269 2014-01-28 19:36:28 <justanotheruser> I guess it isn't that big of a deal, but I think it would be slightly better
270 2014-01-28 19:36:32 <sipa> the software should do all the coordination behind the scenes
271 2014-01-28 19:36:48 <gmaxwell> maaku: though for M of N you must use an interactive protocol to create the key.
272 2014-01-28 19:36:51 <sipa> if they need to interact with public keys or addresses or any crypto material at all, we're doing it wrong
273 2014-01-28 19:37:17 <justanotheruser> gmaxwell: same is true with a public key
274 2014-01-28 19:37:47 <sipa> gmaxwell: the problem is that addresses are (unfortunately) accepted as something you can reuse, and observe
275 2014-01-28 19:37:54 <gmaxwell> justanotheruser: uh, why do you think I was implying other wise?
276 2014-01-28 19:37:54 <sipa> eh, justanotheruser
277 2014-01-28 19:37:58 <maaku> gmaxwell: sure, but you can always fallback to multiple pubkeys in the script for non-interactive use
278 2014-01-28 19:38:09 <gmaxwell> justanotheruser: once you need to confirm the usage you can get the right, acceptable, value for it.
279 2014-01-28 19:38:21 <gmaxwell> maaku: just wasn't sure if you were aware of that.
280 2014-01-28 19:39:06 <maaku> gmaxwell: thx, its an important limitation to bring up regardless
281 2014-01-28 19:40:00 <justanotheruser> I suppose it isn't too much trouble to use a public key. Now that I think about it, the term "address" would probably confuse people when they realize it can be used in M of N addresses, while a "key" can be used to unlock them
282 2014-01-28 19:40:08 <gmaxwell> maaku: it doesn't exist for N of N, for N of N you can just compute it directly.
283 2014-01-28 19:41:04 <sipa> justanotheruser: much of the confusion imho is due to failure to distinguish the current base58 strings when used as an identifier for a key, and when used as a destination for a transaction
284 2014-01-28 19:41:15 <sipa> it's only an address if someone is actually willing to accept coins on it
285 2014-01-28 19:41:35 <maaku> gmaxwell: wait, so for N-of-N you can compute the combined key offline/non-interactively?
286 2014-01-28 19:41:38 <maaku> i didn't know that
287 2014-01-28 19:43:10 <gmaxwell> maaku: yea, IIRC it's just a sum of pubkeys.
288 2014-01-28 19:43:56 <justanotheruser> Okay, well I guess my idea of checkmultisighash just got #rekt
289 2014-01-28 19:44:42 <maaku> justanotheruser: it's just a matter of cost/benefit
290 2014-01-28 19:44:53 <sipa> i don't think there's any benefit :)
291 2014-01-28 19:45:01 <maaku> key revelation is in the scriptSig, so there isn't much benefit
292 2014-01-28 19:45:06 <sipa> (apart from saving 13 bytes per key in the coordination protocol)
293 2014-01-28 19:45:38 <justanotheruser> sipa: so about 0.0000000001btc is saved ;)
294 2014-01-28 19:54:29 <chichov> is there an efficient look-up table or other measure deployed for efficient transaction lookup?
295 2014-01-28 19:55:03 <sipa> chichov: we don't need to look up transactions :)
296 2014-01-28 19:55:08 <chichov> it seems rather costly to scan through the whole blockchain to find just one transaction and verify a signature
297 2014-01-28 19:55:13 <sipa> but there's a rather efficient database with just unspent outputs
298 2014-01-28 19:55:20 <chichov> well, miners have to
299 2014-01-28 19:55:24 <sipa> which is exactly what is needed during verification
300 2014-01-28 19:55:28 <sipa> no, they don't
301 2014-01-28 19:55:38 <chichov> oh, so they do have a database of unspent outputs
302 2014-01-28 19:55:46 <sipa> every full node does, yes
303 2014-01-28 19:55:53 <chichov> now that's interesting
304 2014-01-28 19:55:56 <sipa> it's in $DATADIR/chainstate
305 2014-01-28 19:56:24 <chichov> what is precisely stored in such an entry?
306 2014-01-28 19:56:39 <chichov> the complete unspent transaction information?
307 2014-01-28 19:56:49 <sipa> no, only the transaction outputs
308 2014-01-28 19:56:54 <sipa> and only those that are not yet spent
309 2014-01-28 19:57:16 <gmaxwell> all the data which is needed to verify an incoming block that spends the transaction, and nothing more.
310 2014-01-28 19:57:36 <sipa> (plus a bit of metadata about the transaction itself, like whether it's a coinbase, in which block height it was included, and which version)
311 2014-01-28 19:57:46 <chichov> so eg the hash of the transaction and the unspent output parts
312 2014-01-28 19:58:00 <sipa> https://github.com/bitcoin/bitcoin/blob/master/src/coins.h#L17
313 2014-01-28 19:58:06 <sipa> use the source, luke
314 2014-01-28 19:58:20 <chichov> hehe, was about to ask for one
315 2014-01-28 19:58:40 <chichov> I suppose this is the class for the chainstate encoding?
316 2014-01-28 19:58:47 <sipa> correct
317 2014-01-28 19:58:58 <chichov> excellent, thanks for the feedback
318 2014-01-28 19:59:04 <sipa> a CCoins object is the data about a transaction that is kept
319 2014-01-28 19:59:14 <sipa> the database is just a txid -> CCoins map
320 2014-01-28 20:02:25 <chichov> one thing remains a mystery
321 2014-01-28 20:02:37 <chichov> an output is referenced through the hash of the transaction and the index
322 2014-01-28 20:02:45 <sipa> correct
323 2014-01-28 20:02:52 <chichov> however, I don't see any hash of the transaction here
324 2014-01-28 20:03:05 <sipa> correct :)
325 2014-01-28 20:03:08 <sipa> 20:59:12 < sipa> the database is just a txid -> CCoins map
326 2014-01-28 20:03:21 <chichov> only the version, transaction type, address and index
327 2014-01-28 20:03:26 <sipa> CCoins does not encapsulate the key of the database entry, only the value
328 2014-01-28 20:03:31 <chichov> oh, txid is the hash?
329 2014-01-28 20:03:34 <sipa> yes
330 2014-01-28 20:03:37 <chichov> aaawww
331 2014-01-28 20:03:42 <sipa> transaction id = SHA256^2(tx)
332 2014-01-28 20:03:45 <chichov> now it's complete
333 2014-01-28 20:03:49 <sipa> :)
334 2014-01-28 20:04:06 <chichov> alright, all the building blocks are right here then
335 2014-01-28 20:04:46 <chichov> else lookups would be terribly inefficient
336 2014-01-28 20:04:53 <sipa> very much so
337 2014-01-28 20:05:12 <chichov> thanks for the help, I can continue with my report then
338 2014-01-28 20:05:46 <chichov> I was just wondering, once I'm done with my description of the bitcoin architecture, is there a place where I can submit it for a peer review?
339 2014-01-28 20:05:46 <sipa> yw :)
340 2014-01-28 20:06:14 <sipa> put it on the bitcoin.it wiki, and ask on the bitcoin-development list and/or forum for people to look at it?
341 2014-01-28 20:06:38 <chichov> alright, sounds like a fine solution
342 2014-01-28 20:07:51 <chichov> I'm working on a precise and comprehensible description of the core spec (without going in-depth on the P2P architecture)
343 2014-01-28 20:08:55 <chichov> and I'd be simply glad if my work could go through the process of public scrutiny and maybe function as a helpful future reference
344 2014-01-28 20:09:38 <chichov> not to digress too much - I'll follow your advice
345 2014-01-28 20:09:41 <chichov> thanks for the help
346 2014-01-28 20:20:02 <Luke-Jr> I'm seeing every 4 bytes of byte-data flipped accessing PCI-Express memory; is this likely because my host is LE, or is the PCI-E device actually putting the bytes out of order?
347 2014-01-28 20:24:06 <EasyAt> Does the reference client prefer to preserve anonymity by not collecting dust that is unnecessary to spend on a TX, or does it gather a bunch of dust in TXs to minimuze the UTXO set?
348 2014-01-28 20:25:35 <Luke-Jr> EasyAt: bitcoin is never anonymous
349 2014-01-28 20:26:17 <EasyAt> I didn't say it was
350 2014-01-28 20:27:01 <EasyAt> My question is whether it spends dust that isn't necessary in a TX in order to minimize UTXO even if it tains a few addresses
351 2014-01-28 20:38:12 <maaku> EasyAt: the reference client doesn't try to preserve anonymity at all, other than the bare minimum of using a random change address
352 2014-01-28 20:38:49 <maaku> assume all coins in you wallet are tainted with all other coins in you wallet (unless you applied the coin control patch and micromanage)
353 2014-01-28 20:41:45 <EasyAt> Oh neat
354 2014-01-28 20:41:52 <EasyAt> will the coin control patch be merged in/
355 2014-01-28 20:44:27 <EasyAt> Nvm, found the relevant bitcointalk thread
356 2014-01-28 20:51:25 <gmaxwell> EasyAt: fuck no it won't.
357 2014-01-28 20:51:30 <gmaxwell> ... because it was merged months ago.
358 2014-01-28 20:52:02 <EasyAt> heh
359 2014-01-28 20:52:46 <BlueMatt> gmaxwell: and its been many months since release.....
360 2014-01-28 21:30:21 <alex_fun> hello, in checkpoints file there is line // * estimated number of transactions per day after checkpoint , but how this estimated number is calculated?
361 2014-01-28 21:42:35 <diki> what exactly is a rendezvous point as it pertains ecdsa?
362 2014-01-28 21:43:08 <michagogo> cloud|alex_fun: there's no set formula, as far as I know
363 2014-01-28 21:43:30 <alex_fun> michagogo|cloud: so how it suppose to work?
364 2014-01-28 21:43:30 <michagogo> cloud|I think it's roughly just set to "how many transactions per day do we have these days"
365 2014-01-28 21:43:48 <alex_fun> interesting
366 2014-01-28 21:44:03 <michagogo> cloud|(I don't know what that value is used for or what implications it actually has)
367 2014-01-28 21:45:22 <alex_fun> michagogo|cloud: well before there is code that says static const CCheckpointData data = { &mapCheckpoints,
368 2014-01-28 21:45:38 <sipa> alex_fun: the progress bar uses as formula "how many transactions have we processed of the total estimated number"
369 2014-01-28 21:46:11 <sipa> where the total estimated number uses the last checkpoint's info + time_in_dayes * transactions_per_day
370 2014-01-28 21:49:28 <alex_fun> pretty simple and logical :)
371 2014-01-28 21:49:31 <alex_fun> ty
372 2014-01-28 21:52:40 <realazthat> is testnet getting like 2 blocks a second?
373 2014-01-28 21:52:45 <sipa> :o
374 2014-01-28 21:52:54 <alex_fun> much richness :D
375 2014-01-28 21:52:55 <realazthat> http://blockexplorer.com/testnet/q/getblockcount
376 2014-01-28 21:53:05 <sipa> such blocks, much test
377 2014-01-28 21:53:17 <realazthat> ok, sometimes slower
378 2014-01-28 21:53:22 <realazthat> but a few a minute
379 2014-01-28 21:53:27 <realazthat> why?
380 2014-01-28 21:53:51 <michagogo> cloud|realazthat: someone's pointing a lot of hashpower at it
381 2014-01-28 21:53:59 <realazthat> haha
382 2014-01-28 21:54:02 <realazthat> OK
383 2014-01-28 21:54:09 <realazthat> can someone send me some testnet coins
384 2014-01-28 21:54:17 <sipa> does faucet not work?
385 2014-01-28 21:54:29 <realazthat> one didn't, the other said payouts twice a day
386 2014-01-28 21:54:41 <realazthat> bit impatient
387 2014-01-28 21:54:51 <michagogo> cloud|realazthat: just post an address
388 2014-01-28 21:54:55 <realazthat> mkUiC8TKUdpEx6HFQRRpbwnUe7zRPSdT5K
389 2014-01-28 21:55:02 <realazthat> testnet address
390 2014-01-28 21:55:19 <michagogo> cloud|ACTION waits for his testnet node to start
391 2014-01-28 21:56:04 <diki> sipa:Did you see this? https://bitcointalk.org/index.php?topic=421842.0
392 2014-01-28 21:56:19 <sipa> no
393 2014-01-28 21:56:21 <alex_fun> sipa so how does your code calculate number of transactions per day without relying on block explorer?
394 2014-01-28 21:56:45 <alex_fun> yes some wallets hacking software, imo can be fake else why sell it for 2 btc :)
395 2014-01-28 21:57:13 <diki> the correct term is private key bruteforcer but meh :)
396 2014-01-28 21:57:25 <sipa> alex_fun: it doesn't calculate
397 2014-01-28 21:57:31 <sipa> alex_fun: it's hardcoded in the client
398 2014-01-28 21:57:40 <sipa> diki: meh
399 2014-01-28 21:58:02 <diki> I did wonder what a rendezvous point is though
400 2014-01-28 21:58:04 <alex_fun> sipa function to supply transactions per day is hard coded?
401 2014-01-28 21:58:22 <sipa> alex_fun: you just asked by pointing to the source code...
402 2014-01-28 21:58:24 <michagogo> cloud|alex_fun: Yes, that's the 60000 that you originally asked about
403 2014-01-28 21:58:33 <alex_fun> oki oki
404 2014-01-28 22:04:09 <michagogo> cloud|realazthat: fired a bunch of coin your way
405 2014-01-28 22:06:19 <realazthat> michagogo|cloud: thanks man :D
406 2014-01-28 22:08:55 <realazthat> awesome, my deposit system worked nicely :D
407 2014-01-28 22:09:11 <michagogo> cloud|realazthat: did it?
408 2014-01-28 22:09:15 <michagogo> cloud|Note that those coins are mined
409 2014-01-28 22:09:28 <realazthat> does that matter?