1 2014-07-23 02:10:00 <arowser> arowser tiange
2 2014-07-23 05:07:39 <etotheipi_> strange question: if I wanted to donate to "Bitcoin core development", how would I do that?
3 2014-07-23 05:08:07 <etotheipi_> the website points me to the Bitcoin Foundation... is there a more-direct way to donate to the development?
4 2014-07-23 05:08:50 <wumpus> nothing organized, though ofc you could ask specific developers for donation addresses
5 2014-07-23 05:09:54 <wumpus> let's say you like the headers-first pull a lot, then you just donate to @sipa :)
6 2014-07-23 05:10:09 <etotheipi_> wumpus: I'd like to do a matched donation promotion for Armory's new features... I'm getting some pushback from various people regarding donating to the BF
7 2014-07-23 05:10:27 <etotheipi_> I didn't think it would be a big deal...
8 2014-07-23 05:11:33 <wumpus> well Gavin, Cory and me are paid by the BF, they are the only organization paying developers to work on bitcoin core full-time
9 2014-07-23 05:11:36 <etotheipi_> simply put I would like a nice public target that supports core dev
10 2014-07-23 05:11:50 <etotheipi_> I will do the BF if needed
11 2014-07-23 05:12:42 <Dr-G> there's like a site that pays people who commit somethint to github
12 2014-07-23 05:12:46 <wumpus> but yes a common complaint is that they fund other stuff than development as well
13 2014-07-23 05:13:01 <wumpus> anyhow that's off-topic here :)
14 2014-07-23 05:13:13 <etotheipi_> wumpus: what would you do?
15 2014-07-23 05:13:20 <etotheipi_> we're trying to make a variety of donations
16 2014-07-23 05:13:30 <etotheipi_> both for the good of everything Bitcoin and some PR for us
17 2014-07-23 05:13:46 <Dr-G> http://tip4commit.com/github/bitcoin/bitcoin
18 2014-07-23 05:14:08 <etotheipi_> I'm not a fan of tip4commit, nor does it have good PR value
19 2014-07-23 05:14:24 <Dr-G> better than the foundation way imo
20 2014-07-23 05:14:44 <etotheipi_> "Armory Technologies announces it will match up to $X,000 donations to tip4commit"
21 2014-07-23 05:14:49 <etotheipi_> doesn't have a good ring to it
22 2014-07-23 05:14:58 <wumpus> I'm not a big fan of tip4commit either -- it pays per commit, no matter whether it's a silly message change or deep, painstaking debugging work or difficult feature
23 2014-07-23 05:15:24 <etotheipi_> yes, and some of the most valuable work my guys have done have been consolidating and refactoring... actually net negative lines of code added
24 2014-07-23 05:15:35 <Dr-G> true
25 2014-07-23 05:15:45 <etotheipi_> (I'm not sure exactly what tip4commit does, but I assumed that was it)
26 2014-07-23 05:15:49 <wumpus> so it incentivices clutter, a bit like paying per source code line, which famously resulted in a flight simulator in excel :-)
27 2014-07-23 05:16:13 <Dr-G> hehe
28 2014-07-23 05:16:25 <etotheipi_> so wumpus, any recommendations?
29 2014-07-23 05:16:37 <wumpus> so it's a way, but probably not the best way, although funding open source is a hard problem
30 2014-07-23 05:17:01 <etotheipi_> well, we're going to donate some to FSF, EFF, OpenSSL
31 2014-07-23 05:17:04 <wumpus> you could hire someone to work on a certain open problem
32 2014-07-23 05:17:14 <etotheipi_> heh, actually did that already :)
33 2014-07-23 05:17:34 <etotheipi_> well, we paid maaku a bit to work on the UTXO tree stuff
34 2014-07-23 05:18:05 <wumpus> the point is also to keep it distributed; it's good that Bitcoin Foundation keeps the lights on development-wise, but we don't want the BF to be the only contributor
35 2014-07-23 05:18:21 <Luke-Jr> hey etotheipi_, ltns
36 2014-07-23 05:18:24 <etotheipi_> nonetheless, I was looking for an easy way to support Core development, and it sounds like BF is still the best option for that
37 2014-07-23 05:18:37 <wumpus> (well that's possible, but it'd be a tor-like funding model, the idea was to have it linux-like)
38 2014-07-23 05:18:51 <wumpus> etotheipi_: I agree! and funding the BF is important
39 2014-07-23 05:19:40 <wumpus> etotheipi_: so that is probably the best option
40 2014-07-23 05:20:31 <etotheipi_> yeah, I wouldn't even know how to split up donations to individual developers... I would want someone/an org more in tuned with what's going on, to decide that for me... like the BF :)
41 2014-07-23 05:20:35 <Luke-Jr> wumpus: BF is kinda disappointing with the recent Ghash.io sham-participation :/
42 2014-07-23 05:20:47 <wumpus> apart from tor, blender is another example of an open source project where development is mostly centralized in a foundation
43 2014-07-23 05:22:13 <wumpus> Luke-Jr: I know, but anyhow any organization makes mistakes, it's always easy to pick a few and paint in a completely negative light
44 2014-07-23 05:22:36 <etotheipi_> I support what the Foundation is trying to do and recognize it's not easy
45 2014-07-23 05:22:55 <etotheipi_> and it's unfortunate it's been marred by all this BS
46 2014-07-23 05:22:59 <Luke-Jr> wumpus: yeah, at least they've got a few devs taken care of - that's the important part I guess
47 2014-07-23 05:23:01 <etotheipi_> but I still want the BF to exist
48 2014-07-23 05:23:44 <etotheipi_> wumpus: does the BF pay salaries? or some percentage of donations?
49 2014-07-23 05:24:08 <wumpus> etotheipi_: it pays a fixed salary (well - at least to me)
50 2014-07-23 05:25:10 <wumpus> etotheipi_: AFAIK that's just how they work
51 2014-07-23 05:25:19 <Dr-G> they published a report recently
52 2014-07-23 05:25:39 <Dr-G> about their finances and expenses
53 2014-07-23 05:25:56 <Dr-G> https://bitcoinfoundation.org/static/2014/05/Bitcoin-2013-990-PDC.pdf
54 2014-07-23 05:29:07 <wumpus> apart from devs they also pay for hosting for bitcoin.org (lots of downloads), a development server that runs the pulltester and such, and so on
55 2014-07-23 05:30:52 <etotheipi_> well then, I guess that makes my life easier
56 2014-07-23 05:57:25 <dfletcher> hi does anyone know about bitcoin-abe? trying to connect it to an alt and don't understand how to get the raw transaction of the genesis block that it wants from me.
57 2014-07-23 05:58:52 <jcorgan> this isn't the channel
58 2014-07-23 06:02:24 <wumpus> yes; discussing bitcoin-abe is fine, but no alts here
59 2014-07-23 10:56:37 <venzen> hi, is there a standard term for describing the initial section of a raw transaction (hash, version, vin_sz, vout_sz, lock_time, size) ?
60 2014-07-23 10:58:21 <sipa> venzen: that's not the initial section
61 2014-07-23 10:58:36 <wumpus> isn't nlocktime the last field?
62 2014-07-23 10:59:05 <sipa> it's (version, vin_sz, vin, vout_sz, vout, lock_time)
63 2014-07-23 10:59:20 <venzen> i'm referencing this: http://blockexplorer.com/rawtx/90b18aa54288ec610d83ff1abe90f10d8ca87fb6411a72b2e56a169fdc9b0219
64 2014-07-23 10:59:22 <wumpus> right
65 2014-07-23 10:59:27 <sipa> there is no field 'hash', 'size', and the actual inputs and outputs follow the counts
66 2014-07-23 10:59:29 <venzen> so there is a discrepancy, eh!
67 2014-07-23 10:59:39 <venzen> right
68 2014-07-23 10:59:50 <sipa> well, what bbe shows is interpreted data
69 2014-07-23 11:00:00 <venzen> so thats just blockexplorer doing a blockchain.info on me
70 2014-07-23 11:00:07 <venzen> hmm
71 2014-07-23 11:00:16 <venzen> ok, thanks sipa
72 2014-07-23 11:00:30 <sipa> https://en.bitcoin.it/wiki/Transactions
73 2014-07-23 11:00:31 <wumpus> venzen: https://bitcoin.org/en/developer-guide#transactions
74 2014-07-23 11:00:53 <venzen> is there a name for that stanza of (version, vin_sz, vin, vout_sz, vout, | lock_time)
75 2014-07-23 11:01:08 <wumpus> no
76 2014-07-23 11:01:34 <venzen> if i were to give it one, would "meta data" be absurd?
77 2014-07-23 11:01:52 <wumpus> eh - (version, vin_sz, vin, vout_sz, vout, lock_time) that's the whole transaction
78 2014-07-23 11:02:12 <venzen> oh damn, you're right
79 2014-07-23 11:02:38 <venzen> i should just forget that blockexplorer format, but it's the basis for my tutorial
80 2014-07-23 11:03:06 <stonecoldpat> ,\"02965efa7c916c2ec8d0909a9ab907a0dfc8210e37ab406803211de524165d3b14\"]"
81 2014-07-23 11:03:06 <stonecoldpat> sorry for interrupting current conversation: ive been trying to do addmultisigaddress using json-rpc (java), but I get a parsing error, although it works fine on command line, (according to the help msg, difference between cli and rpc should be a comma between 2 and public keys) - the command is addmultisigaddress 2, [\"0220d368a4cbddc324e3ec566b6250a0b9655b96e568ebe1e4a15dd8f49cbb2cb4\"
82 2014-07-23 11:03:50 <venzen> i'm out - thanks sipa & wumpus
83 2014-07-23 11:03:53 <venzen> ok, well, as always... enlightenment at #bitcoin-dev
84 2014-07-23 11:04:37 <wumpus> you can always use the word metadata, for everything that is part of, or computed from, the original data - that's why government agencies and companies like the word so much
85 2014-07-23 11:09:49 <venzen> thanks wumpus, i'll see if it's really necessary - didn't know blockexplorer was being creative with their formatting of the raw transaction components
86 2014-07-23 11:12:56 <venzen> wumpus: the dev doc for Transactions you refered me to does use the word meta-data for vin_sz, etc, but of course, selectively - some meta-data (script length in bytes) is not displayed by blockexplorer.com
87 2014-07-23 11:14:23 <venzen> glad i asked here and was disabused of the notion that raw transaction output was somehow standarized - assumption can be like stepping on a rake :D
88 2014-07-23 11:15:15 <stonecoldpat> venzen: http://codesuppository.blogspot.co.uk/2014/03/transaction-input-signatures-in-bitcoin.html has a good article about how messed up some transactions are
89 2014-07-23 11:15:34 <stonecoldpat> majority of transactions follow a standard output, but not all of them
90 2014-07-23 11:19:37 <venzen> stonecoldpat: thanks for that - i'm writing an introductory tutorial about standard transactions and its funny how trying to explain something simply just runs you up against areas where your own comprehension is fuzzy!
91 2014-07-23 11:20:19 <venzen> ping jcorgan
92 2014-07-23 11:21:42 <sipa> venzen: it's not really being creative
93 2014-07-23 11:21:48 <sipa> venzen: it just shows the data in a human readable way
94 2014-07-23 11:22:35 <venzen> sipa: granted, i made the assumption that their output was standard
95 2014-07-23 11:24:09 <venzen> btw, if i wanted to make the output of the RPC getrawtransaction command human readable... what format is the output of that command?
96 2014-07-23 11:24:26 <stonecoldpat> verzen: should be JSON
97 2014-07-23 11:24:43 <venzen> stonecoldpat: it seems to be hex
98 2014-07-23 11:25:13 <stonecoldpat> venzen: try decoderawtransaction <hex string>
99 2014-07-23 11:26:32 <stonecoldpat> getrawtransaction will be hex, and then decoderawtransaction will be json
100 2014-07-23 11:26:55 <venzen> stonecoldpat: i'll try. With getrawtransaction <txid> i get a few screens full of continuous output (appears to be hex) - no whitespace [snip]
101 2014-07-23 11:26:58 <venzen> oh ok
102 2014-07-23 11:27:53 <sipa> venzen: or use getrawtransaction <txid> 1
103 2014-07-23 11:28:01 <sipa> which decodes immediately
104 2014-07-23 11:28:22 <venzen> allright!
105 2014-07-23 11:29:36 <sipa> but i wouldn't call that standard either
106 2014-07-23 11:29:44 <sipa> the data itself is just the binary format
107 2014-07-23 11:33:43 <venzen> sipa: i see what you mean, the decoded output is a slice of the totality
108 2014-07-23 11:35:37 <venzen> as developers, do you have ideas about the best (or a prefered) format to present transactions to learners? I thought the blockexplorer.com output is ok - any opinions?
109 2014-07-23 11:39:45 <iwilcox> blockexplorer might imply some dodgy mental models; I think it uses the term "from address" and "address balance", so watch out for that
110 2014-07-23 11:40:12 <iwilcox> Depends on your audience how much that matters, of course.
111 2014-07-23 11:42:10 <venzen> iwilcox: i'm consciously addressing the myth of the "from address" in my tutorial and i like the be.com display format because it doesn't mention addresses in those misconceived ways (well not in the raw transaction output at least)
112 2014-07-23 11:43:00 <venzen> and it shows both scriptSig and scriptPubKey in the correct contexts
113 2014-07-23 11:43:02 <iwilcox> Hrm. They do, or did, somewhere; I used them as an example-of-bad in my no-from-address posting.
114 2014-07-23 11:43:45 <venzen> ok, thanks for pointing that out, i'll be on the lookout for that
115 2014-07-23 11:44:06 <iwilcox> venzen: "All popular blockchain explorers (at time of writing) attempt to show all last-sent-to addresses for a transaction in an effort to be user-friendly, and either show a suggestive arrow or even (in the case of blockexplorer.com) explicitly label the last-sent-to as «from address»"
116 2014-07-23 11:45:55 <venzen> iwilcox: i just checked and you're right: e.g. http://blockexplorer.com/address/17rfobSZ8Dj61c8sanhzzR76ADMjWYYpCP
117 2014-07-23 11:47:28 <sipa> venzen: show an example of the binary data, annotated
118 2014-07-23 11:47:38 <sipa> venzen: like on the protocol description page on the wiki
119 2014-07-23 11:49:06 <venzen> this aspect is difficult to communicate to end-users because they need to grasp some very technical nuts and bolts of the protocol in order to understand _why_ there is not a from address, but only UTXOs ... the language of payment as well as the language of Bitcoin naturally leads the mind to the conclusion that addresses send and receive
120 2014-07-23 11:50:38 <sipa> if that's what you want to explain, i wouldn't bother going into the technical details of transactions at all
121 2014-07-23 11:50:54 <sipa> i like the explanation here: https://en.bitcoin.it/wiki/Change
122 2014-07-23 11:51:42 <venzen> sipa: very good idea - I will, this also introduces the notion that there is not a single display format for transactions
123 2014-07-23 11:51:51 <uiop> if you define "address" as "equivalence class of scripts, with isomorphism defined as identical sets of initial stacks which evalutate to true", then addresses to receive
124 2014-07-23 11:52:02 <uiop> s/to/do/
125 2014-07-23 11:52:17 <sipa> an address is not an equivalence class of scripts... it is just a single script
126 2014-07-23 11:52:27 <venzen> oh yes, you refered me there yesterday and the wiki "change" page is particularly good
127 2014-07-23 11:52:29 <uiop> and the "naive" definition of "address" is just a special case of that
128 2014-07-23 11:52:45 <uiop> close enough for government work
129 2014-07-23 11:53:56 <venzen> hold on... an address is a script? I thought it was a special hashed presentation of a public key...
130 2014-07-23 11:54:55 <sipa> venzen: a 1xxxx address is a shorthand for the script OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
131 2014-07-23 11:54:58 <wumpus> an address can be mapped to an output script, a script doesn't always map to an address
132 2014-07-23 11:55:07 <uiop> sipa: i'm implicitly identifying addresses with their std scripts, then playing fast-and-loose-ish :)
133 2014-07-23 11:55:42 <venzen> sipa: wumpus: well that's great insight
134 2014-07-23 11:55:47 <sipa> a 3xxxxx address is a shorthand for: OP_HASH160 <scriptHash> OP_EQUAL
135 2014-07-23 11:56:05 <venzen> multisig
136 2014-07-23 11:56:10 <sipa> no, p2sh
137 2014-07-23 11:56:20 <sipa> (which can be used for multisig, but you can't tell from just that)
138 2014-07-23 11:56:38 <venzen> i see
139 2014-07-23 11:56:47 <uiop> wumpus: true, good point
140 2014-07-23 11:56:50 <sipa> there's the historic accident in identifying pay-to-pubkey scripts with the same address as their equivalent pay-to-pubkeyhash form would
141 2014-07-23 11:57:31 <uiop> ACTION will work this out on paper when he has the time
142 2014-07-23 11:57:32 <sipa> making addresses both be used as shorthands for destination scripts, and as identifiers for public keys
143 2014-07-23 11:57:39 <venzen> so the scriptPubKey in a standard txout - that is the receiving address itself?
144 2014-07-23 11:57:50 <sipa> the expanded form of it, yes
145 2014-07-23 11:58:00 <sipa> assuming there is a corresponding address
146 2014-07-23 11:58:47 <venzen> assuming it "exists" or assuming it is not another type of script being used?
147 2014-07-23 12:00:05 <sipa> well an output script can be everything
148 2014-07-23 12:00:31 <sipa> if it's not one of the two standard forms that have corresponding shorthand notations ("addresses"), you can't say it *is* the address
149 2014-07-23 12:00:43 <sipa> what is in the transaction is just the output script
150 2014-07-23 12:00:59 <sipa> the address is what you use to construct the transaction, if it's a standard one
151 2014-07-23 12:02:02 <uiop> venzen: if you invoke equivalent classes and then wave your wands rapidly, such concerns vanish asymptotically!
152 2014-07-23 12:02:37 <uiop> i don't spend enough time in this channel
153 2014-07-23 12:02:43 <venzen> sipa: right, and how does one "expand" the 1xx address form? What does it expand to? The OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
154 2014-07-23 12:03:23 <BigBitz> any OPs alive?
155 2014-07-23 12:04:06 <venzen> uiop: hehe, i don't know what you mean, but its bewildering my delicate mind!
156 2014-07-23 12:04:09 <sipa> venzen: decode the base58check, which results in 00 <pubkeyhash> for 1xxxx
157 2014-07-23 12:04:24 <sipa> then turn it into the binary form for OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
158 2014-07-23 12:04:50 <venzen> fantastic, i get it
159 2014-07-23 12:05:53 <sipa> for p2sh addresses, the decoding will result in 05 <scripthash>
160 2014-07-23 12:06:11 <venzen> just a moment while i cross-ref
161 2014-07-23 12:08:43 <venzen> sipa: those prefixes 00 and 05, are they OP codes? I can't find them on the wiki Script page...
162 2014-07-23 12:08:44 <uiop> venzen: sorry, i meant: you said ("...or assuming it is not another type of script being used?"). and what i originally sloppily made an attempt to say.... oh, i just realized i reverse what i meant to say wrt the script and the stack
163 2014-07-23 12:08:53 <sipa> venzen: no, they're address version bytes
164 2014-07-23 12:08:55 <uiop> ACTION is le tired
165 2014-07-23 12:09:05 <venzen> ah ok
166 2014-07-23 12:09:08 <sipa> version 0 is used for pay-to-pubkeyhash adresses, version 5 for p2sh
167 2014-07-23 12:09:17 <venzen> sure
168 2014-07-23 12:09:27 <uiop> i think i'm gonna work out and write up what i mean though
169 2014-07-23 12:09:29 <venzen> as per the examples in the Transaction wiki page... i get it
170 2014-07-23 12:09:43 <venzen> you explain it much better, however
171 2014-07-23 12:09:59 <uiop> if that ever happens, i'll be sure to link in here
172 2014-07-23 12:11:09 <venzen> uiop, you know what they say about procrastination and Class wands... basically, don't procrastinate :)
173 2014-07-23 12:11:34 <uiop> (err, actually i didn't "reverse" it, but how i stated the definition of isomorphism wasn't wuite right)
174 2014-07-23 12:11:48 <uiop> *quite
175 2014-07-23 12:12:20 <uiop> venzen: "wands" makes me think of "/me puts on his wizard hat..." ...
176 2014-07-23 12:12:21 <uiop> hehe
177 2014-07-23 12:19:09 <venzen> sipa: so the 1x and 3x addresses versions expand to their respective scripts with HASH160 versions of the underlying public key in <pubkeyhash>.
178 2014-07-23 12:20:20 <sipa> for 1x addresses, yes
179 2014-07-23 12:20:30 <sipa> for 3x addresses it's a scriptHash rather than a pubkeyHash
180 2014-07-23 12:20:35 <kingkom> Hey! Has anyone here very used the blockchain RPC api with curl before? If so, how do you obtain the CA cert of https://rpc.blockchain.com/ so that you can send the request with the JSON-rpc?
181 2014-07-23 12:20:47 <sipa> kingkom: ask them
182 2014-07-23 12:21:35 <drizztbsd> kingkom: Firefox can't find the server at rpc.blockchain.com.
183 2014-07-23 12:21:36 <sipa> kingkom: them == blockchain.info
184 2014-07-23 12:22:38 <venzen> what does one get if you unpack or decode the scriptSig from the input to the tx? I see the HASH160 version of the address that previously received the UTXO (now being spent), but what is the significance of the hex that precedes it?
185 2014-07-23 12:23:07 <venzen> is it a signature?
186 2014-07-23 12:23:10 <sipa> the signatures or whatever data necessary to satisfy the output script
187 2014-07-23 12:23:25 <venzen> great
188 2014-07-23 12:24:14 <venzen> scriptSig puts that on the stack and scriptPubKey starts its operations from there.
189 2014-07-23 12:24:27 <venzen> thanks, sipa
190 2014-07-23 12:25:02 <uiop> venzen: https://github.com/bitcoin/bitcoin/blob/master/src/script.h https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp
191 2014-07-23 12:25:35 <uiop> venzen: (optimistically saving a roundtrip by omiting the check of whether c++ code is useful to you :)
192 2014-07-23 12:27:08 <uiop> but your use of "stack" in that previous sentence gave me a felling it is
193 2014-07-23 12:28:02 <venzen> uiop: thanks, i'm C++ conversant, yet my actual objective here is a tutorial about transactions for end-users... it's become a tech facts verification journey so i can avoid speaking nonsense!
194 2014-07-23 12:29:29 <uiop> venzen: but virtualmachine interpreters are so purdy, how can you not peak?
195 2014-07-23 12:30:00 <venzen> ACTION blushes
196 2014-07-23 12:30:23 <venzen> thanks all - you're scholars and gentlemen, as always
197 2014-07-23 13:06:42 <hearn> sipa: is there somewhere I can whack a debugging printf when a CCoins is being cleared?
198 2014-07-23 13:06:54 <hearn> sipa: i'm trying to debug why the utxo set ends up looking wrong at a point in the regtest
199 2014-07-23 13:09:59 <raistlinthewiz> hey guys we have develop a new stratum server implementation; https://github.com/CoiniumServ/CoiniumServ check it out
200 2014-07-23 13:19:51 <sipa> hearn: what is bitsquare?
201 2014-07-23 13:20:22 <hearn> sipa: p2p exchange app
202 2014-07-23 13:20:22 <sipa> hearn: the only place where i know that happens is in ConnectInputs (iirc) with an assignments of CCoins()
203 2014-07-23 13:20:42 <hearn> sipa: desktop app, uses p2p dht network for storing offers/bids, bitcoinj for a local spv wallet
204 2014-07-23 13:20:49 <hearn> sipa: it's looking pretty nice, bitsquare.io
205 2014-07-23 13:21:01 <hearn> may use/integrate tlsnotary in future as a form of dispute mediation
206 2014-07-23 13:21:09 <hearn> sipa: hm, ok. i'll take a look there.
207 2014-07-23 13:21:28 <sipa> hearn: but from what you've told me, it looked like there was an empty tx in the mempool, would (now that i think about it) be completely broken
208 2014-07-23 13:21:52 <sipa> oh
209 2014-07-23 13:21:58 <hearn> well getrawmempool shows the tx hash being there, but the utxo set gave the pruned entry indeed
210 2014-07-23 13:22:05 <hearn> so yes i'm confused how that can happen.
211 2014-07-23 13:22:29 <sipa> ah
212 2014-07-23 13:22:32 <sipa> no, i see!
213 2014-07-23 13:22:49 <sipa> so there's a pruned CCoins in CCoinsViewCache (pcoinsTip)
214 2014-07-23 13:23:08 <sipa> which is perfectly normal, before the cache is flushed but some entry was completely spent (or reorged)
215 2014-07-23 13:23:23 <hearn> why is being reorged like being spent, in this case?
216 2014-07-23 13:23:30 <sipa> both remove outputs
217 2014-07-23 13:23:48 <hearn> actually i'm starting to wonder if this is a bug in the pull tester/regtest logic itself
218 2014-07-23 13:23:54 <sipa> no
219 2014-07-23 13:24:13 <sipa> it's the bug in the code that is exposed since #4505
220 2014-07-23 13:24:34 <sipa> the CCoinsViewMempool implementation does not deal well with the underlying cache having existing but spent outputs
221 2014-07-23 13:24:41 <sipa> i'll fix it
222 2014-07-23 13:24:46 <sipa> thanks for reporting :)
223 2014-07-23 13:25:17 <hearn> awesome
224 2014-07-23 13:27:41 <hearn> though actually .... argh now i'm confused. i added another test block to the regtest and bitcoinj is also rejecting a spend of the mempool tx, it also thinks it's been spent. but i can't find any transaction that's spending it. the txns pull tester creates are very weird/artificial, they often don't contain signatures, so i'm wondering if it's producing duplicated transactions somewhere without me being able to spot it
225 2014-07-23 13:30:59 <hearn> i'll wait for your fix and see what happens
226 2014-07-23 13:32:31 <sipa> #4575
227 2014-07-23 13:33:42 <hearn> sipa: a comment explaining why ordering of the checks is critical would be nice
228 2014-07-23 13:33:52 <hearn> ACTION tries the fix
229 2014-07-23 13:34:30 <sipa> hearn: lazy operation: i'm first waiting for pulltester :)
230 2014-07-23 13:34:35 <sipa> but i'll add a comment, indeed
231 2014-07-23 13:35:16 <hearn> yay
232 2014-07-23 13:35:23 <hearn> UTXO query mismatches: 0
233 2014-07-23 13:36:02 <hearn> pull tester is happy even with my additional utxo query tests, so i think the patch works
234 2014-07-23 13:36:53 <hearn> i think my "o" key is breaking :(
235 2014-07-23 14:08:01 <venzen> am i right to say that bitcoins (lowercase 'b') don't exist?
236 2014-07-23 14:08:27 <venzen> in that there is no data structure for them?
237 2014-07-23 14:08:51 <sipa> the data structure is int64_t :)
238 2014-07-23 14:09:09 <sipa> but no, a bitcoin (the currency unit, or any subdivision thereof) has no actual representation
239 2014-07-23 14:09:20 <venzen> hmmm
240 2014-07-23 14:09:25 <venzen> you have a point tho
241 2014-07-23 14:09:28 <sipa> the closest approximation is a UTXO entry
242 2014-07-23 14:09:40 <sipa> which has a particular value in satoshi's, expressed as a int64_t
243 2014-07-23 14:09:43 <venzen> yes, this is what i'm driving at
244 2014-07-23 14:09:51 <wumpus> UTXO entries, which are called 'Coins' internally
245 2014-07-23 14:10:29 <venzen> the amazing thing is we are transacting ownership of UTXOs but calling their iterant amount "bitcoin" :)
246 2014-07-23 14:11:16 <venzen> sipa: so this line of dicussion is probably as old as Bitcoin, right?
247 2014-07-23 14:11:21 <wumpus> it's just a name
248 2014-07-23 14:11:30 <venzen> yeh
249 2014-07-23 14:15:32 <venzen> if one is familiar with the code/protocol then this is self-evident, but this revelation blows the head-top off most people
250 2014-07-23 14:20:02 <helo> not sure... most people realize that fundamentally a digital asset doesn't really exist in the traditional sense
251 2014-07-23 14:20:23 <hearn> bitcoin is often described as a distributed ledger
252 2014-07-23 14:20:26 <hearn> which is pretty close
253 2014-07-23 14:20:38 <jgarzik> agree, though I've grown to prefer "register of assets"
254 2014-07-23 14:20:57 <jgarzik> "your bitcoins are stored in the cloud; bitcoins do not move, they simply change owners"
255 2014-07-23 14:21:07 <venzen> indeed and, well, i say that casually (it doesn't exist), but only after i've put my head-top back on
256 2014-07-23 14:21:38 <jgarzik> the blockchain is the timeline of events, but it is the _evaluation_ of the blockchain that produces the useful results everyone seeks
257 2014-07-23 14:21:38 <venzen> the value is in the public ledger, but the underlying asset is nowhere
258 2014-07-23 14:22:12 <venzen> jgarzik: how do you mean evaluation?
259 2014-07-23 14:22:16 <stonecoldpat> jgarzik: i like the description - simply change owners, very clear way to explain it
260 2014-07-23 14:22:30 <sipa> venzen: blocks are essentially signed and combined 'patches' to the UTXO set
261 2014-07-23 14:22:37 <jgarzik> To me, the blockchain is the ledger
262 2014-07-23 14:22:40 <sipa> transactions consume UTXO entries and add new ones
263 2014-07-23 14:22:42 <jgarzik> and a ledger is a timeline of events
264 2014-07-23 14:22:56 <jgarzik> a chart of balances / chart of accounts is what is achieved by evaluating the blockchain
265 2014-07-23 14:22:58 <sipa> applying all blocks in sequence to the initially empty UTXO set gives you the current state
266 2014-07-23 14:23:14 <venzen> a-ha
267 2014-07-23 14:26:29 <venzen> it's amazing from the pov that the blockchain is the true asset, yet people still fall back into the mode whereby they want to "back" cryptocurrencies (as apparent tokens of value) with Gold
268 2014-07-23 14:26:52 <venzen> its funny
269 2014-07-23 14:28:30 <stonecoldpat> venzen: the blockchain just provides a platform to store bitcoins (or key/value pairs) - its value is based on perception - while I wouldnt' want it backed by Gold - it could very well be in the future
270 2014-07-23 14:29:53 <jgarzik> It is a choice. You can certainly make a USDcoin, backed by USD. "Backed by" is simply one or more parties agree to exchange the digital currency for good X.
271 2014-07-23 14:30:30 <helo> (woahdude) bitcoin is already backed by gold
272 2014-07-23 14:31:05 <venzen> stonecoldpat: jgarzik: sure, and the magic word is "perception" ... and "consensus" value too i guess
273 2014-07-23 14:33:49 <hearn> sipa: why do you think satoshi chose a design where the ledger consists of UTXOs and not explicitly changing balance records per key?
274 2014-07-23 14:34:19 <sipa> hearn: avoid replay problems, avoid privacy issues?
275 2014-07-23 14:35:04 <sipa> or rather, make privacy-improving behavior (not reusing keys) exactly as cheap as the privacy-harming case
276 2014-07-23 14:35:07 <hearn> right
277 2014-07-23 14:35:11 <hearn> that's a better phrasing indeed
278 2014-07-23 14:35:23 <hearn> that's probably how i'll put it in future
279 2014-07-23 15:11:36 <berndj-blackout> stonecoldpat, (relevant nick too btw), do you know about Rai stones? some explanatory value there too imho - the stones don't move but owners change. there's even a stone at the bottom of the ocean!
280 2014-07-23 16:37:53 <Sleepnbum> ACTION <3's the btc devs
281 2014-07-23 17:02:25 <bsm117532> If I create a new script type, will it be propagated on the network? Or does bitcoin only propagate known types?
282 2014-07-23 17:04:40 <sipa> it only propagates standard transactions
283 2014-07-23 17:04:55 <bsm117532> What is required to create a new transaction? Should I file a BIP?
284 2014-07-23 17:04:57 <sipa> which means known template, not over size limits, only pushes in inputs, ...
285 2014-07-23 17:05:13 <sipa> just start using it on testnet
286 2014-07-23 17:05:23 <bsm117532> Oh, testnet will propagate non-standard scripts?
287 2014-07-23 17:05:23 <sipa> (which does not have this rule)
288 2014-07-23 17:05:26 <sipa> yes
289 2014-07-23 17:05:34 <bsm117532> Cool, thanks.
290 2014-07-23 17:05:40 <bsm117532> And again moving that to the main network requires a BIP?
291 2014-07-23 17:06:08 <sipa> not really
292 2014-07-23 17:06:19 <sipa> BIPS are for things that require network agreement
293 2014-07-23 17:06:25 <bsm117532> Then what is required to get it propagated?
294 2014-07-23 17:06:41 <sipa> changing the source code
295 2014-07-23 17:07:13 <bsm117532> Ah okay, easy enough, thanks.
296 2014-07-23 17:07:51 <sipa> i mean: submit a pull request to add it as a standard type, get that accepted, wait for a new release, wait for a majority of the network nodes to upgrade to that release
297 2014-07-23 17:08:14 <bsm117532> Yeah, gotcha.
298 2014-07-23 17:08:38 <bsm117532> Is there any web page out there listing interesting non-standard scripts (besides the wiki?)
299 2014-07-23 18:35:54 <btc111> "Ethereum has vast potential, whereas Bitcoin won't ever do anything well beyond implementing a currency," programmer Nick Szabo, another early Bitcoin proponent who's recently begun tweeting after an extended absence from the internet, told us in an email several weeks ago.
300 2014-07-23 18:37:03 <rnicoll> Ethereum is great if your entire userbase is technophiles
301 2014-07-23 18:37:19 <btc111> looks like we need to implement ethereum functionality, or slowly lose relevance and be replaced
302 2014-07-23 18:37:54 <kazcw> to replace bitcoin, ethereum would need to implement ethereum functionality
303 2014-07-23 18:37:56 <btc111> actaully, they're creating an app store right into the client. where you can use any contracts with the click of a button
304 2014-07-23 18:39:27 <rnicoll> that's a good start at least. I don't know, I worry about scaling, ease of use... if they pull it off, it'll be amazing, and I've been fantastically wrong before, but...
305 2014-07-23 18:40:45 <btc111> and they'll probably raise 50k+ btc. thats $25 million to hire 100 devs and UI/UX guys to do it. meanwhile bitcoin devs aren't even paid.
306 2014-07-23 18:40:51 <btc111> its pathetic.
307 2014-07-23 18:41:21 <btc111> actually i already know that ethereum's plan is to approach the bitcoin core dev's with $300k/yr salary offers.
308 2014-07-23 18:41:32 <rnicoll> I thought a few at the core were salaried?
309 2014-07-23 18:42:32 <btc111> they're putting aside $3-4 million to take the best bitcoin core dev's and bring them to ethereum
310 2014-07-23 18:42:37 <btc111> bitcoin is fucked.
311 2014-07-23 18:43:09 <sipa> #bitcoin please
312 2014-07-23 18:47:48 <BlackPrapor> btc111: imho ethereum guys will make a run with all btc they collect in the next 42 days
313 2014-07-23 18:48:22 <sipa> #bitcoin please
314 2014-07-23 18:48:59 <btc111> they're selling for cash so they dont have a moral hazard
315 2014-07-23 18:49:29 <sipa> please
316 2014-07-23 18:51:31 <nodedubyateef> anyone around that knows how to get bitcore's insight-api exposed as a webservice beyond just localhost?
317 2014-07-23 18:55:32 <earlz> is etherium even open source? Last I checked their "wallet" was obfuscated Java
318 2014-07-23 19:00:21 <rnicoll> not last time I checked, but hopefully at some point :-/
319 2014-07-23 19:05:39 <earlz> I heard they were wanting to patent some aspects of it, to make sure no clone coins can exist
320 2014-07-23 19:06:05 <earlz> I think the whole idea of trying to "close" a distributed system is just stupid
321 2014-07-23 19:08:19 <rnicoll> ACTION nods
322 2014-07-23 19:08:42 <rnicoll> feels a lot like going against the entire idea of the technologies
323 2014-07-23 19:09:52 <earlz> it's because it suppose to make the founders rich, not to improve how people conduct business
324 2014-07-23 19:10:29 <earlz> btw, is it common to craft commits in the name of other people?
325 2014-07-23 19:10:42 <earlz> https://github.com/bitcoin/bitcoin/pull/4331#issuecomment-48266114
326 2014-07-23 19:11:06 <earlz> He made a commit with my idea under my name. I like the idea, but I've never seen this done before heh
327 2014-07-23 19:11:27 <rnicoll> never seen it with new code, certainly have done it when merging from Bitcoin to an altcoin
328 2014-07-23 19:13:17 <earlz> heh the idea is from another coin, but the implementation is different because the other coin is based on bitcoin 0.9 and a lot of refactoring has taken place where it's implemented
329 2014-07-23 19:14:36 <rnicoll> is it your code at all, or just your idea?
330 2014-07-23 19:14:47 <gmaxwell> earlz: when someone else did the actual work and the person putting it in git is just doing some superficial code wrangling and thinks it should be attributed to other people, yes.
331 2014-07-23 19:15:15 <gmaxwell> earlz: I do this with some regulatity in other projects when people send me patches and asking them to use git (and to send a git format patch) would be rude.
332 2014-07-23 19:22:40 <earlz> I like the idea, I've just never seen it done before
333 2014-07-23 20:06:25 <Luke-Jr> earlz: it's pretty much a best practice for attribution
334 2014-07-23 20:35:49 <pkgsrceror> Hi, i'm working on updating bitcoin in pkgsrc. We have 0.8.6 in pkgsrc-wip already. After updating the pkgsrc files, here's the output of the build: http://www.pastebay.com/1470155
335 2014-07-23 20:39:26 <pkgsrceror> I can do stuff like: aclocal; autoheader; automake -a --foreign -i; autoconf; but that fails as well in a different way.
336 2014-07-23 20:51:00 <midnightmagic> pkgsrceror: Are you building on NetBSD?
337 2014-07-23 20:52:51 <pkgsrceror> Yes, but I build on Linux too and it's failing there as well.
338 2014-07-23 20:53:02 <kruug> cd ..
339 2014-07-23 20:53:03 <pkgsrceror> I would test it on SunOS eventually too, midnightmagic.
340 2014-07-23 20:53:28 <midnightmagic> pkgsrceror: I build irregularly on NetBSD and my last successful build was by hand; what git commit are you building from?
341 2014-07-23 20:53:28 <pkgsrceror> and OpenBSD probably
342 2014-07-23 20:53:42 <pkgsrceror> I don't build from master, but from tagged versions.
343 2014-07-23 20:53:51 <midnightmagic> .. what tagged version are you building from?
344 2014-07-23 20:54:01 <pkgsrceror> 0.9.2.1 - like the log says
345 2014-07-23 20:54:47 <pkgsrceror> I can send you my pkgsrc files, if you're interested.
346 2014-07-23 20:55:06 <midnightmagic> pkgsrceror: a pkgsrc version doesn't always correspond to a build number. I'm just being thorough. How can I get ahold of you the next build attempt I make?
347 2014-07-23 20:55:22 <midnightmagic> pkgsrceror: Sure. Throw it up somewhere or commit to a branch of wip on github
348 2014-07-23 20:55:23 <pkgsrceror> rodent@NetBSD.org
349 2014-07-23 20:55:49 <midnightmagic> pkgsrceror: okie doke. Are you in a hurry?
350 2014-07-23 20:56:00 <pkgsrceror> Would be cool to sort this within 2 weeks.
351 2014-07-23 20:57:26 <midnightmagic> pkgsrceror: Any chance you could tell someone that NetBSD 6.1.3_PATCH as of Apr 9 2014 panics when run inside a KVM container configured with 8G ram and 5 CPU?
352 2014-07-23 20:57:30 <midnightmagic> :-]
353 2014-07-23 20:57:39 <midnightmagic> (running bitcoind)
354 2014-07-23 20:58:48 <pkgsrceror> eep
355 2014-07-23 20:58:53 <pkgsrceror> Could you file a PR?
356 2014-07-23 20:59:05 <pkgsrceror> with the send-pr utility
357 2014-07-23 20:59:14 <pkgsrceror> 6.1.4 is out BTW
358 2014-07-23 20:59:33 <midnightmagic> pkgsrceror: :-/ I get much less spam when I don't
359 2014-07-23 20:59:36 <midnightmagic> pkgsrceror: Ah nice, thanks.
360 2014-07-23 20:59:37 <sipa> pkgsrceror: too old autotools?
361 2014-07-23 20:59:44 <sipa> pkgsrceror: otherwise, talk to cfields perhaps
362 2014-07-23 21:01:25 <pkgsrceror> sipa, that build log is from NetBSD 6.0.1 with pkgsrc-2013Q1, so yes sort of old. However, on my development machine which is NetBSD 6.1.2 and pkgsrc-current, it fails too. These pkgsrc files fail under CentOS 6.5 (latest stable) plus a newish branch of pkgsrc, so i think it's an issue with bitcoin's autotools files.
363 2014-07-23 21:01:29 <midnightmagic> pkgsrceror: I just ran autogen on tag v0.9.2.1 and it's working for me with autoconf-2.69nb2 and automake-1.14 ?
364 2014-07-23 21:01:32 <dhill> bitcoind is not going to work on openbsd..
365 2014-07-23 21:01:47 <midnightmagic> dhill: Why not?
366 2014-07-23 21:02:02 <dhill> leveldb needs a kernel with UBC
367 2014-07-23 21:02:13 <dhill> go run the leveldb regress tests on openbsd.. they fail
368 2014-07-23 21:02:23 <pkgsrceror> midnightmagic: I have those versions of autotools and automake installed.
369 2014-07-23 21:02:27 <kazcw> pkgsrceror: I think I had that problem until I forced it to use cmake, don't remember how
370 2014-07-23 21:02:39 <pkgsrceror> I can run autoreconf from the shell and `echo $?` returns 0.
371 2014-07-23 21:02:45 <pkgsrceror> although it throws the same warnings
372 2014-07-23 21:02:46 <dhill> the database always gets corrupted on IBD
373 2014-07-23 21:03:36 <midnightmagic> pkgsrceror: I got this but just warnings: http://pastebin.com/pKcQJ5fA
374 2014-07-23 21:05:11 <pkgsrceror> Here's the newer version of the pkgsrc-wip files i'm using: https://www.sendspace.com/file/k4hxyn
375 2014-07-23 21:07:17 <pkgsrceror> midnightmagic: that's the same output i get when running it by hand, but fails when run under pkgsrc
376 2014-07-23 21:08:31 <kazcw> pkgsrc uses bmake by default, bmake won't work
377 2014-07-23 21:10:47 <elichai2> hi
378 2014-07-23 21:12:16 <pkgsrceror> kazcw: gmake is MAKE_PROGRAM in this instance
379 2014-07-23 21:18:38 <pkgsrceror> midnightmagic: if you send me that PR, i'll file it for you
380 2014-07-23 21:19:08 <Krellan> The new "whitelisted" field in getpeerinfo is useful. Does whitelisting also give exemption from maxconnections?
381 2014-07-23 21:19:08 <midnightmagic> pkgsrceror: okay thanks. I can do that.
382 2014-07-23 21:19:13 <Krellan> Would such a feature be useful to add, if not already there?
383 2014-07-23 21:19:55 <sipa> Krellan: no, yes
384 2014-07-23 21:20:12 <Krellan> sipa: Thanks
385 2014-07-23 21:21:06 <pkgsrceror> midnightmagic: you can contact me for any testing regarding this package under pkgsrc as well. After these issues are sorted, I'm going to test it on all the build machines to which i have access.
386 2014-07-23 21:21:25 <Krellan> Would there be downside to adding that? The assumption is that people only whitelist networks they trust, right?
387 2014-07-23 21:21:27 <pkgsrceror> will provide patches, etc. as necessary
388 2014-07-23 21:21:37 <midnightmagic> pkgsrceror: ah nice, glad to hear it.
389 2014-07-23 21:22:32 <pkgsrceror> OK, i'm out. you guys were super helpful
390 2014-07-23 21:22:33 <sipa> Krellan: my only worry is that they'd add large range of the internet just to get more connections...
391 2014-07-23 21:22:40 <pkgsrceror> would be nice if all IRC channels were like this
392 2014-07-23 21:24:28 <midnightmagic> \o
393 2014-07-23 21:29:25 <Krellan> Hmm, whitelisting large range of the internet would be a pretty dumb thing to do, I would think, and would it get you any more connections?
394 2014-07-23 21:30:07 <Krellan> I get all the connections I can handle until my DSL gets slow, had to set an intentional limit.
395 2014-07-23 21:31:14 <Krellan> Whitelisting status wouldn't make a difference in my ability to solicit external connections, I already get as many coming in as I can handle.
396 2014-07-23 21:32:08 <sipa> yes, it would be a bad idea, and no it would not give you more connections
397 2014-07-23 21:32:09 <kazcw> the issue isn't that it would work, but that people might do it
398 2014-07-23 21:32:31 <gmaxwell> need some protection against memory corruption from thatâ¦
399 2014-07-23 21:33:08 <Krellan> Memory corruption?
400 2014-07-23 21:33:32 <sipa> people patch their client to allow more connections, and then complain that their memory gets corrupted
401 2014-07-23 21:34:08 <Krellan> more than 125 connections?
402 2014-07-23 21:35:01 <sipa> more than 1000
403 2014-07-23 21:35:44 <jcorgan> do you just mean out-of-memory errors, or is there some latent allocation bug that affects >125 connections?
404 2014-07-23 21:36:05 <gmaxwell> jcorgan: select will corrupt memory if you have more than 1024 file descriptors in use.
405 2014-07-23 21:36:19 <jcorgan> oh, nice to know
406 2014-07-23 21:36:21 <gribble> 127901745.543
407 2014-07-23 21:36:21 <sipa> ;;nethash
408 2014-07-23 21:36:37 <Krellan> Ah
409 2014-07-23 21:37:21 <Krellan> the limit of 1024 in select is rather nasty, didn't think of that
410 2014-07-23 21:38:18 <sipa> you can raise your max connections using -maxconnections, but it won't go above some safety limit below 1024
411 2014-07-23 21:38:30 <sipa> if you do hack that limitation out...
412 2014-07-23 21:41:24 <Krellan> I wonder if we could use poll() instead, or are we married to select?
413 2014-07-23 21:41:32 <sipa> sure we could
414 2014-07-23 21:41:38 <sipa> someone would need to write it :)
415 2014-07-23 21:41:41 <otila> libevent?
416 2014-07-23 21:42:24 <sipa> please, no extra dependencies
417 2014-07-23 21:42:44 <sipa> (yes, libevent is nice)
418 2014-07-23 21:43:35 <otila> include some stable version in the tree.. or you wanna reinvent the wheel?
419 2014-07-23 21:44:07 <sipa> no, but satoshi already reinvented it :)
420 2014-07-23 21:45:05 <jrick> is the return value of pcoinsTip->GetCoins() affected by whether an output on the best chain is spent by a tx in mempool?
421 2014-07-23 21:46:22 <gmaxwell> poll would be fine except for portablity, which is why libevent exists.
422 2014-07-23 21:46:50 <sipa> jrick: no
423 2014-07-23 21:47:02 <jrick> sipa: cool, thanks
424 2014-07-23 21:48:01 <sipa> otila: sorry, ignore me; i'm too tired
425 2014-07-23 21:50:06 <Shamar> Hi, I'm carefully reading https://bitcoin.org/en/developer-guide but I can't understand if the Merkle root of a block changes when a transaction is added and if the fact that a new block is created "lock" is ancestor so that it can't accept transactions anymore...
426 2014-07-23 21:50:29 <Shamar> can anyone point me to the proper documentation?
427 2014-07-23 21:51:15 <gmaxwell> Shamar: I can't follow your question. The whole purpose of mining is to create a kind of signature of a set of transactions and a history to make it costly to change.
428 2014-07-23 21:51:29 <Shamar> s/the fact that a new block is created "lock" is ancestor so that it can't accept transactions anymore... /the fact that a new block is created "locks" his ancestor so that it can't accept transactions anymore...
429 2014-07-23 21:51:50 <Krellan> Was reading about select. Redefining FD_SETSIZE before including the header is a hack that is frowned upon these days, right?
430 2014-07-23 21:52:09 <Shamar> gmaxwell, I know this (at high level) but I'm tring to understand how this actually works
431 2014-07-23 21:52:48 <gmaxwell> There is no "lock" a block itself is immutable. If its transactions are changed the block hash changes, and the modified block has a one in 74458914455780671473 chance (currently) of being a valid block.
432 2014-07-23 21:53:47 <Krellan> And passing in an array of fd_set, with each array element representing a chunk of 1024 fd, is another workaround that seems like a hack
433 2014-07-23 21:54:30 <Krellan> I like libevent because it solves the portability problems of poll()
434 2014-07-23 21:54:33 <Shamar> so to mint a block a miner collect all the transactions to fill it completelly?
435 2014-07-23 21:54:44 <Shamar> s/collect/collects
436 2014-07-23 21:54:47 <sipa> Shamar: if he wants
437 2014-07-23 21:54:58 <gmaxwell> Shamar: these are really basic questions, you'll probably get more help in #bitcoin
438 2014-07-23 21:54:59 <sipa> an empty block is also valid
439 2014-07-23 21:55:18 <Shamar> but since it's immutable, it's useless
440 2014-07-23 21:55:25 <Shamar> right?
441 2014-07-23 21:55:25 <sipa> no
442 2014-07-23 21:55:27 <gmaxwell> Krellan: FD_SETSIZE is unchangable on many (most?) systems, including linux. And the FD count doesn't depend on the set but also actually the integer values of the FDs.
443 2014-07-23 21:55:32 <Krellan> It would be a pretty substantial change though. And it would make bitcoind depend on libevent.
444 2014-07-23 21:56:16 <Shamar> ok sorry, I thought they were dev questions
445 2014-07-23 21:56:22 <gmaxwell> (Also ISSET is O(N) on the set size)
446 2014-07-23 21:56:39 <sipa> really?
447 2014-07-23 21:56:48 <sipa> not on linux afaik
448 2014-07-23 21:56:58 <sipa> it's just a 1024 bit array
449 2014-07-23 21:57:17 <sipa> on windows it's a list of handles
450 2014-07-23 21:57:32 <sipa> which is o(n)
451 2014-07-23 21:57:43 <Krellan> Wow, FD_ISSET() is O(n)? I thought fd_set was an array of bits?
452 2014-07-23 21:58:41 <gmaxwell> Krellan: sipa corrected. :)
453 2014-07-23 21:58:41 <Krellan> wow, Windows implements it as a list internally, with no way to index that list quickly by number? didn't know that. Brilliant.
454 2014-07-23 21:59:02 <gmaxwell> (I was ignoring linux because you cannot change the size on linux as you'd proposed)
455 2014-07-23 21:59:33 <Krellan> http://www.kegel.com/c10k.html
456 2014-07-23 21:59:34 <sipa> Krellan: handles are pretty much random 32-bit integers, not neat incrementing numvers like unix fds
457 2014-07-23 22:00:01 <Krellan> I have vague memories of programming Windows in 1996 or so
458 2014-07-23 22:01:12 <Krellan> http://support.microsoft.com/kb/111855 = Yikes, only 64, not 1024.
459 2014-07-23 22:03:18 <sipa> by default
460 2014-07-23 22:03:27 <sipa> it can be raised to 1024
461 2014-07-23 22:04:51 <Krellan> Good to know, wow, they added WSAPoll() but that didn't go so well: http://daniel.haxx.se/blog/2012/10/10/wsapoll-is-broken/
462 2014-07-23 22:05:20 <otila> what about Boost Asio
463 2014-07-23 22:07:07 <jcorgan> otila: shudder the thought
464 2014-07-23 22:08:26 <Krellan> So, as for libevent, we do not want to add another bitcoind external library dependency, right? Or would the benefit outweigh this?
465 2014-07-23 22:08:44 <Krellan> Sigh, everything's so easy until you get up to 1024 connections then it becomes hard :)
466 2014-07-23 22:09:00 <sipa> there's no point in handling that many connections
467 2014-07-23 22:09:26 <sipa> the time between servicing each socket increases, hurting latency
468 2014-07-23 22:09:37 <otila> then add epoll support without extra libs
469 2014-07-23 22:09:44 <sipa> you're better off with a few interconnected bitcoinds
470 2014-07-23 22:09:58 <Krellan> Yep, by that time you're better off splitting program up into threads, giving each thread its own set of 1024
471 2014-07-23 22:10:16 <Krellan> oh wait, you'd have to fork, not thread: fd numbers are a shared resource
472 2014-07-23 22:10:18 <otila> Krellan: shudder the thought
473 2014-07-23 22:11:03 <Krellan> and as gmaxwell said, it's not a limit of active connections, but a limit on the fd number itself: if operating system hands you a fd >=1024 you're dead with select, even if you have few open connections.
474 2014-07-23 22:11:46 <sipa> replacing the select call with poll would solve that, but we'd need to keep select on windows
475 2014-07-23 22:14:15 <gmaxwell> epoll is better but linux only, the BSD/osx side has kqueue. alas. But probably not a big deal since having high numbers of connections wouldn't _generally_ be a good thing.
476 2014-07-23 22:15:51 <gmaxwell> asssuming 2 * 1e6 bytes / 600 seconds, 1000 connections is 26 megabits. So I suppose there is an argument for supporting more, some hosts still wouldn't be bandwidth bottlenecked at that point.
477 2014-07-23 22:16:40 <Krellan> True
478 2014-07-23 22:17:03 <Krellan> So would libevent be overkill? Seems like a clean way to solve the problem in a portable way.
479 2014-07-23 22:17:59 <Krellan> Or continue using select() because it's lowest common denominator that works on all supported platforms, and just be sure to keep fd number <1024 (except on windows).
480 2014-07-23 22:18:40 <gmaxwell> Krellan: its an extra dependency. Our preference is to be hesitant to add them. Since this code isn't consensus critical I wouldn't oppose another one, but for what we're doing some either/or poll vs select would probably be fine.
481 2014-07-23 22:18:59 <gmaxwell> Krellan: we do what you're descrbing as your Or currently.
482 2014-07-23 22:33:00 <Luke-Jr> [21:57:43] <Krellan> Wow, FD_ISSET() is O(n)? I thought fd_set was an array of bits? <-- implementation is not defined by the standard; Windows is stupid, as you note
483 2014-07-23 22:33:13 <Luke-Jr> [22:01:12] <Krellan> http://support.microsoft.com/kb/111855 = Yikes, only 64, not 1024. <-- you can define FD_SETSIZE yourself
484 2014-07-23 22:34:00 <Luke-Jr> gmaxwell: AFAIK FD_SETSIZE is *only* unchangable on glibc
485 2014-07-23 22:45:21 <fuzion24> are there any steps for getting bitcoin-qt building in qtcreator?
486 2014-07-23 22:53:31 <fuzion24> https://github.com/laanwj/bitcoin-qt/blob/master/doc/readme-qt.rst build instructions look very out of date
487 2014-07-23 22:53:57 <fuzion24> err sorry, ignore that.
488 2014-07-23 23:02:05 <kruug> Is there a gitian support forum/channel/etc?
489 2014-07-23 23:33:24 <Luke-Jr> kruug: not really, just here kinda
490 2014-07-23 23:35:49 <kruug> Luke-Jr: does gitian really only work under Ubuntu?
491 2014-07-23 23:36:08 <kruug> I've been wracking my brain and google-fu trying to work with it under Debian...
492 2014-07-23 23:36:26 <Luke-Jr> kruug: I have it working on Gentoo. I think Gavin runs it on Mac.
493 2014-07-23 23:40:14 <Holox> Hey all
494 2014-07-23 23:40:22 <Holox> Sry for my bad english, I'm french
495 2014-07-23 23:41:46 <Holox> I have a question, how I can show in PHP the price of the BTC ?
496 2014-07-23 23:43:23 <kruug> Luke-Jr: it might be a bit off-topic, but is it pretty easy to get gitian working with altcoins?
497 2014-07-23 23:45:41 <sipa> kruug: ask them
498 2014-07-23 23:46:05 <kruug> sipa: no, this would be from scratch...
499 2014-07-23 23:49:50 <Nick____> Hi, I have a question about key generation spec, can anyone help me?