1 2015-04-21 00:47:53 <TheButterZone> never seen this feature request before: https://bitcointalk.org/index.php?topic=1033212.msg11148725#msg11148725
  2 2015-04-21 01:52:31 <Luke-Jr> TheButterZone: #bitcoin
  3 2015-04-21 03:19:19 <theymos> Just in case anyone is interested, it's probably possible to create a @bitcoin.org email address for any of the prominent Bitcoin developers. You can email domain@bitcoin.org if you're interested. (I haven't actually discussed this with him, but I feel like it shouldn't be a problem.)
  4 2015-04-21 08:41:35 <bedeho> BIP16 explains that P2SH outputs are claimed by scriptSigs of the form "...signatures... {serialized script}", where "script" is the script hashed in the outpoint scriptpubkey, but what is the serialization done on the script?
  5 2015-04-21 08:46:48 <sipa> bedeho: turned into a byte vector and a push operation to push it onto the stack
  6 2015-04-21 08:47:59 <bedeho> sipa: thanks
  7 2015-04-21 10:31:41 <bedeho> sipa: should a P2SH scriptSig (...signatures... {serialized script}) start with a OP_0, as standard multisig scriptSigs ?
  8 2015-04-21 10:32:04 <sipa> the OP_0 is only due to a bug in checkmultisig
  9 2015-04-21 10:32:16 <sipa> it's needed if you use checkmultisig, and not of you don't
 10 2015-04-21 10:32:22 <sipa> independent of p2sh
 11 2015-04-21 10:33:25 <bedeho> hence it is not part of a p2sh scriptSig? right?
 12 2015-04-21 10:36:01 <sipa> it is part of the scriptsig, but not part of the redeemscript (=the subscript whose hash is the p2sh address)
 13 2015-04-21 10:39:29 <hearn> good day
 14 2015-04-21 10:39:37 <bedeho> sipa: ok, that seems like the opposite of what I was expecting. Is it this [OP_0 ...signatures... redeem.serialize() ], or this [...signatures... {serialized script which starts with OP_0)}]
 15 2015-04-21 10:39:42 <bedeho> hearn: good day
 16 2015-04-21 10:40:25 <bedeho> I presumed it was the latter
 17 2015-04-21 10:41:15 <sipa> bedeho: if you would not use p2sh, you would have pubkeyscript=X and scriptsig=y
 18 2015-04-21 10:42:04 <sipa> bedeho: with p2sh, it becomes pubkeyscript=p2sh template with hash160(x), and scriptsig=y + push(x)
 19 2015-04-21 10:42:14 <sipa> for any script
 20 2015-04-21 10:42:32 <sipa> checkmultisig has nothing to do with it
 21 2015-04-21 10:44:33 <sipa> if x contains a checkmultisig in your case, y would contain a corresponding op_0
 22 2015-04-21 10:45:26 <sipa> x is cdlled thebfedeemscript
 23 2015-04-21 10:45:34 <sipa> x is called the redeemscript
 24 2015-04-21 10:47:01 <bedeho> sipa: right, this is actually what I initially thought, OP_0 only appears when p2sh is used with multisig. I'm just trying to read through bitcore.js, and it seems to not work that way. Anyway, thank you, that clears that up.
 25 2015-04-21 11:23:40 <hearn> sipa: i'm getting SERVFAIL from querying your dns seed - known issue?
 26 2015-04-21 11:24:27 <sipa> hearn: nope, should be up again
 27 2015-04-21 11:24:33 <sipa> i really should set up monitoring for this...
 28 2015-04-21 11:24:38 <hearn> thanks
 29 2015-04-21 11:24:48 <hearn> yeah, tell me about it. setting up monitoring for my seed is still on the todo list ....
 30 2015-04-21 11:33:05 <sipa> updated graph on bip66 adoption: http://bitcoin.sipa.be/ver-10k.png
 31 2015-04-21 11:34:15 <sipa> almost 40%, probably more
 32 2015-04-21 11:35:45 <bedeho> sipa: apropos, when an N byte signature appears in a scriptSig, is this how it looks: OP_PUSHDATA1 N sig ?
 33 2015-04-21 11:36:38 <bedeho> where sig has the DER encoding in question and is no more than 73 bytes?
 34 2015-04-21 11:41:43 <belcher> petertodd: what do you mean by the openssl call style ?
 35 2015-04-21 11:58:37 <sipa> bedeho: not going to teach you script language basics here
 36 2015-04-21 12:17:29 <hearn> sipa: lol, average block version as a float. very nice.
 37 2015-04-21 12:17:46 <hearn> bedeho: script is explained in the bitcoin.org developer guide
 38 2015-04-21 12:20:03 <bedeho> hearn: ty
 39 2015-04-21 12:22:22 <sipa> hearn: it's capped to 3 before averaging
 40 2015-04-21 12:22:44 <sipa> so it can't be gamed by a rogue miner setting the nVersion field to 1000 or so
 41 2015-04-21 12:23:52 <hearn> cool
 42 2015-04-21 12:24:44 <sipa> hearn: http://bitcoin.sipa.be/ver-ever.png
 43 2015-04-21 12:24:53 <sipa> shows bip16 adoption too
 44 2015-04-21 12:34:05 <hearn> sipa: very nice
 45 2015-04-21 12:34:20 <hearn> sipa: i'm looking forward to seeing the anti-malleability BIP version on that graph
 46 2015-04-21 18:07:32 <jonasschnelli> hm... $master doc/REST-interface.md is not up to date. We should add documentation for /rest/getheaders or consider merging https://github.com/bitcoin/bitcoin/pull/5486.
 47 2015-04-21 18:08:42 <sipa> go ahead
 48 2015-04-21 18:24:58 <gmaxwell> wumpus: I noticed that the binaries for earlier 0.10.1rcs are gone from bitcoin.org; we really should be preserving all binaries we ship (can move to an old directory)
 49 2015-04-21 18:33:41 <kanzure> jonasschnelli: i am going to need some assistance with rebasing on top of that move between files.
 50 2015-04-21 18:34:06 <jonasschnelli> kanzure: fundrawtransaction?
 51 2015-04-21 18:34:36 <kanzure> yes
 52 2015-04-21 18:35:05 <jonasschnelli> okay... yes. Could be non-trivial. :)
 53 2015-04-21 18:35:10 <kanzure> well i'm sure i could figure it out i guess, but i don't exactly do rebased + functions moving around every day.
 54 2015-04-21 18:35:39 <jonasschnelli> Should i pull in your watch-only-support commit in #5503?
 55 2015-04-21 18:35:44 <kanzure> go for it
 56 2015-04-21 18:35:54 <kanzure> there are tests. and stuff.
 57 2015-04-21 18:36:04 <jonasschnelli> then i can play around with rebasing. :)
 58 2015-04-21 18:36:23 <kanzure> it would be nice if you could preserve my commit and GIT_AUTHOR_EMAIL and GIT_COMMITTER_EMAIL but whatevs
 59 2015-04-21 18:37:03 <sipa> git rebase maintains those
 60 2015-04-21 18:38:05 <jonasschnelli> kanzure: for sure... no one likes to steal code
 61 2015-04-21 18:39:03 <kanzure> oh that's not what i meant; i had assumed GIT_AUTHOR_NAME and GIT_COMMITTER_NAME would be kept. i was expressing some hint about a nuancy (different committer/author emails).
 62 2015-04-21 18:39:39 <jonasschnelli> kanzure: i'll pull in your commit: https://github.com/kanzure/bitcoin/commit/a3af4c1c116f09f64d3507c4143b9ec182ed10ee and do some small fixes (mainly merging but i also saw some not required line changes [https://github.com/kanzure/bitcoin/commit/a3af4c1c116f09f64d3507c4143b9ec182ed10ee#diff-d7618bdc04db23aa74d6a5a4198c58fdL1604])
 63 2015-04-21 18:40:08 <kanzure> yep sure
 64 2015-04-21 18:45:37 <wumpus> gmaxwell: any specific use for them? I still have them somewhere
 65 2015-04-21 18:46:42 <gmaxwell> wumpus: it's just a records keeping thing; procedurally anything we release should be retained so if there is any question about its integrity we can answer it; or if we need it for troubleshooting something that got left running etc.  Hopefully we can just reproduce them but that might be harder later; and storing them is pretty cheap.
 66 2015-04-21 18:47:14 <kanzure> and regular backups
 67 2015-04-21 18:48:41 <wumpus> I'm not sure it makes sense to keep it all on bitcoin.org though
 68 2015-04-21 18:49:03 <wumpus> in general, people should only be downloading the full versions, certainly not old rcs
 69 2015-04-21 18:49:28 <wumpus> but keeping it around somewhere, sure
 70 2015-04-21 18:50:34 <gmaxwell> It should be findable by third parties, but sure; I don't care where it is.
 71 2015-04-21 18:51:02 <kanzure> i think there is often a need to get old versions
 72 2015-04-21 18:51:08 <kanzure> especially for research purposes and simulation of network conditions
 73 2015-04-21 18:51:28 <wumpus> old versions, but IMO not rcs
 74 2015-04-21 18:52:05 <kanzure> what possible harm do release candidates have?
 75 2015-04-21 18:52:25 <kanzure> the fact that we're talking about removing builds at all is a little worrisome to me
 76 2015-04-21 18:52:30 <gmaxwell> just more workload, but thats why I was just suggesting an old/ directory; then the workload is mv instead of rm. :)
 77 2015-04-21 18:53:10 <wumpus> kanzure: well make sure that you store them yoourself, then, don't rely on a third party to store them forever
 78 2015-04-21 18:53:21 <wumpus> or better, build them yourself using gitian.
 79 2015-04-21 18:53:40 <kanzure> that is not an argument for why you shuld delete them
 80 2015-04-21 18:53:45 <kanzure> you just gave me an argument for why i should store them
 81 2015-04-21 18:53:51 <kanzure> this is the position that you are supposed to be arguing against >:(
 82 2015-04-21 18:53:52 <kanzure> argh
 83 2015-04-21 18:54:04 <wumpus> I'm not supposed to argue against anything
 84 2015-04-21 18:54:19 <kanzure> you're supposed to argue your position
 85 2015-04-21 18:54:26 <wumpus> why?
 86 2015-04-21 18:54:35 <kanzure> because you must have a reason for deleting them
 87 2015-04-21 18:54:40 <wumpus> server space, for one
 88 2015-04-21 18:55:05 <wumpus> doesn't make sense to store zillions of copies of the executables for all platforms
 89 2015-04-21 18:55:43 <gmaxwell> wumpus: sure, there needs to be a cutoff. I would expect the cutoff to be any file we offer for download to the public.
 90 2015-04-21 18:55:43 <kanzure> well, i certainly agree that a build per commit for all platforms is overkill
 91 2015-04-21 18:56:05 <gmaxwell> But I agree that a different position is also not totally crazy.
 92 2015-04-21 18:56:36 <gmaxwell> I was surprised that we weren't maintaining the old RCs on bitcoin.org at least.  I can keep them personally from now on.
 93 2015-04-21 18:56:51 <jonasschnelli> http://builds.jonasschnelli.ch/releasebuilds/
 94 2015-04-21 18:57:11 <kanzure> also, randomly removing builds is a little unusual for an open-source project of this type
 95 2015-04-21 18:57:14 <jonasschnelli> as long as you gverify against gitian.sig github it should be fine
 96 2015-04-21 18:57:23 <kanzure> perhaps if there was an exact policy that is made very strongly known near the download section or path
 97 2015-04-21 18:57:27 <wumpus> 'randomly'?
 98 2015-04-21 18:57:29 <kanzure> where the regular removals are publicized ahead of time
 99 2015-04-21 18:57:37 <kanzure> well whatever, i'm handwaving
100 2015-04-21 18:57:40 <wumpus> I delete the old rcs when I upload a new one, that's not random.
101 2015-04-21 18:58:02 <wumpus> there is only one rc in the test directory, that has also always been the case
102 2015-04-21 18:58:29 <jonasschnelli> i also agree it makes no sense to keep old rcs. There are some gitian assert infos with sigs which should be sufficient if you need to rebuild a non GM rc
103 2015-04-21 18:59:56 <gmaxwell> jonasschnelli: I think its likely you will not be able to reproduce a year old gitian build (due to dependency bitrots)
104 2015-04-21 19:00:52 <jonasschnelli> gmaxwell: but would you run a one year old binary from a untrusted source? I would only run it if i had built it myself. :)
105 2015-04-21 19:01:49 <gmaxwell> I am surprised about the view with respect to RCs. These are not full releases, but we announce and offer them to the general public, they're not project-internal. We use the determinstic build process for them for security and accountability reasons; retaining the records is just an element of that.  (If we were really confident that gitan would span years, I'd agree this would be less worth thinkin
106 2015-04-21 19:01:55 <gmaxwell> g about)
107 2015-04-21 19:02:11 <wumpus> well I retain them, I'm sure more people do
108 2015-04-21 19:02:22 <gmaxwell> jonasschnelli: someone may _already_ be running it, and we may need to dive into it to diagnose it or understand claims they're making about it.
109 2015-04-21 19:02:39 <gmaxwell> wumpus: Good. :)
110 2015-04-21 19:03:03 <gmaxwell> (I will now too)
111 2015-04-21 19:03:25 <zooko> Is there a record of their secure hashes?
112 2015-04-21 19:03:32 <zooko> brb
113 2015-04-21 19:03:33 <zooko> bbiab
114 2015-04-21 19:03:35 <gmaxwell> yes, the gitian signatures.
115 2015-04-21 19:03:35 <wumpus> that's the only way to be sure anyway
116 2015-04-21 19:04:14 <wumpus> gitian signatures, as well as the signed SHA256SUM.asc
117 2015-04-21 19:04:43 <jonasschnelli> gmaxwell: sure. I agree. I think it would be best if everyone whos doing analyzing of old rcs/releases keep his own gitian binary copies.
118 2015-04-21 19:05:09 <jonasschnelli> =avoiding centralization
119 2015-04-21 19:05:27 <wumpus> in any case, wiping the rcs means that actual versions can go back further, given the same space
120 2015-04-21 19:05:43 <sipa> is space that tight?
121 2015-04-21 19:06:01 <wumpus> I don't know exactly, but it came up at some point
122 2015-04-21 19:06:46 <gmaxwell> sipa: well a release is about 160MB.
123 2015-04-21 19:06:56 <gmaxwell> (due to the many different files)
124 2015-04-21 19:07:01 <wumpus> indeed
125 2015-04-21 19:07:42 <berndj> people don't always know that in 5 years they'll want the last 10 years' build artifacts
126 2015-04-21 19:08:09 <jonasschnelli> kanzure: i stopped merging because of this: https://github.com/kanzure/bitcoin/commit/a3af4c1c116f09f64d3507c4143b9ec182ed10ee#diff-d7618bdc04db23aa74d6a5a4198c58fdR1619
127 2015-04-21 19:08:25 <jonasschnelli> is it worth going twice over CreateTransaction()?
128 2015-04-21 19:08:59 <wumpus> obviously. But well then they can ask nicely here, or on the mailing list if someone has them. For that rare usecase it's not worth keeping them on the server all the time
129 2015-04-21 19:09:34 <kanzure> jonasschnelli: i'm not sure; that's up to you i think.
130 2015-04-21 19:09:39 <kanzure> jonasschnelli: or requires broader discussion
131 2015-04-21 19:09:46 <kanzure> there's no particular reason from my end
132 2015-04-21 19:10:36 <sipa> this is a raw transaction api
133 2015-04-21 19:10:40 <gmaxwell> kanzure: is that about coin selection or something? our existing stuff uses retrial extensively (e.g. for minconf); I think it fine in principle.  Can you give me some context?
134 2015-04-21 19:10:46 <kanzure> berndj: i'm surprised that not everyone here is an obsessive archivist :-)
135 2015-04-21 19:10:46 <sipa> i don't think it should try to be smart
136 2015-04-21 19:11:04 <sipa> if the users didn't want watchonly included, he can say so
137 2015-04-21 19:11:21 <gmaxwell> ah does this try without watchonly first and then include it?
138 2015-04-21 19:11:22 <kanzure> gmaxwell: it's my fundrawtransaction-watchonly branch. i had a line to try coin selection first without watchonlys, then a second time with them.
139 2015-04-21 19:11:48 <kanzure> gmaxwell: i imagien that other control would be nice though, like "plz only use watchonlys" except i don't have a good interface idea for that, and it is not presently a strong use case for me
140 2015-04-21 19:11:53 <gmaxwell> hm. tricky. Its nice if there is a way to do "watchonly only if you must" e.g. "don't make me go to my cold wallet if I don't have to".
141 2015-04-21 19:12:49 <sipa> gmaxwell: seems to me that is a policy decision that the rpc user should make if they want; not sokething the rpc should assume for them
142 2015-04-21 19:12:56 <jonasschnelli> Kanzure: why do you set the nFeeRet=0 when including watchonly?
143 2015-04-21 19:13:01 <sipa> though it also doesn't really hurt
144 2015-04-21 19:13:31 <kanzure> jonasschnelli: fee calculation was broken, just decided to force it to zero. uh... actually i don't remember the real reason. sorry.
145 2015-04-21 19:13:41 <kanzure> wait i mean fee estimation
146 2015-04-21 19:13:47 <gmaxwell> sipa: yes I agree its something of a policy issue; though a mild one, unless it causes really bad coin selection you'd almost never want to not do it. I would personally use that feature.
147 2015-04-21 19:14:43 <gmaxwell> it could just be a make the includewatch into a bitmask, and let the user set it.
148 2015-04-21 19:15:39 <kanzure> fee estimation during coin selection is a little strange
149 2015-04-21 19:15:49 <jonasschnelli> ha. :)
150 2015-04-21 19:15:54 <sipa> gmaxwell: with the code as-is, you risk it making a really bad coin selection from just the hot wallet, even of you were prepared to use the cold wallet
151 2015-04-21 19:15:58 <jonasschnelli> Yes. Its kinda looping.
152 2015-04-21 19:16:25 <kanzure> also the spontaneously-added-output is unfortunate
153 2015-04-21 19:16:34 <jonasschnelli> What about adding a rpc boolean arg for onlyUseWatchonly?
154 2015-04-21 19:16:35 <kanzure> in the future i would like that added output to be specifically mentioned in rpc responses
155 2015-04-21 19:16:43 <kanzure> by giving you the index of the chagne output or something
156 2015-04-21 19:16:59 <jonasschnelli> mixing watchonly and non-watchonly coins is uncommon IMO?
157 2015-04-21 19:17:05 <sipa> kanzure: to allow itngo update that output, rather than add one?
158 2015-04-21 19:17:09 <sipa> jonasschnelli: i believe so
159 2015-04-21 19:17:19 <kanzure> jonasschnelli: i think that is starting to get redundant since there's also includeWatchonly or whatever. but uh, only watchonly sounds okay to me.
160 2015-04-21 19:18:03 <gmaxwell> jonasschnelli: I don't agree. I have an online wallet; I have keys watchonly which are kept offline.  Normally I want to spend from the online wallet; but if I have to span offline, thats okay too.
161 2015-04-21 19:18:06 <sipa> onlywatchonly doesn't sound very useful
162 2015-04-21 19:18:18 <sipa> anyway, afk
163 2015-04-21 19:18:23 <kanzure> onlywatchonly was actually my original use case
164 2015-04-21 19:18:26 <jonasschnelli> kanzure: i mean there can be usecases where you mix cold/hot coins. But i would guess its uncommon. OnlyWatchOnly or NonWatchOnly makes more sense to me.
165 2015-04-21 19:18:45 <kanzure> i simply only have watchonlys and no stored private keys, so by default it was onlywatchonly for me as-is
166 2015-04-21 19:19:00 <gmaxwell> jonasschnelli: if you can't use both you can't actually spend all your coins in one go!
167 2015-04-21 19:19:03 <helo> so you'd have to transport it to your offline machine to sign some of the inputs?
168 2015-04-21 19:19:14 <gmaxwell> helo: yes.
169 2015-04-21 19:19:19 <kanzure> sort of.... my process is far more elaborate than that, but yes :-)
170 2015-04-21 19:19:22 <helo> (and i presume top-up your online wallet in the process)
171 2015-04-21 19:19:22 <jonasschnelli> hmm.... right. Agreed.
172 2015-04-21 19:19:28 <kanzure> (it involves armed guards and other theatrics)
173 2015-04-21 19:21:09 <jonasschnelli> what about having "includeWatchonly" (bool) and "avoidMix" (T.B.RN / bool) as RPC flags?
174 2015-04-21 19:21:32 <kanzure> hmm
175 2015-04-21 19:21:42 <gmaxwell> I do not see the value in avoidmix.
176 2015-04-21 19:21:55 <kanzure> well, having rpc responses like "yo dawg you don't got enough" as an error message seems acceptable, and hten you refiddle the flags appropriately
177 2015-04-21 19:22:17 <kanzure> and then each additional flag would try harder
178 2015-04-21 19:22:28 <jonasschnelli> gmaxwell: let's say you like to do a tx with only coins from your cold wallet
179 2015-04-21 19:22:43 <gmaxwell> helo: yea, I'll attempt to make a transaction online-only and if I fail, I create a new transaction that pays funds to the destination, and funds to the online wallet; and I'd spend whatever coins I like...  right now all my coinselection is external code; but I'd like to be able to use the stuff kanzure and jonasschnelli have been working on there.
180 2015-04-21 19:23:33 <gmaxwell> jonasschnelli: well for that I'd specfically identify the coins. So there are reasons to do that but its kind of venturing into coincontrol at that point.
181 2015-04-21 19:23:52 <kanzure> if possible it would be nice to do the "display the index of the change output in the rpc response" feature here as well
182 2015-04-21 19:24:04 <gmaxwell> e.g. what happens when you have two cold wallets? (one offline, and one in a bank vault) now you want to constrain by group. :)
183 2015-04-21 19:24:30 <kanzure> right.. coin control should be a separate feature some other time. i imagine it would be based on labels or something.
184 2015-04-21 19:24:51 <jonasschnelli> gmaxwell: agreed. Somewhen you need to fiddle with custom inputs.
185 2015-04-21 19:25:09 <jonasschnelli> acoidMix boolean would be easy to implement... but agreed. Can be done later or never.
186 2015-04-21 19:25:09 <wumpus> or make it possible to give it the list of outputs to select from?
187 2015-04-21 19:25:20 <jonasschnelli> ncurse? :)
188 2015-04-21 19:25:44 <wumpus> in that case you can do all the grouping you want yourself
189 2015-04-21 19:25:50 <gmaxwell> yea, would be cool to have label and/or output group based coin control; but much less useful than the basic functionality.
190 2015-04-21 19:26:10 <kanzure> inserting a list of outputs seems problematic; what if you have .. lots?
191 2015-04-21 19:26:39 <wumpus> well, then you have to provide a long list
192 2015-04-21 19:26:53 <gmaxwell> I'd be unlikely to use id based myself; at that point I'd just pick the inputs specifically. ... my own code can link glpk. :)
193 2015-04-21 19:27:05 <wumpus> listunspent will give you all of them
194 2015-04-21 19:28:35 <gmaxwell> I mean at some point what you really want is the ability to create persistant 'strategy' objects and invoke a strategy for coin selection.
195 2015-04-21 19:28:56 <wumpus> implementing all kinds of custom grouping strategies on the wallet side sounds like a losing bargain, there's just too much divergence in what people could want, and you don't want a long list of positional flags either
196 2015-04-21 19:28:57 <gmaxwell> since there are fundimental conflicts between goals in coin selection.
197 2015-04-21 19:29:59 <wumpus> it is a good indication that it belongs at the client side
198 2015-04-21 19:30:35 <gmaxwell> wumpus: there is also deep interactions with the system and domain specific knoweldge, which is the opposite suggestion! :)
199 2015-04-21 19:31:16 <gmaxwell> e.g. to achieve privacy you want taint group tracking.  But how much (if any) extra fees to pay to preserve privacy is a policy decision.
200 2015-04-21 19:33:52 <gmaxwell> Speaking of that; anyone have an principled objection to having listunspent emit an estimated signature size too? Its data thats required for external coin-selection.
201 2015-04-21 19:34:08 <wumpus> well it would be hard to test all the combinations, for one, the code is already pretty complicated
202 2015-04-21 19:36:25 <gmaxwell> at least we'll try- and this isn't consensus stuff; or even things with large funds lost risk... (eventually all the wallet behavior should be backstopped with sanity checks; making it easier to safely screw with stuff before the sanity checks); plus 99% of external code will be untested.
203 2015-04-21 19:37:11 <wumpus> ok...
204 2015-04-21 19:38:49 <wumpus> no objection to adding signature size to listunspent, if that's useful information
205 2015-04-21 19:40:25 <wumpus> (isn't something you can easily compute from the current information, at least in the case of multisig outputs)
206 2015-04-21 19:41:12 <gmaxwell> wumpus: for compressed vs uncompressed the only thing one can do is to make a validateaddress call on each address in the listunspent output right now.
207 2015-04-21 19:41:52 <kanzure> uh so it sounds like the interface was not decided upon
208 2015-04-21 19:42:02 <kanzure> i see multiple conflicting proposals
209 2015-04-21 19:42:07 <gmaxwell> for what?
210 2015-04-21 19:42:12 <wumpus> gmaxwell: right
211 2015-04-21 19:42:17 <kanzure> fundrawtransaction with watchonly support
212 2015-04-21 19:43:05 <gmaxwell> kanzure: I think the only debate is around your feature; it raised a possible requirement people weren't thinking about. It's complicated by the fact that potitional arguments suck.
213 2015-04-21 19:43:37 <kanzure> obv. the minimum requirements for the interface are: (1) principle of least surprise, (2) default to current behavior without watchonlys, (3) expose the ability to select watchonlys, (4) possibly mandatory onlywatchonly flag, (5) some way to toggle the behavior and which retries/attempts are made if funds are unavailable?
214 2015-04-21 19:43:54 <kanzure> gmaxwell: right, no disagreements from me there
215 2015-04-21 19:44:22 <kanzure> er let me clarify, my concern is that it's wasteful to talk about a possible interface and then not come to any reasonable conclusion, especially when we may be wasting jonasschnelli's time :-)
216 2015-04-21 19:45:22 <wumpus> 1, 2 and 3 sound good to me, I think the rest goes too far
217 2015-04-21 19:45:33 <gmaxwell> since there are concerns we should probably back off to the base feature: includewatchonly without being smart.
218 2015-04-21 19:46:05 <kanzure> so includewatchonly should select both controlled coins and watchonlys?
219 2015-04-21 19:46:06 <wumpus> yes, don't be smart. few things as annoying as software that tries to be smart.
220 2015-04-21 19:46:18 <jonasschnelli> i also think it's okay as it is. There are just some code optimizations, fee issue fixing, etc.
221 2015-04-21 19:46:20 <wumpus> Keefe: yes
222 2015-04-21 19:46:27 <gmaxwell> we could later suppliment this with things like making the default "include prefer hot coins, but not if it results in higher fees" or other unsurprising improvements.
223 2015-04-21 19:46:28 <wumpus> eh, kanzure.
224 2015-04-21 19:46:55 <kanzure> gmaxwell: hehe "onlywatchonly" might enforce cold wallet behavior among users. but probably not. they'd probably just hate me instead.
225 2015-04-21 19:47:38 <gmaxwell> smart is okay really only if "doesn't violate least surprise", the most reliable way to achieve that is to only be smart when requested. (though some kinds of smart are safe)
226 2015-04-21 19:47:58 <kanzure> what is the use case for using fundrawtransaction with non-watchonlys anyway? reviewing the coins it has picked? reviewing a funded transaction before you ask bitcoind to sign?
227 2015-04-21 19:48:05 <wumpus> well in the case of a separate cold and hot wallet multiwallet support would be the more sensible route
228 2015-04-21 19:48:21 <gmaxwell> e.g. I believe computing it both ways and taking the online-only constraint if and only if the transaction is equal or better in fees/size is safe. But not worth worrying about now, it's an improvement.
229 2015-04-21 19:48:24 <wumpus> than trying weird grouping flags within a wallet, it breaks the abstraction
230 2015-04-21 19:48:49 <kanzure> i agree wumpus, flag minimization should be preferred here since flags are really alien anyway
231 2015-04-21 19:49:02 <kanzure> could be separate future rpc calls if those flag features are actually required
232 2015-04-21 19:49:24 <gmaxwell> wumpus: You really do not want seperate wallets, if thats what you mean by multiwallet, because it puts you in a really irritating state where you have to move funds to move funds. (speaking from expirence) and will cause uses to go around manually handing keys to deal with it (speaking from direct observation)
233 2015-04-21 19:49:32 <wumpus> kanzure: it would be somewhat more tolerable if these were named arguments. but 'onlywatchonly', even the name... :-)
234 2015-04-21 19:49:39 <gmaxwell> but reduced levels of seperation can be good.
235 2015-04-21 19:50:17 <kanzure> welp okay, that's a tolerable and good interface
236 2015-04-21 19:50:18 <wumpus> gmaxwell: moving funds to move funds sounds pretty logical to me?
237 2015-04-21 19:51:27 <gmaxwell> wumpus: and foo-processor has given you 15 minutes to 'pay'; and won't taken an unconfirmed chain. (also personal expirence)
238 2015-04-21 19:51:27 <wumpus> gmaxwell: at least if you're manually managing the cold and hot wallet
239 2015-04-21 19:52:53 <gmaxwell> much easier to have it just say 'you need offline funds for this, go get them signed ... or abort the transaction'.
240 2015-04-21 19:53:06 <wumpus> gmaxwell: I don't disagree that there are cases in which doing that makes sense, but that's the kind of cases you'd handle manually
241 2015-04-21 19:54:32 <kanzure> jonasschnelli: thoughts on the "the change output is the nth output" data in the rpc response? i didn't look at how much work adding that would be. maybe have to bubble up through many functions :-/.
242 2015-04-21 19:54:34 <wumpus> I don't think trying to come up with a system in which every possible edge-case can be handled automatically is very realistic, but maybe it is, at least start from scratch with an un-muddled abstraction and not a bag of flags :)
243 2015-04-21 19:54:48 <gmaxwell> A distinction to make there is hot vs cold vs vault. I agree 'vault' is something rare and manual.  But hot vs cold is not necessarily; computer security stinks, and I don't want to carry around enough funds to make a mugging attractive.  lol but indeed a bag of flags doesn't get us there.
244 2015-04-21 19:54:51 <kanzure> i think the edge cases should inform design decisions
245 2015-04-21 19:55:15 <kanzure> bag of flags... nice.
246 2015-04-21 19:56:29 <wumpus> let's implement the normal, straightforward case that everyone can agree on first, then later on possibly add more advanced functionality, given that it can be clearly specified
247 2015-04-21 19:57:07 <gmaxwell> I think that was already decided. :)
248 2015-04-21 19:57:12 <gmaxwell> I think, from a design perspective we ought to be able to handle multiple wallets, obviously;  but also wallets that comingle funds with different spending criteria, and then smartly manage them; particularly so you can have a automatically managed cold (warm?) wallet.  ALTERNATIVELY, multiple single type wallets, but with an ability to spend across them; only when you choose to do so might be a near
249 2015-04-21 19:57:18 <gmaxwell>  enough approximation to reduce pain.
250 2015-04-21 19:57:34 <wumpus> hehe
251 2015-04-21 19:59:01 <kanzure> spendpolicy seems like the sort of thing that i'd kick down the road until the wallet was separated
252 2015-04-21 20:01:05 <kanzure> actually, spendpolicy is the sort of thing that might work best with webhooks to application infrastructure, so that you don't have to embed some policy programming environment too
253 2015-04-21 20:01:18 <kanzure> s/webhooks/hooks
254 2015-04-21 20:01:20 <wumpus> well as long as the different wallets are in one process, it would be possible for them to combine inputs for a spent
255 2015-04-21 20:01:36 <gmaxwell> sure, I was just suggesting what something that wasn't a bag of flags OR punting in order to make it the user's fault  might look like. :)
256 2015-04-21 20:02:09 <gmaxwell> certantly wasn't suggesting anyone go do that now.
257 2015-04-21 20:03:38 <jonasschnelli> the proposed signaling way of supporting multiple wallet would allow multiple listeners for RPC calls like fundrawtransaction. Output/inputs is a pass-by-ref std::string)
258 2015-04-21 20:03:51 <wumpus> e.g. feeding multiple wallets into the coin selector would be conceptually straightforward, coming up with a sane RPC interface (that doesn't complicate the normal case of spending from one wallet) is likely the difficult part
259 2015-04-21 20:03:58 <kanzure> "I'd like to add this to #5503 but the nFeeRet=0 as well as the issue mentioned by @TheBlueMatt (calling CreateTransaction() two times) are unclear and needs fixing. RPC tests should also send a funded raw transaction and check the response to make sure it passes the mempool checks (i have a feeling that it won't because of the generated fee)"
260 2015-04-21 20:04:03 <kanzure> hmm
261 2015-04-21 20:04:37 <kanzure> nFeeRet=0 was probably because transaction fee estimation was broken; perhaps it should just be removed.
262 2015-04-21 20:04:58 <jonasschnelli> kanzure: I try to avoid taking a unfinished commit and fix it up (any maybe break it completely).
263 2015-04-21 20:05:06 <kanzure> hrm.
264 2015-04-21 20:05:38 <kanzure> i don't have time to fix this at the moment. i'm also not sure what the actual problem was originally.
265 2015-04-21 20:05:44 <jonasschnelli> Just take my branch, create a fresh branch from it any manually re-implement your watchonly stuff
266 2015-04-21 20:06:20 <jonasschnelli> If you don't have the time i can take over. But it would be nice if you could finish this properly.
267 2015-04-21 20:06:46 <kanzure> hmm. i will get back to you later today, i can't say either way at the moment.
268 2015-04-21 20:07:38 <jonasschnelli> Yes. No worries and no offense. I think you should start by having a complete test-chain (create/fund/sign/send). This would sort out fee issues, etc.
269 2015-04-21 20:08:43 <jonasschnelli> And if you don't find time, we/i can also add the watch-only support later. Because #5503 is already stuffed with code.
270 2015-04-21 20:14:51 <gmaxwell> jonasschnelli: in your python tests, can you avoid trailing whitespace in the future? (e.g. \w+\n)  I have my git setup flag them, so they're a distraction to me when they go in. :)
271 2015-04-21 20:15:59 <jonasschnelli> @gmaxwell: Yes. Sorry. My shitty IDE adds them... will try to avoid these in future
272 2015-04-21 20:19:33 <gmaxwell> jonasschnelli: if you put
273 2015-04-21 20:19:34 <gmaxwell> [color] diff = true log = true ui = auto
274 2015-04-21 20:20:37 <gmaxwell> (er with linebreaks) in your .gitconfig) along with [core]\npager = less -FXRS   they'll be turned red in git diff and git log -p output.
275 2015-04-21 20:21:13 <jonasschnelli> gmaxwell: nice. Have to also configure it that way. ty
276 2015-04-21 20:55:25 <phantomcircuit> Luke-Jr, i noticed that there isn't a defined field in gbt for the network
277 2015-04-21 20:55:41 <phantomcircuit> ie mainnet vs testnet
278 2015-04-21 20:56:27 <wumpus> why would there need to be a field for that in gbt?
279 2015-04-21 20:56:35 <wumpus> you can get the information using another RPC
280 2015-04-21 20:57:07 <phantomcircuit> wumpus, it changes which address to use in constructing the coinbase
281 2015-04-21 21:07:02 <wumpus> but I mean it doesn't make sense to return it in every gbt, it is not as if it will change in the meantime
282 2015-04-21 21:32:22 <StephenM347> Quick question - pre BIP34, were there any transactions successfully mined that have identical TXIDs? And, if so, when an output from one of these is spent, which one will the bitcoind client mark as spent?
283 2015-04-21 21:34:16 <gmaxwell> StephenM347: yes, there are two seperate duplicated coinbase transactions. effectively the second destroyed the first (as the first wasn't spent yet).
284 2015-04-21 21:34:53 <gmaxwell> Maybe the balance is displayed wonky in whomever wallets those are, I've never actually tested that case.. I suppose you could just watching wallet add them to find out.
285 2015-04-21 21:34:58 <_2_band> hi
286 2015-04-21 21:35:24 <StephenM347> gmaxwell: thanks. I see, so it overrode the previous. Is there just one such pair of transactions?
287 2015-04-21 21:35:54 <gmaxwell> StephenM347: yes. Though in theory it could have spread to non-coinbase txn via spends of the coinbases that didn't happen.
288 2015-04-21 21:36:09 <gmaxwell> (it wouldn't have likely happened by accident as the initial duplication surely did)
289 2015-04-21 21:36:39 <gmaxwell> (the software was written assuming no one would be crazy enough to reuse keys. :P )
290 2015-04-21 21:37:50 <StephenM347> gmaxwell: don't happen to know where I could find the repeated txid?
291 2015-04-21 21:39:33 <gmaxwell> yea, they're specialcased in the bitcoin code.
292 2015-04-21 21:40:14 <gmaxwell> one sec
293 2015-04-21 21:40:55 <gmaxwell> around main.cpp:1715
294 2015-04-21 21:41:06 <gmaxwell> !((pindex->nHeight==91842 && pindex->GetBlockHash() == uint256S("0x00000000000a4d0a398161ffc163c503763b1f4360639393e0e4c8e300e0caec")) ||
295 2015-04-21 21:41:07 <gribble> Error: "((pindex->nHeight==91842" is not a valid command.
296 2015-04-21 21:41:09 <gmaxwell> (pindex->nHeight==91880 && pindex->GetBlockHash() == uint256S("0x00000000000743f190a18c5577a3c2d2a1f610ae9601ac046a38084ccb7cd721")));
297 2015-04-21 21:41:38 <gmaxwell> Those are the block hashes, its the coinbases in those which are the duplicates.
298 2015-04-21 21:44:03 <StephenM347> gmaxwell: thanks, but https://blockchain.info/block-index/106692/00000000000a4d0a398161ffc163c503763b1f4360639393e0e4c8e300e0caec and https://blockchain.info/block-index/106730/00000000000743f190a18c5577a3c2d2a1f610ae9601ac046a38084ccb7cd721 don't seem to have duplicate coinbase txids???
299 2015-04-21 21:44:23 <gmaxwell> StephenM347: those are not dupliaces of each other.
300 2015-04-21 21:44:30 <StephenM347> oh
301 2015-04-21 21:44:34 <StephenM347> duplicates of a previous
302 2015-04-21 21:44:36 <gmaxwell> Those are the overwriting transactions in two seperate duplication groups.
303 2015-04-21 21:45:15 <StephenM347> Alright, that clears it up. Thanks a lot!