1 2014-12-16 00:00:22 <gmaxwell> or at least not much more useful.  E.g. you couldn't recursively combine arbritary scripts since you'd almost always go over the push limits.
  2 2014-12-16 00:00:51 <syskall> Ok, I'm just not sure I understand BIP 16. the OP_EVAL proposal seemed very clear to me
  3 2014-12-16 00:01:45 <gmaxwell> Sometimes something which is simple to describe is not simple to make correct and secure. :)
  4 2014-12-16 00:01:54 <syskall> basically the form of a script pubkey can implicitly change the evaluation behavior
  5 2014-12-16 00:02:07 <syskall> I know, I didn't mean to imply that
  6 2014-12-16 00:03:23 <gmaxwell> Would have been arguably preferable if there was an opcode used to trigger it at least, but doing so would expand every one by one byte and would have made the transactions non-standard. In hindsight we should have wanted them non-standard, but we foolishly believed people would adopt p2sh right away, but didn't because wallets did not implement sending to it for a _long_ time.
  7 2014-12-16 00:03:25 <sipa> bip16 pretty much is op_eval, with the.differemce that it is triggered by a template instead of an opcoxe
  8 2014-12-16 00:05:59 <syskall> sipa: took me  a while to figure that out.. had to go through the IRC logs.. wish it had been in the BIP :o
  9 2014-12-16 00:08:21 <gmaxwell> syskall: ?! the operation is described in the bip.
 10 2014-12-16 00:10:01 <syskall> The BIP is not clear
 11 2014-12-16 00:10:30 <syskall> first it defines a new "standard" transaction type .. which implies it's standard as in "relayed"
 12 2014-12-16 00:11:15 <BlueMatt> gmaxwell: why should they have started non-standard?
 13 2014-12-16 00:11:19 <syskall> but it's in fact a new kind of transaction with new validation rules
 14 2014-12-16 00:11:21 <BlueMatt> would have made the conversation even harder...
 15 2014-12-16 00:11:38 <BlueMatt> "why sould I implement it, its not used anywhere, let alone usable because its non-standard"
 16 2014-12-16 00:12:40 <gmaxwell> BlueMatt: because it being IsStandard left non-upgrading miners more exposed to accidentally mining an invalid block.
 17 2014-12-16 00:13:15 <gmaxwell> And yet, avoiding that chicken and egg is part of why we thought it should be standard.  ... but in hindsight it wasn't what mattered.
 18 2014-12-16 00:13:45 <BlueMatt> well, hinsight is not 20/20 here...never know what wallets would have pushed back harder if it were
 19 2014-12-16 00:14:38 <gmaxwell> well it would have been IsStandard one release after it was deployed on the network... which was still before virtually any wallet except bitcoin core supported it.
 20 2014-12-16 00:16:01 <gmaxwell> could even have done a IsStandard that toggled based on coinbase tags. E.g. feature locks in at 80% but remains non-standard until 95% (or until someone just takes out that code)
 21 2014-12-16 00:19:47 <BlueMatt> true
 22 2014-12-16 00:20:46 <gmaxwell> I think the big lesson I got there was that it was important to get affirmitive buy in if we want wallets to implement something promptly.
 23 2014-12-16 00:20:50 <syskall_> what I meant is that reading the BIP, it feels like the BIP simply defines a new type of standard transaction to be relayed (using existing op codes/validation rules). but it does more than that
 24 2014-12-16 00:20:55 <syskall_> that' was just my point
 25 2014-12-16 00:25:05 <Luke-Jr> syskall_: whether a node relays it or not is a decision for the node, independent of BIPs
 26 2014-12-16 00:28:04 <syskall_> Luke-Jr: that's correct
 27 2014-12-16 00:30:36 <gmaxwell> Certantly we've used BIPs before to recommend non-normative behavior.
 28 2014-12-16 00:31:32 <syskall_> in practice though, the BIPS have a big power over what kind of transactions a regular user can expect to get in the blockchain
 29 2014-12-16 00:33:25 <syskall_> while I have both your attention , mind looking at https://bitcointalk.org/index.php?topic=893077.0 ? :)
 30 2014-12-16 00:35:58 <gmaxwell> you cannot implementat that in script today. Though if you search (e.g. 'fair coin toss') you can find a scheme that does work.
 31 2014-12-16 00:36:14 <gmaxwell> you're not getting responses because you haven't searched, and people are ignoring your post because you didn't research.
 32 2014-12-16 00:36:21 <guest28389273871> why is leveldb in the core src tree?
 33 2014-12-16 00:37:07 <phantomcircuit> because it's part of the consensus code so it's best that we can control changes
 34 2014-12-16 00:37:13 <gmaxwell> guest28389273871: because its an integral part of Bitcoin Core's consensus algorithim implementation.  (and even were it not, it's normally not distributed as a freestanding library even on Linux distributions)
 35 2014-12-16 00:37:49 <guest28389273871> in other words, because it is statically compiled?
 36 2014-12-16 00:38:14 <gmaxwell> No, that isn't what I said.
 37 2014-12-16 00:39:00 <guest28389273871> ok, so berkeleydb would be in the core src tree if it were to manage chainstate/blockindex?
 38 2014-12-16 00:39:30 <gmaxwell> Prior to our use of it LevelDB's authors had fixed 'bugs' which if simply fixed in an uncontrolled way would have resulted in consensus forking vulnerabilities.  Generally software isn't written and mantained with the particular requirements of cryptographic consensus in mind.
 39 2014-12-16 00:39:50 <gmaxwell> guest28389273871: Yes, potentially.
 40 2014-12-16 00:40:05 <guest28389273871> alright. i can relate
 41 2014-12-16 00:40:34 <guest28389273871> as much as one could stretch that to apply to, say, boost too
 42 2014-12-16 00:41:06 <gmaxwell> It could indeed. Our path there has been to reduce the role of boost in the codebase. Primarly we use it only in ways that really couldn't conceivably be gotten wrong.
 43 2014-12-16 00:41:31 <gmaxwell> (and it was never used in really far out ways... mostly as a way of importanting C++ features from the future, really)
 44 2014-12-16 00:42:48 <guest28389273871> let me check on another thing. i asked about an 'extention' of the version message to include os/platform info the other day. IRC was that back then...
 45 2014-12-16 00:43:17 <guest28389273871> dead
 46 2014-12-16 00:43:43 <guest28389273871> any thoughts?
 47 2014-12-16 00:45:07 <phantomcircuit> i cant see any legitimate use for that
 48 2014-12-16 00:45:21 <gmaxwell> That doesn't sound interesting or useful, just would be another privacy leak.
 49 2014-12-16 00:45:45 <guest28389273871> i understand the concerns, but how do we know what the 7K nodes are running on out there?
 50 2014-12-16 00:46:00 <gmaxwell> I was somewhat opposed to even having a version string. (I think history has supported my opposition too, its basically worthless because so many things just lie in it even though there is no reason for it)
 51 2014-12-16 00:46:17 <gmaxwell> guest28389273871: having that data wouldn't change our knoweldge there in the slighest.
 52 2014-12-16 00:46:46 <guest28389273871> how do we know 32bit needs support, for instance, etc... it permeates everything we do. travis, source code, docs, gitian...
 53 2014-12-16 00:47:36 <gmaxwell> Supporting 32 bit does not require any additional effort. It just requires writing portable software. Even if there were somehow no need for it, we'd still make sure it worked.
 54 2014-12-16 00:48:11 <gmaxwell> (and the notion that we wouldn't need it is a little crazy, IMO, by number 32 bit processor production still _vastly_ outpaces 64 bit processors)
 55 2014-12-16 00:48:58 <guest28389273871> so, the argument is low level of effort across the current "system reqs". just making sure we're on the same page, not necessarily asking for dropping 32 support at all.
 56 2014-12-16 00:49:10 <gmaxwell> Also, ... we couldn't learn that there from _listening_ nodes. Listening nodes are only a fraction of deployed nodes. There are probably on the order of a hundred thousand hosts running bitcoin, sampling a small portion of the publically inbound reachable ones is not that informative.
 57 2014-12-16 00:50:18 <gmaxwell> Well, you've not articulated a need. So to me it just seems user hostile: I can tell you how this would harm users. I can't come up with a way that it would help them.
 58 2014-12-16 04:46:22 <wumpus> WHAT, who is arguing for dropping 32 bit support
 59 2014-12-16 04:46:51 <wumpus> in other news, my mips32be node is now synchronized to 38% of the testnet chain
 60 2014-12-16 04:58:36 <gmaxwell> wumpus: ... wait, you have be working?
 61 2014-12-16 04:59:07 <gmaxwell> wumpus: by coincidence, I got both my dual G5 PPC hosts working last night (been testing libsecp256k1 and some non-bitcoin stuff on them)
 62 2014-12-16 05:05:44 <wumpus> gmaxwell: yes, I have BE working; most of the work is https://github.com/bitcoin/bitcoin/pull/5478 . There are some other changes required beside that, such as in serialization, and a few silly changes in the network code, but it appears to work.
 63 2014-12-16 05:07:43 <wumpus> and all the tests pass
 64 2014-12-16 05:10:06 <gmaxwell> I guess congrats to everyone on the last year of changes too, since it used to be more gnarly but many things have improved portability as a side effect.
 65 2014-12-16 05:12:48 <wumpus> indeed
 66 2014-12-16 05:21:38 <davec> I second that.  Nice job on the cleanup and refactoring that has been going on guys
 67 2014-12-16 05:59:52 <akaiiro> guys, I just reed this http://en.bitcoinwiki.org/Bitcoin_address
 68 2014-12-16 06:01:01 <akaiiro> and then looked that two of my recent addresses start with 'm'
 69 2014-12-16 06:01:46 <akaiiro> the generates addresses for bitcoin and testnet3 are different in format?
 70 2014-12-16 06:02:30 <wumpus> same format, different prefix byte
 71 2014-12-16 06:02:54 <akaiiro> oh, ok. thanks wumpus
 72 2014-12-16 06:24:16 <wumpus> thanks davec, yes I'm also happy to see where things are going, if we have to break some people's pull requests along the way that's just how things go
 73 2014-12-16 08:27:54 <b-itcoinssg> when you create a multi-sig address with a stated criteria i.e. = m of n public keys (where the number m and n public keys are known), is there only 1 possible address? or can you generate multiple multi-sig addresses that fit that criteria?
 74 2014-12-16 08:33:09 <Luke-Jr> b-itcoinssg: you can, but it's not necessarily useful to do so\
 75 2014-12-16 08:33:21 <Luke-Jr> b-itcoinssg: it's still address reuse, even though the addresses are different
 76 2014-12-16 08:34:16 <b-itcoinssg> Luke-Jr:ok, thanks
 77 2014-12-16 08:38:08 <b-itcoinssg> Luke-Jr: correct me if I'm wrong but right now, you can generate a multi-sig address only if you know public keys and the "m"(although, there is a max for this). right? It would be cool if there was a way to generate a multi-sig address just using the bitcoin addresses, that way anyone could create and hence verify a multi-sig address and the m in m of n.
 78 2014-12-16 08:39:07 <Luke-Jr> you can do this (you still need "m")
 79 2014-12-16 08:39:17 <Luke-Jr> it just isn't standardised
 80 2014-12-16 08:41:16 <b-itcoinssg> oh ok, that is good.
 81 2014-12-16 08:42:58 <b-itcoinssg> there is a limit on m right? like 11 or something? To verify a multi-sig address with only public addresses known, one could exhaustively search all m of n couldn't you?
 82 2014-12-16 08:47:17 <gmaxwell> uh. current smartfee code looks like it could conclude to pay less than minRelayTxFee. :-/
 83 2014-12-16 08:48:46 <Luke-Jr> b-itcoinssg: 15. but maybe less if you use addresses
 84 2014-12-16 08:48:59 <Luke-Jr> or maybe more..
 85 2014-12-16 08:49:19 <b-itcoinssg> ok
 86 2014-12-16 10:52:54 <wumpus> this just adds some tx_invalid/valid tests for OP_CODESEPARATOR, any specific reason it doesn't get any acks? https://github.com/bitcoin/bitcoin/pull/5421
 87 2014-12-16 10:54:27 <gmaxwell> Petertodd pull, shunning.  :P  Nah, just haven't had a chance to actually review it.
 88 2014-12-16 10:55:08 <wumpus> but it adds an entry to tests.json, and it still passes afterwards, that's nearly always good right? :-)
 89 2014-12-16 10:55:45 <gmaxwell> yea, more along the lines of "I need to go figure out how the hell he got a positive use out of it and understand that."
 90 2014-12-16 10:56:17 <gmaxwell> And make sure that this revelation doesn't alert me to any potential consensus bugs or exploitable conditions.
 91 2014-12-16 10:56:25 <wumpus> but yes, good point, we should shun the enemy's pulls *ducks*
 92 2014-12-16 10:56:52 <gmaxwell> He might have used cursed bits.
 93 2014-12-16 10:57:22 <petertodd> two positive uses in fact: you can use OP_CODESPARATOR for zerocash too I just realised
 94 2014-12-16 10:58:15 <gmaxwell> wumpus: sorry for being naughty and using the PR process as my personal reading list. :)
 95 2014-12-16 11:02:09 <petertodd> if you take "reveal a embedded consensus zerocash serial number" to be "validly executing part of a script" then you can put those scripts in transactions, thus giving zerocash access to the bitcoin scripting system for authentication
 96 2014-12-16 11:03:10 <petertodd> OP_CODESEPARATOR is useful there as you can in some cases put the script fragments in transactions in more convenient ways... my other use case is cooler, but still, it's a usecase
 97 2014-12-16 11:03:52 <gmaxwell> ah, for ZC I'd really mostly assumed doing the emerge in the txin basically and getting a scriptpubkeyhash out as the 'serial number'
 98 2014-12-16 11:04:09 <petertodd> gmaxwell: specifically embedded consensus zerocash remember
 99 2014-12-16 11:20:20 <sipa> ... opens #5478
100 2014-12-16 11:20:26 <sipa> "103 files modified"
101 2014-12-16 11:26:30 <michagogo> 10:47:28 <gmaxwell> uh. current smartfee code looks like it could conclude to pay less than minRelayTxFee. :-/ <-- Should we assume that everyone's using the same policy as us?
102 2014-12-16 11:26:56 <sipa> michagogo: no, but we shouldn't create a transaction that we won't relay ourselves
103 2014-12-16 11:27:10 <gmaxwell> michagogo: we don't assume that... but as a minimum... ^ what sipa said.
104 2014-12-16 11:27:35 <michagogo> Won't? Or wouldn't?
105 2014-12-16 11:27:41 <sipa> won't
106 2014-12-16 11:27:45 <michagogo> Ah
107 2014-12-16 11:27:58 <michagogo> Yeah, I can see that being a problem :
108 2014-12-16 11:28:05 <michagogo> :P
109 2014-12-16 11:35:00 <jonasschnelli> header stop building successfully.. it looks like it because of one of mine Qt based pull. will have a look
110 2014-12-16 11:40:35 <jonasschnelli> cfields: any clue why this: "error: ‘class QPixmap’ has no member named ‘convertFromImage’"?
111 2014-12-16 11:40:54 <jonasschnelli> QPixmap::convertFromImage is available in Qt4
112 2014-12-16 11:41:47 <jonasschnelli> only affects the "32-bit + dash" and "No wallet" builds
113 2014-12-16 11:44:21 <wumpus> sipa: yes, it makes more sense to review it by commit than the whole thing at once
114 2014-12-16 11:45:35 <sipa> wumpus: i think it would be easier to review (as a whole) if renaming was done the other way first (use uint256 for the blob behaviour, and some temporary arithmetic_uint256 or whatever for the one with actual bigint semantcis)
115 2014-12-16 11:47:12 <wumpus> sipa: ok...
116 2014-12-16 11:47:39 <sipa> wumpus: don't go off replace the whole thing now; i haven't even gone through it all :)
117 2014-12-16 11:47:43 <sipa> just quick initial remark
118 2014-12-16 11:48:46 <wumpus> but yes in retrospect I should have done it the other way around, probably, although I like that this keeps uint256.h almost untouched and just introduces new types
119 2014-12-16 11:49:32 <sipa> indeed; just looking at the total diff it seems that almost all cases are changed to blob (which is awesome)
120 2014-12-16 11:49:41 <wumpus> could of course have renamed it to something else, but that would mean changing a lot of headers
121 2014-12-16 11:49:47 <wumpus> yup
122 2014-12-16 11:51:36 <wumpus> the only uses of 256-bit arithmetic are for PoW, some crazy hashing for the trickle system, and increasing the nonce for CKey::Sign :p
123 2014-12-16 11:52:11 <wumpus> two of those could be removed, but didn't want to bother in this pull
124 2014-12-16 11:52:12 <sipa> hmm, pity that i relied on uint256 arithmetic behaviour for the sign test cases
125 2014-12-16 11:52:18 <sipa> could have been a xor just as easily
126 2014-12-16 11:54:03 <wumpus> I also like that uint160 can just go. No use of any 160-bit arithmetic anywhere.
127 2014-12-16 11:54:09 <sipa> indeed
128 2014-12-16 11:54:28 <sipa> wumpus: indeed, nChainWork and PoW comparison are really the only truly arithmetic uint256 uses i knew of
129 2014-12-16 11:54:58 <sipa> (big concept ack btw, if that wasn't clear already)
130 2014-12-16 12:00:06 <sipa> petertodd: updated attribution in cltv2 by the way - it was just a quick way of showing how it could be done; not an actual intended patch
131 2014-12-16 12:01:16 <btcdrak> sipa: ya, just for public record, I've rebased it squashing the validation into the signature checker as you suggested https://github.com/btcdrak/bitcoin/compare/bitcoin:master...checklocktimeverify
132 2014-12-16 12:01:27 <sipa> btcdrak: cool
133 2014-12-16 12:02:07 <btcdrak> petertodd should submit a PR soon. There is one question with an unused constant
134 2014-12-16 12:02:31 <petertodd> btcdrak: I think you missed an attribution to sipa :) but I'll add that when I do my PR
135 2014-12-16 12:03:32 <btcdrak> petertodd: yes, I squashed it on purpose to keep it concise and figured it would be better at PR time. I mailed you about it but maybe you havent checked your email yet.
136 2014-12-16 12:04:00 <btcdrak> SCRIPT_ERR_UNSATISFIED_LOCKTIME seems to be unused
137 2014-12-16 12:04:03 <sipa> no worries
138 2014-12-16 12:04:14 <sipa> btcdrak: let me check
139 2014-12-16 12:04:23 <petertodd> btcdrak: I gotta split it into "opcode" and "actually do soft-fork" anyway, so more git rebasing in my future...
140 2014-12-16 12:04:49 <sipa> btcdrak: my mistake
141 2014-12-16 12:04:50 <sipa> fixing
142 2014-12-16 12:06:15 <jonasschnelli> does travis uses Qt4.6 for some builds?
143 2014-12-16 12:06:20 <btcdrak> sipa: it wasnt in the original PR of peter's
144 2014-12-16 12:06:27 <btcdrak> *branch
145 2014-12-16 12:06:33 <sipa> btcdrak: no, script error codes were added in master since
146 2014-12-16 12:06:39 <sipa> so i added it in the rebase, but missed a case
147 2014-12-16 12:07:04 <btcdrak> ah. added you to my repo you can push the change directly if you like
148 2014-12-16 12:07:48 <sipa> btcdrak: updated my branch
149 2014-12-16 12:07:57 <btcdrak> thanks!
150 2014-12-16 12:08:29 <sipa> also, my former branch was actually incorrect wrt to the BIO; if you had any tests, and they didn't catch this, that should be fixed :)
151 2014-12-16 12:08:35 <sipa> *BIP
152 2014-12-16 12:09:06 <sipa> i prefer not to push to other people's repo's, can lead to conflicts or misunderstandings easily
153 2014-12-16 12:09:55 <sipa> jonasschnelli: travis uses whatever is in depends
154 2014-12-16 12:10:37 <jonasschnelli> sipa thanks. I think its a < Qt4.7 issue
155 2014-12-16 12:11:58 <btcdrak> sipa: did you push yet? dont see it
156 2014-12-16 12:12:28 <sipa> yes
157 2014-12-16 12:12:51 <sipa> branch cltv2 on sipa/bitcoin
158 2014-12-16 12:13:32 <btcdrak> last commit 20 hours ago
159 2014-12-16 12:13:56 <sipa> github lazy again?
160 2014-12-16 12:14:21 <btcdrak> oh lol, it happens :)
161 2014-12-16 12:14:38 <sipa> btcdrak: "authored 20 hours ago"
162 2014-12-16 12:14:50 <sipa> the branch was updated 7 minutes ago though
163 2014-12-16 12:14:56 <sipa> rebases don't change the author time
164 2014-12-16 12:15:16 <sipa> 52c2cdba405cd4e52c8ec1fa2c80fba1c638fd0b is the correct commit
165 2014-12-16 12:15:59 <btcdrak> ah, ok. np
166 2014-12-16 12:16:12 <btcdrak> I see.
167 2014-12-16 12:23:28 <jonasschnelli> wumpus #5487 should get in soon to make travis happy again
168 2014-12-16 12:26:43 <wumpus> jonasschnelli: oops!
169 2014-12-16 12:27:48 <jonasschnelli> i probably overlooked the #5228 travis report because the issue must has also be shown then
170 2014-12-16 12:28:17 <wumpus> me too; that's weird. I wouldn't normally merge anything with travis complaining.
171 2014-12-16 12:29:37 <jonasschnelli> i assume the qt travis depends didn't changed since the last coming on #5228. However. Now it's solved.
172 2014-12-16 12:41:18 <jonasschnelli> regarding two step 'sendtoaddress' RPC method. Brainstorming: how would it be possible to get a prepared transaction object which can be committed in a 2nd RPC call?
173 2014-12-16 12:42:22 <jonasschnelli> i think getting a whole rawtransaction object back for later committing is annoying
174 2014-12-16 12:42:22 <sipa> we just need something in between to createrawtransaction and signrawtransaction
175 2014-12-16 12:42:40 <sipa> which adds sufficient inputs to satisfy the outputs
176 2014-12-16 12:42:50 <sipa> please, don't introduce more state :(
177 2014-12-16 12:43:08 <sipa> it's a bit annoying for humans that use the RPC directly, but so much saner for any other usage
178 2014-12-16 12:43:18 <ThomasV> fundrawtransaction ?
179 2014-12-16 12:43:24 <sipa> sounds good
180 2014-12-16 12:44:31 <jonasschnelli> Yes. sounds good. Stateless; definitively. Will implement.
181 2014-12-16 12:44:50 <jonasschnelli> (Will implement = will try to implement)
182 2014-12-16 12:59:46 <jonasschnelli> RPC fundrawtransaction brainstorming: how it would be possible to unlock the inputs? What happens with never signed and broadcasted transactions?
183 2014-12-16 13:00:02 <sipa> unlock what inputs?
184 2014-12-16 13:01:23 <sipa> you mean the lockunspent call?
185 2014-12-16 13:02:07 <sipa> i guess it makes sense to lock certain coins, tell fundrawtransaction to use ignore the locking, and unlock after wards
186 2014-12-16 13:02:18 <sipa> or even make fundrawtransaction lock the inputs used
187 2014-12-16 13:02:28 <sipa> to avoid double-spending yourself
188 2014-12-16 13:04:16 <jonasschnelli> but when fundrawtransaction would lock the inputs, when would be the time to unlock. Assume the user will use fundrawtransaction, forget about the funded tx and afterward would use sendtoaddress.
189 2014-12-16 13:05:03 <wumpus> unfortunately it cannot really be stateless, anything that does the selection for you does need to lock the inputs
190 2014-12-16 13:05:18 <sipa> maybe a boolean flag to fundrawtransaction to lock the inputs used
191 2014-12-16 13:05:19 <fanquake> jonasschnelli New icons look good. Am building with Qt5.4 too.
192 2014-12-16 13:05:33 <sipa> and a separate RPC which takes a raw transaction and unlocks its inputs?
193 2014-12-16 13:05:35 <wumpus> otherwise it's impossible to do any concurrency
194 2014-12-16 13:06:00 <wumpus> ie, two successive calls will just give you the same inputs if you didn't commit in the meantime
195 2014-12-16 13:06:02 <jonasschnelli> unfundrawtransaction :)
196 2014-12-16 13:06:03 <wumpus> sipa: yes, cancel
197 2014-12-16 13:06:14 <wumpus> or unfund, whatever
198 2014-12-16 13:06:36 <sipa> wumpus: well, not cancel necessarily; if you had sent transaction before, they're automatically considered used anyway
199 2014-12-16 13:06:39 <jonasschnelli> what about the sendtoaddress call, should we keep that call confirm-less?
200 2014-12-16 13:06:51 <sipa> confirmless?
201 2014-12-16 13:07:59 <jonasschnelli> i just brainstorming: what if sendtoaddress would have a confirm boolean-flag which when enabled would return a rawtx to sing and send?
202 2014-12-16 13:08:00 <wumpus> sipa: it would be a cancel that you can only do *before* actually sending the transaction, after sending it it's indeed pointless
203 2014-12-16 13:08:19 <sipa> jonasschnelli: i really prefer to keep things separate
204 2014-12-16 13:08:28 <wumpus> introduce a new call pleaase
205 2014-12-16 13:08:42 <wumpus> no more hacky extra flags to those hacky send functions
206 2014-12-16 13:08:47 <sipa> jonasschnelli: as you suggest, sendtotransaction would just become createrawtransaction + fundrawtransaction + signrawtransaction
207 2014-12-16 13:09:03 <sipa> eh, sendtoaddress
208 2014-12-16 13:09:22 <sipa> i would keep sendtoaddress to just mean the whole thing, as it is now, and introduce separate broken-up calls to do the various steps independently
209 2014-12-16 13:10:14 <wumpus> we have too many send functions
210 2014-12-16 13:10:19 <wumpus> only one shall survive
211 2014-12-16 13:10:34 <wumpus> sendmany?
212 2014-12-16 13:10:35 <sipa> </highlandermode>
213 2014-12-16 13:10:38 <jonasschnelli> so keep sendtoaddress as it is know and refine the createrawtransaction + signrawtransaction with a fundrawtransaction?
214 2014-12-16 13:10:45 <sipa> jonasschnelli: not refine
215 2014-12-16 13:10:58 <sipa> createrawtransaction remains unchanged, signrawtransaction remains unchanged
216 2014-12-16 13:11:22 <jonasschnelli> yes. right. but add a fundrawtransaction to lock the inputs and give informations about the fees, etc.
217 2014-12-16 13:11:27 <jonasschnelli> fees=fee
218 2014-12-16 13:11:29 <wumpus> yes
219 2014-12-16 13:11:41 <sipa> just add a fundrawtransaction that takes the output of createrawtransaction, and adds inputs (and potentially a change output), using coin selection and ewhatever criteria (fees?) seem reasonable
220 2014-12-16 13:11:56 <sipa> and then the use can use the output of this to give to sign/sendrawtransaction
221 2014-12-16 13:12:08 <jonasschnelli> okay. clear.
222 2014-12-16 13:12:31 <sipa> it may be useful to first just abstact the coin selection code out
223 2014-12-16 13:12:37 <jonasschnelli> But what about the sendtoaddress user? If he likes to know about the potential fee he needs to create rawtxs?
224 2014-12-16 13:12:55 <wumpus> yes
225 2014-12-16 13:13:00 <sipa> yes
226 2014-12-16 13:13:12 <wumpus> sendtoaddress is a one-step function, it can't ask you anything back
227 2014-12-16 13:13:59 <wumpus> that's why gmaxwell adds a global maximum fee setting in #5485
228 2014-12-16 13:14:08 <sipa> also, a non-wallet based fundrawtransaction may even be useful, where you pass in the entire list of utxos to pick from
229 2014-12-16 13:14:16 <sipa> which obviously can't do any locking
230 2014-12-16 13:14:23 <sipa> that could even go in bitcoin-tx
231 2014-12-16 13:14:30 <sipa> maybe it should only go there
232 2014-12-16 13:14:37 <wumpus> please don't use the same function for wallet and non-wallet use though
233 2014-12-16 13:14:41 <sipa> agree
234 2014-12-16 13:14:41 <wumpus> we've learned that lesson
235 2014-12-16 13:14:45 <sipa> yes, totally
236 2014-12-16 13:15:18 <jonasschnelli> wumpus yes. So the sendtoaddress user needs to create rawtransactions if he likes to know the potential fee?
237 2014-12-16 13:15:29 <sipa> yes
238 2014-12-16 13:15:34 <wumpus> deja vu? yes
239 2014-12-16 13:15:42 <jonasschnelli> :)
240 2014-12-16 13:15:46 <wumpus> same for the sendmany user, the sendfrom user, ...
241 2014-12-16 13:15:52 <wumpus> all of them
242 2014-12-16 13:16:06 <wumpus> all three of them!
243 2014-12-16 13:17:50 <jonasschnelli> I just felt that it could be more easy creating a tx where you get infos about the fees instead the createrawtransaction where you have to specify the inputs.
244 2014-12-16 13:18:28 <wumpus> isn't the idea that you don't have to specify inputs and the wallet will select them for you, using fundrawtransaction?
245 2014-12-16 13:19:13 <sipa> jonasschnelli: you don't specify the inputs
246 2014-12-16 13:19:15 <jonasschnelli> slowly i get it. :)
247 2014-12-16 13:19:26 <sipa> jonasschnelli: just use createrawtransaction with only the outputs
248 2014-12-16 13:19:56 <sipa> jonasschnelli: pass to fundrawtransaction that adds inputs/change as necessary to satisfy money balance and fee requirements
249 2014-12-16 13:20:12 <sipa> jonasschnelli: pass to signrawtransaction to sign the inputs
250 2014-12-16 13:20:20 <sipa> jonasschnelli: pass to sendrawtransaction to broadcast
251 2014-12-16 13:20:47 <jonasschnelli> Okay. All clear now.
252 2014-12-16 13:21:17 <jonasschnelli> fanquake thanks for testing. Especially < 10.10 testes on retina compatibility would be nice
253 2014-12-16 13:21:18 <sipa> a wrapper around createrawtransaction that has the same interface as sendtoaddress would be convenient, but probably clutter...
254 2014-12-16 13:21:48 <wumpus> could be implemented entirely client-side
255 2014-12-16 13:21:54 <wumpus> so, yes, that's clutter
256 2014-12-16 13:22:10 <wumpus> also that would introduce another send function -> no!
257 2014-12-16 13:22:29 <sipa> we could do it as an extra boolean input to sendmany *ducks*
258 2014-12-16 13:22:34 <wumpus> wheee
259 2014-12-16 13:23:01 <wumpus> sendmanyEx2
260 2014-12-16 13:23:11 <sipa> ProcSendManyEx2
261 2014-12-16 13:39:46 <jonasschnelli> so; sendmany with boolean flag would produce same output as createrawtransaction with no inputs specified? Or whatfor is ProcSendMany?
262 2014-12-16 13:40:37 <sipa> jonasschnelli: we *were* joking
263 2014-12-16 13:43:04 <jonasschnelli> *oops*
264 2014-12-16 13:55:01 <jonasschnelli> wumpus: you said: "please don't use the same function for wallet and non-wallet use though". So fundrawtransaction requires a wallet, support for any utxo would not make sense?
265 2014-12-16 13:56:36 <wumpus> fundrawtransaction would be a wallet function or not a wallet function
266 2014-12-16 13:56:45 <wumpus> first would make most sense
267 2014-12-16 13:57:13 <wumpus> fundrawtransaction w/ full utxo would be a pure utility function anyhow so belongs on bitcoin-tx
268 2014-12-16 13:58:25 <jonasschnelli> okay. thanks.
269 2014-12-16 15:46:30 <pavel_> jonasschnelli, can you please run convert -strip on the image displayed? Just to verify if it fixes the issue? BTW - do you see the warning?
270 2014-12-16 16:00:54 <jonasschnelli> pavel_ no. i can't see the warning.
271 2014-12-16 16:01:12 <jonasschnelli> do you know which image triggers the error?
272 2014-12-16 16:07:27 <wumpus> I didn't see it either
273 2014-12-16 16:16:15 <jonasschnelli> i will strip all PNGs. Should remove any unnecessary data (like profile).
274 2014-12-16 16:23:16 <rzhang> I have a question about transaction propagation details. Is this the right place to ask?
275 2014-12-16 16:25:47 <kjj> depends.  easier to just ask the question
276 2014-12-16 16:27:36 <rzhang> Thanks. Does the trickle procedure also apply to txs? For the initiator of a tx, how many peers will it notice per 100ms?
277 2014-12-16 16:30:37 <rzhang> I have read from a paper that with 1/4 possibility that the initiator will send it to all its connections, is that correct? And is the procedure different for a relay peer?
278 2014-12-16 17:32:25 <jtimon> would it make sense to tag 41cced21 "Merge pull request #5267" with 0.10_base or something like that?
279 2014-12-16 17:48:29 <wumpus> meh, I'd like to keep tags just for actual releases
280 2014-12-16 17:48:52 <wumpus> I hope we'll have an actual 0.10.0rc1 tag soon
281 2014-12-16 17:49:20 <wumpus> for now, use the branch
282 2014-12-16 17:58:59 <ajweiss> so make depends does all the wgets for gitian builds now, correct?  all i need to manually grab is the os x sdk?
283 2014-12-16 18:23:29 <sipa> jgarzik: nice mail
284 2014-12-16 18:26:05 <jgarzik> sipa, I felt there were a lot of issues to pick apart
285 2014-12-16 18:53:48 <maraoz> which tests use the file sig_canonical.json? running `git grep sig_canonical` returns only "src/Makefile.test.include:22"
286 2014-12-16 19:04:12 <jtimon> yeah, the idea of having periods with and without moveonly commits makes  sense to me
287 2014-12-16 19:04:26 <sipa> maraoz: heh, the tests there have been incorporated into script tests
288 2014-12-16 19:04:37 <sipa> maraoz: a few months ago
289 2014-12-16 19:04:55 <sipa> i believe the file should be deleted, but let me verify
290 2014-12-16 19:07:06 <maraoz> sipa: thanks. do you know if it was included in other data file? (say script_valid.json?) - those data files are really useful as fixtures for other bitcoin libraries (like bitcore)
291 2014-12-16 19:09:41 <sipa> maraoz: yes
292 2014-12-16 19:09:59 <sipa> script_valid and _invalid
293 2014-12-16 19:10:16 <maraoz> ok, I'll create a PR to remove them in a sec
294 2014-12-16 19:10:42 <sipa> them? plural?
295 2014-12-16 19:12:27 <maraoz> sig_canonical.json and sig_noncanonical.json
296 2014-12-16 19:13:31 <sipa> ah, of course
297 2014-12-16 19:57:28 <andytoshi> sipa: in the comment around line 130 i'm unsure what "p" and "the order" refer to --- is p the (prime) order of the subgroup and "the order" the order of the entire curvegroup?
298 2014-12-16 19:57:41 <andytoshi> in libsecp256k1 pr #123
299 2014-12-16 20:12:02 <gmaxwell> andytoshi: there are only two orders involved, p (the size of the field the curve is defined over) and order (the order of the group), our curve has cofactor 1... there is only one subgroup, all points satisfing the curve eq are members of a single group of size order.
300 2014-12-16 20:16:34 <andytoshi> oh, derp, p is the field order
301 2014-12-16 20:16:42 <andytoshi> thx
302 2014-12-16 20:17:08 <andytoshi> i thought our curve had only one subgroup, was why i was confused
303 2014-12-16 20:21:45 <gmaxwell> hah order in the description is group order, p is field order.
304 2014-12-16 20:22:21 <andytoshi> the x coord should be mod the field order tho
305 2014-12-16 20:22:35 <andytoshi> exponents (and nothing else) should be mod the group order (i think)
306 2014-12-16 20:23:58 <andytoshi> ah, no, the ECDSA def says n
307 2014-12-16 20:24:01 <andytoshi> the gruop order
308 2014-12-16 20:24:15 <gmaxwell> andytoshi: Yes by definition the coordinate itself is mode the field order. But ecdsa awfulness means that 'r' is G*k mod group.
309 2014-12-16 20:24:18 <andytoshi> ah, right, x -is- used as an exponent
310 2014-12-16 20:24:30 <andytoshi> ok, i don't feel bad for forgetting this :P
311 2014-12-16 20:24:33 <gmaxwell> thats where the complexity arises.  X is a challenge but the agreement test isn't quite exact.
312 2014-12-16 20:37:32 <andytoshi> in `exists h. (x(R) + h * order < p && x(R) == xr + h * order)` should it be `exists h. (x(R) + h * order < p && x(R) + h * order == xr)` ?
313 2014-12-16 20:37:58 <andytoshi> note that in the original we check that adding `order` won't wrap x(R) but then we add it to `xr`
314 2014-12-16 20:38:22 <andytoshi> brb lunch
315 2014-12-16 20:42:39 <segrx> Does anyone know what the response to `getrawtransaction <txid>`  (assuming index=1)  when querying for a txid that was previously in the mempool or blockchain, but since been considered invalid (as it conflicted)
316 2014-12-16 20:45:33 <helo> segrx: i would expect it to return the raw transaction, having already indexed it. *searches for removal from index on invalidation*
317 2014-12-16 20:46:16 <segrx> Even if it was only in the mempool, it's inserted in the db and indexed?
318 2014-12-16 20:51:35 <helo> hmm, it looks like it will be removed from the mempool if it is invalidated
319 2014-12-16 20:53:06 <segrx> So in that case, if I query for it -- I should expect to see the typical: "No information available about transaction"
320 2014-12-16 20:54:43 <segrx> but if it was in a block, I should get a response -- but it won't have a "confirmations" field on the json response?
321 2014-12-16 20:54:54 <segrx> (Since it'll still be indexed, but won't be in the best block chain )
322 2014-12-16 20:55:59 <helo> if it isn't in the mempool, then it attempts to locate it using the txindex
323 2014-12-16 20:56:45 <helo> so yes, if it was at some point in a block it looks like it should be found (with no confirmations)
324 2014-12-16 21:22:52 <sipa> gmaxwell: when i say 'order' it always refers to n, the group order
325 2014-12-16 21:22:56 <sipa> eh
326 2014-12-16 21:23:01 <sipa> andytoshi: when i say 'order' it always refers to n, the group order
327 2014-12-16 21:24:27 <sipa> the field size is always referred to as p; i don't think a field itself has an order (its additive and multiplicative groups do, though)
328 2014-12-16 21:25:33 <sipa> segrx: getrawtransaction will return the information of a transaction is it was ever in a processed block (potentially in a reorganized branch), or is currently in the mempool
329 2014-12-16 21:26:39 <sipa> andytoshi: and no, it should x(R) == xr + h * order; x(R) is a field element (mod p), xr is a number mod n
330 2014-12-16 21:28:19 <sipa> (and n < p)
331 2014-12-16 21:31:10 <sipa> andytoshi: ehh wait
332 2014-12-16 21:33:33 <sipa> andytoshi: the overflow conditions is wrong; nice catch
333 2014-12-16 21:33:40 <sipa> (just in the comment)
334 2014-12-16 21:52:34 <sipa> andytoshi: updated the branch; i've added a bit more comments, and only used 'p' and 'n' (rather than 'order'); also, used the actual variable names
335 2014-12-16 22:04:27 <andytoshi> sipa: excellent :) was hoping it was just the comment
336 2014-12-16 22:04:29 <andytoshi> i'll check it out
337 2014-12-16 22:06:42 <andytoshi> sipa: can a malicious actor set xr > n ?
338 2014-12-16 22:07:13 <andytoshi> then h might be -1
339 2014-12-16 22:07:40 <sipa> andytoshi: no, xr is the R value in the signature; it's invalid if it is >= n
340 2014-12-16 22:08:33 <andytoshi> ok, cool
341 2014-12-16 22:09:09 <andytoshi> (in this case the code correctly rejects the signature, but the analysis is broken)
342 2014-12-16 22:09:11 <andytoshi> i think it's fine
343 2014-12-16 22:09:14 <sipa> so xr is between 1 and n-1, inclusive
344 2014-12-16 22:09:32 <sipa> right, the analysis makes assumptions about the ranges of the variables
345 2014-12-16 22:11:04 <andytoshi> ok cool, utack
346 2014-12-16 22:11:18 <andytoshi> i checked all the code, including the new x-comparison function
347 2014-12-16 22:11:32 <andytoshi> tho i used https://crypto.stackexchange.com/questions/17917/how-to-convert-projective-to-jacobian-co-ordinate-in-ecc as my "coordinate transforms are correct" reference :P
348 2014-12-16 22:11:43 <gmaxwell> andytoshi: on github. :P
349 2014-12-16 22:12:13 <gmaxwell> \O/
350 2014-12-16 22:12:16 <andytoshi> done :)