1 2014-02-19 00:33:40 <Techguy305> heellooooo
  2 2014-02-19 00:35:58 <benzrf> hello!
  3 2014-02-19 00:36:12 <benzrf> how can bitcoin check whether sources are valid and unspent without taking ages each time?
  4 2014-02-19 00:37:00 <benzrf> *bitcoin nodes
  5 2014-02-19 00:37:10 <ruukasu> >mfw benzrf knows more about magical internet money than I do
  6 2014-02-19 00:38:10 <teward> ruukasu, don't
  7 2014-02-19 00:38:26 <benzrf> >tfw chanspeak is banned
  8 2014-02-19 00:38:29 <teward> ruukasu, you stopped in #bitcoin, which saved you from my watchful eye, however, don't start here
  9 2014-02-19 00:38:42 <benzrf> i run a bot in another channel
 10 2014-02-19 00:38:51 <teward> best advice on the planet: if you have nothing constructive to say, say nothing.
 11 2014-02-19 00:38:59 <benzrf> the owner programmed it to respond to >mfw and >tfw with 'constructive criticism'
 12 2014-02-19 00:39:13 <ruukasu> teward, don't what?
 13 2014-02-19 00:39:27 <benzrf> ruukasu: talk like a fucking moron
 14 2014-02-19 00:39:41 <benzrf> aka a 4chan user
 15 2014-02-19 00:39:41 <ruukasu> <benzrf> >tfw
 16 2014-02-19 00:39:50 <benzrf> well im doing it ironically so obviously it's ok
 17 2014-02-19 00:39:52 <benzrf> duhh
 18 2014-02-19 00:40:14 <benzrf> ruukasu: stop leading me off-topic
 19 2014-02-19 00:40:20 <ruukasu> teward, I thought the problem was with the social justice conversation, not the slightly off-topic conversation
 20 2014-02-19 00:40:25 <benzrf> seriously, how is efficient txn validity figured out :(
 21 2014-02-19 00:40:39 <teward> ruukasu, if you don't realize what i was talking about when I said "don't" then there's no hope for you
 22 2014-02-19 00:40:48 <benzrf> teward: he's also a libertarian who likes ayn rand
 23 2014-02-19 00:40:53 <benzrf> i lost hope for him ages ago
 24 2014-02-19 00:41:35 <gmaxwell> Please take this discussion elsewhere.
 25 2014-02-19 00:41:37 <teward> ^ that
 26 2014-02-19 00:41:59 <benzrf> man nobody seems to know the answer to my question
 27 2014-02-19 00:41:59 <benzrf> u_u
 28 2014-02-19 00:42:04 <teward> that's where patience comes in
 29 2014-02-19 00:42:08 <sipa> benzrf: we maintain a database of just the unspent transaction outputs
 30 2014-02-19 00:42:16 <benzrf> hmm
 31 2014-02-19 00:42:20 <sipa> benzrf: which is tiny and optimized
 32 2014-02-19 00:42:45 <benzrf> so when a node accepts a new block, it removes any sourced txns from the db?
 33 2014-02-19 00:43:02 <sipa> any transaction _outputs_ that are consumed, yes
 34 2014-02-19 00:43:14 <sipa> and adds the transaction outputs that are added by the transactions in that block
 35 2014-02-19 00:43:30 <benzrf> OK
 36 2014-02-19 00:44:01 <benzrf> what if there's a bug in your client and it accidentally skips marking a txn as unspent?
 37 2014-02-19 00:44:04 <benzrf> *spent
 38 2014-02-19 00:44:11 <sipa> then there's a bug in your client
 39 2014-02-19 00:44:17 <benzrf> might it accept an invalid block?
 40 2014-02-19 00:44:24 <sipa> if there's a bug, anything can happen
 41 2014-02-19 00:44:35 <benzrf> true i suppose
 42 2014-02-19 00:44:44 <benzrf> ok, ill just implement a simple unspent-txn db
 43 2014-02-19 00:44:53 <sipa> what for?
 44 2014-02-19 00:45:01 <benzrf> im writing a minimal-working cc from scratc
 45 2014-02-19 00:45:06 <benzrf> for fun
 46 2014-02-19 00:45:16 <sipa> ok
 47 2014-02-19 00:45:21 <benzrf> i am not trying to make it practical, just theoretically usable
 48 2014-02-19 00:45:29 <benzrf> how do you recommend doing this db?
 49 2014-02-19 00:45:36 <benzrf> one giant flat file of unspent txn ids?
 50 2014-02-19 00:45:46 <sipa> it is not unspent _transactions_
 51 2014-02-19 00:45:48 <benzrf> [im gonna stick with 1 output to a txn, it simplifies things]
 52 2014-02-19 00:45:50 <sipa> it is outputs
 53 2014-02-19 00:45:53 <benzrf> ^^
 54 2014-02-19 00:45:53 <sipa> eh, ok
 55 2014-02-19 00:46:04 <sipa> what programming language?
 56 2014-02-19 00:46:10 <benzrf> ruby
 57 2014-02-19 00:46:15 <sipa> no clue then
 58 2014-02-19 00:46:38 <benzrf> what does btc use?
 59 2014-02-19 00:47:05 <sipa> leveldb as a backend, but there's a custom in-memory cache on top
 60 2014-02-19 00:47:26 <benzrf> im not too worried about speed here
 61 2014-02-19 00:47:42 <benzrf> i might add caching if it's unusably slow
 62 2014-02-19 00:47:58 <benzrf> why a db?
 63 2014-02-19 00:48:03 <benzrf> don't you just need a giant list, not values?
 64 2014-02-19 00:48:08 <benzrf> since everything is implicitly mapped to true
 65 2014-02-19 00:48:23 <sipa> no, you need the value and scriptPubKey of each of those outputs
 66 2014-02-19 00:48:31 <sipa> and some other metadata about transactions
 67 2014-02-19 00:48:42 <sipa> like their height, and whether they were coinbase transactions
 68 2014-02-19 00:48:52 <benzrf> coinbase?
 69 2014-02-19 00:49:12 <sipa> yes?
 70 2014-02-19 00:49:31 <benzrf> what is coinbase i mean\
 71 2014-02-19 00:49:45 <sipa> the first transaction in each block
 72 2014-02-19 00:49:59 <sipa> which is a special, in that it has no real inputs
 73 2014-02-19 00:50:10 <sipa> but is allowed to spend that block's fees and subsidy
 74 2014-02-19 00:50:18 <sipa> that's pretty basic :)
 75 2014-02-19 00:51:45 <benzrf> ah
 76 2014-02-19 00:51:50 <benzrf> coinbase = magic txn
 77 2014-02-19 00:51:57 <benzrf> i only knew it as the latter
 78 2014-02-19 00:51:58 <benzrf> :u
 79 2014-02-19 00:52:09 <benzrf> i planned on implementing those by using a magic source
 80 2014-02-19 00:54:15 <richardus> are you a wizard
 81 2014-02-19 00:54:28 <benzrf> of course i am!
 82 2014-02-19 01:03:44 <luke-jr_> sipa: usually that's called the generation transaction :p
 83 2014-02-19 01:03:53 <luke-jr_> where coinbase is the scriptSig data specifically
 84 2014-02-19 01:04:40 <maaku> luke-jr_: the source code calls both coinbase...
 85 2014-02-19 01:04:42 <sipa> CTransaction::IsCoinbase()
 86 2014-02-19 01:04:50 <sipa> i rest my case :p
 87 2014-02-19 01:04:59 <luke-jr_> sure, but that gets confusing XD
 88 2014-02-19 01:05:12 <sipa> fair enough
 89 2014-02-19 01:05:22 <maaku> no argument on that
 90 2014-02-19 01:05:22 <sipa> deal with it :)
 91 2014-02-19 01:06:28 <luke-jr_> 
ACTION notes the GUIs and RPC use "generated" :p

 92 2014-02-19 01:20:02 <benzrf> mindcrant|bbl
 93 2014-02-19 02:28:48 <maaku> Luke-Jr: are you going to run for a board seat this time?
 94 2014-02-19 02:30:13 <Luke-Jr> maaku: probably, seems people want me to, and nobody else I'd like to see on there has expressed interest AFAIK
 95 2014-02-19 02:34:35 <gavinandresen> The election will be for an Industry seat, so you'll have to get nominated by somebody with an Industry membership.
 96 2014-02-19 02:37:42 <CrackRockerson> Quick question, we are using listtransactions() using the BTC python rpc library.. now the transaction we are getting are unsorted (we are thinking of creating our own local DB to be able to sort the transactions) but is there a smarter way to do this?
 97 2014-02-19 02:38:39 <Luke-Jr> gavinandresen: won't the original 5 seats all be up this year?
 98 2014-02-19 02:38:57 <CrackRockerson> I now the that if you call a similar method using the qt client, there is a -sort operator.
 99 2014-02-19 02:39:25 <CrackRockerson> But we have had no success in using it on the daemon
100 2014-02-19 02:40:01 <gavinandresen> Luke-Jr: I dunno, I'd have to look at when everything expires. We want to stagger terms, having everybody expire at the same time is not good
101 2014-02-19 02:40:02 <Luke-Jr> gavinandresen: personally, I think Tony is a much better fit for an industry seat; and he was interested at least last election, so I wouldn't even try for that most likely
102 2014-02-19 02:40:52 <gavinandresen> (so maybe next election will be some people running for 1-year and some for 2-year seats… or something….  that's all stuff I don't really care about, but other people on the board do)
103 2014-02-19 02:42:46 <gavinandresen> The Foundation is also in the process of being Internationalized, with an umbrella organization and then a US subsidiary. Some of the current board members may move to the US organization (none will serve on both, i don't think… again, organizational structure is something I really don't pay much attention to)
104 2014-02-19 02:44:09 <Luke-Jr> that's confusing, I thought it was always international
105 2014-02-19 02:44:13 <gavinandresen> CrackRockerson: sorting in your app versus sorting before returning the data to your app shouldn't really make a difference.
106 2014-02-19 02:45:22 <gavinandresen> CrackRockerson: … and listtransactions doesn't give any sort options.  Depending on what you're doing, listsinceblock and keeping track of what transactions you already asked about might be more efficient.
107 2014-02-19 02:46:58 <CrackRockerson> I see... thanks for your time and response Gavin
108 2014-02-19 02:47:04 <CrackRockerson> really appreciated
109 2014-02-19 05:58:44 <benzrf> hey
110 2014-02-19 05:58:58 <benzrf> wait nvm <_<
111 2014-02-19 06:08:54 <bitpar> Hey, I'm trying to integrate bitcoind with a web app I am working on. I'm using listsinceblock to get received BTC from users. If a mutated transaction gets confirmed, will the unconfirmed one be removed from listsinceblock?
112 2014-02-19 06:20:54 <bitpar> And is there a reason why 'getbalance' gives only the confirmed balance and 'getbalance account' includes unconfirmed?
113 2014-02-19 06:21:27 <Luke-Jr> yes
114 2014-02-19 06:22:41 <Luke-Jr> accounts are essentially 100% separated from confirmation concepts, for better or worse
115 2014-02-19 06:24:45 <ummjackson> will probably get banned for this but here goes - the Dogecoin development team needs help. if any experience crypto devs are interested please message me. any help is really appreciated, and i really appreciate all the hard work you put into Bitcoin. thanks
116 2014-02-19 06:25:43 <michagogo> cloud|ummjackson: Dogecoin is an off-topic joke
117 2014-02-19 06:26:30 <bitpar> Ok, makes sense. If I'm keeping user's addresses and balances in SQL, is there any reason to also use accounts in bitcoind? I've been looking through the wiki and some code examples but I've yet to find a definitive best practice.
118 2014-02-19 06:27:01 <michagogo> cloud|bitpar: no
119 2014-02-19 06:27:02 <Cusipzzz> don't use bitcoind accounts
120 2014-02-19 06:27:12 <michagogo> cloud|Don- ^
121 2014-02-19 06:31:39 <bitpar> Ok, thank you for your help. One more thing, on malleability again, if I send a transaction and the confirmed hash is different, will the new transaction seen in bitcoind still have a comment I put in? Will the old transaction still appear in the wallet as unconfirmed or does it get cleaned/replaced?
122 2014-02-19 06:33:34 <michagogo> cloud|bitpar: as of 0.8.6, it will stick around as unconfirmed forever, if I'm not mistaken
123 2014-02-19 06:38:12 <bitpar> Does that have any side effects? Assuming I wait for a block, would it still try to spend change using the invalid txhash or would it use the confirmed txhash because that's what's in a block?
124 2014-02-19 06:45:05 <bitpar> I thought the original transaction would be invalidated if confirmed with another txhash since the original would now have spent inputs.
125 2014-02-19 06:48:17 <bitpar> I think transactions with invalid change stick around so I guess it would be the same for mutated ones too.
126 2014-02-19 06:58:01 <bitpar> So my understanding is that I will have unconfirmed send/receive transactions stuck in bitcoind if they are confirmed with a different txhash. Am I safe in sending transactions, as in not spending invalid change inputs, as long as I wait for the previous sent transaction to be confirmed?
127 2014-02-19 07:06:41 <bitpar> And assuming that the block my transaction is confirmed in is not orphaned.
128 2014-02-19 07:15:41 <shaileshg> hi, how do you i get my bitcoin address private key from satoshi client.. it is giving me some 52 characters long hexadecimal string
129 2014-02-19 07:15:55 <shaileshg> i believe it should be 64 characters long..
130 2014-02-19 07:16:06 <shaileshg> *do I get...
131 2014-02-19 07:16:24 <bitpar> dumpprivkey
132 2014-02-19 07:16:50 <shaileshg> bitpar: yeah.. dumpprivkey is giving me 52 characters long string
133 2014-02-19 07:17:01 <shaileshg> and a correction.. its not hex string
134 2014-02-19 07:17:06 <bitpar> that's your private key
135 2014-02-19 07:17:44 <shaileshg> converting that to wif format is not giving me string starting with 5
136 2014-02-19 07:17:55 <shaileshg> which is what wif address should start with
137 2014-02-19 07:19:26 <shaileshg> bitpar: The private key in wallet import format should start with 5.
138 2014-02-19 07:21:56 <bitpar> Isn't dumpprivkey already in WIF?
139 2014-02-19 07:22:26 <michagogo> cloud|Yes
140 2014-02-19 07:22:30 <michagogo> cloud|It is.
141 2014-02-19 07:22:34 <shaileshg> no. In test mode, its for example "cPxAMKwjuNH6UkCWZm8rZwNpywu67Xqx4Kmq31VPvz53trenpnYB" which doesn't look like in WIF format
142 2014-02-19 07:22:47 <michagogo> cloud|shaileshg: uh
143 2014-02-19 07:22:50 <bitpar> Testnet addresses start with a different letter
144 2014-02-19 07:22:56 <michagogo> cloud|WIF is just base58
145 2014-02-19 07:23:32 <michagogo> cloud|dumpprivkey returns in WIF.
146 2014-02-19 07:24:32 <shaileshg> michagogo|cloud: okay
147 2014-02-19 07:25:05 <bitpar> Wouldn't mempool.removeConflicts(tx) remove any unconfirmed transactions with already spent inputs or does that not affect unconfirmed transactions with already spent inputs that were generated by my client?
148 2014-02-19 07:42:58 <michagogo> cloud|bitpar: mempool != wallet
149 2014-02-19 07:43:50 <shaileshg> michagogo|cloud: Oh. I didn't knew there exists two formats for private key.. compressed and uncompressed
150 2014-02-19 07:44:02 <shaileshg> In old format: Private Key WIF (51 characters base58, starts with a '9'):
151 2014-02-19 07:44:12 <shaileshg> In new format: Private Key WIF (compressed, 52 characters base58, starts with a 'c'):
152 2014-02-19 07:44:17 <shaileshg> so, now it makes sense
153 2014-02-19 07:44:26 <michagogo> cloud|shaileshg: there are 4
154 2014-02-19 07:44:45 <michagogo> cloud|Testnet/mainnet and compressed/uncompressed
155 2014-02-19 07:44:53 <michagogo> cloud|2x2
156 2014-02-19 07:44:56 <shaileshg> hmm
157 2014-02-19 07:47:05 <shaileshg> michagogo|cloud: any link to its documentation?
158 2014-02-19 07:48:04 <bitpar> michagogo|cloud: Thanks. Do you know if bitcoind will be ok if I wait for confirmations between each send transactions?
159 2014-02-19 07:56:35 <bitpar> If I set minconf=6, will that avoid any potential spends of unconfirmed change?
160 2014-02-19 08:02:49 <Logicwax> all this malleability talk got me thinking, why do the miners get all the authority in whats included in blocks?  why aren't nodes a part of this voting process?
161 2014-02-19 08:03:10 <Logicwax> in other words, why can't all nodes hold miners to a baseline set of TXs that are agreed to be included
162 2014-02-19 08:03:30 <Belxjander> trust?
163 2014-02-19 08:03:38 <maaku> Logicwax: #bitcoin, please
164 2014-02-19 08:04:02 <Logicwax> such as something like, "other than your unique coinbase tx, and maybe the last few seconds of TXs, you HAVE to include the last 10 minutes to the last minute of TXs or block is invalid"
165 2014-02-19 08:04:10 <Logicwax> ok
166 2014-02-19 08:05:16 <bitpar> According to gmaxwell, minconf doesn't even affect which coins are used as inputs https://github.com/bitcoin/bitcoin/pull/3651
167 2014-02-19 08:05:59 <gmaxwell> It does not.
168 2014-02-19 08:06:22 <gmaxwell> bitpar: we have a setting now in git to not spend unconfirmed change.
169 2014-02-19 08:06:48 <gmaxwell> It's just a binary flag, but indeed it might be better as a confirmation count, perhaps you should open an issue requesting that if you think you want more than a single confirm of checking.
170 2014-02-19 08:07:16 <bitpar> For the time being, should I just wait for my last send transaction to be confirmed before sending another to avoid unconfirmed change inputs? Will that prevent any invalid inputs from getting into my sends?
171 2014-02-19 08:07:32 <bitpar> I can just batch send my transactions with sendmany
172 2014-02-19 08:07:53 <wumpus> bitpar: yes, that will avoid it
173 2014-02-19 08:07:58 <gmaxwell> bitpar: sure, that will achieve that end— it will also only use unconfirmed change as a last resort, if the txn would have otherwise failed.
174 2014-02-19 08:08:12 <wumpus> bitpar: if all your coins are confirmed it cannot use unconfirmed change by definition
175 2014-02-19 08:08:16 <gmaxwell> (already, thats the long-standing behavior)
176 2014-02-19 08:08:26 <wumpus> bitpar: also yes please use sendmany and batch sends
177 2014-02-19 08:08:39 <gmaxwell> though it's a bit hard to depend on the last-resortness since you might end up selecting it due to fee taking you just over the line.
178 2014-02-19 08:09:05 <bitpar> Awesome! I'll wait for a confirm between batch sends, I think that would minimize my load on blockchain too.
179 2014-02-19 08:09:18 <gmaxwell> yea, batching is a great thing to do generally.
180 2014-02-19 08:11:49 <uiop> Logicwax: because miners are literally and by design the judge and jury of what goes into the blockchain, and what exists in the blockchain is the word of god (where god := miners)
181 2014-02-19 08:12:12 <Luke-Jr> uiop: not really
182 2014-02-19 08:12:35 <bitpar> Thank you for your help. I'll use sendmany, it saves on fees and I can just read send transactions from my DB whenever my last transaction gets confirmed instead of having to use message passing.
183 2014-02-19 08:13:08 <uiop> Luke-Jr: what would be your "attack" against miners' ignoring your demands?
184 2014-02-19 08:13:46 <Luke-Jr> uiop: what demands?
185 2014-02-19 08:13:51 <Luke-Jr> miners who break the rules get ignored
186 2014-02-19 08:14:01 <uiop> Luke-Jr: what rules?
187 2014-02-19 08:14:27 <Luke-Jr> …………..
188 2014-02-19 08:14:52 <uiop> Luke-Jr: transaction forwarding rules?
189 2014-02-19 08:15:05 <Luke-Jr> transaction/block validity rules
190 2014-02-19 08:15:16 <uiop> Luke-Jr: if not that, then the only rules are the txn validity rules defined by the spec
191 2014-02-19 08:15:40 <uiop> (obviously i meant w/in those bounds)
192 2014-02-19 08:15:42 <Luke-Jr> there is no spec
193 2014-02-19 08:16:05 <uiop> s/spec/our best approzimation/
194 2014-02-19 08:16:12 <uiop> tr z x
195 2014-02-19 08:18:06 <Logicwax> uiop:  yeah thats what im asking.   why make them god?  why not have a minimum baseline they have to adhere to, that is agreed by nodes.   that way mining pools and 51% wont matter as much
196 2014-02-19 08:18:20 <uiop> but i'm digressing, what i'm really saying is that miners are free to ignore what any particular bitcoin node and/or wallet implem considers acceptable, since they are only constrained by the acceptance of other miners who consider their mined block valid and mine off of it
197 2014-02-19 08:18:56 <Luke-Jr> uiop: but that's not true
198 2014-02-19 08:19:16 <uiop> Luke-Jr: why! (?) :)
199 2014-02-19 08:19:20 <Logicwax> seems it would useful to have nodes all agree on a baseline set of tx's to include.   it would be unrealistic to require them to have every TX even if it occured milliseconds ago
200 2014-02-19 08:19:46 <maaku> Logicwax: and what mechanism would that be?
201 2014-02-19 08:19:51 <Logicwax> but if a TX is in a ton of mempools for a while.....maybe it would be useful to have nodes hold them to it
202 2014-02-19 08:20:00 <maaku> It's a rhetorical question - that's *exactly* what bitcoin solves
203 2014-02-19 08:20:12 <Luke-Jr> uiop: because miners aren't all that important
204 2014-02-19 08:20:31 <maaku> There is no way to have nodes "vote" on what gets on the chain except by some fundamentally scarce resource ... eg. proof-of-work
205 2014-02-19 08:20:42 <maaku> This is #bitcoin 101, please toake it there
206 2014-02-19 08:21:16 <uiop> Luke-Jr: :o
207 2014-02-19 08:21:24 <Logicwax> but i dont like the idea of miners getting all the authority.   what if Visa just throws shit ton of money at being the dominant hash power so as to charge crazy fees and mine (heh) the data for marketing purposes
208 2014-02-19 08:22:05 <Logicwax> maaku: no, i understand what the miners do and why this isn't the case.   im just throwing some food for thought
209 2014-02-19 08:24:12 <bitpar> Logicwax: Why the longest chain is the only authority is explained in the whitepaper https://bitcoin.org/bitcoin.pdf
210 2014-02-19 08:24:38 <Logicwax> i guess I shouldn't have said "why"
211 2014-02-19 08:25:02 <Logicwax> im just rethinking things, since the whole ghash.io almost 50% thing was happening a few weeks ago
212 2014-02-19 08:25:34 <Logicwax> although, p2pool somewhat solves miners abuse
213 2014-02-19 08:26:08 <maaku> Logicwax: there is no way to do what you are proposing and stay decentralized. It is impossible.
214 2014-02-19 08:26:48 <Logicwax> well, difficulty is voted by all nodes, is it not?
215 2014-02-19 08:26:55 <Luke-Jr> ………….
216 2014-02-19 08:27:11 <bitpar> Difficulty is computed by a function, it's not voted on.
217 2014-02-19 08:27:48 <Logicwax> computed yes...but the result is whatever 51% of nodes consider is the answer, no?
218 2014-02-19 08:28:00 <wumpus> no
219 2014-02-19 08:28:01 <bitpar> No
220 2014-02-19 08:28:06 <Logicwax> or is it just the miners decide that too?
221 2014-02-19 08:28:09 <bitpar> No
222 2014-02-19 08:28:25 <phillipsjk> In the US participating in something is considered "voting". They think capitalism works too :)
223 2014-02-19 08:28:41 <wumpus> phillipsjk:  ;)
224 2014-02-19 08:28:42 <Logicwax> heh
225 2014-02-19 08:28:55 <bitpar> Nodes will not accept any blocks if they do not meet the difficulty requirement calculated by the node.
226 2014-02-19 08:29:29 <Logicwax> so what happens when 10,000 people download a copy of bitcoin-qt that has a slightly modded diffculty calc function
227 2014-02-19 08:29:46 <bitpar> a fork happens
228 2014-02-19 08:29:54 <phillipsjk> Logicwax, likely a block-chain fork.
229 2014-02-19 08:29:56 <Logicwax> is it whatever the miners decide it is?
230 2014-02-19 08:30:15 <Logicwax> well that doesnt sound good :/
231 2014-02-19 08:30:38 <phillipsjk> Miners would have to choose what fork to participate in , as would the non-mining nodes.
232 2014-02-19 08:30:53 <wumpus> Logicwax: well if none of those people is a miner, they would reject every new block
233 2014-02-19 08:30:59 <maaku> Logicwax: please don't fill up this channel with non-development stuff. People are trying to work here.
234 2014-02-19 08:31:11 <phillipsjk> It gets awkward if the non-mining nodes disagree with the miners though.
235 2014-02-19 08:31:25 <uiop> Luke-Jr: (i must say though, your unicode period coup de grace took me for a chuckle)
236 2014-02-19 08:31:26 <Logicwax> maaku: ok ok.....the ball was rolling though.  my apologies
237 2014-02-19 08:31:57 <Logicwax> phillipsjk: that sounds like voting to me :)
238 2014-02-19 08:32:24 <maaku> These are fair questions for someone new to bitcoin to ask (you'll find there are plenty of answers), but #bitcoin or bitcointalk or the bitcoin stack exchange are probably better locations
239 2014-02-19 08:33:24 <Logicwax> maaku:  im not asking for what is implemented.   but asking to spur thought on improvement
240 2014-02-19 08:34:11 <phillipsjk> Logicwax, suggesting improvement is difficult if you do not understand it.
241 2014-02-19 08:34:15 <wumpus> you need to understand how it works before you can think of improvements
242 2014-02-19 08:34:25 <uiop> Logicwax: "improvement" (without consensus) is indistinguishable from an attack
243 2014-02-19 08:34:54 <uiop> in fact, since improvement is subjective, it just might be an attack
244 2014-02-19 08:37:35 <Logicwax> right.  and everything said thus far is exactly as I understood it to be.   (except for the severity of the fork).    I just wanted to poll some of your thoughts on how a voting system could be implemented
245 2014-02-19 08:37:49 <Logicwax> or how the block forking that would happen, could not be defined as voting
246 2014-02-19 08:38:55 <uiop> Logicwax: the "voting" is implicit, in the same sense that a mob "votes" to overturn the first car, then to begin the looting. "vote" is another word for "no one can stop it"
247 2014-02-19 08:39:00 <maaku> Logicwax: what you're asking is akin to "What if we built a perpetual motion machine, wouldn't that help?" - why yes, yes it would.
248 2014-02-19 08:40:07 <maaku> Read the whitepaper, the source code, what technical explanations are out there and you will understand why it doesn't even make sense to propose nodes "simply vote"
249 2014-02-19 08:40:15 <Logicwax> uiop: good phrasing.
250 2014-02-19 08:40:53 <Logicwax> but as phillipsjk said with block forking, it sounds like this matches that description of voting (as it wouldnt be the 51% hash power voting, but rather all nodes)
251 2014-02-19 08:41:31 <phillipsjk> Logicwax, except both candidates win
252 2014-02-19 08:42:14 <phillipsjk> ..causing confusion of course.
253 2014-02-19 08:42:31 <bitpar> Logicwax: It's not really voting, my client will disregard a fork that contains a block it considers to be invalid, regardless of the hash power or length of that chain.
254 2014-02-19 08:43:56 <Logicwax> bitpar: exactly.  so you would be casting a vote essentially (your client could be a forked source version, with different rules).   whereas, in the TX's the hash power botes
255 2014-02-19 08:43:57 <wumpus> -dev is not the place for dreamy ideas without a firm grounding in reality, before you know it people start talking about PoW functions that cure cancer or hosting the blockchain in DHTs
256 2014-02-19 08:44:45 <phillipsjk> 
ACTION notes wumpus is not joking.

257 2014-02-19 08:45:10 <bitpar> If I change the source code of my client to use different rules than set by the Bitcoin protocol, then it's not really Bitcoin anymore.
258 2014-02-19 08:45:49 <Logicwax> all I'm trying to say, is that the TX inclusions are voted by hash power.  and difficulty (amongst others im sure) is voted by ALL nodes.     i'll shutup now.
259 2014-02-19 08:46:49 <wumpus> changing the protocol to avoid 50% attacks is among those things, many people have talked about it, the internet is full of discussions about it, the chance that you'll solve this particular problem is very very small. And if you do have that great proposal please write it down clearly in a way that can be implemented, or even better, make an implementation.
260 2014-02-19 08:48:41 <bitpar> And it's not of much benefit if the implementation introduces centralization or another set of problems.
261 2014-02-19 08:49:46 <uiop> wumpus: lol
262 2014-02-19 08:49:51 <uiop> wumpus: (PoWs and DHTs)
263 2014-02-19 08:50:09 <Luke-Jr> wumpus: someone was arguing with me the other day insisting bitcoin should support scientific research with mining
264 2014-02-19 08:50:32 <Luke-Jr> I don't know why they think Bitcoin can overlap with folding@home any better than SETI can :/
265 2014-02-19 08:50:37 <Logicwax> bitpar: all nodes voting on difficulty isn't centralization.  it happens already!
266 2014-02-19 08:51:06 <Luke-Jr> 
ACTION wonders at what point Logicwax gets kicked for idiocy >.>

267 2014-02-19 08:51:08 <Logicwax> heh SETI
268 2014-02-19 08:51:10 <antephialtic> I wouldn't be opposed to that, if it was possible to construct such a "useful" PoW that could be a) tunable to a desired difficulty, b) easily verifiable
269 2014-02-19 08:51:10 <uiop> Luke-Jr: the other week i got served a targeted ad for a (real) mining company based out of reno nevada :)
270 2014-02-19 08:51:11 <wumpus> Luke-Jr: and the worst thing is that they mean well, but suggestion without understanding the scope of the problem are just useless
271 2014-02-19 08:51:46 <wumpus> 'why don't we just...'
272 2014-02-19 08:51:58 <antephialtic> and cunningham chains are of dubious usefulness
273 2014-02-19 08:52:09 <wumpus> anyway, this is offtopic for -dev as well
274 2014-02-19 08:52:34 <uiop> haha, i read PoW and POW until just now
275 2014-02-19 08:52:56 <uiop> s/and/as/
276 2014-02-19 08:53:09 <Luke-Jr> uiop: …?
277 2014-02-19 08:53:23 <Luke-Jr> like Mario POW?
278 2014-02-19 08:53:25 <uiop> i read proof-of-work as prisoner-of-war until 10 seconds ago :)
279 2014-02-19 08:53:28 <Luke-Jr> o
280 2014-02-19 08:54:08 <bitpar> You should ask them why doesn't scientific research support bitcoin mining with their distributed computing.
281 2014-02-19 08:56:44 <uiop> (just read it as that in wumpus' last comment though, of course)
282 2014-02-19 08:57:23 <wumpus> let's just hope no one builds an altcoin based on proof-of-war
283 2014-02-19 08:58:01 <uiop> if they did, i wonder if they'd take prisoners?
284 2014-02-19 09:00:03 <uiop> don't answer that
285 2014-02-19 09:01:27 <gmaxwell> wumpus: it's pretty easy to do proof-you-attacked-another-blockchain.
286 2014-02-19 09:02:02 <uiop> omg, corewars meets the blockchain!
287 2014-02-19 09:03:47 <gmaxwell> good thing SSL doesn't provide non-repudiation, otherwise SSL to ciaworld fact book could get you proof-of-genocide. :(
288 2014-02-19 09:04:45 <Diablo-D3> uh.
289 2014-02-19 09:04:47 <Diablo-D3> I.
290 2014-02-19 09:04:47 <wumpus> well in when people start to blabber about how bitcoin wil bring a dystopia to the world, we can always tell them it could be worse
291 2014-02-19 09:04:48 <Diablo-D3> uih.
292 2014-02-19 09:04:51 <Diablo-D3> gmaxwell: wat.
293 2014-02-19 09:07:26 <uiop> Diablo-D3: gmaxwell's analogy was a homomorphism, not an iso. the brave new world of post-modernism
294 2014-02-19 09:10:08 <BlueMatt> gmaxwell: hah!
295 2014-02-19 09:11:21 <gmaxwell> wumpus: there are template based range checked types that can be used in C++ ... not exactly the speediest stuff.
296 2014-02-19 09:11:41 <gmaxwell> and they often make debugging much harder, since any issue turns into pages of template indirection rubbish.
297 2014-02-19 09:11:41 <wumpus> gmaxwell: right, but CPUs have supported overflow flags since... before I was born
298 2014-02-19 09:12:08 <wumpus> checking those flags would be slower, but it wouldn't need to be much slower
299 2014-02-19 09:12:19 <gmaxwell> wumpus: yep. though algebraic simplification can make them less than useful, also checking the flags register almost always stalls the pipeline.
300 2014-02-19 09:12:53 <gmaxwell> clang can compile with integer sanitization, which is nice, but there is a pretty obvious performance hit.
301 2014-02-19 09:13:42 <Diablo-D3> so why not just use Indra?
302 2014-02-19 09:14:26 <wumpus> gmaxwell: but then you have to make the choice to use it everywhere, it should be an optional thing per case
303 2014-02-19 09:14:43 <wumpus> or per type at least
304 2014-02-19 09:14:45 <antephialtic> q: would it be possible to add a new sighash type w/o a hard fork?
305 2014-02-19 09:15:49 <gmaxwell> antephialtic: yes, by adding a new checksig operator, or via P2SH like nesting of a new script kind.
306 2014-02-19 09:16:21 <antephialtic> yeah, I meant as a new checksig operator.
307 2014-02-19 09:17:35 <gmaxwell> antephialtic: though in past contemplation I've had about new sighash flags, it turns out that a lot of ideas that initially sound good have awkward corner cases.
308 2014-02-19 09:18:06 <gmaxwell> so getting the actual mechnics right may be harder than the actual deployment. :)
309 2014-02-19 09:18:26 <antephialtic> gmaxwell: I've been thinking about this today, would it be possible to have a SIGHASH_DOUBLE that signed two inputs & two outputs
310 2014-02-19 09:19:09 <antephialtic> goal is to enable some kind of transaction reassembly (w/ change output) for a 1RTT coinjoin
311 2014-02-19 09:19:30 <gmaxwell> antephialtic: yea I've wanted that— or more generally something which could bitmask take a count and offset for both inputs and outputs... and would sign them (and the masks themselves, of course)
312 2014-02-19 09:20:41 <gmaxwell> I've also wanted the ability to sign value>=x instead of value, so that an output could be increased by another signature...
313 2014-02-19 09:21:07 <antephialtic> I think a major usecase would be for a merchant server in a BIP70 exchange. Merchant would have freedom to coalesce/permute groups of transactions as they please
314 2014-02-19 09:22:27 <antephialtic> could allow for integration of coinjoin & payment protocol
315 2014-02-19 09:23:40 <gmaxwell> antephialtic: I'd like there to someday be a payment protocol message that says "if you understand this message, please also add these extra txid:vouts to your transaction so I can coalesce my funds via your payment to me"
316 2014-02-19 09:24:48 <antephialtic> yeah that is another way of doing it. Honestly, its probably more realistic to change bip70 at this point than to change opcodes
317 2014-02-19 09:25:04 <antephialtic> but opcode changes are more interesting to think about :)
318 2014-02-19 09:25:59 <gmaxwell> well it can be added to payment protocol in the future too... just a new bip for a new message type.
319 2014-02-19 09:26:23 <t7> get rid of scripts, they (non standard ones) are not used enough to justify the complexity
320 2014-02-19 09:29:33 <antephialtic> gmaxwell: also, have you heard anything about ZeroCash? interested to hear your thoughts
321 2014-02-19 09:35:24 <gmaxwell> t7: go away.
322 2014-02-19 09:36:13 <t7> the minimalists will not be silenced
323 2014-02-19 09:36:44 <t7> we want a tiny, formally verified core
324 2014-02-19 09:37:23 <antephialtic> t7: show us your coq
325 2014-02-19 09:38:13 <t7> we will get a team of 200 to go through each line of C individually
326 2014-02-19 09:38:26 <t7> all with grey beards
327 2014-02-19 09:38:31 <gmaxwell> t7: too bad— first, it's the way it is and there is no way you're convincing people to remove that functoinality, so it's a dead argument.  Beyond that, without the ability to bind external things you end up constantly having to transfer coins to centeralized parties— defeating the purpose of the system.
328 2014-02-19 09:39:51 <gmaxwell> Beyond that, script is actually pretty simple and the implementation of it is within the scope of things that could be formally verified.
329 2014-02-19 09:40:41 <t7> i have a feeling someone already started on that
330 2014-02-19 09:40:50 <t7> i remember reading something
331 2014-02-19 09:41:51 <gmaxwell> roconnor started on a haskell implementation which is somethat he said he'd do before a COQ one, but he burned out on bitcoin before finishing the work. (and had a bunch of complaints, though not about script)
332 2014-02-19 09:42:09 <wumpus> having no scripting language means everything has to be special-caed
333 2014-02-19 09:42:14 <wumpus> special-cased*
334 2014-02-19 09:42:34 <gmaxwell> he did convince us to not implement OP_EVAL which would have made formal analysis much harder.
335 2014-02-19 09:42:47 <epscy> t7: I would like to see a fork without the scriptSig stuff
336 2014-02-19 09:43:41 <gmaxwell> meanwhile ethereum people are talking about raising 30k btc to fund development of a "turing complete" script, including stuff like having a JIT as an essential to implement functionality...
337 2014-02-19 09:43:59 <t7> lol
338 2014-02-19 09:44:13 <SomeoneWeird> 0.o
339 2014-02-19 09:44:19 <wumpus> and a minimal scripting language could be more minimalistic than trying to enumerate what everyone wants (effectively using C++ as a very inflexible scripting language)
340 2014-02-19 09:44:23 <t7> dont they need to define an upper bound of operations or something?
341 2014-02-19 09:44:50 <BlueMatt> gmaxwell: waiiittt...they want a jit as a part of their execution engine?
342 2014-02-19 09:44:52 <BlueMatt> wow....
343 2014-02-19 09:45:13 <gmaxwell> t7: they'll have a cycle counter that burns fees (and then the cycle counter is part of the normative implementation, good freeking luck not having consistency bugs in a JIT there!)
344 2014-02-19 09:45:51 <wumpus> ethereum is kind of the other extreme, it will be too complex to make any sense of for humans
345 2014-02-19 09:45:52 <t7> thats not as stupid as it first sounds
346 2014-02-19 09:45:53 <gmaxwell> BlueMatt: yea, latest banter is about eliminating all high level operations like OP_SHA256 and implementing everything in the script, and then just having a smart implementation that does the right thing (TM) to get acceptable performance.
347 2014-02-19 09:46:36 <BlueMatt> gmaxwell:and they have billions in funding and 10 years to get it right before launch, right?
348 2014-02-19 09:47:05 <gmaxwell> "Good luck!"
349 2014-02-19 09:47:38 <jcorgan> [6~[6~/clear
350 2014-02-19 09:48:10 <antephialtic> heh, maybe they can just use brainfuck as the scripting language
351 2014-02-19 09:48:10 <gmaxwell> t7: they still have the problem of not being able to compensate nodes for the validation costs, sadly.
352 2014-02-19 09:48:36 <wumpus> or VBA :p
353 2014-02-19 09:49:12 <gmaxwell> In any case, it's 180 degrees away from what I think prudent development in that space is.  The first is that the realization that script isn't— and shoudln't be— execution itself. Rather script is a transcript of successful execution the TX author performed, and the script+signature should just be a witness proving that the script was executed faithfully and accepted.
354 2014-02-19 09:49:37 <antephialtic> zkSnark scripts?
355 2014-02-19 09:49:37 <Diablo-D3> gmaxwell: hey, do me a favor
356 2014-02-19 09:49:44 <gmaxwell> Once you've adopted this mental model things like merkelized AST— where you only disclose the branches in the script you actually took— start making obvious sense.
357 2014-02-19 09:50:00 <Diablo-D3> explain to me this tx malleability problem
358 2014-02-19 09:50:19 <gmaxwell> And then— yea, you can then apply moon-math and start talking about succinct witnesses for execution, and scripts that execute in zero-knoweldge.
359 2014-02-19 09:50:37 <gmaxwell> Diablo-D3: go get andy's doc.
360 2014-02-19 09:50:41 <Diablo-D3> gmaxwell: url?
361 2014-02-19 09:50:48 <gmaxwell> Diablo-D3: grep andytoshi \#bitcoin.log | grep http
362 2014-02-19 09:51:01 <Diablo-D3> gmaxwell: because this sounds like something I was trying to figure out like two years ago but couldnt make it work
363 2014-02-19 09:51:06 <Diablo-D3> gmaxwell: I dont log irc
364 2014-02-19 09:51:07 <antephialtic> Diablo-D3: this is a good primer http://www.righto.com/2014/02/bitcoin-transaction-malleability.html
365 2014-02-19 09:51:30 <gmaxwell> Diablo-D3: http://download.wpsoftware.net/bitcoin/malleability-faq.pdf
366 2014-02-19 09:51:46 <Diablo-D3> heh
367 2014-02-19 09:51:52 <Diablo-D3> so it IS the problem I was looking at
368 2014-02-19 09:52:00 <Diablo-D3> I should have kept working at it =/
369 2014-02-19 09:52:02 <gmaxwell> antephialtic: even just the merkelized AST stuff can have big space efficiency and privacy advantages.
370 2014-02-19 09:52:36 <Diablo-D3> gmaxwell: btw, isnt the solution to just not allow garbage in tx?
371 2014-02-19 09:52:50 <stonecoldpat> what is this 'AST stuff'?
372 2014-02-19 09:53:01 <jcorgan> what could possibly go wrong?
373 2014-02-19 09:53:06 <Diablo-D3> stonecoldpat: abstract syntax tree
374 2014-02-19 09:53:12 <stonecoldpat> ah ok
375 2014-02-19 09:53:25 <gmaxwell> antephialtic: e.g. if you can redeem a coin with either key1 or key2+key3+key4+key5  why should your key1 spends disclose and extra 128 bytes of information about those other keys?
376 2014-02-19 09:54:35 <uiop> gmaxwell, wumpus: OP_EVAL would turing complete script
377 2014-02-19 09:55:09 <wumpus> well there were very strict limits proposed on OP_EVAL
378 2014-02-19 09:55:11 <antephialtic> gmaxwell: makes sense.
379 2014-02-19 09:55:49 <wumpus> but it does complicate things a lot, I'm happy that an alternative was chosen
380 2014-02-19 09:58:59 <Diablo-D3> gmaxwell: btw, the proposed fix is to sign an ast instead of the actual tx?
381 2014-02-19 09:59:39 <wumpus> Diablo-D3: eh, no, that train of thought has nothing to do with the malleability issue
382 2014-02-19 10:00:36 <wumpus> Diablo-D3: proposed BIP for dealing with malleability: https://gist.github.com/sipa/8907691
383 2014-02-19 10:00:58 <Diablo-D3> k
384 2014-02-19 10:10:56 <gmaxwell> uiop: well OP_EVAL was proposed as depth limited a depth of ~3.
385 2014-02-19 10:11:45 <gmaxwell> uiop: while no memory limited (or recursion limited) machine meets the most agressive definition, 3 is pretty darn limited.
386 2014-02-19 10:12:19 <gmaxwell> uiop: in any case, it would have greatly complicated static analysis.
387 2014-02-19 10:13:14 <gmaxwell> OTOH, perhaps people wouldn't be talking about pouring millions in costs on etherum now. :-/  ... really stuff in script is horribly underutilized as is, I love that functionality more than most things in bitcoin, but the reality is that it just is not used.
388 2014-02-19 10:13:43 <gmaxwell> though some uses are killed by little niggles, (uh like malleability making nlocked refunds really hard)
389 2014-02-19 10:14:11 <antephialtic> I think script was just a way for satoshi to nerd snipe a bunch of smart people to work on his project
390 2014-02-19 10:14:24 <antephialtic> (kidding, of course)
391 2014-02-19 10:14:40 <gmaxwell> antephialtic: you'd think, but there are really only a few people who have explored interesting things with script.
392 2014-02-19 10:14:41 <wumpus> gmaxwell: imo it just becomes too complex for mortals, too many little details, too many things that can be slightly-wrong causing DOS or even money loss at worst
393 2014-02-19 10:14:45 <stonecoldpat> their just a bit complicated, and the wiki does not do it any favours on trying to explain how they work
394 2014-02-19 10:15:17 <gmaxwell> At least at one point last year I was estimating that something like >90% of all 'fancy' script use was myself an petertodd.
395 2014-02-19 10:15:42 <antephialtic> stonecoldpat: I always liked this document as an intro http://bitcoinhistory.net/Technical_Papers/ProgrammingBitcoinTransactionScripts.pdf
396 2014-02-19 10:16:01 <wumpus> indeed, even this trivial malleability issue that shouldn't be really an issue if you do things the right way caused big havoc
397 2014-02-19 10:16:17 <stonecoldpat> antephialtic: i have not seen that, will give it a read
398 2014-02-19 10:17:12 <gmaxwell> wumpus: yes, though some better tools would help.  E.g. you should be able to enter in a list of keys and draw something like a karnaugh map, and get a script out.
399 2014-02-19 10:17:13 <wumpus> maybe in 20 years we can try a bitcoin with more advanced scripting, right now the world just isn't ready for it
400 2014-02-19 10:17:21 <antephialtic> gmaxwell: if you count multisig, one of the blackmarkets has been using them extensively
401 2014-02-19 10:18:02 <wumpus> gmaxwell: sure, better tools would help, but it takes a long time for good tools to appear, and in the meantime people will just... do something
402 2014-02-19 10:18:09 <gmaxwell> antephialtic: yea, though if we weren't using braindamaged sigining, basic threshold signatures wouldn't even need script.
403 2014-02-19 10:19:24 <gmaxwell> (with schnorr you can do N of N with no special key generation and N of M with a two round multiparty key generation,  and the signatures are indistinguishable from a regular single party signature)
404 2014-02-19 10:20:48 <gmaxwell> antephialtic: in any case, you can do a whole bunch of stuff with a very small amount.
405 2014-02-19 10:20:51 <antephialtic> gmaxwell: haven't heard of schnorr signatures before.
406 2014-02-19 10:20:58 <antephialtic> wiki time :)
407 2014-02-19 10:21:12 <gmaxwell> Schnorr predated DSA. DSA was the NSA's kludge to avoid the schnorr patents.
408 2014-02-19 10:21:25 <gmaxwell> The schnorr patents expired like ... last year.
409 2014-02-19 10:21:40 <stonecoldpat> antephialtic: way i remember them is by thinking of controlling nuclear weapons, usa needed 2/3 people to activiate the warhead (maybe it was russia?)
410 2014-02-19 10:22:08 <gmaxwell> In any case, with nothing more than N of M threshold signatures and hashlocking you can do an enormous number of things.
411 2014-02-19 10:22:34 <antephialtic> many of the NSA cryptosystems I've looked at seem to be lacking in elegance
412 2014-02-19 10:23:03 <stonecoldpat> what is a hash lock?
413 2014-02-19 10:23:28 <gmaxwell> stonecoldpat: requiring a preimage of a hash to spend a coin.
414 2014-02-19 10:24:02 <antephialtic> gmaxwell: wow that is much simpler than DSA
415 2014-02-19 10:24:05 <gmaxwell> which sounds like a totally boring and not very useful functionality.
416 2014-02-19 10:24:12 <stonecoldpat> gmaxwell: so essentially its password-based spending?
417 2014-02-19 10:24:23 <stonecoldpat> i like that alot, didnt think it was possible
418 2014-02-19 10:24:27 <Logicwax> [02:13] <gmaxwell> though some uses are killed by little niggles, (uh like malleability making nlocked refunds really hard)
419 2014-02-19 10:24:33 <Logicwax> gmaxwell: how does that kill nlocked refunds?
420 2014-02-19 10:24:54 <Logicwax> because they refer to the prev TX via TXID?
421 2014-02-19 10:25:01 <gmaxwell> stonecoldpat: Yes. And it's actually insanely powerful. E.g. some protocols I've proposed that are based on hashlocks:  https://en.bitcoin.it/wiki/Zero_Knowledge_Contingent_Payment and https://bitcointalk.org/index.php?topic=321228.0
422 2014-02-19 10:25:05 <gmaxwell> Logicwax: yep.
423 2014-02-19 10:25:21 <Logicwax> ouch.  didnt think about that.    that.....is unfortunate
424 2014-02-19 10:25:25 <gmaxwell> Logicwax: there is a way around it, mostly.
425 2014-02-19 10:26:01 <gmaxwell> You can effectively blind it so that the other party can't reconize the txn that their refund is a refund for... so they'd have to try to mutate all transactions and not just the one they want to kill the refund for.
426 2014-02-19 10:26:09 <gmaxwell> But that complicates the protocols and its not a complete fix.
427 2014-02-19 10:26:46 <gmaxwell> you can also have the other party put their own funds into the escrow instead of or in addition to a refund, but again, complicates things and isn't a complete replacement.
428 2014-02-19 10:27:37 <Logicwax> hrmm i see
429 2014-02-19 10:27:41 <antephialtic> gmaxwell: is there anything preventing one from using an elliptic curve over a prime field as the underlying group for schnorr?
430 2014-02-19 10:27:46 <gmaxwell> antephialtic: yea, schnorr is nice. Strong security proofs, threshold signatures, blindsigning is straightforward...
431 2014-02-19 10:28:20 <gmaxwell> antephialtic: nope, works fine, thats what eddsa (the ed25519 stuff) really is, (well they use a curve with cofactor 8).
432 2014-02-19 10:29:46 <antephialtic> gmaxwell: I sure do love me some djb crypto
433 2014-02-19 10:31:26 <gmaxwell> Well, I'm less impressed than I used to be. Not fond of the cofactor in ed255519, nor the crazy thing they do to make it constant time (require the most significant bit of the private key to be 1, which breaks BIP32 like derivation)... doing all the computation in the FPU registers is a bit unholy and at the end of the day its basically within a factor of 2 of a well optimized secp256k1 implementation ::meh::   :P  In any case, schnorr ...
434 2014-02-19 10:31:32 <gmaxwell> ... signatures are <3.
435 2014-02-19 10:31:47 <bitpar> How come for sendmany it says, "amounts are double-precision floating point numbers", while sendfrom says, "<amount> is a real and is rounded to the nearest 0.00000001"? Both read the value as int64 nAmount = AmountFromValue() and bitcoinrpc.cpp contains if (strMethod == "sendmany" && n > 2) ConvertTo<boost::int64_t>(params[2]);
436 2014-02-19 10:33:00 <gmaxwell> bitpar: JSON numbers are "double-precision floating point numbers" all bitcoin values are converted to integer base units (1e-8 BTC) internally, and a double precision number can exactly represent all of these values.
437 2014-02-19 10:33:09 <Logicwax> to save the usefuleness of nlocked TXs from meow-ability, maybe thats a good reason to argue nTX to make it into the protocol  (aside from zeroconf change problems)
438 2014-02-19 10:34:42 <gmaxwell> Logicwax: lol. No.  Mallablity is a feature too— all the other sighash flags result in inherent mallability. Different transactions having the same hash would be devastating in its own ways.
439 2014-02-19 10:35:16 <gmaxwell> Logicwax: we have a plan we've been executing for years to make it possiblity to make (at the senders option) mallability free txn, the refunds case being a primary motivator for doing that.
440 2014-02-19 10:36:59 <gmaxwell> There have been times when I've wanted the input txid:vout omitted from the signature... but that would be an easily abused functionality.
441 2014-02-19 10:37:16 <gmaxwell> (one reason is that it would allow you to make provably timelocked funds)
442 2014-02-19 10:37:46 <bitpar> I understand that doubles can represent all BTC values. It just seemed odd that sendfrom and sendmany would use different descriptions of what amount is.
443 2014-02-19 10:38:01 <gmaxwell> e.g. you compute the nlocktimed release transaction, set the signature to a nothing up my sleeve number, back compute the public key, and use that as the output in the the transaction paying into the lock.
444 2014-02-19 10:38:19 <gmaxwell> bitpar: submit documentation fixing pull please. :)
445 2014-02-19 10:40:45 <sipa> that convert to int64 is strange
446 2014-02-19 10:41:51 <bitpar> Ok, I haven't contributed before. I can change the description of sendmany to match.
447 2014-02-19 10:43:45 <antephialtic> gmaxwell: do schnorr signatures still exhibit malleability?
448 2014-02-19 10:45:44 <gmaxwell> antephialtic: not the schnorr part itself— andytoshi has created a proof that they are not which has preliminary convinced me. Though most of our malleability comes from the bitcoin hybrid cryptosystem, not DSA itself (only one bit comes from DSA as far as we currently know)
449 2014-02-19 10:46:43 <maaku> yeah, but everything else is within our control to lock down on...
450 2014-02-19 10:48:20 <sipa> the signatures are too :)
451 2014-02-19 10:48:30 <antephialtic> cool. Will do more reading on these later this week. Anyways, I'm off to sleep. goodnight everyone.
452 2014-02-19 10:49:01 <maaku> sipa: I mean the (potential, unknown) intrinsic ECDSA malleability
453 2014-02-19 10:49:32 <maaku> e.g. substituting k values without the private key, or whatever
454 2014-02-19 10:50:48 <gmaxwell> maaku: they seem unlikely to me, at least. I do think we'll eventually get a proof that there are no more.
455 2014-02-19 10:51:33 <jcorgan> gmaxwell: are Schnorr keys comparable in size to RSA ones for equivalent security?
456 2014-02-19 10:52:38 <gmaxwell> jcorgan: when we talk about schnorr around here we're talking about Ec Schnorr... which could use the same group as we use for DSA in bitcoin.
457 2014-02-19 10:53:09 <gmaxwell> Integer schnorr is like DSA... RSA sized keys.
458 2014-02-19 10:53:41 <jcorgan> that's what i was thinking, but didn't realize you were referring to an EC version of Schnorr
459 2014-02-19 11:10:59 <tlrobinson> anyone care to critique my layman's explanation of malleability? http://blog.tlrobinson.net/preview/Fgq9l782N1AxxWrrrVzU/
460 2014-02-19 11:16:05 <sipa> tlrobinson: it likely does not require a hard fork to make malleability of common transaction types impossible
461 2014-02-19 11:16:25 <sipa> though with a hard fork, more complete solutions are possible
462 2014-02-19 11:19:11 <tlrobinson> ok thanks
463 2014-02-19 11:21:28 <sipa> also, some forms of malleability are intentional and a feature required for complex transaction types
464 2014-02-19 11:22:02 <sipa> so it's inevitable that some software will need to be able to deal with it properly
465 2014-02-19 11:23:43 <sipa> however, that's very similar to dealing with double spends (from the poibt of view of your wallet, a mutated transaction is just a new transaction that spends the same funds... however you didn't create it)
466 2014-02-19 11:25:16 <stonecoldpat> @gmaxwell: hash lock - is that what is used for the zero coin idea? you release coin and reclaim it using a password, and then its no longer linkable?
467 2014-02-19 11:25:18 <tlrobinson> that's from the recipient's perspective, whereas gox's issue is from the sender's perspective
468 2014-02-19 11:26:42 <sipa> tlrobinson: agree
469 2014-02-19 11:27:03 <sipa> Persopolis: don't pm me with basic questions please
470 2014-02-19 11:28:56 <sipa> Persopolis: please ask here or in another channel
471 2014-02-19 11:29:12 <Persopolis> right - ok - sorry!
472 2014-02-19 11:34:12 <Persopolis> I asked in a PM as it is nooby question and didn't wana occupy the channel - but sorry I should have asked if you were willing to PM first
473 2014-02-19 11:36:06 <sipa> stop talking about asking your question and just ask it :)
474 2014-02-19 11:37:10 <Persopolis> lol - I didn't understand what is being modified to cause a change to the transaction hash, but yet without invalidating it
475 2014-02-19 11:38:11 <sipa> well the transaction hash covers everything including the signatures
476 2014-02-19 11:38:39 <justanotheruser> So on the bitcoin.it scripts page it lists inputs for an opcode (usually a certain number of bytes or expressions). Is there any reason anyone would want to override this and have more or less inputs...
477 2014-02-19 11:39:18 <justanotheruser> ...than it specifies? (I'm specifically asking how well the stack based language would translate to a functional lisp like language)
478 2014-02-19 11:39:35 <sipa> the signature however doesn't sign the full transaction, but only part of it (in particular, not the signatures thenselves, as you can't know them in advance)
479 2014-02-19 11:40:01 <sipa> Persopolis: so all you need is replace the signature script with another valid signature script
480 2014-02-19 11:40:21 <sipa> adding some dummy push or ignored byte suffices
481 2014-02-19 11:40:53 <sipa> justanotheruser: i don't understand the question
482 2014-02-19 11:41:03 <justanotheruser> sipa: Sorry, I woke up 2 minutes ago
483 2014-02-19 11:56:06 <Persopolis> Sipa - thanks - I think I understand - the scriptSig is being modified (with a corresponding non critical change to the script), but the public key is being left intact?
484 2014-02-19 11:59:58 <wumpus> the signature is  being left intact* just the encoding of it is reduntand and that leaves some wiggling room
485 2014-02-19 12:06:29 <wallet42> Luke-Jr: whats a stale block?
486 2014-02-19 12:06:41 <wallet42> in comparason to a orphan?
487 2014-02-19 12:07:04 <wallet42> nevermind found the answer on stackexchange
488 2014-02-19 12:07:46 <wallet42> https://bitcoin.stackexchange.com/questions/5859/what-are-orphaned-and-stale-blocks
489 2014-02-19 12:09:02 <wallet42> so am i correct if i assume blk* contains only the main chain in the correct order?
490 2014-02-19 12:09:44 <wumpus> wallet42: yes
491 2014-02-19 12:10:46 <wumpus> well the correct order at least, and it won't contain orphans
492 2014-02-19 12:11:10 <wumpus> it may contain other forks than the main chain
493 2014-02-19 12:11:32 <wumpus> but everything is connected
494 2014-02-19 12:11:34 <wallet42> im not sure if i follow...
495 2014-02-19 12:12:14 <wallet42> blockchain.info has a page where they show orphans, but these are only stored by them and does not necessary shows all ever produced (+orphans) blocks since it is not connected to ever node on the network
496 2014-02-19 12:12:37 <wallet42> https://blockchain.info/orphaned-blocks
497 2014-02-19 12:18:47 <tjopper> I see typo´s in this new blockchain page, were do I report those
498 2014-02-19 12:20:33 <sipa> wallet42: that refers to stale blocks
499 2014-02-19 12:21:17 <wallet42> an "orphan" does not have parents, at least in git
500 2014-02-19 12:21:18 <sipa> wallet42: orphan blocks are simply blocks without parent (which almost nobody talks about, and everyone uses the word orphan blocks to refer to blocks that cause orphaned coinbase transactions)
501 2014-02-19 12:21:26 <wumpus> the client doesn't know whether it is on the 'main chain', it only has a local perspective of the best chain known to it at the time and considers that the main chain... but older forks can overtake the current best chain, in which case the blocks from the 'other fork' will already be written to the blkXXXX files
502 2014-02-19 12:21:28 <wallet42> so ophan does not make sense in blocks
503 2014-02-19 12:21:38 <sipa> wallet42: it does
504 2014-02-19 12:21:42 <wallet42> only in transactions if the parent tx becomes invalid
505 2014-02-19 12:21:56 <sipa> wallet42: a node can receive a block for which the predecessor isn't know
506 2014-02-19 12:22:08 <sipa> this is what the bitcoind source code calls orphan blocks
507 2014-02-19 12:22:16 <wallet42> oh okay
508 2014-02-19 12:22:19 <sipa> and those are not stored on disk, but kept in memory for a short time
509 2014-02-19 12:22:29 <wallet42> during the downloading, there are orphaned blocks for instance
510 2014-02-19 12:22:31 <sipa> while we ask for the missing parrent
511 2014-02-19 12:22:42 <wallet42> so what i really mean is stale blocks
512 2014-02-19 12:22:57 <wallet42> the terminology orphan comes from coinbase tx,
513 2014-02-19 12:23:10 <wallet42> which are invalid since not on the main chain
514 2014-02-19 12:23:15 <wallet42> okay i start to understand
515 2014-02-19 12:24:28 <wallet42> so blk** contains stale blocks?
516 2014-02-19 12:24:29 <sipa> so the blocks in the block files are guaranteed to be in order (for now, once we have parallel block download that won't be the case anymore)
517 2014-02-19 12:24:30 <wumpus> if you want a linear blocks file get the bootstrap.dat torrent (or use linearize.py on your own files)
518 2014-02-19 12:29:10 <wallet42> what does bitcoind do if i tell you i have a block for a height you already have
519 2014-02-19 12:29:33 <wallet42> a different one ofc i mean
520 2014-02-19 12:29:51 <stonecoldpat> wallet42: if there is a block chain bigger than the one you provide, then it gets ignored
521 2014-02-19 12:30:09 <stonecoldpat> wallet42: so if the current blockchain is at height 100, and the block you provide is at height 99, then yours does not get accepted
522 2014-02-19 12:30:29 <sipa> wallet42: we simply fetch all blocks you announce
523 2014-02-19 12:30:34 <stonecoldpat> wallet42: if their both at the same height, i think its just what it sees first?
524 2014-02-19 12:30:42 <sipa> wallet42: and the largest valid chain is considered the active one
525 2014-02-19 12:30:50 <sipa> and if there are several, the one we saw firs
526 2014-02-19 12:31:04 <wallet42> so it gets downloaded but ignored
527 2014-02-19 12:31:26 <sipa> if it's not an orphan it will get stored on disk
528 2014-02-19 12:31:45 <wallet42> if i then provide block 99', 100', 101' it also gets loaded and then the reorg is done
529 2014-02-19 12:33:06 <wallet42> since the client loads and stores all valid blocks, the flooding of nodes with easy to calculate blocks is prevented with the checkpoint function
530 2014-02-19 12:33:14 <wallet42> still correct/
531 2014-02-19 12:33:16 <wallet42> ?
532 2014-02-19 12:33:53 <stonecoldpat> well for the most part, blocks arent really easy to calculate
533 2014-02-19 12:34:41 <wallet42> this is true for nowadays blocks
534 2014-02-19 12:35:08 <wallet42> but for blocks at height < 10'000 its still easy with an ASIC
535 2014-02-19 12:35:36 <wallet42> put this is prevented by the checkpoints to my understanding
536 2014-02-19 12:35:46 <wallet42> s/put/but/
537 2014-02-19 12:35:57 <stonecoldpat> pretty much, as they would be considered an orphan block
538 2014-02-19 12:36:25 <wallet42> thx for all clarification
539 2014-02-19 13:09:28 <sipa> stonecoldpat: orphan? no
540 2014-02-19 13:09:39 <sipa> stonecoldpat: they just wouldn't be considered active
541 2014-02-19 13:51:09 <shaileshg> what is the concept of account
542 2014-02-19 13:51:20 <sipa> ignore it
543 2014-02-19 13:51:25 <wallet42> bitcoind has "virtual" accounts
544 2014-02-19 13:51:33 <sipa> they're bean counters inside a wallet
545 2014-02-19 13:51:40 <sipa> but don't correspond to actual coins
546 2014-02-19 13:51:57 <wallet42> you can use "move" rpc to change balances at will
547 2014-02-19 13:52:46 <shaileshg> wallet42: change balances between addresses? in same wallet / account?
548 2014-02-19 13:53:00 <wallet42> shaileshg: account are virtual
549 2014-02-19 13:53:15 <sipa> shaileshg: addresses don't have balances (only the wallet as a whole has)
550 2014-02-19 13:53:25 <sipa> shaileshg: and this is about account balances, which are entirely virtual
551 2014-02-19 13:53:27 <wallet42> shailshg: you can have an empty wallet and create debit/credit
552 2014-02-19 13:53:29 <sipa> they can go negative even
553 2014-02-19 13:53:49 <bitpar> Should you leave users' balances in "" or create a users account?
554 2014-02-19 13:54:00 <wallet42> afaik all balances on all accounts summed up (debit/credit) equals the amount of actual bitcoin in the wallet
555 2014-02-19 13:54:14 <shaileshg> sipa: okay.. so account have account balances which are entirely virtual?
556 2014-02-19 13:54:54 <shaileshg> wallet42: i also think so.. makes sense.. sipa: could you confirm?
557 2014-02-19 13:55:10 <wallet42> shailshg: yes, you can create a new wallet.dat, then having 0 btc ever recieved you can make move "fromaccount" "toaccount" amount
558 2014-02-19 13:55:15 <shaileshg> wallet = sum(credit / debit across all addresses)
559 2014-02-19 13:55:15 <wallet42> move 1 2 10
560 2014-02-19 13:55:57 <wallet42> now you have listaccounts: { "": 0.000, "1": -10, "2": +10}
561 2014-02-19 13:56:45 <shaileshg> wallet42: is there any mapping between account and addresses or account and wallet at all?
562 2014-02-19 13:57:21 <wallet42> im not entirly familiar with the internals, but afaik you can use "setaccount" to tie an address to an virtual account
563 2014-02-19 13:57:38 <wallet42> if this address recieves bitcoin, it gets also creditet to the virtual account
564 2014-02-19 13:57:50 <shaileshg> okay..
565 2014-02-19 13:58:17 <wallet42> but again, im not 100% sure on the internals, eg. is the address tieing only for future payments or also past ones etc...
566 2014-02-19 13:59:05 <shaileshg> hmm
567 2014-02-19 13:59:22 <wallet42> sipa: when was the account system implemented? bitcoind v?
568 2014-02-19 13:59:33 <shaileshg> wallet42: sipa has left
569 2014-02-19 14:00:08 <bitpar> 0.3.18
570 2014-02-19 14:02:24 <wallet42> btw.. is there a ticket to "group" rpc methods? it becomes quite a lot and it may confuse new devs. eg. wallet functions, accounting methods, rawtx stuff, mining related stuff
571 2014-02-19 14:03:02 <wallet42> group for the "help" rpc i mean
572 2014-02-19 14:04:05 <kjj> a while back I wrote a patch to normalize all of the names, but it wasn't picked up
573 2014-02-19 14:05:07 <kjj> oh, for the help message?  Oddly enough, I think that is harder
574 2014-02-19 14:05:45 <kjj> if I recall correctly, the list of RPC commands is made by pulling a line out of each function dispatcher, and then sorting them into alphabetical order
575 2014-02-19 14:07:46 <wumpus> grouping rpcs would make sense
576 2014-02-19 14:08:24 <wumpus> I guess it would be as easy as adding a 'category' field to the CRPCCommand structure
577 2014-02-19 14:08:40 <wumpus> then when help is called, group them by that
578 2014-02-19 14:10:01 <kjj> that table blows already.  at some point (which may not be now) it becomes "cleaner" to return the category by reference
579 2014-02-19 14:12:30 <wumpus> well you could also make a CRPCCommand structure per category
580 2014-02-19 14:12:38 <wumpus> I mean, a table per category
581 2014-02-19 14:13:23 <wumpus> then add all the tables at the beginning; I did that once when I was trying to modularize bitcoind
582 2014-02-19 14:13:41 <wumpus> (ie, the wallet would register its own table of RPC commands)
583 2014-02-19 14:31:20 <jgarzik> wumpus, hmmm, interesting thought
584 2014-02-19 14:31:29 <jgarzik> wumpus, more complex, but more modular
585 2014-02-19 14:32:00 <jgarzik> wumpus, (I'm originally responsible for CRPCCommand table, and am a big fan of table-driven code)
586 2014-02-19 14:35:34 <wumpus> jgarzik: it would be only marginally more complex; there would be a CRPCTable::Register(const CRPCCommand vRPCCommands*, string categoryName) method to register a new category and its functions (and possibly a symmetric function to unregister, though, as long as there is no online loading/unloading of modules that's not really needed)
587 2014-02-19 14:37:48 <jgarzik> wumpus, agreed, but "more complex" also includes supporting and debugging.  I've dealt with plug-in RPC systems before, and you'd be surprised where odd behavior crops up.  Saw one bug in an early cloud RPC service where -some- of its RPCs would disappear at runtime, at unexpected moments
588 2014-02-19 14:37:52 <jgarzik> other RPCs worked just fine
589 2014-02-19 14:38:38 <jgarzik> it was a bug in an RPC plugin registration routine, that was not multi-thread safe, in a system where plugins come and go at runtime
590 2014-02-19 14:38:55 <wumpus> that's mostly a problem if you support loading/unloading modules at runtime, not something I'd recommend for bitcoind
591 2014-02-19 14:39:10 <jgarzik> wumpus, plug-in services are coming...
592 2014-02-19 14:39:40 <wumpus> yes, but like with apache those could be specified at startup time
593 2014-02-19 14:39:55 <jgarzik> wumpus, For example, consider bitcoind integration with P2SH safe addresses, where you auth with a service using 2FA, to get it to sign one key of a multisig: https://www.belshe.com/2013/12/15/p2sh-safe-addresses/
594 2014-02-19 14:41:03 <jgarzik> bitcoind would be interacting with a specific service that the user has a customer relationship with, over a long period of time.  Though granted this is perhaps a bad example, strictly speaking, of a "plugin"   but there is some persistence of this relationship in the bitcoin client over time.
595 2014-02-19 14:41:45 <jgarzik> i.e. sending bitcoins would involve building and signing a local multisig + contacting this service
596 2014-02-19 14:41:47 <wumpus> agreed, it'd be great to support plugins, but I see no point in loading and unloading modules at runtime for bitcoind... we require restarting right now to change the configuration anyway
597 2014-02-19 14:42:18 <jgarzik> Never say never, as an engineer :)
598 2014-02-19 14:42:41 <Inception> Any way to track where donations to 1BTCorgHwCg6u2YSAWKgS17qUad6kHmtQW go? For what kind of work, i mean. I want to donate to specific developements, on a monthly basis
599 2014-02-19 14:42:41 <jgarzik> Hive or another one of those new wallets already supports explicit third party plugins
600 2014-02-19 14:42:46 <wumpus> well then indeed you got your "more complex"
601 2014-02-19 14:42:53 <wumpus> to me, it's not worth the headache
602 2014-02-19 14:44:04 <wumpus> unless "plugin" is something that runs in a different process and communicates over a pipe, then it's easier
603 2014-02-19 14:47:24 <jgarzik> wumpus, honestly that is probably ideal, from a sandboxing perspective
604 2014-02-19 14:47:31 <jgarzik> wumpus, and we already support that execution model
605 2014-02-19 14:47:55 <jgarzik> I wouldn't want third party code mucking about in my wallet's address space
606 2014-02-19 14:48:18 <wumpus> which is indeed a good idea, but that has drifted quite far from 'categorize RPCs' :)
607 2014-02-19 14:49:40 <wumpus> how do we support that execution model?
608 2014-02-19 14:50:59 <jgarzik> wumpus, we already support executing external processes, and boost can do the piping with just a little more work.  Yes, drifting quite a bit from original topic ;p
609 2014-02-19 14:51:04 <jgarzik> -blocknotify etc.
610 2014-02-19 14:52:28 <wumpus> jgarzik: right; there is some support, but splitting off for example the wallet to a seperate process would be still quite involved (one'd have to define some interprocess protocol, at least)
611 2014-02-19 14:57:39 <kjj> pipes suck, by the way, at least if you need to support more than linux
612 2014-02-19 14:58:41 <CodeShark> [peer] <--(p2p protocol)--> [spv layer] <--(signals/slots for in-process, websockets for IPC)--> [applications]
613 2014-02-19 14:58:46 <jgarzik> wumpus, agreed, though the proposal of simply going ahead and making it a separate program, that runs bitcoind under the hood and communicates via RPC with bitcoind, is moderately attractive after I did preliminary coding on the cross-platform fork+pipe solution
614 2014-02-19 14:59:02 <jgarzik> wallet can talk RPC & P2P to local bitcoind
615 2014-02-19 14:59:14 <jgarzik> there's your interprocess communication protocol :)
616 2014-02-19 14:59:19 <wumpus> kjj: well it can go over tcp/ip as well of course
617 2014-02-19 14:59:27 <wumpus> kjj: pipes is just the 'safe default'