1 2013-12-26 00:33:41 <darsie> hi
2 2013-12-26 00:34:20 <darsie> If we wanted, we could change the parameters of bitcoin, such as inflation, right?
3 2013-12-26 00:35:06 <darsie> or confirmation period.
4 2013-12-26 00:35:48 <diki> depends
5 2013-12-26 00:36:09 <diki> on a fork, yes. On main code you need agreement from a lot of people
6 2013-12-26 00:36:54 <darsie> Would a majority of miners suffice to increase the reward?
7 2013-12-26 00:40:38 <darsie> By fork you mean something like litecoins?
8 2013-12-26 00:41:27 <diki> darsie:Yeah that kind of fork
9 2013-12-26 00:41:47 <diki> If you get enough people to use the changes you made, that will become the standard
10 2013-12-26 00:41:52 <diki> but somehow I doubt it
11 2013-12-26 00:42:20 <darsie> Well, if bitcoin becomes the major world currency and we feel it's bad, we might agree on a change.
12 2013-12-26 00:42:50 <darsie> I doubt that it would become that big, actually.
13 2013-12-26 00:43:58 <maaku> darsie: no, every single node would have to upgrade
14 2013-12-26 00:44:14 <maaku> you can't do that kind of change with majority (or even 100%) hashpower
15 2013-12-26 00:44:19 <ttsda> I am attempting to generate addresses from public keys, but I am running into an issue. When I follow all the steps in https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses I get the proper address, without the first character (1), how do I get that character programatically? I don't want to simply prepend the char because I also want to use this code for altcoins.
16 2013-12-26 00:45:22 <darsie> But being flexible might be a requirement to becoming a world currency.
17 2013-12-26 00:45:36 <maaku> darsie: define "being flexible"
18 2013-12-26 00:45:44 <maaku> ttsda: the one comes because of the version prefix
19 2013-12-26 00:46:08 <maaku> if you are in fact following the spec correctly, then that character should come out of the serialization naturally
20 2013-12-26 00:46:41 <maaku> did you follow this step : '4 - Add version byte in front of RIPEMD-160 hash (0x00 for Main Network)'
21 2013-12-26 00:47:18 <maaku> darsie: bitcoin works only because all nodes have agreed on an unchangeable set of rock-hard protocol rules
22 2013-12-26 00:47:23 <ttsda> maaku: I did
23 2013-12-26 00:47:26 <maaku> make them changeable and you destroy bitcoin
24 2013-12-26 00:47:34 <ttsda> maaku: Can you see anything wrong with my code? http://pastie.org/private/avxv91qrxsaxiycmsdza
25 2013-12-26 00:47:41 <maaku> ttsda: then you should be getting a 1 in your serialization
26 2013-12-26 00:47:46 <darsie> maaku: fiat has flexible policy, too.
27 2013-12-26 00:47:59 <maaku> because the first few bits would be all-zero, and zero in base58 is 1
28 2013-12-26 00:48:54 <maaku> why the hex encoding and hex2bin?
29 2013-12-26 00:49:19 <ttsda> I think I just figured out what's wrong, let me just test
30 2013-12-26 00:49:52 <ttsda> Nope
31 2013-12-26 00:50:01 <sipa> darsie: the economic policy is pretty much bitcoin's most fundamental rule. not because it's necessarily the best one, but because one has to be set in stone by the protocol
32 2013-12-26 00:50:26 <deanclkclk> can someone explain to me how bitcoin uses encryption?
33 2013-12-26 00:50:32 <ttsda> maaku: I am converting an hex public key to an address
34 2013-12-26 00:50:43 <sipa> darsie: it could be changed by modifying every single node in the network, but imho it would not be bitcoin at all
35 2013-12-26 00:50:45 <maaku> deanclkclk: simple. it doesn't use encryption
36 2013-12-26 00:50:59 <deanclkclk> what?
37 2013-12-26 00:51:01 <petertodd> sipa: currently every single ful node...
38 2013-12-26 00:51:03 <sipa> deanclkclk: only locally for passphrase-encrypted wallets
39 2013-12-26 00:51:04 <ttsda> deanclkclk: It uses hashing
40 2013-12-26 00:51:08 <deanclkclk> now I'm confused
41 2013-12-26 00:51:14 <sipa> hashing and digital signatures
42 2013-12-26 00:51:18 <sipa> no encryption
43 2013-12-26 00:51:35 <deanclkclk> how does it use the hash?
44 2013-12-26 00:51:52 <sipa> bitcoin uses hashes in about a dozen places
45 2013-12-26 00:52:11 <maaku> deanclkclk: to identify blocks and transactions, and proof of work, and checksums
46 2013-12-26 00:52:20 <deanclkclk> the address I send to receive funds..isn't that a hash/digest?
47 2013-12-26 00:52:32 <darsie> sipa: But if a (vast) majority adopted the change, the minority would follow or fail with transactions accepted by the majority.
48 2013-12-26 00:52:36 <ttsda> Just got it maaku, my code was ignoring the leading 0s
49 2013-12-26 00:52:37 <maaku> and to summarize scripts and pubkeys, and maybe one or two places i'm forgetting
50 2013-12-26 00:52:42 <ttsda> Thanks for the help
51 2013-12-26 00:52:45 <sipa> darsie: yes, so?
52 2013-12-26 00:52:46 <petertodd> darsie: there's a lot of theory about what power miners have to change the protocol rules, but until we see them try to do something liek change the inflation rate we're not really going to know; it's a politics question as well as technical
53 2013-12-26 00:52:48 <maaku> np
54 2013-12-26 00:53:01 <sipa> darsie: what is that minority includes bitpay and mtgox?
55 2013-12-26 00:53:08 <sipa> *if
56 2013-12-26 00:53:09 <deanclkclk> when i read the docs...it gets confusing how BTC uses encryption/hash
57 2013-12-26 00:53:50 <sipa> encryption and hashing and digital signatures are all cryptographic primitives, but they are not the same
58 2013-12-26 00:54:01 <sipa> abd any document that mentions encryption is wrong
59 2013-12-26 00:55:40 <deanclkclk> so what is an address?
60 2013-12-26 00:55:49 <deanclkclk> is that a public key to encrypt something?
61 2013-12-26 00:55:50 <sipa> the hash of a public key
62 2013-12-26 00:56:02 <sipa> no, the public key is used to verify signatures
63 2013-12-26 00:56:55 <sipa> a bitcoin transaction is (simplified) a digitally signed message that transfers owner ship of coins to a new address
64 2013-12-26 00:57:27 <sipa> and it is signed by the private key corresponding to the public key whose hash (address) previously held the coins
65 2013-12-26 00:57:29 <maaku> or the hash of a script
66 2013-12-26 00:57:39 <maaku> (addresses starting with '3')
67 2013-12-26 00:57:43 <sipa> maaku: keep it simple :)
68 2013-12-26 01:01:22 <maaku> deanclkclk: the public key is only used for signing, not encryption
69 2013-12-26 01:02:14 <deanclkclk> how can I sign a message (reciever) but, the sender is the one who has the message?
70 2013-12-26 01:03:47 <maaku> deanclkclk: can you explain a little better, that sounds backwards
71 2013-12-26 01:03:58 <deanclkclk> ok
72 2013-12-26 01:04:11 <deanclkclk> so I'm saying how can I sign a message I don't have
73 2013-12-26 01:04:44 <deanclkclk> the message is coming from the sender
74 2013-12-26 01:05:01 <sipa> the sender is the one who creates the transaction, and signs it
75 2013-12-26 01:05:28 <sipa> and he uses the private key of the address the coins _previously_ belonged to
76 2013-12-26 01:05:29 <deanclkclk> so by sending with my hash...it decrypts it and gets my public key?
77 2013-12-26 01:05:44 <sipa> there is no encryption or decryption anywhere
78 2013-12-26 01:06:07 <deanclkclk> ok..how do you say unhash to get to my public key
79 2013-12-26 01:06:18 <darsie> I signature is an encrypted hash of a message, right?
80 2013-12-26 01:06:29 <Luke-Jr> deanclkclk: an address is a one-time use token that points to an account and represents the full meaning of the payment.
81 2013-12-26 01:06:36 <darsie> s/I/A
82 2013-12-26 01:06:36 <sipa> when sending, you also reveal the full publoc key the coins belonged to
83 2013-12-26 01:07:07 <sipa> to verify, you check that that public key matches the address the coins where previously sent to, and whether the signature is valid for that public key
84 2013-12-26 01:07:08 <Luke-Jr> deanclkclk: technically, it is implemented as a hash of a script (or ECDSA public key), but that is opaque from the user level
85 2013-12-26 01:07:50 <deanclkclk> low level speak plz Luke-Jr
86 2013-12-26 01:07:57 <deanclkclk> ok sipa I think i'm following you
87 2013-12-26 01:08:02 <Luke-Jr> deanclkclk: addresses are a highlevel concept, they don't exist lowlevel
88 2013-12-26 01:08:23 <Luke-Jr> low-level, you just have scripts
89 2013-12-26 01:08:43 <deanclkclk> I meant using Layman's Luke-Jr
90 2013-12-26 01:08:49 <edcba> why "one-time use" ?
91 2013-12-26 01:08:53 <Luke-Jr> deanclkclk: layman is high-level
92 2013-12-26 01:09:00 <deanclkclk> ok
93 2013-12-26 01:09:15 <Luke-Jr> edcba: to a layman, an address is merely a single-use token representing an invoice
94 2013-12-26 01:09:25 <Luke-Jr> deanclkclk*^
95 2013-12-26 01:09:49 <edcba> that's how you interpret it
96 2013-12-26 01:09:52 <Luke-Jr> edcba: because Bitcoin was designed with the assumption that addresses are used once only, and the system gradually breaks down otherwise
97 2013-12-26 01:10:22 <edcba> i didn't see that mentioned in pdf
98 2013-12-26 01:10:45 <Luke-Jr> look again
99 2013-12-26 01:12:30 <sipa> addresses are certainly intended to not be reused - doing so hurts the privacy of the bitcoin sysyem as a whole (not just for yourself) significantly
100 2013-12-26 01:13:16 <sipa> so far, preventing reuse has been hard, as we have no mechanism for negotiating addresses on the fly (anymore, very early in bitcoin's history that did exist, though very ibsecurely)
101 2013-12-26 01:13:27 <sipa> the payment protocol brings that back
102 2013-12-26 01:16:35 <monolithik> "As an additional firewall, a new key pair should be used for each transaction to keep them "
103 2013-12-26 01:16:41 <monolithik> from being linked to a common owner""
104 2013-12-26 01:17:13 <monolithik> straight from the satoshi paper, section 10
105 2013-12-26 01:17:19 <deanclkclk> but, sipa when sending does the sender "unhash" my previously hashed public key to send it?
106 2013-12-26 01:17:27 <sipa> no
107 2013-12-26 01:17:32 <sipa> you cannot u hash
108 2013-12-26 01:17:36 <sipa> unhash
109 2013-12-26 01:17:43 <phantomcircuit> sipa, i will unhash you
110 2013-12-26 01:17:56 <sipa> and he doesn't need to, as he has the private key, he also has the full public key
111 2013-12-26 01:18:01 <deanclkclk> so the sender just sends back the hash I previously sent?
112 2013-12-26 01:18:07 <upb> yes, the sender derieves the public key from the hash and then the private key from the public key
113 2013-12-26 01:18:22 <sipa> deanclkclk: who is 'you' in the story?
114 2013-12-26 01:18:39 <monolithik> perhaps move this conversation to #bitcoin ?
115 2013-12-26 01:19:01 <sipa> well, i'm not in #bitcoin, but it certainly belongs there :)
116 2013-12-26 01:19:55 <deanclkclk> huh upb I'm confused. You and sipa saying two different things
117 2013-12-26 01:20:10 <edcba> Luke-Jr: a new keypair *should*
118 2013-12-26 01:20:25 <sipa> deanclkclk: upb was saying nonsense
119 2013-12-26 01:20:48 <deanclkclk> hard to read through all the chatter
120 2013-12-26 01:20:53 <sipa> deanclkclk: it should be obvious that you cannot derive the public key from the address, or the private key from the public key
121 2013-12-26 01:20:55 <deanclkclk> but, I'm following you sipa
122 2013-12-26 01:21:04 <sipa> deanclkclk: perhaps learn a bit more first :)
123 2013-12-26 01:21:09 <monolithik> edcba: not sure the meaning of 'should' is quite as specific in that context, it isn't an RFC
124 2013-12-26 01:21:56 <monolithik> as opposed to say: http://www.ietf.org/rfc/rfc2119.txt
125 2013-12-26 01:22:02 <edcba> for me it just signals it wasn't assumed that it was an assumption
126 2013-12-26 01:22:13 <sipa> edcba: it's how bitcoin was designed; of course you can use it elseway, but as i said, address reuse seriously hurts the privacy of the system
127 2013-12-26 01:22:39 <deanclkclk> so just to reinterate sipa . The sender gets the hash and send the coin along with the hash ...broadcasting to the network that whoever has the private key of the hash is the owner?
128 2013-12-26 01:22:59 <edcba> ok but we shouldn't forbid them imo
129 2013-12-26 01:23:12 <sipa> edcba: if i could, i would forbid it :)
130 2013-12-26 01:23:23 <Luke-Jr> edcba: reuse is "doing it wrong"
131 2013-12-26 01:23:43 <edcba> i don't like false security/privacy
132 2013-12-26 01:23:44 <sipa> there is no reason at all for reuse except lack pf infrastructure to avoid it
133 2013-12-26 01:24:07 <Luke-Jr> edcba: reuse compromises REAL security/privacy
134 2013-12-26 01:24:10 <monolithik> well, what if a business wants to put a QR code on an ad or something.
135 2013-12-26 01:24:11 <sipa> the privacy benefit is hardly worth mentioning
136 2013-12-26 01:24:20 <sipa> eh, security
137 2013-12-26 01:24:29 <sipa> but the privacy impact is very significant
138 2013-12-26 01:24:41 <Luke-Jr> monolithik: then they put a QR code
139 2013-12-26 01:24:44 <sipa> and no, it is bot enough to obtain full privacy
140 2013-12-26 01:25:07 <sipa> monolithik: then they should put a payment protocol uri on the qr code
141 2013-12-26 01:25:55 <sipa> (not yet, of course)
142 2013-12-26 01:27:53 <monolithik> yeah. I get why reuse is bad from a technical perspective, but when dealing with non-technical folks who are going to try to relate bitcoin addresses to things they know (phone numbers, cc numbers, email addresses, etc) they may have some difficulty understanding the reason for reuse if privacy is not a priority. Obviously this can be mitigated by having clients do it by default, etc.
143 2013-12-26 01:28:53 <petertodd> monolithik: we can probably provide users with a new address type where all payments made to it are only visible to the receiver FWIW
144 2013-12-26 01:29:33 <Luke-Jr> monolithik: addresses are nothing like phone numbers, cc numbers, email addresses, etc
145 2013-12-26 01:29:53 <Luke-Jr> monolithik: I prefer the term "invoice id" as it more accurately reflects on the nature of the "keyword"
146 2013-12-26 01:29:54 <monolithik> I didn't say they were. Only that non-technical people would be likely to consider them so
147 2013-12-26 01:30:27 <petertodd> monolithik: yup, so change the software and system to match their expectations while still providing their expectations of privacy
148 2013-12-26 01:30:31 <edcba> dynamic ip ? :)
149 2013-12-26 01:30:43 <Luke-Jr> edcba: most people don't even know what an IP is
150 2013-12-26 01:30:43 <monolithik> remember: the success of BTC is contingent on people being able to use it properly without understanding the internal workings, like any other technology
151 2013-12-26 01:31:04 <monolithik> petertodd: agreed.
152 2013-12-26 01:31:06 <edcba> change ip every site you want to access to keep privacy
153 2013-12-26 01:31:11 <Luke-Jr> monolithik: it's hard to beat payment protocol for that
154 2013-12-26 01:34:17 <monolithik> petertodd: unrelated, but I've been following the passport/fidelity bond threads, and do you still think OP_RETURN is the best way to do the sacrifice? I agree that sacrificing to miners poses incentive issues, but throwing away coins is disatisfying
155 2013-12-26 01:34:49 <petertodd> monolithik: yes, the economics of any sacrifice where someone gets the reward in the short term lead to pretty ugly incentives to centralize
156 2013-12-26 01:35:11 <petertodd> monolithik: I was quite naive to propose sacrifice-to-fees in the first place frankly
157 2013-12-26 01:35:33 <berndj> does payment protocol allow for having more than one signature of one's public key?
158 2013-12-26 01:36:08 <monolithik> petertodd: yeah, it seems bad to have to split the sacrifice up over multiple blocks, and even then that is only a short term solution
159 2013-12-26 01:36:29 <Luke-Jr> berndj: never necessary.
160 2013-12-26 01:36:35 <petertodd> monolithik: oh, that's not a good mechanism, use annoucne-commit sacrifices for that
161 2013-12-26 01:37:05 <berndj> Luke-Jr, ok, so then everybody has the incentive to just use the already most popular CA?
162 2013-12-26 01:37:06 <petertodd> monolithik: but in general, sacrifice to unspendable is the only safe thing until some way of locking a txout for a few months at least is implemented
163 2013-12-26 01:37:49 <monolithik> OK. I've been wanting to implement something SIN-like, so I might go with that for now
164 2013-12-26 01:38:00 <petertodd> monolithik: go for it
165 2013-12-26 01:38:03 <Luke-Jr> berndj: what?
166 2013-12-26 01:39:37 <berndj> Luke-Jr: http://lair.fifthhorseman.net/~dkg/tls-centralization/ search for "encourage concentration"
167 2013-12-26 01:40:42 <berndj> Luke-Jr: "Remember that a TLS (HTTPS) server can only offer a single certificate." that sets up the incentive to just use whichever CA already has the largest trust footprint
168 2013-12-26 01:41:32 <Luke-Jr> berndj: you can offer a certificate signed by multiple CAs, afaik
169 2013-12-26 01:41:50 <Luke-Jr> but I'm not sure TLS's issues are on-topic here anyway
170 2013-12-26 01:42:08 <Luke-Jr> namecoin is the solution to that
171 2013-12-26 01:42:12 <Luke-Jr> (and DNSSEC maybe?)
172 2013-12-26 01:42:13 <berndj> the way i understood it was that your (single!) certificate has to come first, followed by a chain of certs to get to a root CA
173 2013-12-26 01:42:53 <berndj> Luke-Jr: i think it's relevant if it introduces an incentive to centralize
174 2013-12-26 01:43:20 <Luke-Jr> The CA model is inherently already centralised.
175 2013-12-26 01:43:30 <Luke-Jr> TLS can be used for a decentralised system like namecoin thoguh
176 2013-12-26 02:19:45 <deanclkclk> can someone explain this to me? This record is known as a generation transaction, or a coinbase transaction, and is always the first transaction appearing in every block
177 2013-12-26 02:20:16 <deanclkclk> so each time that a block is solved....isn't the miner that solved the problem gets the bitcoins?
178 2013-12-26 02:20:30 <deanclkclk> is the miner address the same as the receiver address or coinbase tranaction?
179 2013-12-26 02:22:46 <upb> a transaction is not an address, they are different concepts
180 2013-12-26 03:53:09 <wallet43> hi! whats the base58 version byte for testnet private keys where the pubkey is compressed?
181 2013-12-26 04:32:33 <andytoshi> wallet43: 6f i think
182 2013-12-26 04:32:37 <andytoshi> or 111
183 2013-12-26 04:33:50 <wallet43> zomg
184 2013-12-26 04:34:02 <wallet43> no i got it wrong all the time -__-
185 2013-12-26 04:34:43 <wallet43> the difference between compressed and not compressed is not the version byte but an \x01 after the privkey
186 2013-12-26 04:35:26 <wallet43> i thought it was a different version byte since compressed and uncomressed had different starting chars in b58check format
187 2013-12-26 05:29:13 <CodeShark> who is currently in charge of maintenance of the bitcoin.org website?
188 2013-12-26 07:01:16 <fanquake> ;;tslb
189 2013-12-26 07:01:19 <gribble> Time since last block: 32 minutes and 1 second
190 2013-12-26 07:01:55 <maaku> CodeShark: I'm not sure who has commit access, but it's maintained on github : https://github.com/bitcoin/bitcoin.org
191 2013-12-26 07:05:05 <CodeShark> maaku: thanks
192 2013-12-26 10:21:47 <gdoteof> i'm trying to do a sendmany command, when i do listunspent i get the scriptPubKey rather than the (base58?) form that sendmany wants
193 2013-12-26 10:23:27 <gdoteof> i tried using bitcoin.sh but am not sure if i am doing it wrong or fundamentally misunderstand something
194 2013-12-26 10:23:50 <gdoteof> i thought i'd beabel to do base58encode $scriptPubKey
195 2013-12-26 10:24:40 <maaku> gdoteof: wallet is not a base58 encoded scriptPubKey
196 2013-12-26 10:24:58 <maaku> https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses
197 2013-12-26 10:25:06 <gdoteof> maaku: is it possible to get the input to a sendmany from listunspent
198 2013-12-26 10:25:40 <gdoteof> maaku: ok i will read that
199 2013-12-26 10:25:55 <maaku> gdoteof: i'm not sure i understand the question
200 2013-12-26 10:26:03 <maaku> "input to a sendmany"
201 2013-12-26 10:27:17 <gdoteof> maaku: sendmany takes an address as an input; as opposed to 'sendtoaddress' which just 'automatically' chooses the input
202 2013-12-26 10:27:32 <maaku> listunspent shows the address, if it has one
203 2013-12-26 10:28:01 <maaku> sendmany automatically chooses inputs too
204 2013-12-26 10:28:15 <maaku> you can't select outputs to use with sendmany
205 2013-12-26 10:28:25 <gdoteof> hmm
206 2013-12-26 10:28:41 <maaku> sendmany == send to many addresses
207 2013-12-26 10:28:44 <gdoteof> one sec, let me verify what i am talking about
208 2013-12-26 10:28:51 <maaku> maybe you want coin control?
209 2013-12-26 10:29:09 <gdoteof> maaku: right thats what i want to do.. i don't actually care which address(es) they come from but it appears to me i *have* to choose
210 2013-12-26 10:29:39 <maaku> no, sendmany you pass which addresses you are sending *to*
211 2013-12-26 10:29:41 <gdoteof> sendmany <fromaccount> {address:amount,...} [minconf=1] [comment]
212 2013-12-26 10:30:03 <maaku> you never pick which outputs you use as input
213 2013-12-26 10:30:06 <maaku> not without coin control
214 2013-12-26 10:30:17 <gdoteof> maaku: ^ is the help wrong?
215 2013-12-26 10:30:23 <maaku> no it's right
216 2013-12-26 10:30:25 <maaku> what's confusing?
217 2013-12-26 10:30:31 <gdoteof> what is "<from account>"
218 2013-12-26 10:30:50 <maaku> accounts != addresses
219 2013-12-26 10:31:00 <maaku> that's an internal accounting system that has nothing to do with unspent outputs
220 2013-12-26 10:31:06 <maaku> and should be stripped from the daemon imho
221 2013-12-26 10:31:20 <gdoteof> oh so there is just a convenient abstraction for it
222 2013-12-26 10:31:27 <maaku> it was added to support a very specific web wallet backend accounting scenario, and doesn't really make sense outside of that
223 2013-12-26 10:31:29 <gdoteof> so if i labeled an address as "foo" and received coins to it
224 2013-12-26 10:31:47 <maaku> https://en.bitcoin.it/wiki/Accounts_explained
225 2013-12-26 10:31:51 <gdoteof> i can just "sendmany foo"
226 2013-12-26 10:34:04 <maaku> not really. it's just a running total that the daemon kindly keeps track of
227 2013-12-26 10:34:26 <maaku> so if you tag a transaction in which 20 btc entered your wallet as "foo"
228 2013-12-26 10:34:41 <maaku> then "listaccounts" or whatever the API is would show "foo: 20btc"
229 2013-12-26 10:35:34 <maaku> then if you later do a "sendmany foo 1addr1:5.0 1addr2:3.0", listaccounts would show "foo: 12btc"
230 2013-12-26 10:35:52 <maaku> because it sent those 8 bitcoins "from" your foo account
231 2013-12-26 10:36:21 <maaku> but this has nothing to do with the actual bitcoin protocol, is entirely internal to your client, and is not reflected in the block chain structure or choice of inputs at all
232 2013-12-26 10:36:36 <maaku> so, imho, it's a confusing "feature" that shouldn't exist
233 2013-12-26 10:36:54 <maaku> btw, this should probably be moved to #bitcoin
234 2013-12-26 10:38:06 <gdoteof> maaku: okay; thanks. i undersstand now, thanks for the help
235 2013-12-26 14:08:52 <tholenst> Why does sync.h say "TODO: We should move away from using the recursive lock by default."?
236 2013-12-26 14:09:07 <tholenst> are recursive locks bad?
237 2013-12-26 14:20:14 <pigeons> not very portable?
238 2013-12-26 14:35:51 <wumpus> tholenst: yes, it is considered bad forms to use recursive mutexes, for various reasons, among others that it results in reduced locking discipline (that the developer knows when is the lock held, when isn't it held) see: http://www.zaval.org/resources/library/butenhof1.html
239 2013-12-26 14:37:14 <wumpus> also recursive mutexes are a little bit less efficient (because they need to keep track which thread 'owns' them), but that's not the main problem, generally code that uses recursive mutexes can be written with non-reentrant mutexes and will be better for it
240 2013-12-26 14:38:47 <niston> hm I really have a lot of stuck transactions
241 2013-12-26 14:44:21 <tholenst> wumpus: ty
242 2013-12-26 20:08:13 <skinnkavaj> jgarzik
243 2013-12-26 20:08:26 <skinnkavaj> What do you think about this exchange software? Is it good?
244 2013-12-26 20:08:27 <skinnkavaj> https://github.com/justcoin/snow
245 2013-12-26 20:08:59 <skinnkavaj> wumpus: Maybe you have tried snow?
246 2013-12-26 20:09:04 <skinnkavaj> Or anyone else?
247 2013-12-26 20:55:34 <jgarzik> skinnkavaj, heh, well, it's open source, which is leagues better than everything else out there already :)
248 2013-12-26 20:55:58 <skinnkavaj> jgarzik: Yeah that's why I like it
249 2013-12-26 20:56:13 <skinnkavaj> DO you think node.js is a good language for an exchange?
250 2013-12-26 20:56:25 <skinnkavaj> I want to know how many trades it can handle per second
251 2013-12-26 20:59:19 <jr3> http://nodejs.org/
252 2013-12-26 21:00:51 <nessence> I think nodejs can only use a single cpu core
253 2013-12-26 21:04:15 <jgarzik> skinnkavaj, nessence: node.js is indeed like other scripting languages: multiple threads are not really an option. node.js does, however, do async really really well. and like other scripting languages, multi-processing works just fine, and given the lack of threads, people use processes successfully, and have developed helper tools and libs around those models.
254 2013-12-26 21:04:28 <jgarzik> node.js does async better than C ;p
255 2013-12-26 21:05:02 <skinnkavaj> jgarzik: So how many trades it can handled is determined by hardware?
256 2013-12-26 21:05:13 <jgarzik> on the downside, the v8 engine has some ingrained 'int' usage where it shouldn't leading to odd problems with > 1GB objects
257 2013-12-26 21:05:22 <jgarzik> skinnkavaj, yes
258 2013-12-26 21:07:18 <jr3> skinnkavaj, http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/
259 2013-12-26 21:07:45 <nessence> might be a good fit considering the nature of bitcoin being sort of like a protocol
260 2013-12-26 21:08:29 <nessence> probably have to do heavy lifting in C no matter the scripting language
261 2013-12-26 21:27:29 <maaku> skinnkavaj: backend db choice matters much more than language
262 2013-12-26 21:27:53 <maaku> especially since markets are inherently serial
263 2013-12-26 21:28:02 <skinnkavaj> maaku: Can you recommend one?
264 2013-12-26 21:28:11 <maaku> hyperdex
265 2013-12-26 21:29:25 <maaku> or voltdb
266 2013-12-26 21:31:40 <nsh> "<maaku> especially since markets are inherently serial" can you elaborate? not sure what this means exactly, or the connection
267 2013-12-26 21:38:20 <maaku> nsh: market models require serial processing - when a market order is executed, it snags the best price available
268 2013-12-26 21:39:22 <nsh> ACTION nods
269 2013-12-26 21:39:31 <maaku> you can only make this parallel by breaking the market model - adding some randomness to which bids match with which asks
270 2013-12-26 21:40:13 <maaku> which is an interesting academic exercise, but introduces locks which make it unlikely to be more efficient than a simple dumb-but-fast serial processor
271 2013-12-26 21:40:34 <nsh> well, it might not be any more than the randomness added by the serialization of ostensible parallel requests to the front-end
272 2013-12-26 21:40:41 <nsh> *ostensibly
273 2013-12-26 21:41:26 <maaku> nsh: yes, but it is often more about determinism, auditability, and fairness
274 2013-12-26 21:41:38 <nsh> ACTION nods
275 2013-12-26 21:42:01 <maaku> how do you tell the randomness of paralell processing apart from a market which is rigged to give better prices to certain people?
276 2013-12-26 21:42:41 <maaku> with a serial process you get deterministic execution for a given ordering of inputs
277 2013-12-26 21:42:56 <gmaxwell> maaku: encrypted order assignment and some kind of determinstic scheduler?
278 2013-12-26 21:43:11 <maaku> and, because it can be lock free, better performance than a realistic parallel case
279 2013-12-26 21:44:42 <nsh> hmmmm
280 2013-12-26 21:52:01 <maaku> gmaxwell: maybe. i'd be interested in encrypted order processing for other reasons
281 2013-12-26 21:53:06 <maaku> but i'm not sure how you can make a concurrent process have deterministic scheduling without a central node or consensus on scheduling ... which will always be slower than a single fast node not seeking consensus
282 2013-12-26 21:54:57 <nsh> determinism is sufficient but not necessary to prevent corruption. probable lack of bias would also suffice
283 2013-12-26 21:55:10 <nsh> well, even determinism could be evil
284 2013-12-26 21:55:31 <nsh> *proveable
285 2013-12-26 22:02:57 <andytoshi> hmm, perhaps if your exchange were to just crash and start replaying old orders to everybody whenever there is too much activity, that would be sufficient
286 2013-12-26 22:03:02 <andytoshi> ;)
287 2013-12-26 22:04:36 <nsh> ACTION smiles