1 2013-08-30 00:48:48 <Luke-Jr> gmaxwell: did you assign BIP 73?
  2 2013-08-30 00:48:57 <Luke-Jr> I thought gavinandresen was just adding it to the existing BIP O.o
  3 2013-08-30 00:49:58 <gavinandresen> I already bugged Stephen about not following Proper BIP Procedure.
  4 2013-08-30 00:53:22 <petertodd> gavinandresen: Oh, reminds me, I did a OP_CHECKLOCKTIMEVERIFY implementation redefining OP_NOP1. Copies locktime off the stack, compares it with the IsFinal() algorithm against the block including the spend tx, and fails the script if locktime not reached. Also uses IsMajority with nVersion=3 to enable the behavior.
  5 2013-08-30 00:53:46 <petertodd> gavinandresen: Similar to the OP_DEPTH you suggested before.
  6 2013-08-30 00:54:24 <petertodd> Testing of course will be the fun bit...
  7 2013-08-30 00:56:10 <gavinandresen> petertodd: I'm not sure it is worth poking around the edges of Script by defining new opcodes or SIGHASH types; I think we're going to want to hide a 100% redesign behind an OP_NOP.
  8 2013-08-30 00:57:57 <petertodd> gavinandresen: I agree actually. Part of why I think it's worth doing a simple one like OP_CHECKLOCKTIMEVERIFY is to test out the soft-fork procedure for a 100% redesign.
  9 2013-08-30 00:58:21 <petertodd> gavinandresen: Probably based on merklized abstract syntax trees for one thing. Also gmaxwell and I have been talking about changing the way tx's are hashed.
 10 2013-08-30 00:58:23 <gavinandresen> soft fork procedure works just fine, we did it with P2SH.
 11 2013-08-30 00:58:51 <petertodd> gavinandresen: Haven't tried it with a new opcode - IE go through the motions of doing all the testing.
 12 2013-08-30 00:59:16 <gavinandresen> Mmm.  OP_CHECKSIG should be broken down into one or more OP_PUSH_somethings, OP_HASH_N_ITEMS_ON_THE_STACK, then an ECDSA_CHECK_SIG....
 13 2013-08-30 00:59:35 <petertodd> Yup, we're all on the same page there.
 14 2013-08-30 00:59:46 <petertodd> Also a tx hash should be the digest of a merkle tree over the individual parts.
 15 2013-08-30 00:59:54 <gavinandresen> petertodd: meh.  if we're going to do all that testing, might as well do it with something big that is designed to be easy to test and easy to reason about
 16 2013-08-30 01:02:58 <petertodd> Well where's your wishlist for scriptv2 anyway?
 17 2013-08-30 01:05:52 <gavinandresen> creating scriptv2 is way down on the priority list.  In case you haven't noticed, getting simple multisig transactions happening has turned out to be incredibly slow and painful
 18 2013-08-30 01:06:04 <gavinandresen> "walk before you run" and all that.....
 19 2013-08-30 01:06:24 <gavinandresen> (and "talk is cheap", too)
 20 2013-08-30 01:06:50 <petertodd> Getting people to support P2SH has been incredibly slow and painful...
 21 2013-08-30 01:07:07 <Luke-Jr> 0.9 should make all new addresses P2SH? :P
 22 2013-08-30 01:07:25 <petertodd> Luke-Jr: jdillon had a 2.5BTC bounty for that IIRC
 23 2013-08-30 01:07:35 <Luke-Jr> petertodd: for writing it? it should be trivial
 24 2013-08-30 01:08:00 <gavinandresen> it is trivial.  And a really bad idea.
 25 2013-08-30 01:08:04 <Luke-Jr> in fact, didn't CoiledCoin already implement the code?
 26 2013-08-30 01:08:08 <Luke-Jr> gavinandresen: bad idea why? O.o
 27 2013-08-30 01:08:13 <petertodd> Luke-Jr: Yes, which is why when he proposed it he even said he wouldn't pay out to non-core devs for a week or something given how trivial it was.
 28 2013-08-30 01:08:51 <gavinandresen> bad idea because existing users with existing bitcoin addresses would have no problems with any merchants-- it would be new users with new wallets who would find all the broken merchants/exchanges/etc
 29 2013-08-30 01:09:06 <gavinandresen> If I was designing a way to turn off new users???.
 30 2013-08-30 01:09:17 <petertodd> Luke-Jr: Though specifically I think his was to depreciate only bare multisig and pay-to-pubkey - pay to pubkey hash would still be allowed.
 31 2013-08-30 01:09:30 <gavinandresen> (I've started to suspect jdillon is a very sophisticated troll with the ulterior motive of destroying bitcoin)
 32 2013-08-30 01:09:33 <petertodd> Luke-Jr: I thought that was a reasonable compromise - no-one uses bare multisig.
 33 2013-08-30 01:09:43 <petertodd> Meh
 34 2013-08-30 01:09:58 <petertodd> Luke-Jr: It was also not a hard-fork rule, just a isstandard change.
 35 2013-08-30 01:10:33 <Luke-Jr> gavinandresen: hmm, could be released along with some discourage-address-reuse-more stuff
 36 2013-08-30 01:10:45 <warren> discourage how?
 37 2013-08-30 01:11:01 <Luke-Jr> warren: don't expose addresses in an addressbook manner
 38 2013-08-30 01:11:01 <petertodd> warren: Just don't relay if you've seen an address before in the past n minutes.
 39 2013-08-30 01:11:11 <petertodd> warren: ^
 40 2013-08-30 01:11:21 <Luke-Jr> warren: user does Receive the same way they do Send
 41 2013-08-30 01:11:23 <petertodd> The address book is insane... Armory's design is much better.
 42 2013-08-30 01:11:49 <Luke-Jr> fill out the info, then it shows up in Transactions as "not received", with a QR Code and URI there
 43 2013-08-30 01:11:53 <Luke-Jr> so it's clear it's for a single transaction
 44 2013-08-30 01:12:49 <petertodd> Luke-Jr: oh, nice, the "not received" is a good touch
 45 2013-08-30 01:13:16 <gmaxwell> 19:48 < Luke-Jr> gmaxwell: did you assign BIP 73?
 46 2013-08-30 01:13:18 <petertodd> Luke-Jr: Or do a separate "waiting for funds" tab or somesuch.
 47 2013-08-30 01:13:20 <gmaxwell> hm? no.
 48 2013-08-30 01:13:28 <Luke-Jr> gmaxwell: gavinandresen already got that
 49 2013-08-30 01:14:43 <gmaxwell> hm. yea, I would have just suggested merging that into the main payment protocol bip.
 50 2013-08-30 01:16:38 <gavinandresen> I should have been more specific-- I told Stephen he should get consensus from QR-scanning-wallet implementors and then "bang out a BIP"
 51 2013-08-30 01:17:32 <gavinandresen> He skipped the get consensus bit....
 52 2013-08-30 01:17:39 <coingenuity> ERROR: CBlock::WriteToDisk() : OpenBlockFile failed <<<<< has this error ever been figured out
 53 2013-08-30 01:17:51 <coingenuity> "the osx error" as people have been calling it
 54 2013-08-30 01:18:14 <gavinandresen> I've never seen that error
 55 2013-08-30 01:19:06 <coingenuity> gavinandresen: has been plaguing OSX/Debian both since 0.8
 56 2013-08-30 01:19:13 <gavinandresen> okey dokey
 57 2013-08-30 01:19:34 <gavinandresen> if none of the core developers can reproduce it, it is really, really, really hard for us to fix it
 58 2013-08-30 01:19:34 <gmaxwell> coingenuity: uh, thats not consistent with my understanding. Corruption issues in OSX/debian, but they don't look like that. That looks like out of disk space or something.
 59 2013-08-30 01:19:35 <Luke-Jr> first I've seen it too
 60 2013-08-30 01:20:27 <coingenuity> gmaxwell: disk has only 6% usage :X
 61 2013-08-30 01:20:28 <gmaxwell> gavinandresen: Hm. I wonder if all payment request implementations can easily send an accept header. E.g. if you're forced to use webkit as your http library on IOS I wonder if you can customize the accept headers.
 62 2013-08-30 01:20:36 <gmaxwell> coingenuity: or something.
 63 2013-08-30 01:20:47 <coingenuity> yeah...
 64 2013-08-30 01:20:50 <Luke-Jr> gmaxwell: I've never seen a HTTP library which can't send headers
 65 2013-08-30 01:21:48 <petertodd> Luke-Jr: We'll likely run into problems with stupid transparent proxies/firewalls in enterprisey places.
 66 2013-08-30 01:22:06 <gavinandresen> gmaxwell: I think HTTPS support at all might be a barrier
 67 2013-08-30 01:22:07 <petertodd> Luke-Jr: Though SSL *mostly* gets rid of that issue...
 68 2013-08-30 01:22:43 <petertodd> gavinandresen: Failing that, working HTTPS support that actually checks certs properly.
 69 2013-08-30 01:23:13 <gmaxwell> gavinandresen: indeed, well??? I'd say that e.g. your choice someplace might be "use system http library, or implement https yourself" and because of the ssl the latter is not trivial.
 70 2013-08-30 01:23:25 <gmaxwell> and using the system library may impose interesting restrictions.
 71 2013-08-30 01:23:45 <Luke-Jr> 
ACTION ponders if there's a way to generate a token of some sort that can be used to pre-authorize a transfer before the destination is known, similar to people passing around private keys, but with a fixed output amount and not exposing the private key itself

 72 2013-08-30 01:24:59 <petertodd> Luke-Jr: Well, in a semi-user-friendly way you can do the one-time-password scriptPubKeys I proposed, but that gets ugly quick.
 73 2013-08-30 01:25:26 <Luke-Jr> petertodd: I don't see how that would help?
 74 2013-08-30 01:25:48 <Luke-Jr> petertodd: basically we need a signature that can be adapted to any scriptPubKey
 75 2013-08-30 01:25:50 <gmaxwell> Luke-Jr: so you was possession to authorize redemption, right?  Why don't you want to give someone a private key?
 76 2013-08-30 01:26:01 <petertodd> Luke-Jr: Funds get put on a txout only spendable by the OTP, then provide it to spend to the "any destination"
 77 2013-08-30 01:26:07 <petertodd> Luke-Jr: Best I can do though.
 78 2013-08-30 01:26:48 <Luke-Jr> gmaxwell: giving a private key is ugly, forces you to put the exact amount you want on an output, and possibly exposes private info about the rest of your HD wallet?
 79 2013-08-30 01:27:44 <petertodd> Luke-Jr: What's your use-case exactly?
 80 2013-08-30 01:28:04 <gmaxwell> Luke-Jr: you generate a random private key, write a transaction paying funds to it and sign it, and give the key and transaction to the recipent. they can then announce it and also write a txn spending its output.
 81 2013-08-30 01:28:21 <Luke-Jr> petertodd: I want to buy something from bitcoinstore at a friend's house.
 82 2013-08-30 01:28:39 <petertodd> Luke-Jr: Ok, so you don't trust your friends computer 100%?
 83 2013-08-30 01:28:49 <Luke-Jr> right, he runs Windows
 84 2013-08-30 01:29:20 <Luke-Jr> gmaxwell: I was hoping for some EC magic ;)
 85 2013-08-30 01:29:25 <petertodd> Luke-Jr: Well, actually that case is exactly what OTP's do well. You know exactly how much BTC you're risking, and the funds can be unlocked by passwords on a sheet of paper.
 86 2013-08-30 01:30:29 <petertodd> Luke-Jr: HASH160 <H(nonce)> EQUAL IF <insecure-key> CHECKSIG ELSE <secure-key> CHECKSIG ENDIF for example
 87 2013-08-30 01:31:15 <petertodd> Good way to transfer funds from cold-storage for instance.
 88 2013-08-30 01:34:17 <petertodd> Oh, and for the ECC magic version: generate a pubkey via ECC multiplication or addition, and keep one half of what was needed to generate it secret, storing the other half on the insecure computer. Provide the missing half to generate the full key and redeem.
 89 2013-08-30 01:34:49 <petertodd> The magic release key can be just as short as the OTP version actually as you'd do H(magic) to generate the ECC half.
 90 2013-08-30 01:35:12 <petertodd> Damn, I could implement this really quickly... and the TX's are all standard.
 91 2013-08-30 01:35:59 <petertodd> Too bad, I'd nearly come up with a reason for the scripting language. :/
 92 2013-08-30 01:38:16 <petertodd> OK, so here's the other intersting thing: You can use this to implement oracles too. Revealing the sec key is == revealing a nonce in any of the stuff alp's busy implementing. On the other hand, all those examples need non-std tx's anyway, so the only advantage is it's easy for the oracle to prove they do in fact have the sec key.
 93 2013-08-30 01:50:04 <petertodd> https://bitcointalk.org/index.php?topic=260898.msg3040083#msg3040083 <- wrote it up, in addition this is good for privacy in the oracle case because the ECC multiplication means the oracle can never know if somone made use of the seckey they revealed.
 94 2013-08-30 01:51:41 <lianj> petertodd: you made those testnet txs?
 95 2013-08-30 01:55:16 <petertodd> lianj: which ones?
 96 2013-08-30 01:56:51 <lianj> hash160 if  if op_checksig else opchecksig end else op_checkmultisig
 97 2013-08-30 01:57:10 <petertodd> oh, no those are alp's
 98 2013-08-30 01:57:45 <lianj> ah
 99 2013-08-30 01:58:11 <petertodd> pff, you think I actually write code? :/
100 2013-08-30 02:02:40 <lianj> sorry for offtopic but want to see how many disconnect.. if any???  ???????????????????????? ???????? ???????? ???????? ?????????????? ????????
101 2013-08-30 02:02:52 <lianj> meh
102 2013-08-30 02:23:03 <gmaxwell> lianj: if you did that in #bitcoin freenode would have k-lined you.
103 2013-08-30 02:25:57 <warren> (huh?)
104 2013-08-30 02:26:16 <gmaxwell> it's exploiting a bug in Apple IOS unicode parsing.
105 2013-08-30 02:26:20 <gmaxwell> Crashes IOS devices.
106 2013-08-30 02:27:39 <warren> oh
107 2013-08-30 02:28:36 <lianj> gmaxwell: the bad thing i did it in work groupchat because i knew they all use osx. and it not only parted them but didn't allow them to join again until the scrollbuffer was gone
108 2013-08-30 02:29:05 <gmaxwell> it's been done in here several times today, so there was probably no one left.
109 2013-08-30 02:29:10 <petertodd> 
ACTION runs off to make a non-standard transaction

110 2013-08-30 02:29:12 <petertodd> :P
111 2013-08-30 02:29:51 <gmaxwell> oh hahah
112 2013-08-30 02:30:06 <lianj> :D
113 2013-08-30 02:30:35 <gmaxwell> lianj: any idea if this bug can be used to get code execution?
114 2013-08-30 02:31:30 <lianj> not sure. i think not
115 2013-08-30 02:32:42 <lianj> isn't it the same or close to the one from a couple of month back. that also was never turned into something useful
116 2013-08-30 02:33:09 <gmaxwell> guess it's hard to tell if w/ closed code.
117 2013-08-30 02:35:08 <lianj> osx rops exist
118 2013-08-30 02:36:17 <gmaxwell> one that can run from text is interesting though, because, e.g. petertodd's nonstandard txn statement.
119 2013-08-30 02:36:31 <gmaxwell> crazy unicode in transaction -> your mywallet is empty.
120 2013-08-30 02:36:39 <warren> causes entire system or just app to die?
121 2013-08-30 02:37:18 <lianj> ^^
122 2013-08-30 02:37:30 <lianj> prolly just the people watching it on bc.i
123 2013-08-30 02:37:34 <warren> ooh man, what about all those old MacOS versions they no longer maintain?  hosed.
124 2013-08-30 02:45:32 <gmaxwell> extract from coingenuity's logs, WTF! http://0bin.net/paste/Hhf1LTn2RHe3E5BY#CVmV9m5WMiDZeM1FlT4OOP6bWF5X8VfpOZzyANTh89g=
125 2013-08-30 02:56:19 <petertodd> gmaxwell: wierd
126 2013-08-30 02:57:08 <gmaxwell> I would guess the pos was past the end but how did the open pass?
127 2013-08-30 02:58:07 <petertodd> Said "unable to open file", sure the open worked?
128 2013-08-30 02:59:41 <petertodd> gmaxwell: you see this? https://bitcointalk.org/index.php?topic=284000.0
129 2013-08-30 02:59:59 <gmaxwell> Just responded.
130 2013-08-30 03:00:16 <gmaxwell> (1) the stupid fork detection code is being unhelpful here.
131 2013-08-30 03:00:40 <gmaxwell> I'm guessing that his IBD pull selected peer went away.
132 2013-08-30 03:00:48 <gmaxwell> and so he's just sitting around until a block happens.
133 2013-08-30 03:00:51 <petertodd> He's connected to an ancient node, so maybe it's managed to mine a block and got forked.
134 2013-08-30 03:00:59 <petertodd> Ah
135 2013-08-30 03:01:14 <doublec> I have a node that constantly warns ""Warning: Please check that your computer's date and time are correct! If your clock is wrong Bitcoin will not work properly."
136 2013-08-30 03:01:21 <doublec> but time is correct as far as I can see
137 2013-08-30 03:01:28 <gmaxwell> doublec: time zone correct?
138 2013-08-30 03:01:30 <petertodd> doublec: timezone correct?
139 2013-08-30 03:01:39 <gmaxwell> usually thats a result of the timezone being wrong.
140 2013-08-30 03:01:45 <petertodd> say-the-same-thing...
141 2013-08-30 03:02:14 <lianj> woa, lots of blocks currently
142 2013-08-30 03:02:43 <doublec> seems to be, I'm on NZST
143 2013-08-30 03:02:54 <doublec> but I'll investigate
144 2013-08-30 03:03:09 <petertodd> doublec: bitcoind getinfo, what does 'timeoffset' say?
145 2013-08-30 03:03:40 <gmaxwell> (hm why doesn't peerinfo return the peers timeoffsets)
146 2013-08-30 03:04:00 <petertodd> good idea
147 2013-08-30 03:05:07 <doublec> petertodd: I don't have a timeoffset (running 0.8.1)
148 2013-08-30 03:05:36 <petertodd> doublec: hmm... well I'd suggest upgrading for a lot of reasons anyway
149 2013-08-30 03:06:11 <doublec> in my debug.log I see bunches of Added time data, samples 11, offset -1 (+0 minutes)
150 2013-08-30 03:06:22 <doublec> and the occasional Added time data, samples 2, offset -2505753 (-41762 minutes)
151 2013-08-30 03:06:24 <gmaxwell> 0_o
152 2013-08-30 03:07:15 <doublec> most entries are very small offsets
153 2013-08-30 03:07:25 <doublec> those large ones are on initial node startup
154 2013-08-30 03:08:03 <petertodd> gmaxwell: Ah, here's why: nTime from the 'version' message isn't saved, just added to the time data.
155 2013-08-30 03:08:36 <gmaxwell> yea that should be fixed.. we shouldn't be using time from peers we're not connected to to build our correction in any case.
156 2013-08-30 03:09:31 <petertodd> gmaxwell: So save nTimeOffset's for each peer, and compute the master off-set from the set of current peers?
157 2013-08-30 03:09:48 <petertodd> gmaxwell: Oh, and should be only outgoing peers I think.
158 2013-08-30 03:10:19 <gmaxwell> doublec: okay you have that message because at start you had a bunch of times way off from yours and none like yours and it seems we never remove the message once triggered.
159 2013-08-30 03:10:30 <doublec> gmaxwell: ah ok, makes sense, thanks
160 2013-08-30 03:11:05 <gmaxwell> petertodd: my thought was to include incoming but only if they're within a small window of the time you got from outgoing.
161 2013-08-30 03:11:19 <petertodd> gmaxwell: Fair enough, to fine-tune.
162 2013-08-30 03:12:15 <petertodd> gmaxwell: Though easier just to not include them re: calculating it - then it can be a simple mapTimeOffset<peer> where peers are added and removed as needed.
163 2013-08-30 03:13:25 <petertodd> gmaxwell: Er, heck, peers are small enough just iterate over the peer list every time a peer is added/dropped...
164 2013-08-30 03:14:42 <gmaxwell> I'd also like to have some (sadly platform specific) code to check if ntp is in use and healthy and if so, to refuse to believe far off peer times.
165 2013-08-30 03:15:02 <petertodd> reasonable
166 2013-08-30 03:15:25 <gmaxwell> hm. also need to change it to undercorrect by 1 second (towards your local time) so that the network will drift back if it gets offset.
167 2013-08-30 03:15:55 <gmaxwell> e.g. you think the time is 100 network says 150  then your corrected time should be 149.
168 2013-08-30 03:16:18 <petertodd> ha, yeah, you can do that pull-req, or I could just make a accidental off-by-one error in mine...
169 2013-08-30 03:16:51 <gmaxwell> yea, the only reason I haven't done it already is I'd like to actualy try out the behavior and its kind of a pita.
170 2013-08-30 03:16:57 <petertodd> yup
171 2013-08-30 03:17:17 <gmaxwell> e.g. see how long it takes to readjust
172 2013-08-30 03:17:40 <petertodd> and god help you if you accidentally the other way...
173 2013-08-30 03:18:15 <gmaxwell> hey, cute way to sneak in an inflationary bug in an altcoin, esp if you remove the sanity check so network time can go far into the future.
174 2013-08-30 03:18:27 <petertodd> ha
175 2013-08-30 03:18:38 <gmaxwell> esp since so long as eveyone's clock agrees it would be stable.
176 2013-08-30 03:19:00 <gmaxwell> so you could start off with a couple nodes and it would look fine.. and then the clock starts slipping forward and blocks get faster and faster in realtime.
177 2013-08-30 03:19:13 <petertodd> yeah, fixing that would be damn ugly
178 2013-08-30 03:19:36 <gmaxwell> well esp if you didnt notice for a while and built a bunch of far future chain.
179 2013-08-30 03:35:15 <maaku> whoever keeps spamming that malformed unicode, please (1) kindly stop, and (2) die in a fire
180 2013-08-30 03:35:48 <maaku> i have to drop into sql to find and delete chat history for my irc client to even load up again
181 2013-08-30 03:35:52 <maaku> seriously not fun
182 2013-08-30 03:39:18 <gmaxwell> maaku: hopefully exploitation of that bug can't lead to something worse???
183 2013-08-30 03:39:45 <gmaxwell> also, your latest attacker is 21:02 < lianj> sorry for offtopic but want to see how many disconnect.. if any???
184 2013-08-30 03:40:08 <maaku> quite possibly could; things like this make me nervious about running osx
185 2013-08-30 03:41:35 <gmaxwell> I don't yet do this for the terminal I IRC in, but I do all my webbrowsing in a VM because of the nastyness of the internet.
186 2013-08-30 03:41:52 <maaku> good idea i think i'll start the same
187 2013-08-30 03:42:21 <petertodd> ;;google irsii exploits for the version gmaxwell uses
188 2013-08-30 03:42:22 <gribble> No matches found.
189 2013-08-30 03:42:29 <petertodd> guess you're safe
190 2013-08-30 03:42:46 <lianj> totally ^^
191 2013-08-30 03:43:08 <maaku> bug has all the symptoms of a buffer overflow ... wouldn't be suprised if a clever construction enabled remote execution
192 2013-08-30 03:44:13 <lianj> will see. don't have an apple machine with osx on it to tinker
193 2013-08-30 03:44:27 <lianj> and ofc am not clever enough
194 2013-08-30 03:44:59 <CodeShark> there's an IRC attack going on?
195 2013-08-30 03:45:18 <maaku> CodeShark: it's a os x vulnerability
196 2013-08-30 03:45:24 <CodeShark> oh? what is it?
197 2013-08-30 03:45:59 <CodeShark> my limechat has been crashing today
198 2013-08-30 03:46:00 <maaku> unicode sequence that when processed by CoreText (osx/ios' text rendering framework) crashes the process
199 2013-08-30 03:46:06 <CodeShark> aha
200 2013-08-30 03:46:11 <CodeShark> interesting
201 2013-08-30 03:46:37 <maaku> http://techcrunch.com/2013/08/29/bug-in-apples-coretext-allows-specific-string-of-characters-to-crash-ios-6-os-x-10-8-apps/
202 2013-08-30 03:47:21 <maaku> haha, people put it in their wifi network name
203 2013-08-30 03:47:37 <maaku> crash any ios device nearby with wifi on
204 2013-08-30 03:48:15 <gmaxwell> I don't think you can put non-ascii in a ssid.
205 2013-08-30 03:48:27 <edcba> why not lol
206 2013-08-30 03:48:28 <lianj> didn't know ssids supported unicode
207 2013-08-30 03:48:35 <edcba> it's all bytes
208 2013-08-30 03:48:40 <lianj> true
209 2013-08-30 03:48:47 <lianj> but that ios read it as such
210 2013-08-30 03:49:04 <gmaxwell> Should name my AP ?????????
211 2013-08-30 03:49:19 <maaku> gmaxwell: i think i will
212 2013-08-30 03:49:27 <maaku> or PILE OF POO
213 2013-08-30 03:49:31 <Diablo-D3> name it unicode for poo
214 2013-08-30 03:49:34 <Diablo-D3> damnit maaku
215 2013-08-30 03:49:34 <lianj> gmaxwell: nice to type then
216 2013-08-30 03:49:47 <ThomasV> I'd like to know what the string means in Arabic
217 2013-08-30 03:49:56 <lianj> prolly gibberish
218 2013-08-30 03:50:37 <CodeShark> if it actually meant something in arabic that would have some pretty ugly implications :p
219 2013-08-30 03:51:18 <ThomasV> lol yeah
220 2013-08-30 03:51:22 <gmaxwell> CodeShark: no worse than "Bush hid the facts"
221 2013-08-30 03:51:55 <lianj> http://i.imgur.com/NEywyVS.png
222 2013-08-30 03:52:11 <gmaxwell> (windows overzealous charset determination code would turn any textfile that started with that string into mojobake due to parsing it at UCS-2)
223 2013-08-30 03:53:39 <maaku> gmaxwell: the multi-party sort requires a serial chain of operations, yes?
224 2013-08-30 03:53:52 <maaku> that might be requiring a bit much...
225 2013-08-30 03:54:22 <gmaxwell> maaku: yes, darnit I went for a walk right after writing that and ment to go add as a disadvantage is that it requires all parties to be online in realtime.
226 2013-08-30 03:54:44 <gmaxwell> I mean, technically it doesn't but it's log^2 N rounds of communication.
227 2013-08-30 03:55:29 <gmaxwell> er. log2^2 N  so if you're only logging in once a day it'll be 10 days to complete your computation. :P
228 2013-08-30 03:58:55 <gmaxwell> maaku: the number of rounds of corse depends on the geometry of the sorting network. the implemention in viff.dk has a sort which uses more than the theoretical minimum number, but has a lot of parallelism.
229 2013-08-30 03:59:38 <gmaxwell> er uses more than the minimum number of comparisons... but I don't think one can be done which has less than log2^2(N) communication.
230 2013-08-30 04:36:36 <gmaxwell> so.. that "mastercoin" thing has started its blockchain spamming. :(
231 2013-08-30 04:36:37 <gmaxwell> https://blockchain.info/address/15og4WXZPwkMnnsb3dj6HqgTUfcRLx4J9b
232 2013-08-30 04:37:50 <petertodd> wtf?
233 2013-08-30 04:38:44 <gmaxwell> it works by sending a colored coin to a destination bitcoin address (mastercoin payment), and then also using two additional txouts to embed data.
234 2013-08-30 04:38:56 <petertodd> ugh
235 2013-08-30 04:39:24 <gmaxwell> https://sites.google.com/site/2ndbtcwpaper/MasterCoin%20Specification.pdf
236 2013-08-30 04:39:51 <gmaxwell> so his system attacks us with perpetually unprunable data for every transaction.
237 2013-08-30 04:39:52 <petertodd> what a dumb-ass - could have done that with multisig
238 2013-08-30 04:40:08 <gmaxwell> I'm sorry, I was incorrect to not be worried about it a few days ago.
239 2013-08-30 04:40:20 <gmaxwell> He's not bringing in mobs of support with a mastercoin giveaway.
240 2013-08-30 04:40:25 <gmaxwell> s/not/now/
241 2013-08-30 04:41:13 <petertodd> well yet another example of why the only real limit on UTXO growth is the blocksize limit
242 2013-08-30 04:42:09 <gmaxwell> well, as why utxo expiration is necessary.. while I'm bending my mind to figure out ways to get people to clean up txouts, this guy is pumping the chain full of forever unspendable ones.
243 2013-08-30 04:42:41 <gmaxwell> it looks like the system requires all the txn to involve particular addresses, so it seems it would currently be pretty easy to block directly.
244 2013-08-30 04:42:55 <petertodd> yeah, although that can change pretty easily
245 2013-08-30 04:44:29 <petertodd> This is also why i keep on saying OP_RETURN should be pushed forward, and on top of that it should be strictly easier and cheaper to use it than any other mechanism
246 2013-08-30 04:47:36 <gmaxwell> petertodd: but as you said, he could have been using multisig for this. There isn't a technical issue here.
247 2013-08-30 04:49:16 <petertodd> gmaxwell:Yes, but if you say over and over again "hey! here's this op return mechanism!" people will know about it. The multisig trick isn't well known.
248 2013-08-30 04:51:02 <petertodd> Also note how we could easily make a new address to make it trivial to pay to op_return, perhaps starting with 0 or x or d
249 2013-08-30 04:51:38 <petertodd> Of course, yeah, there are limits to how far such measures can go...
250 2013-08-30 04:51:45 <gmaxwell> petertodd: I had the idea of 0 value outputs in sendtoaddress and sendmany being an OP_RETURN that pushes the unpacked address as data.
251 2013-08-30 04:51:51 <petertodd> yup
252 2013-08-30 04:52:36 <gmaxwell> in any case, I made a simple post https://bitcointalk.org/index.php?topic=272577.msg3040712#msg3040712
253 2013-08-30 04:52:41 <gmaxwell> lets see what happens there.
254 2013-08-30 04:53:13 <petertodd> IMO mention the multisig thing right there
255 2013-08-30 04:53:28 <gmaxwell> I didn't think we had to actually worry about this because he hasn't written his software yet. I believe are all just transactions he's doing 'by hand' in order to promote his system.
256 2013-08-30 04:53:56 <petertodd> heh, which means he probably can't easily do a multisig scriptPubKey...
257 2013-08-30 04:54:36 <gmaxwell> should figure out whos mining these things.
258 2013-08-30 04:55:14 <petertodd> everyone is: they are fee paying
259 2013-08-30 04:55:24 <petertodd> just barely follow gavin's rule too
260 2013-08-30 04:55:48 <gmaxwell> ah, indeed I can't count zeros
261 2013-08-30 04:56:03 <petertodd> at least it's just 73, for now...
262 2013-08-30 05:00:12 <gmaxwell> this is an example somewhat of the futility of trying to use rule to enforce behavior.  People are urinating on the wall of town hall, you put up a fence to stop them... and they just urinate on the fence and insist that it's righteous because they stayed outside of the fence like the rule said.
263 2013-08-30 05:00:45 <gmaxwell> It's really hard to have a rule and have people not interpret its boundary as a permission.
264 2013-08-30 05:00:48 <petertodd> Yup. What you need is an electric fence.
265 2013-08-30 05:01:30 <gmaxwell> radioactive fence.
266 2013-08-30 05:01:58 <petertodd> electric radioactive fence - when you're going for a darwin award, might as well have some redundency
267 2013-08-30 05:09:47 <gmaxwell> petertodd: :(
268 2013-08-30 05:10:11 <gmaxwell> some searching reveals that he was fighting against the anti-dust changes and it was pointed out to him that unprunable data is bad.
269 2013-08-30 05:10:25 <petertodd> figures
270 2013-08-30 05:10:35 <gmaxwell> so I'm not hopeful that this is a simple education matter.
271 2013-08-30 05:11:13 <petertodd> The only good solution is hard limits IMO; I told Warren I'd be happy to help out on a UTXO expiration proposal for Litecoin.
272 2013-08-30 05:12:00 <gmaxwell> 'Yup! But it's not a deal-breaker. Upon further consideration, I realized it's just another form of "you have to pay to put data in the block chain" which is fine. It doesn't prevent message-based protocols from working.'
273 2013-08-30 05:12:37 <petertodd> wow
274 2013-08-30 05:12:47 <petertodd> I wonder if he really understands what the UTXO set even is
275 2013-08-30 05:13:36 <gmaxwell> (Thats from this thread: https://bitcointalk.org/index.php?topic=197799.msg2395350#msg2395350)
276 2013-08-30 05:14:11 <petertodd> gah
277 2013-08-30 05:14:26 <gmaxwell> At least we can be happy that he doesn't have software for it yet... 100 people doing this would be worse than one...
278 2013-08-30 05:14:29 <petertodd> the colored coin community in general seems to be filled with stupid people
279 2013-08-30 05:14:46 <gmaxwell> I have a super sexy hammer, you are now my nail.
280 2013-08-30 05:15:10 <gmaxwell> I'm guilty of it too, finding all kinds of things to throw SCIP at... but at least that fixation doesn't create big externalized costs.
281 2013-08-30 05:15:11 <petertodd> ...and you said I'm full of cringe-worthy ideas
282 2013-08-30 05:15:57 <gmaxwell> Colored coins people hit on the BIG IDEA that bitcoin tracks things and then the mind spins with all the things you could track, without stopping to think if all of them really make sense to track using bitcoin.
283 2013-08-30 05:16:28 <petertodd> yup, whereas smart people realize the nuances of what exactly bitcoin can track - in particular what exactly bitcoin means for trust
284 2013-08-30 05:16:46 <petertodd> thinking the colored coins are even important is a huge red flag...
285 2013-08-30 05:18:06 <gmaxwell> well I've thought they were neat but on reflection keep realizing that almost any use involves some kind of trusted entity to give them meaning, and in that case??? might as well have that entity do the tracking.
286 2013-08-30 05:18:43 <petertodd> yup. The *one* example where colored coins actually can make sense is fidelity bonds.
287 2013-08-30 05:19:07 <gmaxwell> oh it's not the _one_ you can construct other ones, but fewer than people seem to think.
288 2013-08-30 05:19:27 <petertodd> oh yeah? examples?