1 2012-02-04 00:17:53 <Ferroh> There are checkpoints in the blockchain that prevent you from adding blocks before a certain point in time, correct?
  2 2012-02-04 00:18:22 <Ferroh> How often do these checkpoints occur?
  3 2012-02-04 00:19:24 <Ferroh> They are hardcoded iirc so how many checkpoints are there?
  4 2012-02-04 00:19:34 <gmaxwell> Use the source, luke.
  5 2012-02-04 00:19:51 <Ferroh> Well, are there more than 10?
  6 2012-02-04 00:20:06 <Ferroh> yes i could use the source grumble grumble
  7 2012-02-04 00:20:12 <gmaxwell> There are 9 now.
  8 2012-02-04 00:20:18 <Ferroh> ok thanks :)
  9 2012-02-04 00:20:19 <gmaxwell> I guess 10 if you count block 0.
 10 2012-02-04 00:20:41 <shargs> https://github.com/bitcoin/bitcoin/blob/master/src/checkpoints.cpp
 11 2012-02-04 00:20:43 <vsrinivas> Ferroh: its not difficult actually -- see checkpoints.cpp is src.
 12 2012-02-04 00:21:35 <gmaxwell> freewil: they prevent some silly dos attacks and prevent a network isolated node (that got a good copy of the source) from being fed a fake chain.
 13 2012-02-04 00:42:26 <Mqrius> Wtf? Is sending an RPC that doesn't exist supposed to crash bitcoin?
 14 2012-02-04 00:44:07 <gmaxwell> Mqrius: what answer are you expecting there?
 15 2012-02-04 00:44:20 <gmaxwell> "Oh, yes, Mqrius it's a security feature you see..."
 16 2012-02-04 00:44:48 <gmaxwell> Doesn't crash it for me have a reproduction?
 17 2012-02-04 00:45:01 <Mqrius> Well, I don't use RPC often, so I was wondering if this was normal. Personally I would expect it to just return an error or something, instead of crash.
 18 2012-02-04 00:45:09 <Mqrius> So, I'm wondering if that's normal or not
 19 2012-02-04 00:45:16 <gmaxwell> bitcoind dslfsdk
 20 2012-02-04 00:45:59 <copumpkin> Mqrius: perhaps you overflowed a nice buffer in your message ;)
 21 2012-02-04 00:45:59 <Mqrius> I'm using bitcoin client 0.5.0.1-beta on windows, with python as rpc, and tried the command service.getblocks()
 22 2012-02-04 00:47:29 <gmaxwell> Mqrius: any idea what RPC getblocks calls?
 23 2012-02-04 00:47:57 <Mqrius> It doesn't exist, or at least according to the wiki. (I was looking for the function getblockcount)
 24 2012-02-04 00:48:30 <gmaxwell> Mqrius: and bitcoin itself crashed?
 25 2012-02-04 00:49:01 <Mqrius> Yeah. The GUI, but that has bitcoind integrated in it in windows if I understand it correctly.
 26 2012-02-04 00:50:12 <gmaxwell> yes, if you enable it.
 27 2012-02-04 00:50:29 <gmaxwell> can you try again and see if it happens every time?
 28 2012-02-04 00:51:13 <Mqrius> gmaxwell: Yes, happens every time, also for different (nonexistant) commands
 29 2012-02-04 00:53:15 <gmaxwell> where is the python rpc library you're using?
 30 2012-02-04 00:53:59 <Mqrius> It's the default, python-jsonrpc
 31 2012-02-04 00:54:29 <Mqrius> It's built-in if I'm not mistaken.
 32 2012-02-04 00:54:43 <Mqrius> (Python v2.7 btw)
 33 2012-02-04 00:59:00 <gmaxwell> Mqrius: hmph. no crash here.
 34 2012-02-04 00:59:09 <gmaxwell> In [4]: access.getblocks()
 35 2012-02-04 00:59:19 <gmaxwell> In [5]: access.getinfo()
 36 2012-02-04 00:59:20 <gmaxwell> {'balance':
 37 2012-02-04 00:59:58 <Mqrius> Strange.
 38 2012-02-04 01:00:00 <gmaxwell> perhaps its .5.0 specific, windows specific, or -qt specific. :-/
 39 2012-02-04 01:00:07 <Mqrius> Yeah, I guess
 40 2012-02-04 01:00:21 <Mqrius> I'll just not use non-existant commands then :)
 41 2012-02-04 01:00:50 <gmaxwell> well... hopefully someone who is configured more like you than I am will test and wee which of those reasons it is.
 42 2012-02-04 01:04:57 <Mqrius> Fair enough.
 43 2012-02-04 01:10:48 <Mqrius> Nice, my new-block-beeper is working :)
 44 2012-02-04 01:13:36 <Mqrius> *beep*
 45 2012-02-04 01:17:27 <gmaxwell> hmp I would have just read the log file rather than the rpc.
 46 2012-02-04 01:22:00 <Mqrius> Hmm, it's just very simple and short to get the number of blocks directly. I'd have to look into what is logged etc otherwise, and also you can't monitor a file for changes on windows afaik
 47 2012-02-04 01:28:18 <roconnor> are orphan transactions relayed?
 48 2012-02-04 01:28:24 <roconnor> in the standard client?
 49 2012-02-04 01:30:03 <gmaxwell> No.
 50 2012-02-04 01:32:56 <echolabia> I downloaded Bitcoin yesterday, and my internet unexpectedly cut out when I had almost completed "catching up" on the blockchain. Now I have "0 active connections to the bitcoin network," and the blockchain is still incomplete. Is it possible to restart my connection to the network?
 51 2012-02-04 01:33:53 <gmaxwell> echolabia: sure. it'll reconnect on its own.
 52 2012-02-04 01:34:11 <roconnor> gmaxwell: I think the bitcoin 0.4.0 client is relaying my transaction that tries to spend my unsendable duplicated coinbase.
 53 2012-02-04 01:34:16 <gmaxwell> (and it will resume exactly where it was)
 54 2012-02-04 01:34:39 <roconnor> gmaxwell: given that the long says it got a bunch of getdata requests for it.
 55 2012-02-04 01:34:42 <roconnor> *log
 56 2012-02-04 01:35:00 <echolabia> gmaxwell: that's what I thought: it's just been a while and still no active connections. Guess I'll be patient! Thanks for the help.
 57 2012-02-04 01:35:50 <gmaxwell> echolabia: if you restart it it should connect again instantly. but if it's not doing it on its own it a bit .. sounds like a bug.
 58 2012-02-04 01:36:03 <gmaxwell> roconnor: hm.
 59 2012-02-04 01:36:04 <roconnor> gmaxwell: oh and it also appears in the old gui ... and it has one confirmation ??
 60 2012-02-04 01:36:29 <roconnor> WTF
 61 2012-02-04 01:37:08 <gmaxwell> I don't quite follow what you're testing. You have a duplicate coinbase. And you think you've spent it twice?
 62 2012-02-04 01:37:30 <roconnor> I made a coin base
 63 2012-02-04 01:37:32 <roconnor> spent it
 64 2012-02-04 01:37:34 <roconnor> made it again
 65 2012-02-04 01:37:45 <roconnor> and now I'm trying to spend the duplicated one
 66 2012-02-04 01:38:13 <gmaxwell> the node will always relay its own transactions even if they are unspendable gibberish.
 67 2012-02-04 01:39:10 <roconnor> my client is upto 45654 blocks ... now my transaction has 2 confirmations ... blockexporer is refusing to show block 45653
 68 2012-02-04 01:39:20 <roconnor> but does show block 45654
 69 2012-02-04 01:39:28 <roconnor> http://blockexplorer.com/testnet
 70 2012-02-04 01:39:29 <roconnor> check it
 71 2012-02-04 01:39:31 <roconnor> out
 72 2012-02-04 01:39:46 <roconnor> ... I think the idea that you cannot spend a duplicate coinbase is a lie
 73 2012-02-04 01:40:05 <roconnor> though blockexplorer is very unhappy about it
 74 2012-02-04 01:40:15 <gmaxwell> So spend it again?
 75 2012-02-04 01:40:22 <roconnor> gmaxwell: you want it?
 76 2012-02-04 01:40:25 <gmaxwell> I mean, if you can spend it twice why not 200 times?
 77 2012-02-04 01:40:41 <roconnor> gmaxwell: well presumably I will have to duplicate it again
 78 2012-02-04 01:40:48 <roconnor> this is not a double spend
 79 2012-02-04 01:41:10 <gmaxwell> I wonder which one it spent first.
 80 2012-02-04 01:41:16 <roconnor> it is a ligitmate transaction that happens to have exactly the same has as a previous spent transaction.
 81 2012-02-04 01:41:24 <roconnor> gmaxwell: I spent the original coinbase first
 82 2012-02-04 01:41:38 <roconnor> before I mined the duplicate coinbase.
 83 2012-02-04 01:41:42 <gmaxwell> ah.
 84 2012-02-04 01:42:44 <roconnor> so I claim that mining a coinbase and spending it and remining it and spending it again is legal.
 85 2012-02-04 01:42:47 <gmaxwell> I wonder what would happen if you duplicated a coinbase and in the duplicate block spent the first one?
 86 2012-02-04 01:42:55 <roconnor> arguably the spend spend isn't spending it again.
 87 2012-02-04 01:43:09 <roconnor> but spending a new coin that has an indentical name
 88 2012-02-04 01:43:24 <roconnor> gmaxwell: that would be the next test
 89 2012-02-04 01:44:06 <roconnor> but I guess it would be like doing a duplicate coinbase, there can only be one unspendable coin at a time; however ...
 90 2012-02-04 01:44:51 <gmaxwell> or one after .. when it .. really would get killed by the maturity check.
 91 2012-02-04 01:44:55 <roconnor> gmaxwell: still, I wonder if this can be turned into some sort of double spend attack involving an innocent block reorg.
 92 2012-02-04 01:45:58 <roconnor> theymos: I broker the BBE on testnet!
 93 2012-02-04 01:46:01 <roconnor> *broke
 94 2012-02-04 01:46:09 <roconnor> where is theymos when you need him :P
 95 2012-02-04 01:47:09 <gmaxwell> so.. yea.. mine, spend, dupemine, spenddupe .. reorg removing the dupemine.. will spend dupe get reinserted? I don't think so, remember how that works.
 96 2012-02-04 01:47:57 <roconnor> gmaxwell: removing the dupemine is too hard  ... at least I think
 97 2012-02-04 01:48:06 <roconnor> I waited 100 blocks before trying to spenddupe
 98 2012-02-04 01:48:13 <roconnor> I should have tried earlier
 99 2012-02-04 01:49:12 <roconnor> gmaxwell: I was thinking mine spend spend2; dupemine, spenddupe, prepare spenddupe2  ??? profit
100 2012-02-04 01:52:28 <gmaxwell> oh.. so using it to bypass the maturity check
101 2012-02-04 01:52:40 <roconnor> ya
102 2012-02-04 01:52:49 <roconnor> but there are some details that need filling in
103 2012-02-04 01:52:53 <roconnor> around the ??? part
104 2012-02-04 01:53:28 <gmaxwell> yea, though if so thats not too terrible at least..
105 2012-02-04 01:55:06 <roconnor> how do I leave a message for theymos that I blew up block 45653 on testnet?
106 2012-02-04 01:56:04 <roconnor> gmaxwell: ??? might involve non-merchant databases.
107 2012-02-04 01:56:24 <roconnor> that are assuming that transactions ID are unique.
108 2012-02-04 01:59:26 <shargs> vuvuzela
109 2012-02-04 02:00:37 <roconnor> man, I put a 25 TBTC transaction fee on that since I didn't think the transaction was valid. :D
110 2012-02-04 02:06:25 <roconnor> gmaxwell: setup transactions 0A , AB, BC, 0A, AB, then place (CD, BC, CE) in a block, the reoginaize by replacing that block with (BC, CD) which makes CE supposedly unspendable.
111 2012-02-04 02:06:50 <roconnor> gmaxwell: XY is a transaction consuming coin X and producing coin Y.
112 2012-02-04 02:07:02 <theymos> roconnor: What'd you do to cause a block to go missing from BBE testnet?
113 2012-02-04 02:07:04 <roconnor> gmaxwell: 0X is a coinbase transaction producing a coin with hash X.
114 2012-02-04 02:07:33 <gmaxwell> the bigger area of concern for me in this space is if you can make a sequence that nodes who see the reorg accept but nodes who just go from history reject.
115 2012-02-04 02:07:33 <roconnor> theymos: I made a coinbase transaciton, spent it, remade a coinbase that has the same ID, and spent that.
116 2012-02-04 02:07:57 <roconnor> theymos: the block cointaing that last spend is missing.
117 2012-02-04 02:09:28 <roconnor> gmaxwell: it is things like this that make me wonder why anyone would put there life savings into bitcoin. :D
118 2012-02-04 02:10:26 <roconnor> on the bright side, I think my Haskell implementation isn't broken after all
119 2012-02-04 02:10:43 <gmaxwell> roconnor: if you look far enough you'll find people who put their life savings into beanybabies.
120 2012-02-04 02:11:03 <roconnor> gmaxwell: seems wiser than bitcoins :D
121 2012-02-04 02:12:10 <gmaxwell> roconnor: you're expressing a lot of confidence about all the non-technical reasons doing that would be a terribly stupid idea by suggesting possible brokenness here is a big factor! :)
122 2012-02-04 02:13:02 <roconnor> gmaxwell: not this specific issue, but I think it is representative of the general quality of the bitcoin core protocol. anyhow, I didn't mean to start an argument about this.
123 2012-02-04 02:13:37 <roconnor> there is a tricky issue in what happens with duplicate coinbase transactions that are mined within the 100 block vesting period.
124 2012-02-04 02:13:47 <roconnor> my haskell implemenation might get it wrong.
125 2012-02-04 02:13:55 <gmaxwell> roconnor: oh, I didn't intend to argue. Sorry!
126 2012-02-04 02:14:06 <roconnor> oh good
127 2012-02-04 02:14:41 <roconnor> for example I think my implementation my accept the follow:
128 2012-02-04 02:15:17 <roconnor> mine a coin base, 70 blocks later mine it again, 30 blocks later spend the first coinbase, 30 blocks later spend the second coinbase
129 2012-02-04 02:15:17 <theymos> Duplicate transactions should just be rejected IMO.
130 2012-02-04 02:15:59 <roconnor> theymos: that would require remembering the hash of every coinbase ... probably reasonable.
131 2012-02-04 02:16:06 <luke-jr> O.o
132 2012-02-04 02:16:16 <luke-jr> or just having a hash table of them
133 2012-02-04 02:16:30 <roconnor> luke-jr: how is that different?
134 2012-02-04 02:16:54 <luke-jr> hash table uses less RAM? :P
135 2012-02-04 02:17:11 <roconnor> hash tables solve everything!!
136 2012-02-04 02:17:34 <gmaxwell> ESPECIALLY IF DISTRIBUTED!?!?!!
137 2012-02-04 02:20:11 <roconnor> gmaxwell: I don't suppose there is an easy way to figure out the details of what is and is not valid in this corner case?
138 2012-02-04 02:20:36 <roconnor> getting it wrong in my client could cause a chain fork.
139 2012-02-04 02:22:20 <graingert> !google hashdos
140 2012-02-04 02:22:21 <gribble> HashDoS - Twitter: <http://twitter.com/hashdos>; Large percentage of websites vulnerable to HashDoS denial of ...: <http://nakedsecurity.sophos.com/2011/12/28/large-percentage-of-websites-vulnerable-to-hashdos-denial-of-service-attack/>; Effective DoS attacks against Web Application Plattforms  #hashDoS: <http://cryptanalysis.eu/blog/2011/12/28/effective-dos-attacks-against-web- (1 more message)
141 2012-02-04 02:23:56 <graingert> luke-jr: if you're making a serious suggestion, a hash table of hashes
142 2012-02-04 02:24:20 <luke-jr> sounds good then
143 2012-02-04 02:24:23 <luke-jr> DHT of transaction ids
144 2012-02-04 02:28:07 <roconnor> I guess armory is broken too
145 2012-02-04 02:33:37 <theymos> roconnor: I figured out how you broke BBE testnet. There is an SQL constraint preventing outputs from being spent twice, and your weird transaction failed the constraint. Did you actually spend a tx twice from some point of view, or is BBE totally imagining this?
146 2012-02-04 02:33:58 <roconnor> theymos: I did spend a tx twice from some point of view
147 2012-02-04 02:36:15 <theymos> Why did the network not reject the second transaction?
148 2012-02-04 02:36:52 <roconnor> theymos: because the first tx was already spend, and so when I made the same coinbase again it was spendable.
149 2012-02-04 02:40:28 <roconnor> theymos: this is going to be a pain for you to fix I imagine.
150 2012-02-04 02:42:22 <theymos> Probably I can just remove the constraint, but I want to understand why this was allowed. So you created a coinbase, spent it, created a duplicate coinbase, and spent that? My understanding was that Bitcoin would essentially ignore the second coinbase.
151 2012-02-04 02:42:38 <roconnor> theymos: That is what I did
152 2012-02-04 02:42:50 <roconnor> theymos: hey, what do you expect for an undocumented protcol.
153 2012-02-04 02:43:13 <roconnor> fine, ... losely documented protocol.
154 2012-02-04 02:43:19 <luke-jr> lol
155 2012-02-04 02:45:08 <theymos> Bitcoin marks outputs in the first transaction as unspent when it receives the duplicate coinbase?
156 2012-02-04 02:45:38 <luke-jr> theymos: my guess would be it replaces the first txn with the 2nd
157 2012-02-04 02:45:42 <roconnor> theymos: what do you mean by first transaction?
158 2012-02-04 02:45:52 <theymos> The first coinbase that is later duplicated.
159 2012-02-04 02:47:15 <roconnor> in my example, I presume, the first coinbase output is marked as spent when it is spend and then from that point on it is as if the first coinbase never existed.
160 2012-02-04 02:47:40 <roconnor> oh god, what happens when I spend one of two coinbase outputs and then duplicate the coinbase.
161 2012-02-04 02:47:44 <roconnor> it boggles my mind.
162 2012-02-04 02:48:01 <roconnor> theymos: there are about a billion variations that I have no idea what happens.
163 2012-02-04 02:48:52 <luke-jr> I suspect the first coinbase txn simply become inaccessible
164 2012-02-04 02:48:52 <theymos> There were already known attacks due to duplicate coinbases, but I was unaware of this behavior and it's very worrying. Previously I thought that Bitcoin would treat the duplicate coinbase as just a "reference" to the original one. Overwriting it is much worse.
165 2012-02-04 02:49:28 <josephcp> i think only the first one gets spent, the second is ignored
166 2012-02-04 02:50:28 <roconnor> my implementation overwrites the old coinbase ... but I guess that doesn't really say much about the reference implementation.
167 2012-02-04 02:51:01 <roconnor> theymos: what were the known attacks and how were they fixed?
168 2012-02-04 02:51:11 <josephcp> hrmmm
169 2012-02-04 02:51:55 <josephcp> do you have the tx hash in testnet?
170 2012-02-04 02:52:39 <roconnor> josephcp: the coinbase is a1d7c19f72ce5b24a1001bf9c5452babed6734eaa478642379f8c702a46d5e27
171 2012-02-04 02:52:56 <roconnor> the first spend is 0018417e23c7ad94c62e3dbcd571df2fb23f29ba375ffb5709701e9812ee8286
172 2012-02-04 02:52:57 <josephcp> the second spend?
173 2012-02-04 02:53:14 <roconnor> the second spend is fae8bfd6a2d98294416d8d280d3637682e87ad71e0dfc6b8b20804263067c42d
174 2012-02-04 02:53:15 <josephcp> ok thnks
175 2012-02-04 02:54:24 <theymos> roconnor: It wasn't fixed. Gavin's message from bitcoin-security: http://pastebin.com/jYyzBcrz
176 2012-02-04 02:55:35 <luke-jr> theymos: where is the subscribe for that?
177 2012-02-04 02:55:41 <theymos> It's private.
178 2012-02-04 02:55:42 <roconnor> theymos: this seems to indicate you don't need to do the attack on coinbases, and bipass the 100 transaction requirement there
179 2012-02-04 02:55:50 <luke-jr> theymos: I should be on it :p
180 2012-02-04 02:56:11 <roconnor> theymos: I'm not yet convinced it is any worse than a typical 1-confirmation attack.
181 2012-02-04 02:56:18 <roconnor> theymos: but it is very worrying
182 2012-02-04 02:56:22 <roconnor> I don't know the full implications.
183 2012-02-04 02:56:46 <josephcp> either way being able to spend it twice seems bad in and of itself
184 2012-02-04 02:56:54 <theymos> Yeah, I'm really bothered by this strange behavior. It'd be best to just reject duplicates and not worry about it.
185 2012-02-04 02:57:03 <luke-jr> theymos: that's more damaging that what you posted suggests
186 2012-02-04 02:57:05 <josephcp> because modeling the schema is wrong as hell
187 2012-02-04 02:57:15 <josephcp> you have duplicate primary keys
188 2012-02-04 02:57:28 <luke-jr> theymos: ignore duplicates would be better IMO
189 2012-02-04 02:57:32 <roconnor> josephcp: ya, even if bitcoin is somehow still sound, it is hell for merchants
190 2012-02-04 02:57:54 <josephcp> yeah, it breaks things and "feels" like there might be other unexplored vulnerabilities
191 2012-02-04 02:58:06 <luke-jr> if someone pulls off the "cancel someone else's coinbase" attack, they can split the network with it&
192 2012-02-04 02:58:10 <josephcp> can you try spending it a 3rd time? I know it's VERY VERY unlikley to work
193 2012-02-04 02:58:21 <luke-jr> will -rescan fix it, I wonder?
194 2012-02-04 02:58:26 <roconnor> huh?
195 2012-02-04 02:58:51 <theymos> BBE testnet is fixed now.
196 2012-02-04 02:58:59 <theymos> (And I removed that constraint from mainnet.)
197 2012-02-04 02:59:09 <roconnor> theymos: that was fast
198 2012-02-04 02:59:30 <roconnor> theymos: ah
199 2012-02-04 02:59:37 <roconnor> theymos: arguably http://blockexplorer.com/testnet/block/0000000013aa9f67da178005f9ced61c7064dd6e8464b35f6a8ca8fabc1ca2cf should be fixed
200 2012-02-04 02:59:43 <roconnor> though perhaps it isn't urgent
201 2012-02-04 02:59:48 <theymos> It was very easy. Just ALTER TABLE inputs DROP CONSTRAINT x.
202 2012-02-04 02:59:53 <luke-jr> 1. mine Coinbase A-1
203 2012-02-04 03:00:03 <luke-jr> 2. mine Coinbase A-2, clone of A-1
204 2012-02-04 03:00:07 <luke-jr> 3. mine Coinbase B
205 2012-02-04 03:00:22 <luke-jr> 4. release Coinbase A-2 and Coinbase B to opposite node sets
206 2012-02-04 03:00:33 <luke-jr> 5. mine & release Coinbase C based on Coinbase B
207 2012-02-04 03:00:45 <luke-jr> now half of the nodes reorg, forgetting A-1 too
208 2012-02-04 03:00:52 <luke-jr> 6. Spend Coinbase A-1
209 2012-02-04 03:01:05 <theymos> roconnor: Should I change the text to "This caused by a horrible, ugly bug in Bitcoin that should be fixed ASAP"? ;)
210 2012-02-04 03:01:08 <luke-jr> all the nodes that forgot A-1 will reject this
211 2012-02-04 03:01:11 <roconnor> luke-jr: oh right, if that happens then the client is really buggy.
212 2012-02-04 03:01:31 <luke-jr> now you have two blockchains
213 2012-02-04 03:01:38 <roconnor> theymos: ideally you'd tell me how that transaction is spent, but maybe changing the text is a good first step.
214 2012-02-04 03:01:50 <luke-jr> and the perfect setup to double-spend until it's fixed
215 2012-02-04 03:01:58 <josephcp> theymos: but there can be situations where tracing transaction history will go to the wrong one when building the foreign keys :-/ you need to add a constraint to the select query to include unspent now
216 2012-02-04 03:02:34 <luke-jr> if it wasn't for the fact that Bitcoin goes up every time there's bad news, I'd be selling all mine about now
217 2012-02-04 03:02:35 <luke-jr> :P
218 2012-02-04 03:02:41 <roconnor> josephcp: the "correct" primary key is a the transaction and block id pair
219 2012-02-04 03:03:03 <roconnor> or maybe even (transcation, block id, and merkle tree location)
220 2012-02-04 03:03:14 <theymos> I'm not so concerned about correct display on BBE of these very strange transactions.
221 2012-02-04 03:03:22 <roconnor> theymos: heh, okay
222 2012-02-04 03:03:37 <josephcp> roconnor: when spending txouts you're not including the block id though
223 2012-02-04 03:03:43 <roconnor> theymos: sorry for messin up your block explorer :P
224 2012-02-04 03:04:17 <theymos> roconnor: Thanks for uncovering this interesting behavior! :)
225 2012-02-04 03:04:18 <josephcp> txin only has the hash, you need to select for unspent outs
226 2012-02-04 03:04:32 <luke-jr> theymos: you probably shouldn't have leaked that email :P
227 2012-02-04 03:04:47 <splatster> theymos: Are you going to split up the forum redesign into pieces or did you end up deciding against it?
228 2012-02-04 03:05:43 <theymos> luke-jr: It's a very old email. Security won't be harmed by releasing it -- security may be helped if more severe bugs are found than Gavin saw.
229 2012-02-04 03:08:02 <josephcp> well if you do decide to reject duplicates, remember that there are duplicates in mainnet, so the checking has to start after a set number of blocks...
230 2012-02-04 03:08:11 <theymos> splatster: I haven't processed all of the bids yet. I got a few more at the end of January. At first glance none of them look great, though. Matthew N. Wright also said that he would submit a bid, which might be pretty good. (I gave him another week.) I've been working on building a BBcode parser in Boost.Spirit in case I do end up splitting it, which has been pretty interesting.
231 2012-02-04 03:12:16 <roconnor> josephcp: it would sufficent to require outputs from be spent only once
232 2012-02-04 03:12:27 <roconnor> josephcp: which is compatible with how main net is now
233 2012-02-04 03:12:59 <luke-jr> theymos: actually, that attack isn't super-expensive either
234 2012-02-04 03:13:09 <luke-jr> you can do it by mining 1 block
235 2012-02-04 03:13:10 <josephcp> oh yeah good point
236 2012-02-04 03:13:35 <roconnor> luke-jr: btw, you don't have to use duplicate coinbases, you can use duplicate outputs of coinbases, which get around any 100 block issues.
237 2012-02-04 03:13:40 <luke-jr> you just need to time your announcement of that 1 block well
238 2012-02-04 03:14:04 <luke-jr> ie, connect to every node, and when you hear of the competing block announce yours as well
239 2012-02-04 03:14:06 <roconnor> I mean duplicate transactions built on duplicate coinbases
240 2012-02-04 03:14:45 <luke-jr> roconnor: :o
241 2012-02-04 03:15:01 <luke-jr> I don't see how that would work
242 2012-02-04 03:16:02 <roconnor> luke-jr: mine a coinbase transaction A, spend it to B, spend it to C, mine coinbase A, spend it to B spend it to C
243 2012-02-04 03:16:36 <roconnor> now the duplicate C's are analogus to duplicate coinbases, but well past any 100 block vetting period.
244 2012-02-04 03:26:16 <jamescarr> ping
245 2012-02-04 03:29:49 <BTC_Bear> M                                                     pong
246 2012-02-04 03:49:36 <egecko> how do you track down the transaction for a received bitcoin?
247 2012-02-04 03:50:43 <egecko> i.e. when you request the received by address, it returns all the bitcoins received, but it doesnt show much more beyond address, account, amount, and confirmations
248 2012-02-04 03:51:05 <theymos> listtransactions
249 2012-02-04 04:00:48 <shargs> cool
250 2012-02-04 04:06:28 <shargs> The idea of checking whether a committed integer lies in a specific interval was???first developed in [2].
251 2012-02-04 04:11:38 <roconnor> heh ``
252 2012-02-04 04:11:40 <roconnor> one of the reasons this keeps
253 2012-02-04 04:11:41 <roconnor> slipping down my TODO list is because I'm not sure it is worth making
254 2012-02-04 04:11:43 <roconnor> code changes for such an obscure potential attack that doesn't (as far
255 2012-02-04 04:11:44 <roconnor> as I can see) gain the attacker anything.
256 2012-02-04 04:12:10 <roconnor> yep, it's totally better to wait until it is known that the attacker can gain something, and then fix it. :^)
257 2012-02-04 04:17:04 <shargs> By using the indirect disclosure proof in the payment protocol, ZCash realizes revocable anonymity, which allows a trustee to trace the owner of the E-cash according to its payment transcript. ZCash is the first E-cash scheme which realizes both divisibility and revocable anonymity.
258 2012-02-04 04:18:38 <roconnor> shargs: link?
259 2012-02-04 04:19:39 <shargs> http://www.sciencedirect.com/science/article/pii/S1567422302000248
260 2012-02-04 04:20:23 <shargs> the application to bitcoin would be the ability to hide transaction amounts in the transcript, but still prove your accant balance lies within a particular interval
261 2012-02-04 04:20:44 <roconnor> shargs: oh good, I was trying to figure out how to do that
262 2012-02-04 04:20:56 <roconnor> I though it would be possible with partial homomorphic encryption
263 2012-02-04 04:21:45 <shargs> if you want more privacy, you just increase the difference between input and output..
264 2012-02-04 04:23:00 <shargs> it seems to be horribly complex crypto stuff
265 2012-02-04 04:23:21 <roconnor> I'm not on campus so I cannot read the paper
266 2012-02-04 04:24:29 <shargs> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.113.6247
267 2012-02-04 04:25:01 <shargs> we make a further step towards practicality of complete (i.e., divisible) anonymous e-cash by presenting a solution where all pre cedures (set-up, withdrawal, payment and deposit) are bounded by tens of exponentiations
268 2012-02-04 04:25:53 <shargs> theres a simple scheme which is analogous:  each "transaction" would be represented by a source address, and a number that represents the upper limit of the amount, but not the exact amount which is encrypted
269 2012-02-04 04:26:19 <shargs> then you can prove to anyone that you have at least X coins left in your account, without revealing anything about previous transactions
270 2012-02-04 04:27:42 <shargs> that is a lame way to do it.. the horribly complex crypto is supposed to make it more opaque
271 2012-02-04 04:31:12 <egecko> anyone have ideas on why a sendfrom request would be returning a not found error?
272 2012-02-04 04:34:13 <shargs> http://www.cs.ut.ee/~lipmaa/crypto/link/zeroknowledge/pok.php
273 2012-02-04 04:34:27 <shargs> search for "proofs tha the committed numbers belong to an interval (Range proof)"
274 2012-02-04 04:34:53 <roconnor> etotheipi_: there is a bug in armory in an extremely unlikely corner case of the bitcoin protocol (which its probably a bug in the protocol that will hopefully get fixed really soon).
275 2012-02-04 04:34:55 <shargs> theres like 20 papers on the problem
276 2012-02-04 04:35:13 <etotheipi_> what's the bug, roconnor?
277 2012-02-04 04:35:58 <roconnor> etotheipi_: say I mine a coinbase transaction with hash A
278 2012-02-04 04:36:12 <roconnor> etotheipi_: and then I spend it with transaction with hash AB
279 2012-02-04 04:37:00 <roconnor> etotheipi_: and then I mine a coinbase transaction again with hash A, then it doesn't appear again in armory
280 2012-02-04 04:37:14 <roconnor> etotheipi_: I've confirmed that it is spendable with transaction AC
281 2012-02-04 04:37:26 <roconnor> (which also doesn't appear in armory)
282 2012-02-04 04:37:58 <etotheipi_> you mean, Armory reports it as spendable?
283 2012-02-04 04:37:58 <roconnor> etotheipi_: it probably isn't worth fixing
284 2012-02-04 04:38:17 <roconnor> etotheipi_: no, I mean it is spendable, but Armory doesn't report its existence.
285 2012-02-04 04:39:01 <etotheipi_> I thought those duplicate tx's were not spendable?
286 2012-02-04 04:39:08 <roconnor> they are
287 2012-02-04 04:39:11 <etotheipi_> I mean, I thought the network wouldn't allow you to spend them
288 2012-02-04 04:39:13 <roconnor> in some cases
289 2012-02-04 04:39:18 <etotheipi_> or is that a "bug"?
290 2012-02-04 04:39:21 <roconnor> yes
291 2012-02-04 04:40:04 <roconnor> http://blockexplorer.com/testnet/tx/fae8bfd6a2d98294416d8d280d3637682e87ad71e0dfc6b8b20804263067c42d
292 2012-02-04 04:40:26 <roconnor> ^^ proof that it is spendable
293 2012-02-04 04:41:14 <etotheipi_> is that testnet?
294 2012-02-04 04:41:20 <roconnor> yes
295 2012-02-04 04:41:45 <etotheipi_> so you have found a way to spend them?
296 2012-02-04 04:41:53 <roconnor> yes
297 2012-02-04 04:42:01 <roconnor> so long as the first one is spent, the second one will be spendable.
298 2012-02-04 04:42:17 <roconnor> ... god only knows what happens if the first one is partially spent.
299 2012-02-04 04:42:20 <etotheipi_> hmmm.... that sounds like a bug
300 2012-02-04 04:43:42 <roconnor> etotheipi_: if you want, try to figure out how to double spend using duplicate transactions, or at least revoke transactions to screw someone.
301 2012-02-04 04:43:44 <etotheipi_> that sounds like something that could fork the blockchainj if there was a large variety of full-validation nodes
302 2012-02-04 04:44:10 <roconnor> etotheipi_: ya; there are a million possible ways this could be implemented
303 2012-02-04 04:44:30 <etotheipi_> interesting...
304 2012-02-04 04:44:34 <roconnor> luke-jr suggests because of the way reorgs are handled that the standard client could even fork itself.
305 2012-02-04 04:45:24 <etotheipi_> well I'm out of town, so I'm not doing any real dev until monday, so I can't even really look at it right now
306 2012-02-04 04:45:52 <etotheipi_> no doubt, that's quite a corner case...
307 2012-02-04 04:46:17 <roconnor> etotheipi_: ya, I don't think there is any point of even addressing it yet
308 2012-02-04 04:46:23 <roconnor> etotheipi_: but I thought I'd let you know.
309 2012-02-04 04:46:31 <etotheipi_> unless someone figures out how to leverage it maliciously
310 2012-02-04 04:46:47 <etotheipi_> would it be resolved by a rescan?
311 2012-02-04 04:47:04 <roconnor> etotheipi_: sure, it would be resolved by a rescan
312 2012-02-04 04:47:20 <etotheipi_> for instance, because of the way that I scan the blockchain, no matter how complicated of a reorg happens, when you rescan it will organize "correctly"
313 2012-02-04 04:47:26 <roconnor> but imagine how long the block fork could go on.
314 2012-02-04 04:47:38 <etotheipi_> (though, I've unit-tested the Armory code so it should work real-time, anyway)
315 2012-02-04 04:47:52 <roconnor> etotheipi_: you rescan the entire chain on every reorg?
316 2012-02-04 04:47:56 <etotheipi_> no
317 2012-02-04 04:48:08 <roconnor> well there you go
318 2012-02-04 04:48:26 <etotheipi_> although with full-ram.... I don't see why not :)
319 2012-02-04 04:48:30 <roconnor> in standard client, luke-jr suggest that it will get confused about which transaction is which during a reorg
320 2012-02-04 04:48:38 <etotheipi_> it takes less than a sec to reorganize all the headers and invalidate a bad chain
321 2012-02-04 04:48:38 <roconnor> understandably
322 2012-02-04 04:49:29 <roconnor> okay
323 2012-02-04 04:49:49 <roconnor> in my haskell code I don't even have a reorg :P
324 2012-02-04 04:50:09 <roconnor> I just have a priority queue, so if a new longest chain appears, then it is magically on top of the heap.
325 2012-02-04 04:50:12 <etotheipi_> I made sure that when a tx is invalidated via reorg, that it doesn't just disappear
326 2012-02-04 04:50:33 <etotheipi_> it's instead marked as invalidated... and then the user can be notified they just became a victim
327 2012-02-04 04:50:58 <roconnor> etotheipi_: nice
328 2012-02-04 04:51:33 <etotheipi_> although, I never save it, so I guess it would disappear after a restart.... maybe I'll make sure it's saved to disk
329 2012-02-04 04:52:20 <etotheipi_> okay, so really obscure memory question...  https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h#L25
330 2012-02-04 04:52:46 <etotheipi_> in the mlock function, it looks like it's finding the memory-page-floor
331 2012-02-04 04:54:24 <etotheipi_> but I can't figure out why there's such a complicated function for the size
332 2012-02-04 04:54:38 <etotheipi_> I would think it would be a simple multiple of the pagesize
333 2012-02-04 05:05:53 <shargs> monthly catacomb occupation fee
334 2012-02-04 05:27:19 <shargs> catacomb
335 2012-02-04 05:47:50 <shargs> ok
336 2012-02-04 05:54:43 <egecko> what is the base reference date/time for the "time" associated with a transaction?
337 2012-02-04 06:03:09 <egecko> 1/1/1900?
338 2012-02-04 06:04:01 <cjd> probably january 1970 but I'm not sure
339 2012-02-04 06:04:08 <cjd> ;;google unix time
340 2012-02-04 06:04:08 <gribble> Unix time - Wikipedia, the free encyclopedia: <http://en.wikipedia.org/wiki/Unix_time>; Online Conversion - Unix time conversion: <http://www.onlineconversion.com/unix_time.htm>; Unix Time Stamp . com: <http://www.unixtimestamp.com/>
341 2012-02-04 06:06:39 <shargs> ok
342 2012-02-04 06:06:43 <egecko> is it safe to presume that times are in UTC?
343 2012-02-04 06:07:04 <cjd> unix time doesn't care about time zone
344 2012-02-04 06:11:30 <shargs> cool
345 2012-02-04 07:00:50 <helo_> would it be useful to have a p2sh op that causes the transaction to fail validation if a particular block hash hasn't occured recently?
346 2012-02-04 07:02:37 <gmaxwell> helo_: by useful do you mean "enabling an attack, such that I can revoke funds spent to someone by simply doing a fairly minor reorg and not even respending the input"?
347 2012-02-04 07:03:05 <helo_> definately not :)
348 2012-02-04 07:05:43 <gmaxwell> There was a discussion about that sort of tying thing before but I can't find it. In the biggest usecase what you should simply endeavor to do is make the new txn dependant on the relevant input payment.
349 2012-02-04 07:06:07 <gmaxwell> (someone was asking about it with respect to a gambling site that he wanted to do fast&secure payment turnarounds for)
350 2012-02-04 07:06:25 <gmaxwell> If you can do that you can even work with zero confirms.
351 2012-02-04 07:06:36 <helo_> ahh makes sense
352 2012-02-04 07:08:00 <gmaxwell> I'd think that the kind of backwards matching you described would need to be protected by a maturity delay like we have for generation txn sort of the opposite of what people want in that situation (faster!)
353 2012-02-04 09:05:58 <FellowTraveler> hi all.
354 2012-02-04 09:06:06 <pusle> hei :)
355 2012-02-04 09:06:46 <FellowTraveler> I heard yall were having some kind of problems with poisonous people?
356 2012-02-04 09:07:28 <FellowTraveler> Now, are these the kind of people who have poisonous fangs, or are we talking more about, say, poisonous skin?
357 2012-02-04 09:07:56 <pusle> I'm not really a developer but from observing the conversations I wouldn't say there is such a problem
358 2012-02-04 09:08:16 <FellowTraveler> that's not the word on the street
359 2012-02-04 09:08:21 <FellowTraveler> word on the street is, a house divided can't stand
360 2012-02-04 09:09:04 <FellowTraveler> FYI since I just designed it, here's the upcoming systray menu options for Open-Transactions:  http://pastebin.com/i4C88ZWX
361 2012-02-04 09:09:15 <FellowTraveler> I guess I better get back to work.  Good luck finding the antidote!
362 2012-02-04 09:09:52 <pusle> O_o
363 2012-02-04 09:23:53 <makomk> By the way, thinking about it we already have an index of transactions that could've been used to prevent duplicate coinbases; right now it's used for looking up the outputs that a transaction spends.
364 2012-02-04 09:24:48 <makomk> (Another dropped item from the TODO BEFORE LAUNCH list for Coiledcoin, no surprises there.)
365 2012-02-04 09:53:48 <gribble> New news from bitcoinrss: dishwara opened issue 797 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/797>
366 2012-02-04 11:39:11 <saspiron> Could you have bitreceipts sorta a proof of purchase?
367 2012-02-04 11:39:43 <saspiron> where i buy something and i get a bitreceipt that then says i bought that item?
368 2012-02-04 11:52:38 <Moron__> saspiron
369 2012-02-04 11:52:39 <Moron__> :P
370 2012-02-04 12:28:10 <luke-jr> [23:16:02] <roconnor> luke-jr: mine a coinbase transaction A, spend it to B, spend it to C, mine coinbase A, spend it to B spend it to C
371 2012-02-04 12:28:15 <luke-jr> meh, he left
372 2012-02-04 12:28:27 <luke-jr> I don't think that can work, since the inputs will always be different
373 2012-02-04 13:51:21 <jamescarr> the bitcoin client for linux is buggy as hell
374 2012-02-04 13:53:01 <pickett> works fine for me
375 2012-02-04 15:28:31 <roconnor> luke-jr: all the inputs will be the same.
376 2012-02-04 15:28:51 <Diablo-D3> http://www.anandtech.com/print/5503
377 2012-02-04 16:06:09 <luke-jr> roconnor: only if they are coming from the same outputs
378 2012-02-04 16:06:24 <roconnor> which they will be
379 2012-02-04 16:06:30 <luke-jr> can't be
380 2012-02-04 16:07:01 <roconnor> say I mine transacion A, spend it with transaction B and that spend with transaction C.
381 2012-02-04 16:07:10 <roconnor> then say I mine a duplicate coinbase A
382 2012-02-04 16:07:23 <luke-jr> oh!
383 2012-02-04 16:07:25 <luke-jr> interesting
384 2012-02-04 16:07:25 <roconnor> by it's very definition the two A's have the same hash
385 2012-02-04 16:07:34 <roconnor> then I spend the duplicate A to duplicate B
386 2012-02-04 16:07:49 <roconnor> and since duplicate B is identical to duplicat A, it by definition has the same hash
387 2012-02-04 16:08:04 <luke-jr> yeah& if it wasn't for the fact that Bitcoin goes up with bad press, I might be selling now <.<
388 2012-02-04 16:08:31 <roconnor> luke-jr: this is all part of my due diligence before buying :P
389 2012-02-04 16:08:49 <luke-jr> ;)
390 2012-02-04 16:10:33 <TD> mining a duplicate coinbase means finding a hash without changing the extranonce, right
391 2012-02-04 16:11:29 <roconnor> oops, accidently turned off my wireless
392 2012-02-04 16:11:54 <roconnor> TD yes
393 2012-02-04 16:12:23 <TD> oh, never mind
394 2012-02-04 16:12:41 <TD> i was thinking that'd make it harder. but it doesn't. you  just include your own tx that you use as an extranonce
395 2012-02-04 16:13:10 <TD> the non-uniqueness of coinbase transactions has bothered me for a while. i wish satoshi had required inclusion of the prevblockhash in it
396 2012-02-04 16:13:32 <roconnor> extranonce really isn't needed AFAIU; just change the time by 1 second after you run out of nonce.
397 2012-02-04 16:13:56 <TD> eventually you'll hit the drift checks, no
398 2012-02-04 16:14:01 <roconnor> TD: the rumour was that these duplicated coinbase transactions were unspendable.
399 2012-02-04 16:14:04 <TD> i never looked at whether that is a problem or not, really
400 2012-02-04 16:14:10 <roconnor> but I proved that this is false last night.
401 2012-02-04 16:14:16 <TD> oh dear
402 2012-02-04 16:14:37 <roconnor> if you mine A and spend it, and then mine a duplicate A, the duplicate A is spendable.
403 2012-02-04 16:14:48 <TD> ah yes
404 2012-02-04 16:14:58 <roconnor> I don't know what happens when you partially spend A
405 2012-02-04 16:15:14 <roconnor> and I don't know what happens if you throw a block reorg into the mix
406 2012-02-04 16:15:22 <roconnor> luke-jr suggests it will be very very bad.
407 2012-02-04 16:16:10 <TD> though, if you mine two coinbases and spend them twice
408 2012-02-04 16:16:15 <TD> it's not really a double spend?
409 2012-02-04 16:16:20 <roconnor> nope
410 2012-02-04 16:16:23 <TD> and yes. i'm sure there are some nasty edge cases around this behavior.
411 2012-02-04 16:16:30 <TD> every tx really should be unique :(
412 2012-02-04 16:17:17 <TD> probably a re-org across such blocks would lead to db corruption. if not in the satoshi client then for sure in random 3rd party software that handles the chain
413 2012-02-04 16:18:00 <TD> i wonder if a "discouraged blocks" type change could be introduced that requires the prevblockhash to appear in the coinbase scriptSig at some point
414 2012-02-04 16:18:25 <roconnor> ya, even if by some miracle the satoshi client is fine; it will be a nightmare for merchants.
415 2012-02-04 16:18:48 <TD> well. hopefully most merchants just use one of a small number of implementations
416 2012-02-04 16:18:51 <TD> like the satoshi client :)
417 2012-02-04 16:18:55 <TD> that said
418 2012-02-04 16:19:06 <TD> i still don't fully understand how to double spend like that
419 2012-02-04 16:19:16 <roconnor> one option I was avocating was that an outpoint can be only spent at most once, no matter what.
420 2012-02-04 16:19:19 <TD> you say, mine one, spend it, mine another, spend it. it doesn't get you anything?
421 2012-02-04 16:19:30 <luke-jr> I wonder if -rescan would fix it
422 2012-02-04 16:19:34 <roconnor> this would be compatible with the existing mainnet
423 2012-02-04 16:19:38 <pusle> this is a hash collision "attack" ?
424 2012-02-04 16:19:39 <luke-jr> I'm not sure it would
425 2012-02-04 16:19:41 <luke-jr> pusle: no
426 2012-02-04 16:20:03 <luke-jr> pusle: this is a SHA256(a) == SHA256(a)
427 2012-02-04 16:20:03 <roconnor> TD: I think it would be easier to revoke a transaction you made to a merchent (and burin the coins) rather than double spend.
428 2012-02-04 16:20:16 <roconnor> TD: so it would be more of a screw you than any advantage for the attacker
429 2012-02-04 16:20:24 <roconnor> TD: but even that I don't know how to pull off yet.
430 2012-02-04 16:20:29 <pusle> well that's exactly what I meant
431 2012-02-04 16:20:32 <TD> yeah so it's more theoretical for now
432 2012-02-04 16:20:40 <TD> the kind of thing best fixed with a gradual change of the rules
433 2012-02-04 16:20:48 <luke-jr> I think a rescan might fix it, actually
434 2012-02-04 16:21:21 <roconnor> luke-jr: I don't doubt it; but what havock can you do while some clients have rescaned and others have not?
435 2012-02-04 16:21:25 <luke-jr> true
436 2012-02-04 16:21:34 <TD> the alert system should be able to trigger re-scans
437 2012-02-04 16:21:35 <TD> imho
438 2012-02-04 16:21:41 <TD> the risk of abuse is very low
439 2012-02-04 16:21:49 <roconnor> TD: Ideally this would be fixed before someone turns this theoretical thing into a practical thing.
440 2012-02-04 16:21:59 <roconnor> rather than after
441 2012-02-04 16:21:59 <TD> open up a BIP?
442 2012-02-04 16:22:31 <roconnor> BIP 23 : outPoints can be only spent at most once.
443 2012-02-04 16:22:39 <TD> well, that is supposed to already be the rule
444 2012-02-04 16:22:42 <roconnor> ... outPoints should only be spent at most once in any valid chain
445 2012-02-04 16:22:46 <roconnor> TD: done.
446 2012-02-04 16:22:48 <TD> the problem is that if you mine the same tx twice, there are two identical outpoints
447 2012-02-04 16:23:13 <roconnor> BIP 23 : identical outPoints can be only spent at most once.
448 2012-02-04 16:23:14 <TD> i think requiring txns to be unique is a cleaner solution
449 2012-02-04 16:23:20 <TD> otherwise every software has to know about this bizarre edge case
450 2012-02-04 16:23:24 <roconnor> TD: that isn't compatible with the current mainnet.
451 2012-02-04 16:23:31 <TD> of transactions with the same hash at different parts of the block chain
452 2012-02-04 16:24:03 <luke-jr> *can* we make repeated coinbases invalid?
453 2012-02-04 16:24:15 <luke-jr> sure, light clients won't be able to check, but that's just 1 confirmation&
454 2012-02-04 16:24:16 <TD> oh, right, i forgot somebody already did this
455 2012-02-04 16:24:17 <roconnor> luke-jr: that isn't compatible with the current mainnet
456 2012-02-04 16:24:26 <luke-jr> roconnor: it is if you set a starting block number
457 2012-02-04 16:24:31 <TD> maybe the rule change can be conditioned on a starting point
458 2012-02-04 16:24:32 <TD> indeed
459 2012-02-04 16:25:01 <roconnor> luke-jr: possible; if you like nightmare implemenations ...
460 2012-02-04 16:25:11 <pusle> or just say the oldest one "wins" ?
461 2012-02-04 16:25:15 <roconnor> maybe I'd just make the last duplicated coinbase a new genesis block for me :D
462 2012-02-04 16:25:27 <luke-jr> roconnor: I don't. But if BIP 16 goes in, might as well do less nightmare stuff
463 2012-02-04 16:25:40 <roconnor> TD: I'm sure we can come up with several BIPs to solve this problem :P
464 2012-02-04 16:26:01 <TD> i'd like to see one that helps reduce complexity for alt implementations, for obvious reasons :)
465 2012-02-04 16:26:16 <TD> i think as long as bitcoinj clients don't receive any coins from duped coinbases, and there's never a re-org across them, it won't care
466 2012-02-04 16:26:23 <TD> however, it's better to remove the edge case via a protocol fix
467 2012-02-04 16:27:36 <TD> a rule change that discourages blocks with non-unique coinbases, and then an implementation fix to auto uniquify, would resolve that
468 2012-02-04 16:27:50 <roconnor> TD: having a conditional starting point makes for complex code.
469 2012-02-04 16:27:58 <TD> only for implementations that mine
470 2012-02-04 16:28:03 <TD> which today means only satoshi client
471 2012-02-04 16:28:14 <roconnor> TD: why only for miners?
472 2012-02-04 16:28:15 <luke-jr> TD: not entirely
473 2012-02-04 16:28:25 <luke-jr> TD: the Satoshi client is actually incapable of mining at this point
474 2012-02-04 16:28:37 <TD> alright, implementations that are used to generate work for miners
475 2012-02-04 16:28:45 <luke-jr> the other mining servers just hijack its block validation
476 2012-02-04 16:29:08 <luke-jr> TD: yes, the Satoshi client cannot generate work fast enough for mining on Bitcoin
477 2012-02-04 16:29:58 <luke-jr> afaik, every miner is not using mainline-bitcoind work now
478 2012-02-04 16:30:35 <TD> roconnor: ok, let me think through every edge case
479 2012-02-04 16:30:37 <luke-jr> a few are using bitcoind derivatives
480 2012-02-04 16:30:52 <luke-jr> most make work in other servers
481 2012-02-04 16:31:00 <TD> yes, alright, you know what i meant
482 2012-02-04 16:31:19 <TD> afaik nobody is mining on blocks validated by something other than satoshis code (or at least i hope they are not)
483 2012-02-04 16:31:30 <roconnor> TD:  I do ... on test net
484 2012-02-04 16:31:37 <roconnor> and when I want to dry my socks
485 2012-02-04 16:31:46 <luke-jr> TD: ah, you mean for the parent block?
486 2012-02-04 16:32:00 <TD> yes
487 2012-02-04 16:32:08 <luke-jr> ok, I get it now. sorry for the indirection
488 2012-02-04 16:32:53 <TD> roconnor: i need to think about what happens in a majority loses case. i suppose even with discouraged dupe coinbases, lightweight implementations need to handle the case where they have received coins that are then overridden by a duped coinbase, that then vanishes via a re-org
489 2012-02-04 16:32:54 <TD> ugh
490 2012-02-04 16:34:10 <TD> i suppose you can have a special case for coins received via a coinbase. if you find some in a block, check the wallet for a tx that already has that hash. if you find it, discard that new coinbase entirely and wait for a re-org to sort things out
491 2012-02-04 16:34:18 <genjix> i sent this to eligius pool http://blockchain.info/tx-index/15082100/f003f0c1193019db2497a675fd05d9f2edddf9b67c59e677c48d3dbd4ed5f00b
492 2012-02-04 16:34:54 <genjix> theymos: i think blockexplorer is down
493 2012-02-04 16:34:55 <TD> what is it? compressed pubkey or something?
494 2012-02-04 16:35:06 <theymos> genjix: Not for me.
495 2012-02-04 16:35:22 <TD> theymos: i was having issues with it hanging on searches earlier too
496 2012-02-04 16:35:52 <genjix> yep it's hanging now for me.
497 2012-02-04 16:35:58 <theymos> Yeah, searches are taking too long and are timing out. I might have to remove some of the things it searches for.
498 2012-02-04 16:36:14 <genjix> it doesnt normally hang so much
499 2012-02-04 16:36:46 <luke-jr> genjix: not on IM anymore?
500 2012-02-04 16:36:49 <genjix> TD: it's an old op_eval transaction lzsaver sent me
501 2012-02-04 16:36:56 <theymos> One of the BBE servers is down, so one server is handling all of the load.
502 2012-02-04 16:37:20 <genjix> luke-jr: i'm trying to avoid chat/forums for a while... too distracting
503 2012-02-04 16:37:30 <genjix> guess this is me breaking that :p
504 2012-02-04 16:37:35 <luke-jr> genjix: how do I get BIPs? :P
505 2012-02-04 16:37:46 <luke-jr> genjix: Eligius has not received your txn recently, FYI
506 2012-02-04 16:38:12 <genjix> i sent it 2 days ago and now it's in the blockchain
507 2012-02-04 16:38:22 <luke-jr> oh
508 2012-02-04 16:38:25 <luke-jr> missed that
509 2012-02-04 16:38:27 <luke-jr> :D
510 2012-02-04 16:38:31 <genjix> :D
511 2012-02-04 16:38:52 <luke-jr> huh? ozcoin mines OP_EVAL?
512 2012-02-04 16:38:53 <roconnor> genjix: what's special about that f003f0 transaction?
513 2012-02-04 16:38:59 <genjix> also libbitcoin has python bindings now http://ideone.com/JNdOz
514 2012-02-04 16:39:31 <roconnor> oh, the OP_NOP1
515 2012-02-04 16:39:39 <luke-jr> roconnor: it's OP_EVAL
516 2012-02-04 17:04:37 <theymos> genjix: I added a "go" button to BBE that should be much faster than normal search.
517 2012-02-04 17:04:57 <genjix> ok thanks theymos
518 2012-02-04 17:06:54 <genjix> theymos: still slow (searching a tx). if i go to a direct link though, it loads fast
519 2012-02-04 17:07:50 <genjix> i use blockexplorer.com/b/ /block/ /tx/ to navigate :)
520 2012-02-04 17:11:24 <theymos> That's because the search feature searches for the input as any part of the hash (LIKE %input%), which is pretty slow. I could make it even faster if the input was known to be a prefix.
521 2012-02-04 17:25:08 <luke-jr> genjix: anyway, I need a BIP for Low-SigOp M-of-N txns: http://pastebin.com/cw59JfnU
522 2012-02-04 17:27:55 <genjix> this is pretty good.
523 2012-02-04 17:29:30 <genjix> luke-jr: can you add a list of what would need to be changed in the current protocol/clients? i get the idea that there could be some unexpected things in the script system which are found would need to be changed, so it's good to have a formal list there.
524 2012-02-04 17:30:23 <genjix> luke-jr: BIP 18
525 2012-02-04 17:42:32 <luke-jr> genjix: BIP 18 is something different
526 2012-02-04 17:43:24 <luke-jr> genjix: no clients need to be changed, besides the new std txn
527 2012-02-04 17:49:48 <genjix> thats one thing (new std tx)
528 2012-02-04 17:50:35 <genjix> also
529 2012-02-04 17:50:36 <genjix> The current Satoshi bitcoin client does not relay or mine transactions with scriptSigs larger than 200 bytes; to accomodate 3-signature transactions, this will be increased to 500 bytes.
530 2012-02-04 17:50:41 <genjix> 2 things
531 2012-02-04 17:53:47 <luke-jr> that's a standard txn thing.
532 2012-02-04 17:57:01 <luke-jr> so & 23 is the next number I think? I guess 19 isn't used either&?
533 2012-02-04 17:58:42 <genjix> what about that list of rule changes?
534 2012-02-04 17:59:46 <luke-jr> the entire Specification section is that
535 2012-02-04 18:02:44 <luke-jr> http://pastebin.com/Q1WA9MsK better?
536 2012-02-04 18:03:34 <luke-jr> or better yet, add significant contributors to Author list: http://pastebin.com/kq5AeXir
537 2012-02-04 18:03:58 <genjix> yeah it seems good. im just trying to understand. see if i missed anything
538 2012-02-04 18:04:48 <genjix> i think better to put yourself only as the author
539 2012-02-04 18:05:08 <genjix> now what is BIP 18 for?
540 2012-02-04 18:06:09 <genjix> if BIP 18 depends on BIP 17 then it's best to not have a BIP that depends on another Draft
541 2012-02-04 18:06:25 <genjix> i.e to wait until the standard it depends on, actually becomes a standard.
542 2012-02-04 18:06:32 <luke-jr> BIP 18 is unfinished still, until BIP 16 vs 17 is decided
543 2012-02-04 18:06:50 <luke-jr> this new BIP is useless if BIP 16 goes through, actually
544 2012-02-04 18:07:02 <luke-jr> since BIP 16 changes the rules for OP_CHECKMULTISIG
545 2012-02-04 18:07:26 <genjix> ok but my point is that 16 or 17 would be a long time before they actually come,
546 2012-02-04 18:07:35 <genjix> maybe more than a month
547 2012-02-04 18:07:40 <luke-jr> maybe
548 2012-02-04 18:07:44 <genjix> so best to use up those slots now
549 2012-02-04 18:08:11 <luke-jr> well, BIP 18 is conceptually done, and applies to either P2SH solution
550 2012-02-04 18:08:20 <luke-jr> it's just a matter of technical details that it depends on 16/17
551 2012-02-04 18:08:23 <genjix> reserving spaces is best for only short periods of time. this is the 2nd time i reserved a slot and it went unused for more than a week
552 2012-02-04 18:08:38 <luke-jr> it's not unused. we talk about BIP 18 in discussion
553 2012-02-04 18:08:44 <genjix> ok
554 2012-02-04 18:08:54 <genjix> ok then use BIP 19
555 2012-02-04 18:08:56 <luke-jr> ok
556 2012-02-04 18:09:18 <genjix> call BIP 18 a reference BIP (the number could change in the future or something :p)
557 2012-02-04 18:09:20 <luke-jr> would you rather wait until 16/17 is done before a 17-based BIP though? I'm confused :p
558 2012-02-04 18:09:48 <luke-jr> I guess I could just Withdraw it if BIP 16 gets deployed
559 2012-02-04 18:09:58 <genjix> yeah it depends. gavin's BIPs were all submitted at once and they kinda depended on each other
560 2012-02-04 18:11:24 <genjix> i need to think more about whether that BIP 18 can be accepted or not.
561 2012-02-04 18:11:43 <genjix> i think it would be fair to personally
562 2012-02-04 18:11:50 <luke-jr> BIP 18 is the one that is valid for both 16/17&
563 2012-02-04 18:12:05 <genjix> oh ok
564 2012-02-04 18:12:19 <genjix> yeah but we still dont know if either will get accepted
565 2012-02-04 18:12:45 <luke-jr> I find it unlikely neither will
566 2012-02-04 18:12:49 <genjix> anyway this BIP 19. send me the final version.
567 2012-02-04 18:12:58 <luke-jr> https://en.bitcoin.it/wiki/BIP_0019
568 2012-02-04 18:14:18 <luke-jr> genjix: realistically, unless BIP 17 gets enabled, Gavin will likely force BIP 16 on the network by client deployment
569 2012-02-04 18:14:34 <luke-jr> and the "no P2SH" position clearly has minority support IMO
570 2012-02-04 18:16:08 <genjix> ic
571 2012-02-04 18:17:00 <genjix> i like the hard-fork idea
572 2012-02-04 18:17:14 <luke-jr> hard-fork is inevitable, but I think a few years off
573 2012-02-04 18:17:16 <theymos> The tx-version-2 BIP 16 solution seems like something almost everyone can agree on, though I think Gavin will not like having to roll out yet another change.
574 2012-02-04 18:17:24 <luke-jr> Satoshi's hardfork was timed 2 years later
575 2012-02-04 18:17:35 <luke-jr> theymos: indeed
576 2012-02-04 18:19:19 <genjix> done
577 2012-02-04 18:19:26 <luke-jr> ty
578 2012-02-04 18:20:38 <genjix> k im on #bitcoinconsultancy ... focus now
579 2012-02-04 18:24:29 <gmaxwell> theymos: it's such a trivial change though...
580 2012-02-04 18:25:42 <theymos> Did Gavin say anything about it yet?
581 2012-02-04 18:25:47 <Eliel> luke-jr: I have a suggestion about BIP 18. How about have it specify a hard fork change 2 years into the future with the extra bytes removed from the spec?
582 2012-02-04 18:26:34 <luke-jr> theymos: he said he was OK with it, IIRC
583 2012-02-04 18:27:21 <luke-jr> Eliel: then we can't change our mind without breaking the clients implementing that rule
584 2012-02-04 18:27:49 <luke-jr> Eliel: perhaps after a while
585 2012-02-04 18:28:05 <Eliel> then make it 3 years to allow for changing our mind? :P
586 2012-02-04 18:28:36 <luke-jr> if in a year, it seems sensible, a 2 year out proposal seems logical
587 2012-02-04 18:28:52 <luke-jr> no reason to decide things now
588 2012-02-04 18:31:16 <Eliel> I'm starting to think a rule change coordination protocol might be needed. :)
589 2012-02-04 18:41:42 <luke-jr> anyone know if git master still accepts OP_EVAL transactions into blocks?
590 2012-02-04 19:32:46 <gmaxwell> https://bitcointalk.org/index.php?topic=62609.msg731238#msg731238  :-/
591 2012-02-04 19:36:04 <BTC_Bear> lol, the negatives are back.
592 2012-02-04 19:39:44 <gmaxwell> it must be something about python developers handling bitcoin amounts using radix-2 floating point.
593 2012-02-04 19:54:13 <etotheipi_> okay, really obscure memory question:  serialize.h:42
594 2012-02-04 19:55:02 <etotheipi_> mlock appears to redefine the pointer to round down to the nearest pagefloor, but what about the second parameter which is the size.  Is there a reason it isn't just a multiple of the pagesize (it seems awfully complicated)
595 2012-02-04 19:56:21 <gmaxwell> etotheipi_: say size is 8 bytes and the original pointer was 7 below the end of the page.
596 2012-02-04 19:56:35 <gmaxwell> etotheipi_: you need to lock 2 pages to copletely cover the data.
597 2012-02-04 19:56:45 <gmaxwell> etotheipi_: rounding up the size to 1 page wouldn't do it.
598 2012-02-04 19:57:01 <tcatm> mlock() will take care of locking all affected pages
599 2012-02-04 19:57:27 <gmaxwell> tcatm: alas, not portably. On some platforms mlock _must_ be called with page aligned arguments.
600 2012-02-04 19:57:47 <tcatm> windows?
601 2012-02-04 19:57:54 <gmaxwell> etotheipi_: none the less, bitcoin's usage of mlock is generally pretty stupid. You shouldn't mimic it. You should have a seperate pool of locked memory.
602 2012-02-04 19:57:57 <gmaxwell> tcatm: mac.
603 2012-02-04 19:59:44 <gmaxwell> etotheipi_: E.g. it's better to at startup mlock a few hundred K and use your own allocator against it.. and try damn hard to avoid calling malloc more... since mlock may not work in the future... best if you can make your mlocked memory requirements completely static.
604 2012-02-04 20:00:19 <gmaxwell> tcatm: oh even the manpage on linux helpfully tells you this.
605 2012-02-04 20:00:23 <gmaxwell> Linux Notes
606 2012-02-04 20:00:26 <gmaxwell> ever, POSIX.1-2001 allows an implementation to require that addr is page aligned, so portable  appli
607 2012-02-04 20:00:29 <gmaxwell> cations should ensure this.
608 2012-02-04 20:03:31 <etotheipi_> gmaxwell: I recognize the need to potentially lock multple pages... but I'm asking you can't just use something like (int)((dataSz / pagesize) + 1) * pagesize
609 2012-02-04 20:03:54 <etotheipi_> ehh... now htat I start to write it out, I see that it's not going to  get any simpler than what's already there...
610 2012-02-04 20:05:18 <etotheipi_> good recommendation on the static mlock'd pool
611 2012-02-04 20:05:29 <gmaxwell> etotheipi_: right. Well, you could express it in some other ways.
612 2012-02-04 20:06:01 <gmaxwell> etotheipi_: thats what one does when writing realtime software (make your damn memory behavior as static as possible because you don't know how long sbrk will take!)
613 2012-02-04 20:08:17 <luke-jr> gmaxwell: do you know the OS won't context-switch, in a RTOS?
614 2012-02-04 20:11:47 <gmaxwell> luke-jr: Yes but that doesn't have anything to do with sbrk not being O(1). (And plenty of people do realtime work on not-really-rtoses.. e.g. linux if you need only ms responses you can reliably get them from linux as long as you're careful about the kernel and hardware)
615 2012-02-04 20:14:09 <shargs> gmaxwell: http://www.cs.ut.ee/~lipmaa/crypto/link/zeroknowledge/pok.php   search for "proofs that the committed numbers belong to an interval (Range proof)"
616 2012-02-04 20:14:26 <shargs> how to keep transaction amounts private in bitcoin
617 2012-02-04 20:16:33 <gmaxwell> shargs: it would also need to be a non-interactive proof.
618 2012-02-04 20:17:00 <gmaxwell> (since the transacting party is not going to go about proving it to every bitcoin node now and in the future. :) )
619 2012-02-04 20:17:28 <shargs> yep theres a non-interactive proof
620 2012-02-04 20:18:20 <gmaxwell> Interesting.
621 2012-02-04 20:18:38 <gmaxwell> (and thanks for the page I don't think I'd see that before, looks handy)
622 2012-02-04 20:19:05 <shargs> yeah its a nice collection
623 2012-02-04 20:19:45 <shargs> theres a simple way to do it: post the upper limit of the amount, but not the exact amount. that way you can still prove you have at least X coins without revealing the exact amount of your previous transactions
624 2012-02-04 20:19:56 <shargs> that doesn't use the cool crypto tho
625 2012-02-04 20:22:18 <luke-jr> gmaxwell: personally, I try to keep everything on the stack when possible :P
626 2012-02-04 20:23:43 <shargs> now if only some crypto master will translate these papers into something that can be implemented practically
627 2012-02-04 20:29:56 <shargs> This can be seen as a variant of the socialist millionaires' problem [4] where two parties each with a secret input
628 2012-02-04 20:31:37 <shargs> "This is the first divisible e-cash scheme that provides both full unlinkability and anonymity without requiring a trusted third party. "  http://www.springerlink.com/content/w1600452652072r6/
629 2012-02-04 20:32:00 <josephcp> i think this problem is very different because you have to know prior transactions to respend it, it makes me suspect it's less likely to be possible without some major tradeoff
630 2012-02-04 20:33:12 <josephcp> (the tradeoff is probably massive transaction sizes)
631 2012-02-04 20:33:34 <gmaxwell> shargs: appears to require binary binning.
632 2012-02-04 20:35:04 <shargs> Alice wants to prove that she is young enough to borrow money from her bank, without revealing her age. She therefore needs a tool for proving that a committed number lies in a specific interval. Up to now, such tools were either inefficient (too many bits to compute and to transmit) or inexact (i.e. proved membership to a much larger interval). This paper presents a new proof, which is
633 2012-02-04 20:35:48 <shargs> http://www.springerlink.com/content/yyb55d3tat49bc8g/
634 2012-02-04 20:36:14 <shargs> im sure bitcoin III will have support for it
635 2012-02-04 20:37:17 <gmaxwell> I'm doubtful. I'm still generally of the of the opinion that the clique anonymity stuff is basically worthless... But whatever, it's still interesting.
636 2012-02-04 20:39:04 <k9quaint> hmmm, solidcoin 3.0, finally doing away with the blockchain where all the bugs and poor designs reside!
637 2012-02-04 20:39:24 <gmaxwell> Yea, merging it with rexcoin.
638 2012-02-04 20:39:43 <shargs> privacy is always good. and with a range proof you can essentially pay for the amount of security you want (add coins to epand the range you can prove your balance lies within)
639 2012-02-04 20:41:04 <shargs> this post hints at it too: http://crypto.stackexchange.com/a/512
640 2012-02-04 20:41:12 <cjd> I demand a pdf
641 2012-02-04 20:41:26 <gmaxwell> shargs: I think you need to think a bit more carefully.
642 2012-02-04 20:42:12 <gmaxwell> shargs: it's not as simple as that. If you _only_ implemented that then the recipent of your funds would have to fully disclose the outputs of the transaction which paid him in order to spend those funds in order to establish the new bounds.
643 2012-02-04 20:42:52 <shargs> no you dont have to disclose the exact amount, since you can attach the previous non-interactive proof along with your own
644 2012-02-04 20:43:14 <shargs> it takes extra coins to increase the amount of privacy you have, so people who dont need it can forego it
645 2012-02-04 20:45:27 <josephcp> that's like saying I'm going to mail you a blank check, you can write anything between 1 and 1 million dollars, you can redeem it for whatever you want
646 2012-02-04 20:45:53 <shargs> nah you should read the paper
647 2012-02-04 20:46:00 <josephcp> everyone's going to force 1 million dollars to force you to acknowledge to everyone
648 2012-02-04 20:46:12 <josephcp> what the real amount was
649 2012-02-04 20:46:31 <gmaxwell> shargs: I think you're full of it, because you're not thinking carefully about the whole system, but I don't have 20 minutes to argue with you about it.
650 2012-02-04 20:47:01 <josephcp> pick 3: fininte coins, cannot double-spend, no central authority, hidden transactions
651 2012-02-04 20:47:03 <cjd> 17:00 < shargs> nah you should read the paper <-- IMO paper locked up in springerlink == nonexistant
652 2012-02-04 20:47:28 <cjd> if they won't show me, I will assume scam until proven otherwise
653 2012-02-04 20:47:31 <gmaxwell> cjd: you == lazy; http://www.iacr.org/archive/eurocrypt2007/45150482/45150482.pdf
654 2012-02-04 20:47:36 <cjd> thx
655 2012-02-04 20:47:53 <josephcp> haha i was lazy too thnx
656 2012-02-04 20:49:25 <shargs> lazy non-rigorous objections to cutting-edge research
657 2012-02-04 20:49:27 <shargs> interesting haha
658 2012-02-04 20:49:45 <cjd> hahaha doesn't cite satoshi
659 2012-02-04 20:49:58 <cjd> I'll read it, I just assumed that it was locked up
660 2012-02-04 20:50:34 <josephcp> or "looked into this stuff enough to know where it is probably going" ;-)
661 2012-02-04 20:51:01 <gmaxwell> shargs: Have you actually read that paper or just the abstract?
662 2012-02-04 20:54:46 <shargs> that is not actually the crucial paper
663 2012-02-04 20:54:47 <shargs> http://www.springerlink.com/content/yyb55d3tat49bc8g/
664 2012-02-04 20:55:07 <cjd> ^^that isn't either
665 2012-02-04 20:55:16 <shargs> have you read it?
666 2012-02-04 20:55:35 <shargs> criticizing papers you haven't read is all well and good
667 2012-02-04 20:55:58 <shargs> well if you want to be lazy that is
668 2012-02-04 20:56:05 <cjd> yeap, just read it
669 2012-02-04 20:56:14 <cjd> but being only one page, it doesn't prove anything :P
670 2012-02-04 20:56:21 <gmaxwell> shargs: You're out of line.
671 2012-02-04 20:56:44 <shargs> gmaxwell: have you been offended by something? tell it to your therapist
672 2012-02-04 20:56:47 <gmaxwell> shargs: As I said before, range proofs simply added to bitcoin don't grant the properties you're claiming.
673 2012-02-04 20:57:19 <gmaxwell> shargs: Stop wasting people's time with gibberish non-proposals.
674 2012-02-04 20:57:34 <shargs> get back to me when you have a passing familiarity with the revelant crypto literature before spouting your unresearched theories at me
675 2012-02-04 20:57:42 <Moron__> i like to critice papers on quantum chromodynamics
676 2012-02-04 20:57:46 <Moron__> it makes me feel smart
677 2012-02-04 20:57:49 <Moron__> :)
678 2012-02-04 20:57:53 <gmaxwell> shargs: I'm not criticizing the paper.
679 2012-02-04 20:57:59 <shargs> gmaxwell: a paper you havent read
680 2012-02-04 20:58:09 <cjd> shargs: you're making claims but you've not linked to a single paper yet, just springerlink urls with front pages and more claims
681 2012-02-04 20:58:12 <josephcp> Moron__: reddit.com/r/vxjunkies
682 2012-02-04 20:58:28 <gmaxwell> shargs: the paper is not about adding the properties to bitcoin which you're talking about. It's about range proofs. I'll accept that it's solid and does what the abstract says.
683 2012-02-04 20:58:36 <shargs> cjd: if you dont have access to the research thats not my fault.
684 2012-02-04 20:58:47 <cjd> there is no research
685 2012-02-04 20:58:50 <shargs> lol
686 2012-02-04 20:58:56 <cjd> springerlink is not real
687 2012-02-04 20:58:58 <cjd> prove me wrong
688 2012-02-04 20:59:04 <shargs> ignored
689 2012-02-04 20:59:18 <gmaxwell> shargs: please ignore me too.
690 2012-02-04 20:59:27 <shargs> gmawell your objection is about as relevant as <cjd> springerlink is not real
691 2012-02-04 20:59:32 <gmaxwell> ...
692 2012-02-04 20:59:48 <amiller> oh man, we're spouting off about homomorphic encryption today! this is my favorite topic
693 2012-02-04 20:59:50 <amiller> i'd recommend papers by jens groth
694 2012-02-04 20:59:57 <gmaxwell> cjd: You can find the paper via google trivially.
695 2012-02-04 21:00:00 <shargs> lol you expect a paper written prior to bitcoin's invention to reference bitcoin? cool trick
696 2012-02-04 21:00:40 <gmaxwell> shargs: who are you talking to?
697 2012-02-04 21:00:41 <cjd> I've never seen a real paper come from springerlink, therefor I have no evidence that it's anything but fraud --- And I wish links to "unavailable research" were generally regarded that way.
698 2012-02-04 21:01:35 <amiller> http://www.cs.ucl.ac.uk/staff/J.Groth/
699 2012-02-04 21:01:43 <amiller> none of THOSE papers are paywalled
700 2012-02-04 21:02:04 <gmaxwell> shargs: You're claiming that range proofs would magically make bitcoin more anonymous. You are mistaken. I don't know _why_ you are mistaken, but I'm not your tutor so I don't care.
701 2012-02-04 21:02:14 <shargs> that is a trove of good stuff amiller
702 2012-02-04 21:02:16 <gmaxwell> shargs: none of that has anything to do with how excellent some range proof system is.
703 2012-02-04 21:02:17 <Moron__> gmaxwell: range proofs?
704 2012-02-04 21:02:19 <cjd> I know it's kinda playing the luke card but paywalled == dead to me
705 2012-02-04 21:02:32 <Moron__> gmaxwell: that sounds interesting, are they what I think they are?
706 2012-02-04 21:02:56 <shargs> gmaxwell: if you dont understand why disclosing a numerical range offers more privacy than disclosing an exact value then your input isnt valuable here
707 2012-02-04 21:02:57 <gmaxwell> cjd: http://www.iacr.org/cryptodb/archive/2000/EUROCRYPT/18070431.pdf
708 2012-02-04 21:02:58 <amiller> hey i know, anyone who wants to talk more about this stuff, join #homo
709 2012-02-04 21:03:26 <gmaxwell> shargs: If you don't know how bitcoin works then you're in the wrong channel, my friend.
710 2012-02-04 21:04:04 <Moron__> is range-proof = figuring out how far something is away by internet latencies or something?
711 2012-02-04 21:04:29 <shargs> range proof in this contet is a proof that an encrypted number lies within a particular range, without disclosing the exact value
712 2012-02-04 21:04:32 <cjd> thx for the link gmax, otoh part of my response is about discouraging people from dropping links which are not available to everyone
713 2012-02-04 21:04:35 <gmaxwell> shargs: Disclosing a range doesn't actually drop into the system, because the public needs to break open those disclosures frequently. This is what I initially pointed out to you. All you've been able to do is wave your arms about litrature which is irrelevant to this.
714 2012-02-04 21:04:40 <Moron__> oh right
715 2012-02-04 21:05:08 <Moron__> is that something specail to ecdsa?
716 2012-02-04 21:05:09 <amiller> it's easier to talk about 'private contracts' in terms of something like opentransactions
717 2012-02-04 21:05:49 <gmaxwell> I think I'm going to start paying someone to have agents (which are unknown to me) come into channels I'm in and try to waste mytime with almost plausable jibberish.
718 2012-02-04 21:06:07 <gmaxwell> Then there will be no doubt that this risk exists, and I'll be able to manage my time more effectively.
719 2012-02-04 21:06:38 <sipa> anything i've missed here the past day?
720 2012-02-04 21:07:04 <shargs> gmaxwell: no the public doesn't. you can choose who you transact with. when you're passing inequalities around, you don't need to tighten them until the transacted amount exceeds the possible range (in which case you can pay for more privacy by reloading your accounting)
721 2012-02-04 21:07:26 <cjd> almost plausible jobberish :D
722 2012-02-04 21:07:28 <shargs> in any case, its a significant increase in privacy (tho by no means perfect)
723 2012-02-04 21:07:39 <gmaxwell> sipa: there was some discussion with respect to BIP16+txn version 2, some oddness with a pool mining what appears to be OP_EVAL transactions.
724 2012-02-04 21:07:58 <sipa> ok
725 2012-02-04 21:09:42 <gmaxwell> shargs: Go write proposal for a complete system. I'll gladly comment on it it's a waste of my time to comment incrementally as you add potentially interacting parts to address each criticism as I raise it.
726 2012-02-04 21:10:51 <gmaxwell> (even better, actually code it and have it running too!)
727 2012-02-04 21:11:31 <k9quaint> gmaxwell: I think the phrase you are looking for is "Patches are welcome!"
728 2012-02-04 21:11:36 <gmaxwell> (double bonus if it's actually pratical and each transaction doesn't require carrying hunreds of 2kb proofs)
729 2012-02-04 21:12:06 <gmaxwell> k9quaint: no, they're not welcome this isn't bitcoin that he's advocating. It's not the sort of thing that could be just added to bitcoin.
730 2012-02-04 21:12:46 <gmaxwell> k9quaint: it might form an interesting system to use along side, or instead of bitcoin though. If it were actually secure and pratical.
731 2012-02-04 21:14:54 <roconnor> sipa: I proved that it is possible to spend a duplicate coinbase.
732 2012-02-04 21:15:06 <roconnor> sipa: which opens a whole can of worms
733 2012-02-04 21:15:30 <sipa> roconnor: which order of creating / spending it?
734 2012-02-04 21:15:31 <k9quaint> gmaxwell: didn't you watch the gavin poison video?
735 2012-02-04 21:15:43 <roconnor> sipa: create, spend, create duplicate, spend duplicate.
736 2012-02-04 21:15:52 <luke-jr> gmaxwell: FWIW, ozcoin that mined the OP_EVAL is apparently running a recent git checkout
737 2012-02-04 21:15:52 <sipa> roconnor: sounds exactly correct to me
738 2012-02-04 21:16:05 <sipa> roconnor: imho, you should be able to spend that
739 2012-02-04 21:18:43 <nathan7> Anyone here who is willing to paypal money to me in exchange for an mtgox euro code?
740 2012-02-04 21:19:13 <roconnor> sipa: if I mine A, wait 70 blocks duplicate mine A, wait 30 blocks spend A, wait 30 blocks, is the duplicate A spendable?
741 2012-02-04 21:20:41 <sipa> roconnor: shouldn't be
742 2012-02-04 21:20:59 <roconnor> sipa: then my haskell client has a bug.
743 2012-02-04 21:21:05 <luke-jr> sipa: there is an attack that can split the network in that case
744 2012-02-04 21:21:38 <sipa> iirc, every tx overwrites the "spendable" vector of its id
745 2012-02-04 21:22:43 <nathan7> Great. Now I have to figure out intl wire.
746 2012-02-04 21:22:46 <roconnor> sipa: I don't include coinbases into my set of available coins until it matures. ... hence the bug
747 2012-02-04 21:23:26 <roconnor> sipa:  what are the odds that the standard client corrently manages block reorgs in the presence of duplicate transactions?
748 2012-02-04 21:23:28 <sipa> the correct solution would be to disallow duplicate tx's, unless they are completely spent
749 2012-02-04 21:23:39 <sipa> roconnor: i believe it will work correctly
750 2012-02-04 21:24:07 <sipa> no guarantees of course, there can be all kinds of strange behavior
751 2012-02-04 21:25:04 <nathan7> ..well ffs, 15 USD of fees
752 2012-02-04 21:25:47 <roconnor> gmaxwell: ping
753 2012-02-04 21:26:26 <roconnor> sipa: sounds like you've read and understood the transaction chaining code.
754 2012-02-04 21:27:34 <sipa> roconnor: well, processing a transaction (over)writes its TxIndex datastructure in the db
755 2012-02-04 21:28:10 <roconnor> sipa: and during a block reorg?
756 2012-02-04 21:28:26 <roconnor> does it unoverwrite it restoring the previous TxIndex?
757 2012-02-04 21:28:48 <sipa> dang
758 2012-02-04 21:28:53 <sipa> i think you're right
759 2012-02-04 21:28:56 <roconnor> you guys and your mutable data structures :P
760 2012-02-04 21:29:06 <roconnor> if only it was written in Haskell
761 2012-02-04 21:29:32 <roconnor> sipa: after that who knows what happens, but it is certain to be bad.
762 2012-02-04 21:29:41 <cjd> no mutibility? that must generate a lot of garbage
763 2012-02-04 21:29:55 <roconnor> cjd: ya I guess.