1 2012-01-02 00:17:15 <midnightmagic> BlueMatt: You know I'm just rah-rah'ing the patch right? I totally 100% agree it should be tested, but I know that sometimes things get dropped on the floor. Squeaky wheel gets the grease as they say..
  2 2012-01-02 00:26:04 <BlueMatt> midnightmagic: well you are making plenty of arguments, but none of them are really valid, you are saying it will be dropped, no pull req has even been dropped
  3 2012-01-02 00:26:43 <sipa> which pull req are we talking about?
  4 2012-01-02 00:27:06 <BlueMatt> midnightmagic: pull requests have laid unpulled because people dont update it
  5 2012-01-02 00:27:10 <luke-jr> BlueMatt: liar
  6 2012-01-02 00:27:38 <luke-jr> I can get you PLENTY of maintained pull requests that were dropped
  7 2012-01-02 00:27:40 <sipa> pull reqs have been closed for being too old and not updated
  8 2012-01-02 00:28:04 <luke-jr> sipa: and for "Gavin doesn't like it" and "you're submitting too many pull requests today, and Gavin doesn't want to review them all"
  9 2012-01-02 00:28:08 <midnightmagic> Who's laanwj? Is he in here?
 10 2012-01-02 00:28:12 <luke-jr> midnightmagic: wumpus
 11 2012-01-02 00:28:13 <sipa> midnightmagic: wumpus
 12 2012-01-02 00:28:21 <BlueMatt> luke-jr: not true...
 13 2012-01-02 00:28:34 <luke-jr> BlueMatt: yes true
 14 2012-01-02 00:30:44 <midnightmagic> wumpus: coderrr requested people +1 it in the bitcointalk thread. This suggests that posted support is meaningful to him. As much as people think comments should have a constructive purpose, making people know others value the effort they put into a pull request seems valid to me.
 15 2012-01-02 00:31:13 <BlueMatt> midnightmagic: coderrr clearly knows there is support there, from the bitcointalk thread and his blog
 16 2012-01-02 00:31:47 <BlueMatt> midnightmagic: posting +1s on github is obnoxious, a waste of time, and just distracts people who are actually trying to provide useful feedback on the pull request
 17 2012-01-02 00:33:01 <midnightmagic> BlueMatt: Uh..  you also seem to be in the dark about why people are +1'ing it. coderrr hasn't updated his blog to remove the "+1" requests yet. http://coderrr.wordpress.com/2011/06/30/patching-the-bitcoin-client-to-make-it-more-anonymous/
 18 2012-01-02 00:33:38 <BlueMatt> midnightmagic: I dont care if he has removed it, its a waste of your time, my time, coderrr's time and everyone else's time
 19 2012-01-02 00:33:46 <BlueMatt> its also obnoxious and annoying
 20 2012-01-02 00:33:50 <midnightmagic> BlueMatt: And, I thought it would be worthwhile to point out that a LOT more eyes are on it after the endless strawmen criticisms in 28c3
 21 2012-01-02 00:34:21 <BlueMatt> were there any links to that pull at 28c3?
 22 2012-01-02 00:35:02 <midnightmagic> BlueMatt: You have stated that how bitcoin is perceived is important. That pull request is directly addressing one of the main anonymity criticisms at the..  5 or so talks @ 28c3 that mentioned it. Some of them really obnoxiously, I might add.
 23 2012-01-02 00:35:08 <BlueMatt> not many security researchers care to research pull requests
 24 2012-01-02 00:35:27 <kiba``> midnightmagic: what pull?
 25 2012-01-02 00:35:34 <BlueMatt> the main client's goal is NOT to make bitcoin anonymous, nor does that pull solve the problems
 26 2012-01-02 00:35:36 <midnightmagic> #415
 27 2012-01-02 00:36:02 <BlueMatt> its cool because it allows people to control their coins more, but it doesnt make people anonymous, nor does it allow them to be
 28 2012-01-02 00:36:08 <BlueMatt> bitcoin isnt anonymous
 29 2012-01-02 00:36:19 <BlueMatt> sorry, get over it
 30 2012-01-02 00:36:40 <midnightmagic> lol you don't need to tell me such things about bitcoin, I'm well aware.
 31 2012-01-02 00:36:43 <sipa> anonymity is the only way bitcoin has to protect privacy
 32 2012-01-02 00:37:12 <BlueMatt> ok, so why are you saying that 415 solves the criticism's of bitcoin's anonymity at 28c3?
 33 2012-01-02 00:37:19 <midnightmagic> BUT, to be able to explicitly mitigate the auto address selector algorithms willingness to aggregate data..  it does solve that problem.
 34 2012-01-02 00:38:13 <sipa> BlueMatt: seen bitcoin-seeder?
 35 2012-01-02 00:38:32 <BlueMatt> sipa: its on my list of things to checkout (and probably replace the dnsseeder on dnsseed.bluematt.me)
 36 2012-01-02 00:38:45 <sipa> hehe
 37 2012-01-02 00:39:12 <BlueMatt> sipa: well-written program is always > something thrown together to work, but not much else
 38 2012-01-02 00:39:29 <sipa> it still needs a lot of work :)
 39 2012-01-02 00:39:52 <BlueMatt> sipa: heh, probably still better than dnsseed...
 40 2012-01-02 00:39:59 <BlueMatt> luke-jr: what bug?
 41 2012-01-02 00:40:02 <midnightmagic> seriously, I don't want that stupid little 1BTC that BTC-Bear sent me 6 months ago to permanently contaminate my shit, regardless of all the pristine coins I make as a miner. :)
 42 2012-01-02 00:40:15 <luke-jr> BlueMatt: miners can add arbitrary data to any transaction, changing their txnid
 43 2012-01-02 00:40:20 <sipa> midnightmagic: that is a very reasonable request
 44 2012-01-02 00:40:33 <BlueMatt> luke-jr: ok...but then the sig becomes invalid, correct?
 45 2012-01-02 00:40:57 <luke-jr> BlueMatt: nope
 46 2012-01-02 00:41:15 <sipa> luke-jr: really?
 47 2012-01-02 00:41:23 <BlueMatt> luke-jr: well you cant change the outputs w/o making sigs invalid...
 48 2012-01-02 00:41:27 <midnightmagic> sipa: Thank you.
 49 2012-01-02 00:41:34 <luke-jr> so long as the extra data is part of the sig area&
 50 2012-01-02 00:41:39 <BlueMatt> midnightmagic: still, arguing that that is the most important thing in bitcoin is just wrong...
 51 2012-01-02 00:41:43 <luke-jr> sig can't sign itself
 52 2012-01-02 00:42:04 <BlueMatt> midnightmagic: I never said that the pull shouldnt be looked at/pulled
 53 2012-01-02 00:42:12 <BlueMatt> midnightmagic: I said +1ing is a waste of everyone's time
 54 2012-01-02 00:42:32 <BlueMatt> luke-jr: have you tested that?
 55 2012-01-02 00:42:57 <luke-jr> BlueMatt: would you like me to?
 56 2012-01-02 00:43:00 <luke-jr> :p
 57 2012-01-02 00:43:06 <sipa> luke-jr: on testnet, yes
 58 2012-01-02 00:43:10 <BlueMatt> luke-jr: not on mainnet, but on testnet
 59 2012-01-02 00:43:11 <luke-jr> that's boring tho
 60 2012-01-02 00:43:17 <luke-jr> plus, I have no miner
 61 2012-01-02 00:43:23 <BlueMatt> luke-jr: testnet exists for a reason
 62 2012-01-02 00:43:33 <midnightmagic> BlueMatt: Oh, goodness, no, I don't mean to imply that it's the *most* important. No need to read into my terseness.. I'm just saying those peeps talking out their ass at 28c3 need an answer.
 63 2012-01-02 00:44:03 <luke-jr> midnightmagic: the answer is "it looks like there's anonymity attempts, because it's supposed to have some degree of PRIVACY"
 64 2012-01-02 00:44:11 <BlueMatt> midnightmagic: fair enough, but again +1ing is a waste and is just annoying as fuck
 65 2012-01-02 00:46:51 <luke-jr> atomic?
 66 2012-01-02 00:47:15 <sipa> atomic, indeed
 67 2012-01-02 00:53:33 <gmaxwell> The current coin selection is dumb in general.
 68 2012-01-02 00:53:58 <gmaxwell> For example, and more importantly I think, it will result in needless fees because its basically blind to fees.
 69 2012-01-02 00:54:25 <BlueMatt> luke-jr: sipa thanks, Im a dumbass for some reason today...
 70 2012-01-02 00:54:32 <gmaxwell> It's possible that improvements to it would also allow it to improve privacy for cases where doing some doesn't bother the other selection criteria.
 71 2012-01-02 00:56:41 <gmaxwell> I think both would be independantly good.
 72 2012-01-02 00:56:54 <sipa> exactly, the pull req is nice, but not a solution for most users
 73 2012-01-02 00:57:08 <sipa> there are other nice things that can be done to improve privacy, by the way
 74 2012-01-02 00:57:16 <sipa> such as creating more than one change txout
 75 2012-01-02 00:57:29 <gmaxwell> also, auto-sweeping dust.
 76 2012-01-02 00:57:49 <sipa> if you see a tx splitting 28.23 into 25.00 and 5.23, you can be pretty sure the 5.23 is change
 77 2012-01-02 00:57:50 <gmaxwell> Right now jagged change makes a lot of chainge inevitable.
 78 2012-01-02 00:58:01 <sipa> 3.23 that is
 79 2012-01-02 00:58:05 <gmaxwell> er. sorry, spliced spoken and written conversation.
 80 2012-01-02 00:58:12 <coderrr> sipa, i was thinking about that, if you have more than one change out, you actually increase the chances of guessing whcih is change
 81 2012-01-02 00:58:15 <gmaxwell> jagged change makes a lot of change identifyable.
 82 2012-01-02 00:58:34 <coderrr> if there are 3 outs instead of 2, 66% chance that any out is change, rather than 50%
 83 2012-01-02 00:58:47 <gmaxwell> e.g. you have a 1.234567 input ... almost any spend you do for that is going to identify the change.
 84 2012-01-02 00:58:48 <sipa> coderrr: what if it were a 25.00 out, a 2.00 change and a 1.23 out?
 85 2012-01-02 00:58:56 <sipa> coderrr: would the 25 or the 2 be change?
 86 2012-01-02 00:59:09 <coderrr> but yea gets complicated when you take into acct the diffenret amounts
 87 2012-01-02 00:59:16 <sipa> i've been thinking about an algorithm to create outputs that "look" like the real output
 88 2012-01-02 00:59:34 <coderrr> exactly, it becomes a battle
 89 2012-01-02 00:59:44 <sipa> it's only a heuristic of course
 90 2012-01-02 01:00:02 <sipa> but if all clients everywhere were doing something like it, things would become a lot harder to trace, imho
 91 2012-01-02 01:00:13 <coderrr> yea could be
 92 2012-01-02 01:00:47 <gmaxwell> You can often costlessly add additional inputs to txn to sweep up jaggedness though. I can't come up with a good heuristic over when to decide not to do so though.. I was thinking about some kind of size-histrogram (e.g. keep at least one input of each size).. but it goes arm wavy fast.
 93 2012-01-02 01:02:47 <gmaxwell> A stupid feature that would probably help privacy is to have a way of telling it "Round up this payment to avoid change" e.g. pay someone "49.12+1" and it sends some amount between 49.12 and 50.12 .. as is required to make a better coin selection.
 94 2012-01-02 01:03:11 <gmaxwell> that kind of rounded up payment is pretty handy if you're paying into something that is just an online account of your own. (e.g. mtgox)
 95 2012-01-02 01:03:59 <sipa> coderrr: to be honest, it's not my own idea, but one by satoshi, in a mail forwarded to me by Gavin :)
 96 2012-01-02 01:05:08 <CIA-100> bitcoin: Luke Dashjr blknotify * r7546ad986fc2 bitcoind-personal/src/ (init.cpp main.cpp): Execute a command when best block changes (-blocknotify=<cmd>) http://tinyurl.com/8xsymgd
 97 2012-01-02 01:14:06 <luke-jr> sipa: think this is in your "pull area"? https://github.com/bitcoin/bitcoin/pull/570
 98 2012-01-02 01:15:32 <sipa> luke-jr: i'll ack something like that as soon as there is a way to reverse a transaction in the client that doesn't seem to get accepted
 99 2012-01-02 01:16:20 <luke-jr> sipa: there's a reason the force parameter requires -nosafefees and that parameter is undocumented ;)
100 2012-01-02 01:16:33 <luke-jr> sipa: and it IS useful even without -nosafefees
101 2012-01-02 01:16:41 <sipa> it is useful
102 2012-01-02 01:16:43 <sipa> and dangerous
103 2012-01-02 01:17:01 <luke-jr> not without the undocumented cmdline option, no
104 2012-01-02 01:17:38 <BlueMatt> luke-jr: I wrote a much less intrusive, more strongly worded, and more descriptive version a long time ago...
105 2012-01-02 01:18:09 <luke-jr> BlueMatt: I must have missed the pull request for that. In any case, this one is up to date.
106 2012-01-02 01:18:21 <luke-jr> and supports multiple behaviours people want and need
107 2012-01-02 01:18:35 <BlueMatt> but I agree with sipa/gavin/etc
108 2012-01-02 01:18:37 <luke-jr> including the common "I'd rather get an error than include the fees automatically"
109 2012-01-02 01:18:44 <BlueMatt> shouldnt not be considered for pull until it is safe
110 2012-01-02 01:18:49 <luke-jr> it is safe by default.
111 2012-01-02 01:19:00 <BlueMatt> there shouldnt be unsafe options
112 2012-01-02 01:19:08 <luke-jr> there's always unsafe options.
113 2012-01-02 01:19:31 <BlueMatt> undocumented or otherwise, because you know there will be 1000 forum threads that say "JUST LAUNCH BITCOIN WITH -killme TO NEVER PAY FEES!!!!!111one"
114 2012-01-02 01:19:57 <luke-jr> would it be better if I changed it to -nosafefees='I understand this will break my transactions unless I am a miner' ?
115 2012-01-02 01:20:13 <luke-jr> sipa: ^
116 2012-01-02 01:21:47 <sipa> luke-jr: not necessary, i consider it a useful option, but please let us have a way to detect rejected transactions before we allow it
117 2012-01-02 01:22:00 <sipa> (i was planning on implementing that soon)
118 2012-01-02 01:22:20 <luke-jr> sipa: so, how about I put an "#if 0" around the force-enable bit?
119 2012-01-02 01:22:30 <luke-jr> or you mean before 0.6 closes?
120 2012-01-02 01:22:51 <sipa> i hope before 0.6 closes, yes, but it may be a close call
121 2012-01-02 01:23:55 <luke-jr> sipa: will you merge that pull if I "#if 0" out the -nosafefees?
122 2012-01-02 01:24:26 <sipa> what's the point then?
123 2012-01-02 01:24:59 <luke-jr> like I said, it's highly useful even without that function
124 2012-01-02 01:25:36 <luke-jr> by default, it means you'll get an error before a fee over 0.01 BTC is paid rather than automatically paying a (eg) 1 BTC fee without confirmation
125 2012-01-02 01:25:45 <luke-jr> 'maxtxfee' can be then raised to allow it
126 2012-01-02 01:26:00 <luke-jr> or people can set 'maxtxfee' to 0 to never auto-pay fees, and always get an error
127 2012-01-02 01:31:24 <sipa> luke-jr: it also modifies the priority algorithm for your own transactions?
128 2012-01-02 01:32:09 <luke-jr> sipa: is there a reason not to?
129 2012-01-02 01:32:58 <sipa> i don't see a reason for not doing that, but it should be documented
130 2012-01-02 01:33:09 <luke-jr> if someone is mining, they'll probably be pretty ticked off if they find a block and don't get all their txns confirmed :P
131 2012-01-02 01:33:18 <luke-jr> none of the priority stuff is documented right now afaik
132 2012-01-02 01:33:26 <luke-jr> maybe on the wiki, which shouldn't be updated until merge IMO
133 2012-01-02 01:33:42 <sipa> right
134 2012-01-02 01:33:49 <sipa> ok, in CreateTransaction
135 2012-01-02 01:34:02 <luke-jr> ?
136 2012-01-02 01:34:15 <luke-jr> oh, you mean add a comment?
137 2012-01-02 01:34:55 <sipa> when creating/increasing fee, you moved the check for < MIN_TX_FEE down
138 2012-01-02 01:34:58 <sipa> into a min
139 2012-01-02 01:37:05 <luke-jr> because MIN_TX_FEE is only applicable if it's under nMaxFee
140 2012-01-02 01:37:18 <luke-jr> otherwise, the user will get an error (or force it)
141 2012-01-02 01:37:38 <sipa> wouldn't that make it possible to cause it to raise the fee a bit, but less than the assumed required fee
142 2012-01-02 01:37:42 <sipa> and have it accepted still?
143 2012-01-02 01:37:56 <sipa> (without the -nosafefees)
144 2012-01-02 01:38:11 <luke-jr> hmm
145 2012-01-02 01:38:38 <luke-jr> I don't *think* so&
146 2012-01-02 01:38:57 <sipa> you may be right, there could be another check further on
147 2012-01-02 01:39:29 <luke-jr> that code there only special-cases deciding whether to move the change to fee or leave it as change
148 2012-01-02 01:44:42 <luke-jr> ah right
149 2012-01-02 01:44:52 <luke-jr> nMaxFee is a strict cap on the fee in CreateTransaction
150 2012-01-02 01:45:07 <luke-jr> but the JSON-RPC sets nMaxFee to MAX_MONEY without fForceFee
151 2012-01-02 01:45:16 <sipa> i see
152 2012-01-02 01:45:19 <luke-jr> (.h default is also MAX_MONEY)
153 2012-01-02 01:53:34 <luke-jr> sipa: so& do I "#if 0" out -nosafefees to get it merged? :P
154 2012-01-02 01:55:00 <sipa> i don't decide that alone - i'd rather wait until transaction rejection is there
155 2012-01-02 01:55:21 <luke-jr> night
156 2012-01-02 01:55:30 <luke-jr> I'll leave it as-is for now then
157 2012-01-02 03:21:51 <coderrr> is this a bug? https://gist.github.com/1549331  should be  HaveKeys(keys, keystore);
158 2012-01-02 03:22:20 <coderrr> or should taht keys line be removed?
159 2012-01-02 03:39:08 <coderrr> im assuming that's to skip the m and n integers at the beginning and end of multisig, but wouldn't that mean vSolutions.size()-2 instead of -1 ?
160 2012-01-02 03:55:47 <midnightmagic> coderrr: one line or the other looks like it must be buggy unless i am not grasping the scope of keys()
161 2012-01-02 03:55:58 <coderrr> yep
162 2012-01-02 03:56:58 <midnightmagic> there are some of those kinds of problems in namecoind: prep up some data, and then not use it in the following function calls.
163 2012-01-02 03:57:28 <midnightmagic> something just like that is actually the reason why the base namecoind thinks lots of names are expired right now but they really aren't
164 2012-01-02 05:18:19 <BlueMatt> sipa: ping
165 2012-01-02 05:18:25 <BlueMatt> ;;seen sipa
166 2012-01-02 05:18:26 <gribble> sipa was last seen in #bitcoin-dev 3 hours, 23 minutes, and 8 seconds ago: * sipa needs sleep now
167 2012-01-02 05:18:36 <BlueMatt> arg, why are people always going to sleep???
168 2012-01-02 05:22:41 <BlueMatt> ;;bc,blocks
169 2012-01-02 05:22:42 <gribble> 160220
170 2012-01-02 05:24:12 <cjdelisle> heh
171 2012-01-02 05:25:07 <justmoon> BlueMatt: sleep... right I knew there was something I forgot to do
172 2012-01-02 05:48:48 <luke-jr> BlueMatt: you miss the part about nobody having any real incentive to implementing txn replacement/"upgrading"
173 2012-01-02 05:49:24 <luke-jr> whereas it's cheap to use power tools wisely :P
174 2012-01-02 05:53:23 <coderrr> BlueMatt, you see that bug i posted above?
175 2012-01-02 05:55:34 <BlueMatt> coderrr: yea, didnt look into it though...
176 2012-01-02 05:56:00 <BlueMatt> luke-jr: I think I need to coin  a saying about bitcoin-dev "All talk, no work"
177 2012-01-02 05:56:03 <BlueMatt> or something like that
178 2012-01-02 05:56:11 <BlueMatt> no one wants to do the real work
179 2012-01-02 05:56:17 <coderrr> k, just trying to figure out if im missing something, it seems that comment is lying too, and it only checks if you own at least one key
180 2012-01-02 05:56:32 <BlueMatt> coderrr: forward it to the git blame culprit
181 2012-01-02 05:56:44 <coderrr> lol k, good plan
182 2012-01-02 05:56:45 <BlueMatt> (probably gavin, didnt he write CHECKMULTISIG)?
183 2012-01-02 05:57:23 <coderrr> indeed, gavin it is
184 2012-01-02 06:50:04 <amiller> hey has there been any work on bitcoin transactions with an expiration
185 2012-01-02 06:50:10 <amiller> measured for example in numbers of blocks
186 2012-01-02 06:51:20 <amiller> for example a tx:output that can only be spent using pubKeyA within 100 blocks of the block containing the tx itself, and only to pubKeyB after that?
187 2012-01-02 06:51:44 <amiller> i guess namecoin does that
188 2012-01-02 06:54:29 <JZavala> what is a namecoin...
189 2012-01-02 06:58:26 <amiller> i would think there could be something like OP_INPUTBLOCK and OP_CURRENTBLOCK
190 2012-01-02 06:58:37 <amiller> and you could subtract them and compare them to a threshold
191 2012-01-02 07:42:36 <amiller> actually i have a more general question as well...
192 2012-01-02 07:43:18 <amiller> is it possible to create a bitcoin transaction that restricts how it can be spent in the NEXT transaction?
193 2012-01-02 07:44:36 <amiller> that is, a scriptPubKey that restricts not just the scriptSig in the transaction that spends it, but also the scriptPubKeys in the outputs of that transaction?
194 2012-01-02 08:12:09 <edcba> amiller: what do you want to achieve ?
195 2012-01-02 08:12:23 <phantomcircuit> amiller, no
196 2012-01-02 08:12:30 <phantomcircuit> amiller, well yes and no
197 2012-01-02 08:12:50 <phantomcircuit> but mostly no
198 2012-01-02 08:15:18 <amiller> edcba, as a simple example, suppose i want to give 10 BTC to someone so that they can either donate it to EFF, or to Tahoe-LAFS, but those are their only options
199 2012-01-02 08:16:30 <amiller> phantomcircuit, how so?
200 2012-01-02 08:17:01 <phantomcircuit> well you could sign it with your own key
201 2012-01-02 08:17:13 <phantomcircuit> then sign the transaction yourself on request
202 2012-01-02 08:17:37 <phantomcircuit> amiller, you might as well just donate yourself ;)
203 2012-01-02 08:18:26 <amiller> okay the practical application i really want has a few more components than the simple examples i gave
204 2012-01-02 08:19:04 <amiller> but the important part is that i'd like to be able to see in the block chain that the constraint is there
205 2012-01-02 08:19:27 <phantomcircuit> then no
206 2012-01-02 08:20:10 <amiller> i see
207 2012-01-02 08:20:14 <amiller> that's too bad
208 2012-01-02 08:21:15 <forrestv> amiller, just give the recipient two already-signed transactions donating to either organization
209 2012-01-02 08:21:18 <amiller> some other things you could do with that: you could spend a bitcoin with a blacklist address, so that its value can never be sent to a particular address you dislike but otherwise can be spent as normal
210 2012-01-02 08:21:35 <amiller> forrestv, the problem with that is i can't "promise" that the transaction will only go to those two organizations
211 2012-01-02 08:22:01 <amiller> because i could always just sign my own third transaction that goes back to me and submit it to the blockchain before the other guy gets a chance to decide
212 2012-01-02 08:22:16 <forrestv> would the blacklist address propagate to other transactions? there isn't much point otherwise
213 2012-01-02 08:22:31 <amiller> yeah i suppose the blacklist idea would require the constraint to apply recursively
214 2012-01-02 08:22:34 <forrestv> and that problem could be solved by requiring the recepient's signature too
215 2012-01-02 08:22:35 <edcba> amiller: blacklist won't work
216 2012-01-02 08:22:40 <edcba> just use a temp addr
217 2012-01-02 08:22:49 <edcba> then constraint doesn't exist anymore
218 2012-01-02 08:22:58 <edcba> oops
219 2012-01-02 08:23:00 <forrestv> recipient*
220 2012-01-02 08:23:03 <edcba> too late :)
221 2012-01-02 08:23:33 <amiller> forrestv, i want the "promise" not just to be between me and the recipient, but to the public in general
222 2012-01-02 08:23:36 <edcba> anyway an address is different from a person
223 2012-01-02 08:23:48 <edcba> so blacklisting is quite difficult
224 2012-01-02 08:24:00 <amiller> yeah i don't see it as terribly useful
225 2012-01-02 08:24:28 <edcba> i'd prefer some scheme to combine transactions in order to be in a block
226 2012-01-02 08:24:36 <amiller> well, i might as well describe the useful application i have in mind
227 2012-01-02 08:24:47 <amiller> i'd like to be able to post 'double-spend collateral' for a green address
228 2012-01-02 08:25:36 <amiller> where i say here's 500 BTC, the only way it can be spent is if someone provides evidence that i double spent in some other transaction, by including in the scriptSig two different signed transactions with a common input
229 2012-01-02 08:25:53 <edcba> hmm
230 2012-01-02 08:26:18 <amiller> but the collateral is only good if it's publicly verifiable that I can't just spend it back to myself
231 2012-01-02 08:26:33 <edcba> ok
232 2012-01-02 08:27:01 <edcba> but how some guy can verify the green address is not you again ?
233 2012-01-02 08:28:31 <amiller> what i would say is something like, here's 500 btc, 250 goes to a miner fee, 250 gets destroyed forever, and for this tx to be valid it needs to contain a <serialized txA> <serialized txB> <sigA> <sigB>
234 2012-01-02 08:28:31 <cjdelisle> I would think there should be a multisig trick where ((john && taho) || (john && eff)) can sign for it
235 2012-01-02 08:29:23 <cjdelisle> it seems possible using OP_IF and OP_MULTISIG
236 2012-01-02 08:29:55 <forrestv> amiller, why not just destroy it all forever right now?
237 2012-01-02 08:29:57 <amiller> where the txA and the txB contain some common string and the sigA and sigB match the corresponding serialized txs
238 2012-01-02 08:30:26 <amiller> forrestv, because until it gets spent, there is a 250btc incentive for miners to try to catch me if i double spend
239 2012-01-02 08:30:37 <amiller> that's why it would function as collateral
240 2012-01-02 08:31:20 <cjdelisle> redesigning anti-doublespend over again strikes me as a bad plan
241 2012-01-02 08:32:07 <amiller> it should be an improvement over 'green addresses' the way they are now
242 2012-01-02 08:32:16 <forrestv> cjdelisle, what existing anti-doublespend method are you referring to?
243 2012-01-02 08:33:00 <cjdelisle> hmm just the block chain synchronization stuff
244 2012-01-02 08:33:22 <cjdelisle> I gather this is wandering into area not protected by that
245 2012-01-02 08:33:46 <cjdelisle> and that sounds like a recipe for embarassement
246 2012-01-02 08:33:51 <amiller> so the value of green addresses is that if you trust a third party never to double spend, then you don't have to wait for the blockchain to settle and you can accept payment immediately
247 2012-01-02 08:34:36 <forrestv> cjdelisle, we're talking about methods to make 0-confirmation transactions trustworthy
248 2012-01-02 08:35:51 <cjdelisle> just detect doublespends IMO
249 2012-01-02 08:36:05 <cjdelisle> it only takes a few seconds for the whole network to see your tx
250 2012-01-02 08:36:25 <cjdelisle> and at that point doublespending attacks are not very effective
251 2012-01-02 08:37:37 <cjdelisle> if tycho and slush were to add a bots like luke's which read off transactions as they were discovered and validated, you could wait until the 3 validated a transaction and unless you're dealing with hundreds of btc, nothing to worry about
252 2012-01-02 08:38:13 <forrestv> cjdelisle, in response to your first idea, nodes don't forward a transaction if it conflicts with an already-received one
253 2012-01-02 08:38:53 <forrestv> so a node might not see both, unless it were on the edge between the two parts of the network that heard either transaction first
254 2012-01-02 08:39:07 <cjdelisle> don't have to see both
255 2012-01-02 08:39:21 <cjdelisle> just have to see that the major pools all saw yours and didn't drop it
256 2012-01-02 08:41:05 <amiller> so some of sipa's script extension proposal sort of involves parsing the current transaction
257 2012-01-02 08:41:06 <amiller> https://gist.github.com/1262449
258 2012-01-02 08:41:25 <amiller> OP_TXHASH specifically
259 2012-01-02 08:42:49 <amiller> so i could imagine an op like OP_OUTPUT1 that puts a serialized version of the first tx:output <scriptpubkey> and <amount> on the stack
260 2012-01-02 08:46:46 <forrestv> amiller, your idea is still vulnerable to a kind of finney attack, where you're constantly mining for a block that gets your deposit back
261 2012-01-02 08:47:31 <forrestv> in addition to containing the double-spend transaction
262 2012-01-02 08:50:38 <amiller> yeah
263 2012-01-02 08:51:22 <amiller> so in my example the collateral is 250 btc that is guaranteed to destroyed, there's no way to get it back even if you mine and try a finney attack
264 2012-01-02 08:51:52 <amiller> the additional 250 btc that goes to the miner as an incentive you could get back if you mine your own blocks with your own double spends in it
265 2012-01-02 08:52:20 <amiller> if we could rely on the expiration time then another way it could work is
266 2012-01-02 08:52:56 <amiller> the collateral gets destroyed when a double spend is detected, unless a year's worth of blocks go by and then you can get your deposit back
267 2012-01-02 08:57:17 <forrestv> ah
268 2012-01-02 12:08:09 <justmoon> roconnor: got three bullet points on static analysis, see if you can add any: http://piratepad.net/E8AEAQJUw7
269 2012-01-02 12:13:05 <roconnor> thanks
270 2012-01-02 12:13:29 <roconnor> justmoon: BTW, I don't think I buy luke-jr's attack as I understood it from your description
271 2012-01-02 12:14:00 <roconnor> justmoon: in order to build an attack block the attacker has to perform sufficent proof of work, which by its nature is expensive on average.
272 2012-01-02 12:14:48 <roconnor> justmoon: such a block has to be atop the current chain otherwise a smart client could delay processing it until it is part of a most-difficult chain.
273 2012-01-02 12:15:27 <roconnor> justmoon: and if the block is invalid the attack window is about 10 minutes on average.
274 2012-01-02 12:15:52 <sipa> roconnor: an attacker wishing to create a block with an invalid transaction in currently needs the same
275 2012-01-02 12:16:49 <roconnor> sipa: an attacker only needs to create an invalid transaction; not an invalid block
276 2012-01-02 12:17:00 <sipa> those will not pass IsStandard()
277 2012-01-02 12:17:03 <sipa> roconnor: however, if IsStandard() is removed (or miners use their own rules), it may be possible to let them check pathological scripts
278 2012-01-02 12:18:27 <sipa> justmoon: nice summary, by the way
279 2012-01-02 12:18:45 <roconnor> sipa: what are you thinking?
280 2012-01-02 12:18:48 <roconnor> er
281 2012-01-02 12:18:52 <roconnor> that came out badly
282 2012-01-02 12:19:05 <roconnor> sipa: what are you thinking when you say " it may be possible to let them check pathological scripts" ?
283 2012-01-02 12:21:09 <sipa> right now, miners will not accept non-standard transactions into their memory pool
284 2012-01-02 12:21:21 <sipa> (or those who do are at their own risk)
285 2012-01-02 12:23:10 <sipa> so if you create a script such as described in justmoon's text, with the intention of DoS'ing a node, it will not be executed unless it is in a block
286 2012-01-02 12:23:19 <roconnor> sipa: what about miners who charge their fees based on the number of OP_CHECKSIGs and OP_MULTICHECKSIGs?
287 2012-01-02 12:23:26 <jgarzik> luke-jr: for what do you wait?
288 2012-01-02 12:24:20 <sipa> roconnor: all i'm saying is that with IsStandard() in place, in one form or another, there is no problem
289 2012-01-02 12:25:18 <sipa> however, i'm in favor of removing or at least weakening that check over time
290 2012-01-02 12:25:24 <roconnor> sipa: I don't think that was luke-jr's argument.
291 2012-01-02 12:25:48 <roconnor> sipa: afterall IsStandard() is simply a form of static analysis; one that does happen to work in the presence of OP_EVAL.
292 2012-01-02 12:25:58 <sipa> true
293 2012-01-02 12:26:09 <sipa> i'm not sure what you're saying now
294 2012-01-02 12:26:19 <sipa> or what we're discussing
295 2012-01-02 12:27:50 <sipa> justmoon mentions that there is a equally bad attack, namely a large block with a bad tx at the end; you answer that it is not the same, as a pathological script will cause havoc by just producing a script, while luke's attack requires a proof-of-work; i claim that with IsStandard() in place, a pathological script that is not in a block will not cause harm either as it is discarded before entering the memory pool
296 2012-01-02 12:28:45 <makomk> coderrr: I actually noticed in my own testing that it seemed to treat multi-sig transactions where you only have one key and more are required as yours, come to think of it.
297 2012-01-02 12:30:20 <roconnor> sipa: yes, but that argument applies only to standard miners.  There are other non-standard miners and I think it would be a mistake to not give them consideration when ammending the protocol.  Otherwise you should be ammending the protocol to fail with any non-standard transaction.
298 2012-01-02 12:30:36 <sipa> roconnor: yes, absolutely
299 2012-01-02 12:34:03 <justmoon> sipa: is it safe to assume that we will never ever want to accept non-standard transactions into the memory pool?
300 2012-01-02 12:34:11 <sipa> no
301 2012-01-02 12:34:17 <justmoon> sipa: maybe that's a very strong argument for statis analysis actually
302 2012-01-02 12:34:33 <justmoon> i.e. static analysis allows to define rules for semi-standard transactions in the future
303 2012-01-02 12:34:42 <sipa> well, imho a miner decides what he accepts into his pool
304 2012-01-02 12:35:14 <justmoon> right, but say we want to allow arbitrary scripts as standard, but disable specific op codes
305 2012-01-02 12:35:17 <sipa> but if we cannot guarantee safe runtime behaviour at the network rule level, you shift responsibility for only allowing sane scripts to the miner
306 2012-01-02 12:35:23 <sipa> and that is probably not the best solution
307 2012-01-02 12:36:12 <justmoon> sipa: are you agreeing or disagreeing with me right now? ^^
308 2012-01-02 12:36:22 <genjix> justmoon & sipa, how were those times? we might have to adjust them so tell me what works best for both of you
309 2012-01-02 12:36:28 <genjix> especially if it becomes a regular thing
310 2012-01-02 12:36:55 <sipa> tuesday around midnight is fine for me, genjix
311 2012-01-02 12:37:12 <sipa> justmoon: i'm agreeing i think :)
312 2012-01-02 12:37:22 <justmoon> genjix: I can't do regular anything, sorry - I can pop in to meetings if I happen to be on, that's it - but you don't need me anyway, I don't usually care about the original client too much :P
313 2012-01-02 12:37:48 <genjix> justmoon: well it's not about the original client, just 'things'
314 2012-01-02 12:38:10 <justmoon> genjix: well, the only I would care about is blockchain-level changes and hopefully we won't do those every week
315 2012-01-02 12:38:16 <justmoon> only thing*
316 2012-01-02 12:38:50 <justmoon> although we may have to do them every week if we prematurely launch OP_EVAL </sarcasm>
317 2012-01-02 12:38:51 <genjix> ok but you'd be surprised what having a regular communication could do. simply discussing ideas and stuff
318 2012-01-02 12:39:20 <justmoon> yes, yes, I'll see what I can do, now bugger off ;)
319 2012-01-02 12:39:32 <justmoon> thanks for organizing it though :)
320 2012-01-02 12:40:44 <roconnor> justmoon: I added a bullet
321 2012-01-02 12:41:13 <justmoon> roconnor: thanks!
322 2012-01-02 12:47:34 <justmoon> sipa, roconnor: so, where does this line of argument lead us: "Suppose we want to one day allow arbitrary scripts as IsStandard, but put constraints on the maximum count of certain opcodes and on which opcodes are allowed. If we want to include OP_EVAL in the set of allowed opcodes in that case it's important that OP_EVAL is implemented in a way that allows static analysis. If proponents of the current implementation want to argue that we don
323 2012-01-02 12:47:35 <justmoon> 't need static analysis now, the burden is on them to show how we could retrofit it when/if we get to this point or why they think we will never want to allow some freedom in IsStandard that includes OP_EVAL."
324 2012-01-02 13:02:49 <sipa> justmoon: pretty good argument, i'd say
325 2012-01-02 13:03:14 <sipa> in favor of static analysis
326 2012-01-02 13:03:18 <justmoon> sipa: k, can you check the list for static analysis proposal and see if I missed any?
327 2012-01-02 13:03:21 <justmoon> http://piratepad.net/E8AEAQJUw7
328 2012-01-02 13:03:31 <justmoon> or misattributed any, etc.
329 2012-01-02 13:05:54 <sipa> justmoon: i believe i mentioned that a dry run cannot predict the outcome of a checksig
330 2012-01-02 13:06:35 <justmoon> sipa: you mean you were the first?
331 2012-01-02 13:07:03 <justmoon> yep, you were
332 2012-01-02 13:07:22 <sipa> i think so, but you had an example to prove the potential exponential behaviour
333 2012-01-02 13:07:58 <justmoon> yep, I checked, you were the first :)
334 2012-01-02 13:08:04 <justmoon> credit where credit is due :D
335 2012-01-02 13:09:03 <sipa> anyway, i'll elaborate the fixed position prefix idea and send it to the mailinglist
336 2012-01-02 13:09:23 <justmoon> very good - did I miss any promising proposal that we know about?
337 2012-01-02 13:09:34 <justmoon> I got a list of four at the bottom right now
338 2012-01-02 13:10:09 <sipa> i don't know any other that allow analyysis
339 2012-01-02 13:10:25 <genjix> yay for the victory of static analysis over dry runs
340 2012-01-02 13:11:45 <justmoon> I'm not going too declare victory yet, if working on bitcoin has taught me anything, it's that I know nothing about anything until I post it to mailing list and someone completely take it apart :D
341 2012-01-02 13:11:48 <justmoon> takes*
342 2012-01-02 13:14:50 <jeremias> :D
343 2012-01-02 13:14:56 <jeremias> pretty good description
344 2012-01-02 13:15:06 <justmoon> thanks :)
345 2012-01-02 13:15:32 <justmoon> oh wait, were you talking about my OP_EVAL summary or my mailing list humility comment? :D
346 2012-01-02 13:20:57 <justmoon> hmm, should I use nicknames or real names in the summary btw?
347 2012-01-02 13:21:26 <justmoon> I'll probably leave it at nicknames
348 2012-01-02 13:23:07 <roconnor> justmoon: honestly I don't really know people's real names, so I'd find it more confusing to use them :D
349 2012-01-02 13:23:34 <justmoon> hi I'm Stefan :D
350 2012-01-02 13:23:37 <justmoon> :P
351 2012-01-02 13:23:45 <roconnor> :D
352 2012-01-02 13:23:48 <roconnor> I'm roconnor
353 2012-01-02 13:24:02 <justmoon> lol
354 2012-01-02 13:24:16 <justmoon> ok, point taken, I'll leave it at nicks
355 2012-01-02 13:25:03 <mcorlett> justmoon: You're the Stefan Thomas from the Bittalk.tv thing?
356 2012-01-02 13:25:13 <justmoon> the same, yep
357 2012-01-02 13:25:35 <justmoon> sipa: there are 150 Stefan Thomases on facebook
358 2012-01-02 13:25:51 <justmoon> in fact there is a facebook group for stefan thomases
359 2012-01-02 13:25:57 <mcorlett> sipa: He only mentioned his first name, wise guy!
360 2012-01-02 13:26:00 <roconnor> justmoon: BTW, do you know what the point of OP_IFDUP is?
361 2012-01-02 13:26:13 <sipa> mcorlett: dang!
362 2012-01-02 13:26:25 <justmoon> mcorlett: my forum nick is "Stefan Thomas" with a description of "aka justmoon" :D
363 2012-01-02 13:26:38 <roconnor> justmoon: it is one of the few (only) operations that doesn't statically change the size of the stack.
364 2012-01-02 13:26:41 <sipa> ok, i still don't know any other Stefan involved in Bitcoin, but maybe I don't know that many real names either
365 2012-01-02 13:26:57 <roconnor> oh right and OP_MULTISIGCHECK
366 2012-01-02 13:27:07 <roconnor> damn
367 2012-01-02 13:27:13 <sipa> I'm quite sure that there were people at the conference I knew online, not recognizing them IRL
368 2012-01-02 13:27:22 <roconnor> if only m and n were part of the OP_MULTISIGCHECK code
369 2012-01-02 13:27:42 <genjix> roconnor: hi i'm genjix
370 2012-01-02 13:27:49 <sipa> anyway, gotta go
371 2012-01-02 13:27:53 <justmoon> sipa: bye
372 2012-01-02 13:27:59 <roconnor> The more I think about it the more I think that is a big mistake in the protocol.
373 2012-01-02 13:28:07 <justmoon> roconnor: OP_CHECKMULTISIG has a max of 20 - that's not too bad
374 2012-01-02 13:28:08 <genjix> there is only one of me in the whole world
375 2012-01-02 13:28:19 <genjix> my dad mis-transliterated his surname to english
376 2012-01-02 13:28:32 <roconnor> justmoon: but it would be better if m and n were staticaly given.
377 2012-01-02 13:28:48 <justmoon> roconnor: you can't have everything
378 2012-01-02 13:28:54 <roconnor> justmoon: static analysis would give more accurate time and space usage
379 2012-01-02 13:29:02 <justmoon> roconnor: the problem with OP_EVAL is that it can contain easily 6 OP_CHECKMULTISIGs, putting its upper bound at 120
380 2012-01-02 13:31:12 <roconnor> justmoon: if I were the senior bitcoin developer I could have everything. BWAHH!
381 2012-01-02 13:31:33 <mcorlett> sipa: Here are a couple of semi-involved Stefans: http://www.google.com/search?q="stefan"%20bitcoin%20-thomas%20-weusecoins
382 2012-01-02 13:31:39 <roconnor> I don't know, probably OP_CHECKMULTISIG is already in use.
383 2012-01-02 13:32:00 <justmoon> mcorlett: rofl
384 2012-01-02 13:32:17 <justmoon> I see a "Bitcoin Stefans" facebook group in my future
385 2012-01-02 13:32:25 <mcorlett> Hahaha!
386 2012-01-02 13:32:42 <justmoon> http://en.wikipedia.org/wiki/Project_Steve
387 2012-01-02 13:34:17 <mcorlett> You should start a trend of naming your children variations of the name "Stefan" on the forums.
388 2012-01-02 13:34:29 <mcorlett> Bitcoin children!
389 2012-01-02 13:34:32 <mcorlett> Our future!
390 2012-01-02 13:34:47 <justmoon> yeah... no.
391 2012-01-02 13:34:51 <justmoon> ;)
392 2012-01-02 13:35:09 <mcorlett> Oh well... at least I tried!
393 2012-01-02 13:35:16 <justmoon> my ego thanks you for indulging it
394 2012-01-02 13:36:09 <genjix> project steve includes Stefan, Steven and Stephan
395 2012-01-02 13:36:23 <justmoon> yep, unfortunately I'm not a scientist
396 2012-01-02 13:36:53 <genjix> weird, i just realised that Stevan is softer than Stephan is softer than SteFan
397 2012-01-02 13:37:11 <genjix> Steven
398 2012-01-02 13:37:34 <justmoon> yeah, man, I'm hardcore
399 2012-01-02 13:37:57 <justmoon> all those other guys are SOFT, but I'm SHARP
400 2012-01-02 13:38:08 <justmoon> this has got to be a low point for this channel
401 2012-01-02 13:38:12 <genjix> jajaja
402 2012-01-02 13:38:14 <mcorlett> genjix: Stop repeating the name in your head, or http://en.wikipedia.org/wiki/Semantic_satiation
403 2012-01-02 13:39:57 <genjix> interesting article
404 2012-01-02 13:45:15 <CIA-100> libbitcoin: Kamil Domanski * recfacba8d032 / (5 files in 4 dirs): early stub of node discovery http://tinyurl.com/7gbxop5
405 2012-01-02 13:55:22 <justmoon> gavinandresen: sipa, roconnor and I have been working on a summary of the private discussion to be posted on the list, can you review please? http://piratepad.net/E8AEAQJUw7
406 2012-01-02 13:56:32 <gavinandresen> justmoon:  I've got another alternative proposal that I think I like
407 2012-01-02 13:57:03 <gavinandresen> Are sipa and roconnor here?
408 2012-01-02 13:57:13 <justmoon> on and off
409 2012-01-02 13:58:34 <gavinandresen> So I was thinking.... what if the new pay-to-code-hash transaction is just:    HASH160 <> EQUAL  ?
410 2012-01-02 13:58:51 <gavinandresen> Old clients would verify that the hash is correct.
411 2012-01-02 13:59:12 <gavinandresen> New clients would recoginize "ah, a pay-to-script, I should take the top item on the scriptSig and use that as the scriptPubKey"
412 2012-01-02 13:59:17 <gavinandresen> (after verifying the hash)
413 2012-01-02 13:59:40 <justmoon> sounds good, no recursion though, right?
414 2012-01-02 13:59:51 <gavinandresen> No, no recursion.  No find-and-replace.
415 2012-01-02 14:00:11 <gavinandresen> Just "Run the script like an old client.  If it validates, take last item on scriptSig and validate again."
416 2012-01-02 14:00:26 <gavinandresen> And probably "fail validation if scriptSig is not push-only"
417 2012-01-02 14:00:54 <justmoon> I think that's my new favorite proposal
418 2012-01-02 14:01:23 <justmoon> would like to look at recursion again though - maybe someone has a clever idea for that as well
419 2012-01-02 14:02:11 <gavinandresen> I think I agree with roconnor:  recursion should wait until we really deeply understand the current Script.
420 2012-01-02 14:02:29 <justmoon> good to have to sane, conservative gavin back :D
421 2012-01-02 14:03:02 <gavinandresen> I just want the feature, and if there is a safer way to get it....
422 2012-01-02 14:03:09 <sipa> in that case i'd still prefer to have an OP_EVAL there
423 2012-01-02 14:03:30 <sipa> whose semantics is: replace script with current top-of-stack and start over
424 2012-01-02 14:04:12 <gavinandresen> But then you get into cannot-statically-analyze again....
425 2012-01-02 14:04:21 <sipa> ah bah; of course
426 2012-01-02 14:04:23 <gavinandresen> ... because top-of-stack may not be what you started with
427 2012-01-02 14:04:57 <justmoon> we can still add OP_EVAL, this new idea doesn't consume a NOP at all
428 2012-01-02 14:05:02 <justmoon> we just don't need it as urgently
429 2012-01-02 14:05:03 <gavinandresen> Right
430 2012-01-02 14:05:12 <sipa> good point
431 2012-01-02 14:06:02 <sipa> justmoon: but but.. there has not yet been a christmas this year!
432 2012-01-02 14:06:06 <gavinandresen> "We" still need to specify the rules for counting sigOps inside the serialized scripts
433 2012-01-02 14:06:47 <genjix> the idea is a hack
434 2012-01-02 14:06:50 <justmoon> same... as normal?
435 2012-01-02 14:06:51 <genjix> but i like it
436 2012-01-02 14:06:57 <genjix> haha
437 2012-01-02 14:07:03 <justmoon> that was @counting
438 2012-01-02 14:07:27 <justmoon> why is the counting any different?
439 2012-01-02 14:07:37 <genjix> i dont think it is
440 2012-01-02 14:07:41 <sipa> it still needs to be specified, even if it is trivial
441 2012-01-02 14:07:48 <gavinandresen> Right now, a CHECKMULTISIG is counted as 20 sigops.  That will be an issue if they get popular.
442 2012-01-02 14:08:10 <justmoon> I see, so you're thinking here's our chance to tighten that
443 2012-01-02 14:08:14 <gavinandresen> Yes
444 2012-01-02 14:08:14 <justmoon> hmm
445 2012-01-02 14:08:15 <sipa> note that old clients will only count the visible operations
446 2012-01-02 14:08:22 <sipa> and you want to keep co,patibility with those, no?
447 2012-01-02 14:08:43 <gavinandresen> Rule could be:  n CHECKMULTISIG where n is one of the OP_1 to OP_16 opocdes is counted as n in the serialized part of scritpSig
448 2012-01-02 14:09:08 <gavinandresen> If n doesn't immediately precede (if it is calculated somehow) then count as worst-case (20)
449 2012-01-02 14:09:27 <gavinandresen> sipa:  right, we need to keep no hard-block-chain-split with old clients
450 2012-01-02 14:09:27 <genjix> if you tighten it you risk a fork
451 2012-01-02 14:09:39 <justmoon> genjix: no old clients will see it as just data
452 2012-01-02 14:09:42 <gavinandresen> genjix:  that's why it is "in the serialized scriptSig script"
453 2012-01-02 14:09:50 <genjix> yeah but then what's the purpose?
454 2012-01-02 14:10:05 <gavinandresen> I think most CHECKMULTISIGs will be done using the new method
455 2012-01-02 14:10:24 <genjix> an attacker doesnt care though. he just wants to make a bad block
456 2012-01-02 14:11:13 <gavinandresen> The purpose is to allow more "new-style" CHECKMULTISIG operations in a block that old clients AND new clients will both accept as valid.
457 2012-01-02 14:11:16 <genjix> there are a bunch of forking changes that may happen in the future... might be a good idea to have a wish-list for that day
458 2012-01-02 14:12:10 <justmoon> so funny, now that gavin has gone back to being sane, I have gone back to being superfluous :D
459 2012-01-02 14:12:13 <gavinandresen> yes, that's on my todo list....   I worry about keeping it on the wiki, though.....
460 2012-01-02 14:12:48 <gavinandresen> I keep telling people to slap me upside my head if I go insane and people keep thinking I'm not serious
461 2012-01-02 14:12:58 <justmoon> gavinandresen: should I still post my summary to the mailing list? any corrections?
462 2012-01-02 14:13:11 <genjix> i get you. but what if new clients accept same number of SIG ops in main script and less in the EVAL script
463 2012-01-02 14:13:20 <genjix> and old clients accept same number of SIG ops
464 2012-01-02 14:13:29 <gavinandresen> justmoon:  No, it is a good summary of the opposition to OP_EVAL
465 2012-01-02 14:13:34 <gavinandresen> justmoon: so post it
466 2012-01-02 14:13:50 <genjix> anyway i am really glad for no dry-run and keeping static analysis
467 2012-01-02 14:14:41 <gavinandresen> genjix: a majority of mining power still needs to be doing things "the new way" for everything to work smoothly.
468 2012-01-02 14:14:45 <justmoon> posted.
469 2012-01-02 14:14:53 <genjix> true
470 2012-01-02 14:15:55 <gavinandresen> ... so there still needs to be a vote, etc.   And if you are mining using the old code AND mining non-standard transactions then you could pretty easily end up on the wrong side of a blockchain split.
471 2012-01-02 14:16:09 <genjix> oh miners could not build off bad blocks
472 2012-01-02 14:16:18 <genjix> simple
473 2012-01-02 14:16:46 <genjix> yeah i dont think a fork is a problem
474 2012-01-02 14:16:58 <justmoon> vote? who gets to vote? miners?
475 2012-01-02 14:17:06 <genjix> yeah
476 2012-01-02 14:17:13 <justmoon> kk
477 2012-01-02 14:17:27 <gavinandresen> Yes, we'll ask them to put a string in their coinbase showing they accept the new rules
478 2012-01-02 14:17:34 <genjix> vote with their C/G/XPUs
479 2012-01-02 14:18:17 <genjix> make it [X]
480 2012-01-02 14:21:09 <justmoon> gavinandresen: so what's the exact sigPubKey in your proposal? OP_HASH160 OP_EQUALVERIFY?
481 2012-01-02 14:21:45 <gavinandresen> justmoon:  OP_HASH160 <push 20-byte-hash> OP_EQUAL
482 2012-01-02 14:21:55 <gavinandresen> scriptPubKey has to leave a true value on the stack....
483 2012-01-02 14:22:21 <justmoon> right
484 2012-01-02 14:23:20 <gavinandresen> Hey [Tycho] .  You should delay rolling out OP_EVAL.
485 2012-01-02 14:23:57 <[Tycho]> Hello.
486 2012-01-02 14:24:08 <[Tycho]> Should I stop including it in my coinbase too ?
487 2012-01-02 14:25:27 <gavinandresen> [Tycho]: yes.  Although there's no rush, I'm thinking about an alternative that is different but compatible
488 2012-01-02 14:26:16 <genjix> [Tycho]: what's your email?
489 2012-01-02 14:26:16 <[Tycho]> Ok, I'll make necessary adjustments before 15.01.2012
490 2012-01-02 14:26:44 <[Tycho]> genjix: at the bottom of my webpages.
491 2012-01-02 14:27:05 <genjix> [Tycho]: which is?
492 2012-01-02 14:27:14 <[Tycho]> deepbit.net
493 2012-01-02 14:27:30 <kinlo> the getmemorypool call, it never includes the generation transaction right?   So one is always required to "decompile" the transactions it is presenting to calculate the required sum to put in the generation transaction?
494 2012-01-02 14:29:24 <[Tycho]> gavinandresen: were there any changes to proposed checkmultisig usage ? When it will be safe to send multisigs to main net ?
495 2012-01-02 14:30:13 <gmaxwell> kinlo: Why ask here instead of just running it?
496 2012-01-02 14:30:15 <gmaxwell> jeesh.
497 2012-01-02 14:30:19 <gmaxwell> "coinbasevalue" : 5000350000,
498 2012-01-02 14:30:31 <gavinandresen> [Tycho]: No changes to CHECKMULTISIG; if you can find somebody to mine them it is safe to create them now (the plain CHECKMULTISIG without OP_EVAL)
499 2012-01-02 14:30:34 <kinlo> uh
500 2012-01-02 14:30:45 <kinlo> gmaxwell: my apologies, I must be blind
501 2012-01-02 14:31:02 <gmaxwell> kinlo: heh, none needed. :) I just thought it was funny. :)
502 2012-01-02 14:31:13 <kinlo> eh
503 2012-01-02 14:31:22 <kinlo> well I *should* have seen that!
504 2012-01-02 14:31:42 <[Tycho]> gavinandresen: with one additional "0" before actual args ? Ok.
505 2012-01-02 14:31:59 <gmaxwell> well, it's less obvious that it includes fees if your pool doesn't have any fees in it.
506 2012-01-02 14:32:05 <[Tycho]> It's sad that nice addresses for multisigs aren't available...
507 2012-01-02 14:33:33 <kinlo> gmaxwell: well, it currently has fee's in it
508 2012-01-02 14:36:54 <gmaxwell> kinlo: Hey, I'm trying to give you an out here! :)
509 2012-01-02 14:37:09 <kinlo> gmaxwell: it was a 6 between all zero's
510 2012-01-02 14:37:26 <kinlo> but actually, the sheer number of transactions made me overlook the bottom part
511 2012-01-02 14:37:52 <kinlo> I'm now trying to figure out the bits part without having to ask :p
512 2012-01-02 14:38:51 <kinlo> it looks like difficulty but trying to confirm myself
513 2012-01-02 14:38:59 <gmaxwell> kinlo: yes, that the compact target.
514 2012-01-02 14:39:15 <kinlo> great!
515 2012-01-02 14:39:25 <kinlo> now only write code to create a block :)
516 2012-01-02 14:40:01 <gmaxwell> kinlo: if you weren't aware p2pool uses getmemorypool so you can go look at its code.
517 2012-01-02 14:40:20 <kinlo> I haven't had a look at p2pool yet
518 2012-01-02 14:40:24 <kinlo> lemme do that first
519 2012-01-02 14:40:57 <gmaxwell> (and p2pool has solved two blocks so far since the newyear, both with transactions, whoppie!)
520 2012-01-02 14:41:02 <genjix> gmaxwell: what's your email?
521 2012-01-02 14:41:09 <gmaxwell> genjix: gmaxwell@gmail.com
522 2012-01-02 14:41:14 <genjix> thanks
523 2012-01-02 14:41:19 <genjix> nanotube: ?
524 2012-01-02 14:58:12 <luke-jr> jgarzik: coinbaser merged into master
525 2012-01-02 14:58:59 <roconnor> [Tycho]: It shouldn't be hard to come up with an addressing scheme for arbitrary scripts.  Something like URI:bitcoin-script:<base64 encoding of script>  I'm sure people have already thought of this.
526 2012-01-02 14:59:46 <roconnor> [Tycho]: if you define it, it will quickly become defacto
527 2012-01-02 14:59:57 <[Tycho]> Cool.
528 2012-01-02 15:00:32 <[Tycho]> But multisigs can be redeemed by different scripts.
529 2012-01-02 15:00:40 <gavinandresen> bitcoin-script:<blah> makes me nervous....
530 2012-01-02 15:01:44 <gavinandresen> ... for the same reason an openssl-digest-scheme:<blah> URI that users could see would make me nervous
531 2012-01-02 15:01:52 <roconnor> gavinandresen: well, it is out-of-band data isn't under our control anyways, so no point in sweating it.
532 2012-01-02 15:02:18 <gavinandresen> roconnor: I just don't want to encourage it as "here's a good way to do it"
533 2012-01-02 15:03:07 <roconnor> [Tycho]: what do you mean by "But multisigs can be redeemed by different scripts."
534 2012-01-02 15:03:27 <justmoon> what's wrong with an address type for arbitrary scripts? [version byte] [scriptPubKey] [checksum]?
535 2012-01-02 15:04:37 <gavinandresen> justmoon: Seems ripe for hacking to me.  An attacker could modify scriptPubKey and adjust the checksum if they can MITM
536 2012-01-02 15:05:08 <justmoon> I didn't read the earlier part of the discussion, but it seems like if you're MITM you can replace any address
537 2012-01-02 15:06:22 <gavinandresen> justmoon: true....  I'll admit my reaction is more "feels wrong" rather than "I've thought hard about it"
538 2012-01-02 15:06:44 <justmoon> I just wanted to point out that bitcoin:<address> where address can be standard, eval or sigpubkey seems cleaner than a separate bitcoin-script:<sigPubKey>
539 2012-01-02 15:07:11 <luke-jr> justmoon: when presented with long "garbage" data, humans tend to check the first and/or last few characters to be sure it's what they want
540 2012-01-02 15:07:38 <justmoon> luke-jr: meaning?
541 2012-01-02 15:07:52 <luke-jr> justmoon: meaning a MITM of a non-hash is less likely to be noticed
542 2012-01-02 15:08:03 <luke-jr> more*
543 2012-01-02 15:08:05 <luke-jr> err
544 2012-01-02 15:08:07 <luke-jr> less* :
545 2012-01-02 15:08:23 <justmoon> luke-jr: well, if a human sees an address, I call that a bug
546 2012-01-02 15:08:31 <gavinandresen> luke-jr: yup
547 2012-01-02 15:08:41 <gavinandresen> justmoon: Sure, in a perfect world humans never see them....
548 2012-01-02 15:08:46 <luke-jr> justmoon: it's inevitable that humans must verify addresses at some point.
549 2012-01-02 15:08:47 <gavinandresen> ... but we don't live in a perfect world
550 2012-01-02 15:09:41 <luke-jr> it's not a new "problem"
551 2012-01-02 15:09:58 <luke-jr> if SSH couldn't solve it, chances are neither will we
552 2012-01-02 15:10:59 <justmoon> luke-jr: right, there is no online shopping, because nobody could solve the problem of how to identify the merchant without having users compare 30 byte crypto strings by hand
553 2012-01-02 15:10:59 <roconnor> meh, I don't really see what all the worry about URI:bitcoin-script: is
554 2012-01-02 15:11:29 <luke-jr> justmoon: there is online shopping, because people *do* compare crypto hashes by hand
555 2012-01-02 15:12:12 <justmoon> whatever, no interested in having the argument - you worry about the usability/security of your software and I'll worry about mine
556 2012-01-02 15:12:20 <amiller> couldn't a client could always recognize 'whitelisted' scripts according to trust rules
557 2012-01-02 15:12:44 <amiller> the first time you see a new odd script, well you'd have to look at the code and analyze it (or look it up somewhere)
558 2012-01-02 15:12:45 <roconnor> justmoon: isn't the solution to online shopping to make Credit Card companies liable for frauduent transactions for wich we indirectly pay 2% - 5% fees for?
559 2012-01-02 15:13:06 <roconnor> justmoon: ah sorry you are right
560 2012-01-02 15:13:12 <roconnor> this topic is wandering
561 2012-01-02 15:13:44 <luke-jr> amiller: exactly my point
562 2012-01-02 15:15:01 <roconnor> [Tycho]: maybe bitcoin-script:<base64 encoding of script>/<checksum> would be a little better
563 2012-01-02 15:15:33 <amiller> if everyone is suddenly interested in static analysis, i wonder why you wouldn't use a simply typed lambda calculus or something equivalent
564 2012-01-02 15:15:35 <[Tycho]> Actually now I think that multisigs may not need an address format
565 2012-01-02 15:15:37 <amiller> or like the kernel language of Coq
566 2012-01-02 15:16:02 <roconnor> amiller: that would be ideal, but we've got what Satoshi has given us.
567 2012-01-02 15:16:04 <luke-jr> roconnor: base64 probably isn't valid in URIs
568 2012-01-02 15:16:13 <gavinandresen> What would be better is if the URI includes the https: website address of the entity paying, and the client securely asked "does this address/Script belong to you?"
569 2012-01-02 15:16:33 <roconnor> luke-jr: it is valid in data URI's.  I use them all the time.  Thought there is a special URI version of base64 IIRC.
570 2012-01-02 15:16:44 <gavinandresen> Or maybe even better, asked a third-party "hey, could you ask amazon.com if bitcoin-uri:gobbledygook belongs to them"
571 2012-01-02 15:16:56 <luke-jr> gavinandresen: HTTPS just moves the verification to <someone else>; centralization
572 2012-01-02 15:17:27 <gavinandresen> luke-jr: right, ideally you want to spread the trust so an attacker has to compromise several somebodies
573 2012-01-02 15:18:12 <luke-jr> gavinandresen: now you're sounding like the namecoin suggestion ;)
574 2012-01-02 15:19:13 <gavinandresen> I'd actually be happy trusting the existing HTTPS certificate authority system.  It works "good enough" for online commerce
575 2012-01-02 15:19:51 <gavinandresen> (it doesn't work 'good enough' if you're doing something very high-value like building a nuclear bomb-making plant)
576 2012-01-02 15:21:03 <luke-jr> gavinandresen: it works good enough, because as roconnor said, people can dispute/reverse credit card charges
577 2012-01-02 15:21:23 <bobke> talk to the hand BCBot
578 2012-01-02 15:21:23 <luke-jr> gavinandresen: there have been multiple compromises, and with Bitcoin, it'd be too late when that happenede
579 2012-01-02 15:22:51 <gavinandresen> luke-jr: compromises of the https certificate authority system aimed at consumers?  I'd appreciate it if you email me references if you have time, I'd love to read more.
580 2012-01-02 15:22:57 <gavinandresen> (just not right now)
581 2012-01-02 15:23:39 <luke-jr> gavinandresen: but more importantly to me, if HTTPS is enabled for Bitcoin payments, is that I can use a self-signed cert and include an address in the URI, and it will be treated the same as a CA-signed cert if the SSL cert gets signed by the URI-included address
582 2012-01-02 15:23:48 <luke-jr> rather than forking over $$$ for a CA to sign my domains
583 2012-01-02 15:23:56 <luke-jr> (just on principle)
584 2012-01-02 15:25:38 <gmaxwell> If you successfully compromise a CA ripping off a few ecommerce txn would a waste of a profitable chance.  I was about to make the same point that luke made though, that it would add unfortunate friction to make commercial certs a required component of bitcoin ecommerce. (if nothing else, it provides another centeralized hook that might be employed to dork with bitcoin businesses in someone's hypothetical analysis of the decenteralization of
585 2012-01-02 15:26:06 <luke-jr> http://arstechnica.com/security/news/2011/03/how-the-comodo-certificate-fraud-calls-ca-trust-into-question.ars/2
586 2012-01-02 15:26:35 <sipa> gavinandresen: a bitcoin address is currently two things: an identifier for a keypair, and a template for a txout script; somehow i'd feel more confortable with the base58 string referring only to the key, and if you want a payment to it, use a URI that embeds the base58 string
587 2012-01-02 15:27:23 <roconnor> sipa: how is it used as an identifier for a keypair?
588 2012-01-02 15:28:58 <sipa> for example for message signing
589 2012-01-02 15:29:13 <sipa> or when creating a multikey address
590 2012-01-02 15:29:49 <sipa> anyway, more a philosophical thing than a technical problem
591 2012-01-02 15:39:43 <nanotube> genjix: sup?
592 2012-01-02 15:51:58 <sipa> roconnor: your second amendment is not backward compatible
593 2012-01-02 15:55:14 <luke-jr> &
594 2012-01-02 15:56:28 <copumpkin> sipa: guns?
595 2012-01-02 15:57:25 <sipa> copumpkin: ?
596 2012-01-02 15:57:37 <copumpkin> just being silly, sorry :)
597 2012-01-02 15:57:41 <justmoon> sipa: second amendment to the us constitution protects the right to bear arms
598 2012-01-02 15:57:52 <sipa> justmoon: ah, lol :D
599 2012-01-02 15:58:53 <genjix> nanotube: i wanted to email you but its on forum anyway https://bitcointalk.org/index.php?topic=56376.msg670966
600 2012-01-02 15:59:15 <cjdelisle> ugh
601 2012-01-02 15:59:20 <cjdelisle> please no x509
602 2012-01-02 15:59:27 <copumpkin> lol
603 2012-01-02 15:59:40 <genjix> my bank uses it so it must be good
604 2012-01-02 16:00:12 <copumpkin> I think we should redo bitcoin from scratch and use ASN.1 pervasively in the protocol
605 2012-01-02 16:00:17 <cjdelisle> x509 is like a prison, nobody likes it but everybody is stuck with it
606 2012-01-02 16:00:30 <justmoon> cjdelisle: that sounds more like marriage
607 2012-01-02 16:00:37 <cjdelisle> same thing
608 2012-01-02 16:00:41 <justmoon> ah
609 2012-01-02 16:00:56 <sipa> henceforth, x509 shall be named "marriage"
610 2012-01-02 16:01:03 <justmoon> not that us bachelor nerds know what the hell we're talking about :P
611 2012-01-02 16:01:17 <cjdelisle> heh /nod
612 2012-01-02 16:01:30 <cjdelisle> why use ASN.1 when you could use XM(hel)L!
613 2012-01-02 16:02:11 <cjdelisle> AND JAVA
614 2012-01-02 16:04:17 <nanotube> genjix: there's no date. am i to assume this is today? ;)
615 2012-01-02 16:06:21 <justmoon> nanotube: I think Tuesday?
616 2012-01-02 16:07:04 <justmoon> genjix sent an earlier mail to fewer people suggesting a weekly meeting on tuesday, so I think this is the first installment of that
617 2012-01-02 16:07:08 <justmoon> could be wrong though
618 2012-01-02 16:08:34 <justmoon> nanotube: yeah, it's definitely on Tuesday. I found proof. :)
619 2012-01-02 16:09:45 <genjix> nanotube: Tuesday
620 2012-01-02 16:09:57 <genjix> ill correct that
621 2012-01-02 16:10:09 <gmaxwell> Oh. I figured it was today due to the lack of saying so.
622 2012-01-02 16:10:16 <roconnor> sipa: ah oops, you are right.
623 2012-01-02 16:10:25 <roconnor> sipa: I don't know what I was thinking.
624 2012-01-02 16:10:48 <roconnor> You'd have to add an OP_DROP or something else equally as akward
625 2012-01-02 16:10:57 <roconnor> bah
626 2012-01-02 16:11:11 <justmoon> gmaxwell: you should have received the version of the email where it says tuesday in the subject line
627 2012-01-02 16:12:17 <genjix> when is the next satoshi client release going to be btw?
628 2012-01-02 16:15:05 <CIA-100> bitcoin: Kamil Domanski * rabe4f045b4f7 gentoo/net-p2p/libbitcoin/ (Manifest libbitcoin-0.1.0_alpha2.ebuild): net-p2p/libbitcoin: 0.1.0_alpha2 http://tinyurl.com/87da9oh
629 2012-01-02 16:15:06 <CIA-100> bitcoin: Kamil Domanski * r13804b451e40 gentoo/app-crypt/subvertx/ (Manifest subvertx-0.1.1.ebuild): app-crypt/subvertx: 0.1.1 http://tinyurl.com/6oaft4x
630 2012-01-02 16:15:07 <CIA-100> bitcoin: Kamil Domanski * rcfc9bd195888 gentoo/net-p2p/libbitcoin/ (Manifest libbitcoin-9999.ebuild): net-p2p/libbitcoin-9999: updated dep to boost 1.48 http://tinyurl.com/6ll224w
631 2012-01-02 16:48:50 <nanotube> justmoon: genjix: ok, tuesday it is. :)
632 2012-01-02 16:53:00 <gmaxwell> hm. I notice that a new node loses 40 seconds adding the initial keys to the keypool.
633 2012-01-02 16:53:17 <gmaxwell> (while nothing else appears to be happening concurrently)
634 2012-01-02 16:58:17 <BlueMatt-mobile> Is this meeting thing official...ima be on a plane
635 2012-01-02 16:58:50 <ZellFaze> I think so.  About as official as it gets for Bitcoin.
636 2012-01-02 16:58:59 <gavinandresen> Extremely very official.  We're going to elect board members and vote on whether or not to use Roberts Rules of Order
637 2012-01-02 16:59:28 <gavinandresen> (sarcasm intended there)
638 2012-01-02 17:00:01 <[Tycho]> What meeting ?
639 2012-01-02 17:00:34 <BlueMatt-mobile> gavinandresen lol, ok ill be on
640 2012-01-02 17:01:08 <justmoon> BlueMatt: if you're not there you will have to hand in your GPU and badge
641 2012-01-02 17:01:09 <gavinandresen> [Tycho]: genjix is organizing regular Tuesday meetings
642 2012-01-02 17:03:05 <genjix> ZellFaze: you have a chocobo for your avatar and the name of a FF8 character :D
643 2012-01-02 17:03:08 <genjix> congrats
644 2012-01-02 17:03:22 <genjix> congrats on having good taste
645 2012-01-02 17:03:33 <ZellFaze> Thank you. The name wasn't actually a reference to FF8 (which is one that I have not played actually).
646 2012-01-02 17:03:46 <ZellFaze> I came up with the name independently when I was 12 years old. xD
647 2012-01-02 17:03:51 <ZellFaze> But I do love chocobo's.
648 2012-01-02 17:04:34 <BlueMatt-mobile> justmoon ok ill keep that in mind...though i belive my badge got lost in the mail...
649 2012-01-02 17:05:13 <justmoon> BlueMatt-mobile: ok, just sign here with your lamport signature and I'll get you a new one
650 2012-01-02 17:05:20 <roconnor> justmoon: begining the script with NOP1 will make the implementation easier, but meh, whatever you guys want.
651 2012-01-02 17:05:27 <genjix> party membership has to be approved by the priesthood
652 2012-01-02 17:06:29 <justmoon> roconnor: yeah, I'm ok with your way too if that's what people decide
653 2012-01-02 17:09:32 <gavinandresen> roconnor: implementation isn't actually easier, you need to match the entire scriptPubKey in any case (otherwise an attacker could split the chain)
654 2012-01-02 17:09:33 <genjix> justmoon, roconnor: what about if these 'unusual' script types (if we're setting a future precedent for them), have a marker operation: OP_MARKER <byte> OP_DROP
655 2012-01-02 17:10:31 <roconnor> genjix: that is the repaired version of my second ammendment.
656 2012-01-02 17:10:45 <justmoon> genjix: I don't think that's necessary - one case does not a series make
657 2012-01-02 17:10:47 <gavinandresen> I like keeping it as simple as possible.  And saving the bytes.
658 2012-01-02 17:10:57 <roconnor> genjix: I'd be happy with that as well, but people get in a tizzy about bytes for some reason.
659 2012-01-02 17:11:28 <roconnor> (even though clients are welcome to compress scripts in whatever way they please)
660 2012-01-02 17:11:46 <gavinandresen> A marker byte just means extra rules.. because what if I follow the marker byte(s) by something OTHER than HASH<>EQUAL ?
661 2012-01-02 17:12:26 <roconnor> gavinandresen: then OP_MARKER is treated as a NOP ... which is convient since that is what it is right now.
662 2012-01-02 17:12:47 <justmoon> you need markers to solve ambiguity, there is no ambiguity here
663 2012-01-02 17:13:17 <genjix> who knows what the future might bring
664 2012-01-02 17:13:17 <roconnor> justmoon: right; I'm just prosoing it to make the implementation easier and perhaps less error prone.
665 2012-01-02 17:13:23 <roconnor> *proposing
666 2012-01-02 17:13:49 <roconnor> but maybe it isn't that big of a deal
667 2012-01-02 17:14:09 <genjix> but it's not a big deal. the future holds a lot of scope for hackery, patching and plaster.
668 2012-01-02 17:14:38 <justmoon> genjix: speaking of the future, OP_MARKER means using up a NOP
669 2012-01-02 17:15:32 <roconnor> justmoon: the implementation I'm thinking of is "parse the header" if it is there.  If so, try to parse according to the appropriate template, if that suceeds intepret the special template, otherwise interpret the script normally.
670 2012-01-02 17:15:33 <genjix> OP_NOP OP_NOP
671 2012-01-02 17:15:43 <genjix> like unicode
672 2012-01-02 17:16:08 <roconnor> justmoon: but ya, maybe this is unecessary
673 2012-01-02 17:16:19 <genjix> OP_SELECT OP_NOPX
674 2012-01-02 17:16:37 <justmoon> roconnor: I see your reasoning, it's just a judgment call, I'm happy with either way
675 2012-01-02 17:18:12 <gavinandresen> roconnor: just look at the first byte of scriptPubKey, if it is OP_HASH160 then it is probably the new transaction type, if it is DUP then it is probably the standard transaction type, if it is push-some-data it is probably the <pubkey> CHECKSIG transaction type....
676 2012-01-02 17:18:41 <roconnor> gavinandresen: I guess
677 2012-01-02 17:18:45 <gavinandresen> ... if it is OP_1 or OP_2 or OP_3 then it is probably the new multisignature standard transaction type....
678 2012-01-02 17:18:55 <BlueMatt-mobile> gavinandresen and when luke throws an invalid tx by the new opeval replacement to make it ambiguous?
679 2012-01-02 17:19:11 <BlueMatt-mobile> into the chain*
680 2012-01-02 17:19:43 <roconnor> gavinandresen: are you sure these don't already occur in the chain?
681 2012-01-02 17:19:44 <gavinandresen> BlueMatt-mobile: You mean he puts   <sigs>  <arbitrary nonce>  ... and then HASH160 <> EQUAL  ?
682 2012-01-02 17:19:56 <roconnor> gavinandresen: we don't want to make existing transactions invalid.
683 2012-01-02 17:19:58 <BlueMatt-mobile> gavinandresen yea
684 2012-01-02 17:20:05 <gavinandresen> We still need a careful rollout, with miners expressing support before doing full validation. That doesn't change.
685 2012-01-02 17:21:03 <BlueMatt-mobile> Well it makes it ambiguous because it was valid by old miners (though op nop) was designed for new feature rollouts
686 2012-01-02 17:21:12 <gavinandresen> It'll be "if the timestamp in the block being validated is after (whatever we decide) then do full validation and reject the block if it doesn't succeed"
687 2012-01-02 17:21:22 <BlueMatt-mobile> And i would argue you have to keep lukes tx
688 2012-01-02 17:21:41 <gavinandresen> BlueMatt-mobile: if his txn makes it into the chain before the switchover date then no problem.
689 2012-01-02 17:21:56 <BlueMatt-mobile> I would prefer to not have block switchovers and just always interpret the opnop as an eval tx
690 2012-01-02 17:22:10 <gavinandresen> ???
691 2012-01-02 17:22:33 <gavinandresen> I'm not following....
692 2012-01-02 17:22:54 <sipa> no miner will want to enforce the new rules without knowing other miners do the same
693 2012-01-02 17:22:56 <BlueMatt-mobile> In the old opeval (and new ones with markers) we dont have to have a block set to start enterpreting differently
694 2012-01-02 17:23:01 <sipa> they'd be locking themselves out
695 2012-01-02 17:23:11 <gavinandresen> BlueMatt-mobile: yes, we do....
696 2012-01-02 17:23:13 <justmoon> BlueMatt-mobile: yes you do?!
697 2012-01-02 17:23:20 <BlueMatt-mobile> Not really...
698 2012-01-02 17:23:26 <gavinandresen> Yuh-huh!
699 2012-01-02 17:24:01 <BlueMatt-mobile> If there arent conflicting txes in the chain, we dont have to care
700 2012-01-02 17:24:11 <gavinandresen> Attacker could put a:    DUP HASH <> EQUALVERIFY NOP1  transaction in the chain that validates on old clients but doesn't on new.  There HAS to be a switchover
701 2012-01-02 17:24:11 <justmoon> BlueMatt-mobile: that's true for both proposals
702 2012-01-02 17:25:03 <justmoon> basically if the switchover is done and there wasn't a conflicting transaction, then you can remove the check
703 2012-01-02 17:25:24 <justmoon> but there is no need to rush that
704 2012-01-02 17:25:43 <justmoon> and all it takes is one guy publishing a conflicting transaction and we just have to keep the check forever :P
705 2012-01-02 17:25:49 <justmoon> luke-jr: looking at you...
706 2012-01-02 17:25:59 <ZellFaze> Lets not do that then.
707 2012-01-02 17:27:09 <genjix> why are you looking at luke? did he do something before?
708 2012-01-02 17:27:23 <genjix> or is it because of the non-parsable coinbases :/
709 2012-01-02 17:27:30 <genjix> that caused me a headache
710 2012-01-02 17:27:41 <roconnor> hah
711 2012-01-02 17:27:59 <gavinandresen> luke-jr mines non-standard transactions.
712 2012-01-02 17:28:00 <roconnor> that's awesome
713 2012-01-02 17:28:10 <genjix> i see
714 2012-01-02 17:28:52 <ZellFaze> Has he ever actually managed to get a block made and accepted by the network?
715 2012-01-02 17:29:09 <genjix> he runs a mining pool
716 2012-01-02 17:29:12 <genjix> ofc he does
717 2012-01-02 17:29:39 <justmoon> genjix: I have a theory that he only proclaims to be pre-1968 catholic traditionalist sect and tonal number system supporter in order to troll people
718 2012-01-02 17:29:59 <copumpkin> he's secretly a hardcore atheist?
719 2012-01-02 17:30:17 <ZellFaze> And secretly doesn't like tonal at all.
720 2012-01-02 17:30:29 <copumpkin> he's a hexadecimal user! the horror!
721 2012-01-02 17:30:33 <genjix> well i speak esperanto...
722 2012-01-02 17:30:43 <genjix> some people think that's weird or strange
723 2012-01-02 17:30:50 <genjix> and i run linux
724 2012-01-02 17:30:54 <BlueMatt> ok, no I see that it is true either way, I just say that it makes much more sense to use an OP_NOP as that is what they are for
725 2012-01-02 17:31:02 <gavinandresen> Now now, lets not start rumors about luke-jr.  For example, I'm pretty sure that was NOT him I saw lurking in the back of the auditorium at my CIA talk
726 2012-01-02 17:31:11 <justmoon> lol
727 2012-01-02 17:31:27 <BlueMatt> without using an OP_NOP, a conflicting tx is perfectly reasonable
728 2012-01-02 17:31:38 <BlueMatt> with using an OP_NOP it isnt, even if it can happen either way
729 2012-01-02 17:31:43 <genjix> sometimes it's good to off out there on the fringe because that's where good ideas come from.
730 2012-01-02 17:31:54 <gavinandresen> HASH160 <> EQUAL  is a really dumb transaction to send.  Any miner could rip you off when you try to redeem it.
731 2012-01-02 17:32:01 <BlueMatt> Im just saying I waay prefer to mark them, as that is what OP_NOP is for, and it makes more sense
732 2012-01-02 17:32:04 <BlueMatt> gavinandresen: so?
733 2012-01-02 17:32:15 <justmoon> BlueMatt: why use up NOP1
734 2012-01-02 17:32:59 <justmoon> BlueMatt: if you want to do a HASH160 <hash> EQUAL transaction, just change to break the pattern, done
735 2012-01-02 17:33:15 <justmoon> no reason everyone else has to suffer for it
736 2012-01-02 17:33:23 <genjix> wasnt it TD who said that the scripting system is more limited than it seems?
737 2012-01-02 17:33:49 <gavinandresen> Because We Say So.
738 2012-01-02 17:33:57 <justmoon> BlueMatt: ?! and redefining NOP doesn't fall under that?
739 2012-01-02 17:34:08 <BlueMatt> justmoon: no, because thats what NOP is for...
740 2012-01-02 17:34:13 <roconnor> gavinandresen: unless you mine the transaction yourself ... though even then it is a little risky.
741 2012-01-02 17:34:27 <justmoon> BlueMatt: no, NOP is for "this operation does nothing"
742 2012-01-02 17:34:43 <BlueMatt> justmoon: which is added because its useful for upgrading...
743 2012-01-02 17:34:55 <roconnor> justmoon: OP_NOP is different from OP_NOP1
744 2012-01-02 17:35:17 <BlueMatt> (well the 1-10 ones)
745 2012-01-02 17:35:29 <roconnor> oops I haven't implemented OP_NOP
746 2012-01-02 17:35:32 <justmoon> roconnor: uh no?
747 2012-01-02 17:35:35 <justmoon> roconnor: kk
748 2012-01-02 17:35:39 <ZellFaze> If you guys will excuse my ignorance (I'm new to the scripting system for Bitcoin) we have a NOP that does something? And we are discussing whether or not we want to change how that NOP works right?
749 2012-01-02 17:35:55 <gavinandresen> We have 11 NOPs that do nothing right now.
750 2012-01-02 17:36:01 <roconnor> justmoon: OP_NOP is code number 97
751 2012-01-02 17:36:06 <BlueMatt> (OP_NOP and OP_NOP1-10)
752 2012-01-02 17:36:13 <gavinandresen> (eleven!)
753 2012-01-02 17:36:13 <roconnor> justmoon: OP_NOP1 is code number 176
754 2012-01-02 17:36:22 <justmoon> roconnor: sorry, you're right I was looking at the patched script.cpp by accident
755 2012-01-02 17:36:40 <justmoon> roconnor: which has case OP_NOP OP_NOP2 etc.
756 2012-01-02 17:37:02 <BlueMatt> brb, they just delayed my flight because the plane is broken...fuck me...
757 2012-01-02 17:37:08 <roconnor> boy, I can't believe I forgot to implement OP_NOP
758 2012-01-02 17:37:12 <genjix> roconnor: you have a bitcoin version?
759 2012-01-02 17:37:15 <justmoon> gavinandresen: assuming we want to keep one as NOP, we have ten to spend
760 2012-01-02 17:37:16 <roconnor> well, I would have found out eventually
761 2012-01-02 17:37:16 <ZellFaze> So none of our NOPS are doing anything right now as they should.
762 2012-01-02 17:37:19 <roconnor> genjix: yep
763 2012-01-02 17:37:23 <genjix> which one?
764 2012-01-02 17:37:24 <justmoon> gavinandresen: don't want to waste 'em
765 2012-01-02 17:37:44 <ZellFaze> Alright. I think I am on the same page now. For some reason I thought we somehow managed to get a NOP doing something other than noping.
766 2012-01-02 17:37:49 <genjix> roconnor: which one?
767 2012-01-02 17:37:58 <roconnor> oh I did impelement it
768 2012-01-02 17:38:02 <roconnor> good
769 2012-01-02 17:38:17 <roconnor> genjix: I haven't released it yet.
770 2012-01-02 17:38:24 <gmaxwell> ZellFaze: The NOPs exist as an extension mechenism.
771 2012-01-02 17:38:27 <genjix> aha ok
772 2012-01-02 17:38:37 <luke-jr> genjix: Eligius's coinbases are perfectly parsable..
773 2012-01-02 17:38:40 <copumpkin> genjix: guess what language!
774 2012-01-02 17:38:46 <roconnor> genjix: it's written in haskell
775 2012-01-02 17:38:51 <roconnor> oops
776 2012-01-02 17:38:53 <copumpkin> roconnor: dammit!
777 2012-01-02 17:38:54 <roconnor> I gave away the answer
778 2012-01-02 17:39:00 <luke-jr> justmoon: gavinandresen: I accept non-standard txns yes, but I also support OP_EVAL
779 2012-01-02 17:39:07 <gmaxwell> ZellFaze: by later redefining them to do things you can have instructions that do nothing on old nodes but do something on new nodes. With due care this can allow the two node types to coexist.
780 2012-01-02 17:39:40 <justmoon> luke-jr: just don't accept anything with a scriptPubKey of "HASH160 <hash> EQUAL" for now
781 2012-01-02 17:39:55 <luke-jr> justmoon: patches welcome.
782 2012-01-02 17:40:12 <justmoon> luke-jr: let me rephrase: do what you want :)
783 2012-01-02 17:40:12 <luke-jr> but srsly, that sounds like a retarded "solution"
784 2012-01-02 17:40:20 <ZellFaze> gmaxwell: That makes sense. I had figured that part out.  I had just somehow gotten it into my head that OP_NOP was doing something instead of being the NOP that is kept a NOP.
785 2012-01-02 17:40:32 <luke-jr> I'd welcome a patch to reject any OP_NOP2+
786 2012-01-02 17:40:54 <luke-jr> anyhow, I thought the OP_EVAL meeting wasn't for 2 more hours?
787 2012-01-02 17:40:55 <justmoon> luke-jr: I can give you a patched bitcoinjs if you want?
788 2012-01-02 17:41:02 <gmaxwell> luke-jr: 26 more hours.
789 2012-01-02 17:41:03 <luke-jr> justmoon: not useful to me
790 2012-01-02 17:41:26 <justmoon> luke-jr: suit yourself then
791 2012-01-02 17:41:43 <luke-jr> gmaxwell: there was no day mentioned that I saw :P
792 2012-01-02 17:41:49 <luke-jr> oh, right, the other email said Tue&
793 2012-01-02 17:41:50 <ZellFaze> gmaxwell: I thought the OP_EVAL meeting was today too.  I have work tomorrow.
794 2012-01-02 17:42:02 <ZellFaze> Whoops.
795 2012-01-02 17:43:14 <gmaxwell> Any suggestions for node deadlock troubleshooting?  I have a brand new node install that is deadlocked during bringup, but I don't know where its locked.
796 2012-01-02 17:44:15 <gmaxwell> It's on a new system so there might be something freaky about the system.... dunno. Stracing just shows the ThreadSocketHandler2 looping like normally, but it's not responding to any RPCs or doing anything else useful.
797 2012-01-02 17:44:25 <BlueMatt> gmaxwell: compiled using DEBUG_LOCKORDER?
798 2012-01-02 17:45:43 <gmaxwell> No, I can do that.. though I don't know if the failure is reproducable.
799 2012-01-02 17:46:13 <justmoon> roconnor: do you know if anybody has looked into bitcoin-specific compression in-depth?
800 2012-01-02 17:46:15 <BlueMatt> well backup the ~/.bitcoin so you can try...
801 2012-01-02 17:46:51 <roconnor> justmoon: not that I'm aware of, but given the prevalence of standard transactions there are some obvious compression schemes.
802 2012-01-02 17:47:05 <roconnor> justmoon: I've been tempted to employ them.
803 2012-01-02 17:47:23 <justmoon> roconnor: right, me too - disk I/O is my main bottleneck
804 2012-01-02 17:47:35 <sipa> justmoon: yes, i have
805 2012-01-02 17:47:39 <justmoon> roconnor: standard compression might be almost as good