1 2012-01-15 00:49:59 <Eliel> hmm... this proposal from piuk, OP_NO_SKIP looks promising.
  2 2012-01-15 00:53:56 <sipa> Eliel: where do i read about it?
  3 2012-01-15 00:54:08 <Eliel> https://en.bitcoin.it/wiki/BIP_0017_DRAFT
  4 2012-01-15 00:54:33 <Eliel> I was initially a bit puzzled about how exactly that differs from OP_EVAL but then I got it :)
  5 2012-01-15 00:57:53 <sipa> it is flawed
  6 2012-01-15 00:58:17 <sipa> what if i just push the script onto the stack in scriptSig, without any OP_NO_SKIP ?
  7 2012-01-15 00:58:56 <Eliel> why would that be a problem?
  8 2012-01-15 00:59:09 <sipa> because that would verify
  9 2012-01-15 00:59:16 <sipa> without the script being executed
 10 2012-01-15 00:59:40 <Eliel> oh true
 11 2012-01-15 00:59:55 <sipa> the proposal demands from the the txin to do its verification, and only performs some additional check that it pushed a particular script onto the stack
 12 2012-01-15 01:00:20 <gmaxwell> meh, I think people shouldn't write bips until the idea passes a basic sanitycheck.
 13 2012-01-15 01:00:43 <sipa> how do you comment on a BIP?
 14 2012-01-15 01:01:58 <gruez> gmaxwell: regarding your block sync fix
 15 2012-01-15 01:02:23 <gruez> i started at 4:45 today
 16 2012-01-15 01:02:25 <Eliel> sipa: you can probably comment here, it's where I found the link https://bitcointalk.org/index.php?topic=56969.40
 17 2012-01-15 01:02:34 <gruez> and it's stuck at 90%
 18 2012-01-15 01:02:50 <gruez> working as intended?
 19 2012-01-15 01:03:14 <gmaxwell> gruez: I have no idea what timezone you're in.
 20 2012-01-15 01:03:25 <gmaxwell> and is it actually _stuck_ ? mouseover and get the block number.
 21 2012-01-15 01:09:27 <Eliel> sipa: sipa do you think piuk's proposal could be made to work if it defined 2 new opcodes? one would be OP_NO_SKIP and the other somehow checks that OP_NO_SKIP was used in input.
 22 2012-01-15 01:11:46 <Eliel> ... or, keep it one opcode but modify it to come after the push it affects. Then it can be the first thing in scriptPubKey
 23 2012-01-15 01:12:21 <sipa> that would require the same kind of changes as CHV
 24 2012-01-15 01:19:34 <gruez> gmaxwell: not "stuck"
 25 2012-01-15 01:19:40 <gruez> just painfully slow
 26 2012-01-15 01:19:47 <gruez> now it's 91%
 27 2012-01-15 01:20:10 <gruez> my timezone is est
 28 2012-01-15 01:20:16 <gruez> so it's 9:20 right now
 29 2012-01-15 01:21:10 <cjdelisle> is that the MSVC++ version?
 30 2012-01-15 01:22:10 <gruez> gmaxwell: do you want the logs?
 31 2012-01-15 01:22:26 <gruez> i have timestamp enabled
 32 2012-01-15 01:22:45 <gruez> logtimestamps=1
 33 2012-01-15 01:23:58 <gruez> cjdelisle: not sure what you're talking about?
 34 2012-01-15 01:24:16 <gruez> it's on windows xp
 35 2012-01-15 01:24:18 <gruez> on vmware box
 36 2012-01-15 01:24:25 <gruez> https://bitcointalk.org/index.php?topic=56491.0
 37 2012-01-15 01:24:53 <cjdelisle> I thought you were building bitcoin in visual C++
 38 2012-01-15 01:25:32 <gruez> cjdelisle: nah
 39 2012-01-15 01:25:38 <cjdelisle> ic
 40 2012-01-15 01:26:10 <cjdelisle> I've heard that MSVC is *really* smart about some optimizations
 41 2012-01-15 01:26:19 <gmaxwell> gruez: you can archive them up and send them to me when they're done, though I expect I'll won't learn much from them and that it's just not fast because IO in windows vp in vmware isn't fast.
 42 2012-01-15 01:27:25 <gmaxwell> cjdelisle: I'm not aware of any evidence that compiler smartness could make more than a non-trivial improvement in bitcoin performance.
 43 2012-01-15 01:27:45 <gmaxwell> cjdelisle: our most obvious performance problems are IO related.
 44 2012-01-15 01:27:51 <cjdelisle> hmm
 45 2012-01-15 01:28:27 <gruez> gmaxwell: which log should i send? debug.log?
 46 2012-01-15 01:28:32 <gmaxwell> (and *really* smart is armwaving, GCC is also *really* smart.)
 47 2012-01-15 01:28:46 <cjdelisle> I don't know how it works but I imagine it seeking to a given transaction in block0001...
 48 2012-01-15 01:28:48 <gmaxwell> gruez: yes, but let it finish. and zip/rar it up.
 49 2012-01-15 01:29:12 <gmaxwell> cjdelisle: there is an index of offsets.
 50 2012-01-15 01:29:18 <roconnor> Eliel: BIP 0017 is pretty naive.
 51 2012-01-15 01:29:25 <gruez> gmaxwell: is there a reason why IO on vmware is slow?
 52 2012-01-15 01:29:26 <cjdelisle> /nod
 53 2012-01-15 01:29:35 <Eliel> roconnor: yes, I realized that already :)
 54 2012-01-15 01:29:36 <gruez> it should be close to the same speed as the host system, right?
 55 2012-01-15 01:29:49 <roconnor> Eliel: You can easily hack this so that any miner can steal transactions
 56 2012-01-15 01:30:24 <roconnor> OP_CHECKMULTISIGVERIFY OP_HASH160 [20-byte-hash-value] OP_EQUAL
 57 2012-01-15 01:30:37 <gmaxwell> gruez: It's somewhat slower than the host in general.. but I have no clue what it does wrt sync writes it might be better (if its unsafe) or much worse.
 58 2012-01-15 01:30:46 <roconnor> all a miner has to do is make some OP_CHECKMULTISIGVERIFY work and push something with the right hash onto the stack
 59 2012-01-15 01:31:24 <roconnor> and the transaction the miner takes over has all the information to make the hash.
 60 2012-01-15 01:31:32 <roconnor> very very bad proposal
 61 2012-01-15 01:32:17 <roconnor> can I just edit the BIP with this comment and put the BIP out of its missery?
 62 2012-01-15 01:32:47 <sipa> roconnor: already did, on the talk page
 63 2012-01-15 01:35:55 <sipa> maybe could have elaborated a little
 64 2012-01-15 01:39:41 <roconnor> sipa: I documented the exploit and unilaterally changed the status to rejected.
 65 2012-01-15 01:39:55 <theymos> What do you guys think of the critcism of luke-jr's CODEHASHVERIFY proposal? I didn't look through luke-jr's code too closely, but I think that the idea *can* be done safely without more effort than P2SH.
 66 2012-01-15 01:40:23 <roconnor> theymos: I personally find it on par with P2SH
 67 2012-01-15 01:40:45 <theymos> Does that mean you don't like it? I thought you weren't enthusiastic about P2SH.
 68 2012-01-15 01:40:52 <roconnor> theymos: but both are slightly worse than doing nothing IMHO
 69 2012-01-15 01:41:08 <roconnor> theymos: and this whole process is still too fast.
 70 2012-01-15 01:41:45 <theymos> Is there a proposal that you think is better than doing nothing?
 71 2012-01-15 01:41:53 <roconnor> not yet
 72 2012-01-15 01:42:28 <Eliel> roconnor: what is it that p2sh and chv would make worse?
 73 2012-01-15 01:42:30 <gmaxwell> theymos: roconnor will never see any proposal as better than nothing, I believe.
 74 2012-01-15 01:43:04 <gmaxwell> Because he sees no value in P2SH style transactions, either from the perspective of compact addresses or moving storage to input scripts.
 75 2012-01-15 01:43:17 <roconnor> Eliel: it undoes most the confindence gained so far with the current core protocol for insufficent gain.
 76 2012-01-15 01:43:52 <roconnor> gmaxwell may be correct
 77 2012-01-15 01:43:55 <gmaxwell> roconnor: Do you see any value in avoding accepting random script data from untrusted nodes (packed into addresses) and then using that in your transactions?
 78 2012-01-15 01:44:06 <sipa> i wonder how well-founded that confidence is, given that in juli 2010 such a major mistake was still there
 79 2012-01-15 01:44:41 <gmaxwell> (especially when "you" may be some kind of thin client device which may not have room for a lot of code to measure the sanity of an address given to you?)
 80 2012-01-15 01:44:48 <roconnor> gmaxwell: no particularly, though I might not have understood you correctly.
 81 2012-01-15 01:45:17 <luke-jr> "CHV requires the scriptPubKey interacts with data from scriptSig which has not been push onto the stack" <-- why is this a problem?
 82 2012-01-15 01:45:19 <roconnor> sipa: ya I know
 83 2012-01-15 01:45:38 <sipa> roconnor: he means using an address that encodes an entire serialized txout script, imho
 84 2012-01-15 01:45:43 <roconnor> maybe there is an argument to move quickly since there ought not be much confidence in bitcoin yet.
 85 2012-01-15 01:46:31 <roconnor> anyhow, I said these proposals are slightly worse than nothing;  You won't see the same opposition I gave OP_EVAL from me.
 86 2012-01-15 01:47:09 <roconnor> I think the time given to considering the proposal is a worse problem than the proposal itself.
 87 2012-01-15 01:47:16 <theymos> Mike Hearn also prefers doing nothing in this area, using more "overlay network" sort of features to provide a good user experience.
 88 2012-01-15 01:47:58 <roconnor> theymos: ya, out of band communications can be used to securly transmit payment scripts.
 89 2012-01-15 01:48:19 <gmaxwell> roconnor: my understanding is that you don't think p2sh is important because we could have 'addresses' which were just seralized txout scripts.
 90 2012-01-15 01:48:34 <roconnor> gmaxwell: yes
 91 2012-01-15 01:48:37 <sipa> I like p2sh for moving code from txouts to txins, and for the ease with which we can quickly get complex transactions into the current infrastructure
 92 2012-01-15 01:49:01 <sipa> my fear is that it will limit our progress towards real payment protocols which do not bother with static short addresses
 93 2012-01-15 01:49:17 <gmaxwell> roconnor: I'd feel somewhat uncomfortable taking whole txout scripts from untrusted sources, I think it's an extra opening for problems. Especially for thin clients which would otherwise not need any real script validation logic.
 94 2012-01-15 01:50:13 <gmaxwell> sipa: you're lamenting that it removes a flaw with payment protocols also remove. This is pretty much the weakest kind of argument. (I'm often guilty of it though 'we shouldn't do this good thing because it makes some other better thing less attractive')
 95 2012-01-15 01:50:35 <luke-jr> lol
 96 2012-01-15 01:50:36 <roconnor> I sort of think bitcoin will end up being used as hight-powered money backing a federation of banks that use open transactions
 97 2012-01-15 01:50:40 <gmaxwell> Payment protocols are good and important for many other reasons, and short addresses won't harm them (in fact they help them slightly too)
 98 2012-01-15 01:50:47 <roconnor> making all this script manupulation nonsense irrelevent.
 99 2012-01-15 01:51:03 <sipa> roconnor: let's use paypal, bro
100 2012-01-15 01:51:47 <roconnor> hopefully open transactions will be better than paypal, but maybe not.
101 2012-01-15 01:51:48 <gmaxwell> roconnor: even if you believe bitcoin will only back up something else the more flexible and powerful bitcoin is, the more competative and low cost thing things built on top of it will need to be.
102 2012-01-15 01:52:13 <sipa> gmaxwell++]
103 2012-01-15 01:52:23 <roconnor> meh
104 2012-01-15 01:52:37 <gmaxwell> So it's all good and 'fancy scripts', fwiw would be very important for OT integration.. e.g. every OT payment would be a payment to N OT agents holding keys, almost certantly.
105 2012-01-15 01:54:00 <roconnor> gmaxwell: I don't know enought about OT to know if what you say is true.
106 2012-01-15 01:54:03 <amiller> the thing i'm concerned about with opentransactions is that no attention is given to it as a protocol
107 2012-01-15 01:54:06 <gmaxwell> Also, moving storage to inputs from outputs means that in the future pruned but full validating nodes will be much smaller than otherwise especially if we end up with a lot of pay to N of 5 addresses and this will be important for retaining decentralization.
108 2012-01-15 01:54:07 <amiller> it's a library, not a protocol
109 2012-01-15 01:54:34 <roconnor> amiller: huh?
110 2012-01-15 01:54:36 <sipa> gmaxwell: not sure what problem you see with accepting txouts from untrusted sources?
111 2012-01-15 01:54:58 <amiller> roconnor, the default scripting language for smart contracts in OT for example is turing complete
112 2012-01-15 01:54:58 <gmaxwell> roconnor: at least my reading on it is that it uses a federated model that eliminates the need for trusting single parties by having multiple parties that sign off.
113 2012-01-15 01:55:11 <roconnor> ouch
114 2012-01-15 01:55:14 <amiller> it's not really engineered for trust at this point
115 2012-01-15 01:55:23 <amiller> it's kind of got a different mentality
116 2012-01-15 01:55:28 <roconnor> I haven't had a chance to look at the protocol
117 2012-01-15 01:55:39 <roconnor> it is even more poorly documented than bitcoin was
118 2012-01-15 01:55:47 <amiller> i've been trying to find a way to reconcile bitcoin and opentransactions for a while
119 2012-01-15 01:56:10 <amiller> yeah
120 2012-01-15 01:56:12 <sipa> amiller: talk to da2ce7
121 2012-01-15 01:56:41 <gmaxwell> sipa: meh, perhaps there is nothing wrong with it you'd just take it as opaque data, stick it in your transactions, and hope that it doesn't crash your peers.
122 2012-01-15 01:56:59 <sipa> exactly
123 2012-01-15 01:57:09 <gmaxwell> sipa: but e.g. you can't know if it'll get relayed or not or whatever without attempting to parse it, and there be dragons.
124 2012-01-15 01:57:21 <gmaxwell> Kinda annoying when you're responsible for the related txn fees.
125 2012-01-15 01:57:27 <sipa> it shouldn't be your problem
126 2012-01-15 01:57:34 <sipa> but the receiver's
127 2012-01-15 01:57:57 <gmaxwell> Well, it is if it's an address and you're putting it in the output script. I suppose the reciever could tell you the fee to apply too.
128 2012-01-15 01:58:18 <gmaxwell> but of course if the fee also depends on the inputs (E.g. with our current anti-dos rules)&
129 2012-01-15 01:58:51 <sipa> let's assume that in the future we're talking about, those problems are solved
130 2012-01-15 01:59:21 <gmaxwell> meh, Well, I think some of them are fundimental. But I'll agree that its not an issue if you stick a payment protocol in there.
131 2012-01-15 01:59:33 <gmaxwell> (well except for the, 'hope it doesn't crash your peers')
132 2012-01-15 02:01:08 <gmaxwell> And, a bit more on that point,  "so let me see if I have this right: You put a form on your ecommerce site where users provide _code_ which you stick into messages blindly which you then send to your gateway finance trasaction processing system, and it executes that code?"  just .. meh. I'm not opposed, I just don't prefer actual scripts in addresses for this kind of reason.
133 2012-01-15 02:01:12 <roconnor> gmaxwell: really you should take the script, build your transaction and hand it back to the receipiant
134 2012-01-15 02:01:18 <roconnor> gmaxwell: let him crash his peers
135 2012-01-15 02:01:33 <roconnor> and let him find a miner
136 2012-01-15 02:01:37 <sipa> indeed
137 2012-01-15 02:01:49 <gmaxwell> Indeed, the payment protocol stuff solves a lot.
138 2012-01-15 02:02:26 <gmaxwell> But payment protocols are not things we can universally use.
139 2012-01-15 02:02:43 <gmaxwell> It's important that I can launch a message in a bottle with an address and end up with payments.
140 2012-01-15 02:03:07 <sipa> sure, if that is waht you want
141 2012-01-15 02:05:13 <gmaxwell> there are some interesting challenges for example, a payment protocol implies you have an accessible online agent.   so instead of a piece of text you now have infrastructure you must secure. (maybe it doesn't have a wallet but it's still something complicated thats valuable to attack if only to impersonate you)
142 2012-01-15 02:07:43 <roconnor> gmaxwell: doesn't the same problem exist with current addresses?
143 2012-01-15 02:08:33 <gmaxwell> Yes you have to secure the infrastructure providing them. But the 'infrastructure' can be a static text file with a gpg signed message in it.
144 2012-01-15 02:10:48 <gmaxwell> To be super clear, I'm not arguing against a payment protocol. I'm arguing that you shouldn't worry that improving other things will ruin the endgame, because the endgame includes more than just a payment protocol.
145 2012-01-15 02:12:02 <roconnor> oh I'm not worried about P2SH ruining anything.
146 2012-01-15 02:13:02 <gmaxwell> sipa is.
147 2012-01-15 02:13:07 <gmaxwell> Well at least a little. :)
148 2012-01-15 02:13:41 <sipa> at least my worry is for something probably inevitable anyway :)
149 2012-01-15 02:14:41 <gmaxwell> anti-spamness of P2SH is pretty attractive too. ... that you can sharply charge for output size without breaking interesting uses of bitcoin is a very good thing.
150 2012-01-15 02:15:08 <gmaxwell> ITSM that every idiot who learns a bit about bitcoin quickly gets the idea that he's going to use it as the worlds most awesome hard disk.
151 2012-01-15 02:19:33 <luke-jr> kjj doesn't understand that *nobody* is willing to break old clients, does he? :P
152 2012-01-15 02:24:46 <doublec> gmaxwell: just push them namecoins way
153 2012-01-15 02:25:36 <gmaxwell> doublec: what, 50mb namecoin blockchain is feeling inadequate?
154 2012-01-15 02:26:28 <luke-jr> lol
155 2012-01-15 02:27:33 <TuxBlackEdo> lol
156 2012-01-15 02:27:36 <doublec> gmaxwell: namecoin are adversting itself as a name/value store - so push the "I want to store data" people that way
157 2012-01-15 02:28:30 <TuxBlackEdo> why not keep storing data in the bitcoin blockchain?
158 2012-01-15 02:28:37 <TuxBlackEdo> there's already tons of crap in there
159 2012-01-15 02:28:55 <gmaxwell> TuxBlackEdo: because it makes it unusuable as a decenteralized currency eventually.
160 2012-01-15 02:29:37 <TuxBlackEdo> would it be possible to release a version of bitcoin with all bitcoin addesses tallied
161 2012-01-15 02:29:52 <TuxBlackEdo> i mean
162 2012-01-15 02:30:01 <gmaxwell> with 100k full nodes, every megabyte of data stored takes 100 gigabytes of diskspace across the whole distributed system.
163 2012-01-15 02:30:12 <TuxBlackEdo> a blockchain with like all the addresses tallied
164 2012-01-15 02:30:34 <gmaxwell> TuxBlackEdo: I may not know what you mean by 'tallied'?
165 2012-01-15 02:32:10 <gmaxwell> In any case, while there isn't much tension between scalability and tx-data-size, there very much is tension between decenteralization and tx-data-size.
166 2012-01-15 02:32:17 <TuxBlackEdo> because the blockchain has a ton of transactions right? couldn't you just release a new genesis blockchain that has the tallies of all the amounts already in there (basically getting rid of transaction history)
167 2012-01-15 02:33:00 <Eliel> TuxBlackEdo: that's reasonably simple to do I think. The bigger problem is convincing everyone to migrate to it.
168 2012-01-15 02:33:08 <gmaxwell> TuxBlackEdo: nodes can already forget old transactions if they want.
169 2012-01-15 02:33:29 <roconnor> gmaxwell: why do you say that?
170 2012-01-15 02:33:41 <gmaxwell> roconnor: by old I mean completed.
171 2012-01-15 02:34:11 <TuxBlackEdo> Eliel, but it would be easily verifiable that there aren't any new amounts added or subtracted
172 2012-01-15 02:34:18 <Eliel> TuxBlackEdo: in fact, if I ever decide to start up an alternate chain, that's probably what I'll do :P
173 2012-01-15 02:34:21 <roconnor> they cannot bring new peers upto date if they do that
174 2012-01-15 02:34:34 <gmaxwell> Correct.
175 2012-01-15 02:34:45 <gmaxwell> Sounds like a problem for the new peers.
176 2012-01-15 02:35:06 <gmaxwell> roconnor: but no worse than what TuxBlackEdo suggests.
177 2012-01-15 02:35:06 <luke-jr> TuxBlackEdo: Bitcoin the protocol doesn't know what an address is
178 2012-01-15 02:35:06 <roconnor> might be a problem for you if people stop mining your chain
179 2012-01-15 02:35:26 <luke-jr> (yet another reason to switch to scripthashes&)
180 2012-01-15 02:35:56 <gmaxwell> roconnor: with what TuxBlackEdo guessts people would just have to 'trust' that the summary is correct. If you're willing to do that you could just accept a pruned chain from someone and trust that it's not all lies.
181 2012-01-15 02:37:07 <gmaxwell> moreover, any agreement that you could use to decide that TuxBlackEdo's summary was correct you could use to just validate the authenticity of a pruned chain at a given height.
182 2012-01-15 02:38:20 <gmaxwell> roconnor: in any case, this is all nicely soluable but not in bitcoin. Alas.
183 2012-01-15 02:38:38 <TuxBlackEdo> this would be kind of like a checkpoint, everyone the community already blindly accepts checkpoints
184 2012-01-15 02:38:48 <gmaxwell> No, it's not like a checkpoint.
185 2012-01-15 02:38:51 <roconnor> I don't see how what you or TuxBlackEdo is a solution to anything
186 2012-01-15 02:39:08 <roconnor> but I'm pretty confused
187 2012-01-15 02:39:50 <gmaxwell> TuxBlackEdo: no checkpoint in bitcoin has ever arbitrated over the identity of the right chain. Thats not what they're for.
188 2012-01-15 02:40:28 <luke-jr> TuxBlackEdo: I think you're describing a planned feature for Bitcoin 2.0, but that's a ways off
189 2012-01-15 02:40:30 <gmaxwell> roconnor: Well you should be, because I haven't mentioned how the storage issue is solved.
190 2012-01-15 02:40:36 <roconnor> oh good
191 2012-01-15 02:41:49 <gmaxwell> It's solved by bytecoin's "balance sheets", my "open transaction committments", Elden Tyrell's "trustless thin clients" ... or whatever other name it gets given when someone invents the same idea. :)
192 2012-01-15 02:42:18 <gmaxwell> which is basically committing to a tree of open transactions in every block, rather than committing to new transactions to an existing chain.
193 2012-01-15 02:42:41 <roconnor> how does that solve anything?
194 2012-01-15 02:42:44 <gmaxwell> And having the new spenders provide the source input transactions along with the tree fragements to prove their connectedness.
195 2012-01-15 02:43:53 <gmaxwell> roconnor: means that fully validating nodes don't have to store anything except block headers.
196 2012-01-15 02:44:16 <gmaxwell> Because the new blocks would tell them everything they need to know to advance their state.
197 2012-01-15 02:45:05 <roconnor> gmaxwell: fully validating nodes is weaker than full nodes?
198 2012-01-15 02:46:03 <theymos> How are reorgs handled? Do you have to remember the last 1000 blocks of transactions?
199 2012-01-15 02:46:46 <roconnor> theymos: with enough source input data you should be able to roll your open transactions back using the chain of headers.
200 2012-01-15 02:48:53 <gmaxwell> Right. You remember either the past states for reorgs, or just the history of changes and then you roll them back.
201 2012-01-15 02:49:52 <roconnor> gmaxwell: but fully validating nodes are weaker than full nodes.  Full nodes still need to remember everything in order to bring new full nodes or fully validating nodes online?
202 2012-01-15 02:50:01 <theymos> How do new nodes get to the current state? Unless they download all transactions (from someone who is still storing everything...), it seems to me that they need to trust the network or something else.
203 2012-01-15 02:50:54 <gmaxwell> You have a continuous level of choice in how much you trust vs how much data you need to bootstrap.
204 2012-01-15 02:51:27 <theymos> I don't see how that's superior to choosing how much data you download pruned and how much unpruned in the current system.
205 2012-01-15 02:51:47 <gmaxwell> So you could do the 'full node' route by talking to the archives and replaying the whole history... or you could, say, only reply the last year and trust that if someone was cheating it would have been disclosed in the last year, for example.
206 2012-01-15 02:52:02 <gmaxwell> theymos: because you can bootstrap anywhere into it.
207 2012-01-15 02:53:11 <gmaxwell> the current system basically just lets you be zero trust, or only be able to trust the network after the fact, e.g. you couldn't mine or judge an unconfirmed txn.
208 2012-01-15 02:53:40 <theymos> Would the current system be equivalent if transactions always included a copy of the input transactions?
209 2012-01-15 02:53:44 <gmaxwell> with commitments on open txn, even if you didn't bootstrap from block zero, you could still mine and judge unconfirmed txn with fairly high confidence.
210 2012-01-15 02:54:18 <gmaxwell> theymos: no because you don't know if that input was spent right outside of your viewing horizon.
211 2012-01-15 02:54:41 <gmaxwell> You could get the current system there by doing that _and_ adding a hash root for a tree of open transactions, which is validated by miners.
212 2012-01-15 02:55:26 <gmaxwell> The someone asking you to process a txn would provide the inputs and the fragments to show that the input was valid as of the block you were going to build on top of.
213 2012-01-15 02:57:06 <gmaxwell> I have some vague hope that namecoin will actually go and build this first, because this space of ideas is far more important to namecoin than bitcoin.
214 2012-01-15 02:57:53 <gmaxwell> Because namecoin has no useful solution for a zero-trust lite resolver today,  a bitcoin style SPV node in namecoin could just get fed stale answers and NXdomain and not know any better.
215 2012-01-15 02:59:18 <theymos> Ah, I see now how your tree system could be useful. When I was reading your forum post it also seemed useless to me.
216 2012-01-15 03:02:36 <theymos> I don't know whether the increased tx and block size would be worth it in Bitcoin. In the far future I don't think many nodes will have enough bandwidth to keep up with blocks anyway.
217 2012-01-15 03:05:35 <gmaxwell> If you assume removing the block size limits completely, then bitcoin fails as a decenteralized system. I think that would be sad.
218 2012-01-15 03:06:14 <gmaxwell> at the moment you need no more than 14kbit/sec to keep up in the absolutely worst case.
219 2012-01-15 03:07:01 <theymos> I don't think relying on super-nodes would be a failure as long as setting up a super node is not *impossible* for the average person.
220 2012-01-15 03:13:24 <gmaxwell> theymos: eehh, I expect that what you end up with there is that I setup a supernode. And it correctly rejects blocks fudged by the banking cartel, but it doesn't matter because very few people use my node, and I'm the odd man out.
221 2012-01-15 03:13:48 <gmaxwell> And that seems sad to me, far sadder than needing to use an overlay system in order to achieve visa peak transaction volumes.
222 2012-01-15 03:14:18 <gmaxwell> Realistically the flood everyhere hide nothingness of bitcoin which is important for overall security is a poor match to high volume low value transactions.
223 2012-01-15 03:15:50 <gmaxwell> to put an analogy to it,  if you insisted everyone do business in "gold" you'd end up with everyone using "gold nodes" and the value of gold would be debased because of cheating with the notes.
224 2012-01-15 03:16:50 <gmaxwell> Better to have gold be gold, as annoying as it is to handle, and do your sodapop purchases with scampal which you occassional trade up with your gold balances.
225 2012-01-15 03:17:28 <theymos> You might be right about that. A semi-centralized overlay network would indeed be better than a corrupt base system.
226 2012-01-15 03:17:36 <amiller> would you say then that bitcoin works best when the txes are sort of slow and sort of expensive?
227 2012-01-15 03:19:07 <gmaxwell> amiller: somewhat. Rather, lets drop the word 'best' for something more concrete.
228 2012-01-15 03:20:07 <gmaxwell> A bitcoin system which is properly decenteralized is fairly expensive per transaction. That expense is _justified_ by the good economic-security properties of the decenteralization.
229 2012-01-15 03:20:43 <gmaxwell> It's expensive because everyone validating it must see and validate it all, and must store a lot of it.
230 2012-01-15 03:20:53 <gmaxwell> You can reduce that cost by reducing the decenteralization.
231 2012-01-15 03:21:33 <theymos> gmaxwell: Your system could be mostly added to the current system in a backward-compatible way by requiring that the unspent-tree-root be in the coinbase (or some other transaction). Other network messages can be used to get the other data.
232 2012-01-15 03:21:47 <gmaxwell> Though if you don't want high decenteralization there are better system topologies that have better trust vs scale vs cost curves they can't achieve the absolute trust of bitcoin, but they can achieve much better scale.
233 2012-01-15 03:22:09 <gmaxwell> theymos: yes, I think so, it could be migrated to in parts if people wanted to go that way.
234 2012-01-15 03:22:23 <gmaxwell> There might be a minor flag day related to validation rules for miners.
235 2012-01-15 03:23:23 <gmaxwell> My thinking is also this: if bitcoin loses its hard-zero-trust-full-decenteralization (well, its lost it at the moment due to pools but I think we'll fix that), then there is and probably will be nothing else with that property.
236 2012-01-15 03:24:16 <gmaxwell> So I'd rather bitcoin stay _that_ and have other agile things provide fast transactions. We could even integrate them, if they were also p2p and had the right properties, into the popular bitcoin software.
237 2012-01-15 03:25:26 <gmaxwell> But thats just me blathering. I dunno what the future will hold.
238 2012-01-15 03:25:54 <amiller> well when you pick the right level of abstraction for the script, i think you'll find that it's a bridge between the agile servers and the mass public bitcoin
239 2012-01-15 03:26:16 <amiller> you'd basically factor the scripting contract language out of the random lottery pool structure that's really the characteristic of bitcoin
240 2012-01-15 03:26:41 <amiller> even OT servers will be able execute bitcoin script meaningfully
241 2012-01-15 03:39:15 <roconnor> dang, my freenode SSL certificate expired.
242 2012-01-15 03:42:15 <gmaxwell> SSL: Pratical security.
243 2012-01-15 04:05:12 <gribble> New news from bitcoinrss: forrestv opened pull request 759 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/759>
244 2012-01-15 06:53:00 <gmaxwell> So  who wants to guess how much data is actually written to the underlying disk during a fresh node sync-up?  (you don't get to play if you saw my comments about this in #p2pool earlier)
245 2012-01-15 06:55:12 <pusle> I got a nice screenshot for ya!
246 2012-01-15 06:55:13 <pusle> ;)
247 2012-01-15 06:55:21 <pusle> my lap top was trashing for a whole day
248 2012-01-15 06:55:24 <pusle> laptop
249 2012-01-15 06:55:31 <pusle> about 150gigs
250 2012-01-15 06:55:56 <pusle> but with your fix, it's now way down?
251 2012-01-15 06:56:52 <pusle> I think everybody else is sleeping gmax :)
252 2012-01-15 06:57:15 <gmaxwell> The mlock thing I found doesn't impact IO.
253 2012-01-15 06:57:31 <gmaxwell> pusle: I wasn't expecting a fast response.
254 2012-01-15 06:57:46 <pusle> ok, sorry then :/
255 2012-01-15 09:41:09 <Eliel> luke-jr: what kind of a practical problems do you expect to happen because of BIP 16? I'm personally fine with both BIP 16 and CHV but I don't feel like I really understand your objection to BIP 16.
256 2012-01-15 09:55:30 <CIA-100> bitcoin: Con Kolivas * r8171ceab8535 cgminer/findnonce.c: Simplify submit_nonce loop and avoid potentially missing FOUND - 1 entry. Reported by Luke-Jr. http://tinyurl.com/8xdgybj
257 2012-01-15 10:25:13 <CIA-100> libbitcoin: genjix * r6a9d96c26f8e /include/bitcoin/data_helpers.hpp: Improved uncast_type. http://tinyurl.com/7regkuz
258 2012-01-15 12:00:35 <CIA-100> bitcoin: p2k * rc70767fc2a40 ecoinpool/ (8 files in 4 dirs): Faster Block Chain Sync; Bugfix for Encrypted Passwords http://tinyurl.com/79rk3r7
259 2012-01-15 14:16:30 <etotheipi_> anyone in Ubuntu willing to help me test Armory? (https://bitcointalk.org/index.php?topic=56424)
260 2012-01-15 14:16:52 <etotheipi_> Windows works, too, but the build process is nasty
261 2012-01-15 14:31:05 <finway> gmaxwell: 1hour to 100k blocks, is this quick?
262 2012-01-15 14:31:13 <finway> initial download
263 2012-01-15 14:31:23 <sipa> sounds quite good
264 2012-01-15 14:31:36 <finway> i'm testing 0.5.2
265 2012-01-15 14:31:51 <finway> seems wonderful
266 2012-01-15 14:32:31 <finway> Huge improvement!
267 2012-01-15 14:33:47 <finway> sipa: When will the "blockhead downloading first, catch up later" client release?
268 2012-01-15 14:44:06 <Diablo-D3> that was fun
269 2012-01-15 14:44:12 <Diablo-D3> I locked up my gpu
270 2012-01-15 14:44:19 <Diablo-D3> but monitor didnt switch off
271 2012-01-15 14:44:56 <occulta> finway is that betqa?
272 2012-01-15 14:53:36 <etotheipi_> anyone know how you can search the IRC logs (such as, for this channel)?  I can get to the per-day select calendar, and individual pages, but I can't figure out how to search for text
273 2012-01-15 15:01:41 <roconnor> idea: miners should be encouraged to replace all sigScripts with equivalent sigScripts containing only PUSHDATA.  Bonus points for removing unneccesary PUSHDATA.
274 2012-01-15 15:01:54 <roconnor> pros: sigScripts end up with only PUSHDATA
275 2012-01-15 15:02:09 <roconnor> cons: transaction hashes change.
276 2012-01-15 15:02:25 <roconnor> counter-argument: these people deserve to have their transaction hashes changed.
277 2012-01-15 15:02:34 <Diablo-D3> best counter argument ever
278 2012-01-15 15:09:58 <CIA-100> bitcoin: Janne Pulkkinen master * r29b7273 / (src/qt/forms/aboutdialog.ui src/qt/forms/sendcoinsdialog.ui): *Clear all has a tooltip now *About dialog updated - http://git.io/gLiG-A https://github.com/bitcoin/bitcoin/commit/29b7273153c37b7c898ee058717925915f7d055b
279 2012-01-15 15:09:59 <CIA-100> bitcoin: Wladimir J. van der Laan master * r5dc0900 / (src/qt/forms/aboutdialog.ui src/qt/forms/sendcoinsdialog.ui): Merge pull request #758 from Matoking/master ... https://github.com/bitcoin/bitcoin/commit/5dc090009ea3b943d9b474555eea04acf6b6a972
280 2012-01-15 15:18:34 <etotheipi_> anyone here willing to help me test Armory?  (https://bitcointalk.org/index.php?topic=56424)
281 2012-01-15 15:19:51 <etotheipi_> I want to get an release alpha in the next week or two, but I need more testing (plus I know someone here wants offline transactions :))
282 2012-01-15 15:24:58 <roconnor> I think I'll modify my client to add messages to sigScripts in transactions I relay (on testnet)
283 2012-01-15 15:26:39 <etotheipi_> roconnor, what will that do?  won't it just break all the tx hashes?
284 2012-01-15 15:26:47 <etotheipi_> err.. signatures
285 2012-01-15 15:27:01 <roconnor> it will encourage miners to strip them I hope
286 2012-01-15 15:28:13 <etotheipi_> for what benefit?   did i miss an earlier discussion about miners-should-strip-off-data?
287 2012-01-15 15:28:37 <roconnor> 28 minutes ago I made the suggestion :)
288 2012-01-15 15:29:09 <etotheipi_> yeah, I saw that... but I guess I didn't understand... all the signatures will break meaning nothing can be valid
289 2012-01-15 15:29:33 <roconnor> etotheipi_: nope. Miners right now can replace any signature script with any equivalent signature script.
290 2012-01-15 15:29:55 <etotheipi_> oooh, right, because that script is removed before signign
291 2012-01-15 15:30:02 <etotheipi_> I was thinking of the output script
292 2012-01-15 15:30:05 <roconnor> This is the "bug" pointed out by Dan at DefCon IIRC
293 2012-01-15 15:30:33 <etotheipi_> this makes a lot more sense, now
294 2012-01-15 15:33:27 <etotheipi_> that almost seems so obvious in hindsight... is there anything stopping miners jamming arbitrary OP_DROP data into those scripts
295 2012-01-15 15:33:54 <etotheipi_> or I guess they  could put pushdatas on the bottom of the stack where it will be ignored after a equalverify/checksigverify
296 2012-01-15 15:33:55 <roconnor> if in the end, the stack isn't correct enough to validate, the transaction won't be accepted
297 2012-01-15 15:36:08 <etotheipi_> roconnor, what OS are you in?
298 2012-01-15 15:36:20 <roconnor> linux
299 2012-01-15 15:37:03 <etotheipi_> perfect.  I would be honored if you would look at Armory for me (https://bitcointalk.org/index.php?topic=56424)... I desperately need some testers
300 2012-01-15 15:37:18 <etotheipi_> and it's pretty easy to get going in Linux (at least it is in Ubuntu)
301 2012-01-15 15:37:24 <roconnor> does it work on testnet?
302 2012-01-15 15:37:29 <etotheipi_> yes, testnet is default
303 2012-01-15 15:37:48 <etotheipi_> just make sure you have a testnet satoshi client running and sync'd already
304 2012-01-15 15:38:08 <roconnor> I probably cannot look at it until next weekend
305 2012-01-15 15:38:13 <roconnor> or maybe later this week
306 2012-01-15 15:38:36 <etotheipi_> but you can use it pretty safely on main-network, just be sure to use the print-paper-backup method and no matter how bad it crashes, you'll always have your keys
307 2012-01-15 15:40:13 <etotheipi_> (but it's pretty robust, as I've done quite a bit of testing myself, but I can't tell if I'm too nice to it... I need users doing whacky things to test its robustness)
308 2012-01-15 16:04:40 <sipa> roconnor: i doubt any miner will touch scriptSig at all
309 2012-01-15 16:07:06 <roconnor> sipa: they will once my rogue relayer comes online
310 2012-01-15 16:07:48 <sipa> etotheipi_: large git repository!
311 2012-01-15 16:10:16 <etotheipi_> sipa, I haven't figured out how to remove some stupid exes I accidentally committed
312 2012-01-15 16:10:30 <etotheipi_> obviously I removed them from the project, but the repo is holding onto them
313 2012-01-15 16:10:43 <etotheipi_> and I'm not good enough with git to figure out how to actually remove it
314 2012-01-15 16:11:00 <sipa> i use git rebase for such things
315 2012-01-15 16:11:10 <sipa> allows you to go back to an earlier commit, and change things
316 2012-01-15 16:11:13 <etotheipi_> well, they're pretty deep in the blockchain by now
317 2012-01-15 16:11:18 <etotheipi_> err... not blockchain,
318 2012-01-15 16:11:22 <sipa> and let it rebuild the commits afterwards
319 2012-01-15 16:11:40 <etotheipi_> okay, I'll look into that, thanks
320 2012-01-15 16:12:22 <etotheipi_> won't that cause it to break for anyone currently checked out on a later commit?
321 2012-01-15 16:12:57 <sipa> yes
322 2012-01-15 16:13:55 <etotheipi_> gah... so there's no easier way to delete the data while just keeping the dangling pointer in the tree for hash integrity?
323 2012-01-15 16:14:13 <sipa> etotheipi_: ***ERROR:  C++ block utilities not available.
324 2012-01-15 16:14:25 <sipa> (after following your instructions)
325 2012-01-15 16:14:27 <etotheipi_> did follow the build instructions on the site?
326 2012-01-15 16:14:34 <etotheipi_> are in you in ubuntu?
327 2012-01-15 16:14:39 <sipa> yes, make swig worked perfectly
328 2012-01-15 16:14:52 <etotheipi_> first test:  failed
329 2012-01-15 16:14:53 <sipa> ubuntu 11.10 amd64
330 2012-01-15 16:14:55 <etotheipi_> :(
331 2012-01-15 16:15:14 <sipa> i believe it just doesn't look in that cppForSwig directory>
332 2012-01-15 16:15:15 <sipa> ?
333 2012-01-15 16:15:32 <etotheipi_> the swig object is copied to the base directory
334 2012-01-15 16:15:39 <etotheipi_> the issue is usually some kind of missing dependency
335 2012-01-15 16:15:54 <sipa> right, but . is usually not in LD_LIBRARY_PATH
336 2012-01-15 16:15:55 <etotheipi_> but I stupidly decided to print that generic message, instead of printing the actual error that would be useful for me
337 2012-01-15 16:17:26 <sipa> feel free to tell me what to change, etotheipi_
338 2012-01-15 16:17:40 <etotheipi_> thansk for your patience sipa, I'm investigating now
339 2012-01-15 16:18:30 <etotheipi_> in that base directory, can you open python and type "import CppBlockUtils"
340 2012-01-15 16:18:37 <etotheipi_> that will give me the error that is actually useful
341 2012-01-15 16:19:49 <sipa> that error looks like a problem with cryptopp, which i only installed after compiling most objects
342 2012-01-15 16:19:52 <sipa> i'll rebuild first
343 2012-01-15 16:21:31 <sipa> you don't use the cryptopp included in the source?
344 2012-01-15 16:21:38 <etotheipi_> it's a long story
345 2012-01-15 16:21:43 <etotheipi_> it's used on the windows side
346 2012-01-15 16:21:55 <etotheipi_> and I've tried it in Ubuntu, but I ran into some issues
347 2012-01-15 16:22:16 <sipa> ImportError: ./_CppBlockUtils.so: undefined symbol: _ZN8CryptoPP16IteratedHashBaseIjNS_18HashTransformationEE6UpdateEPKhm
348 2012-01-15 16:22:18 <sipa> that's the error
349 2012-01-15 16:22:25 <etotheipi_> yeah, definitely a cryptopp thing
350 2012-01-15 16:22:40 <sipa> but there is definitely something wrong
351 2012-01-15 16:23:04 <etotheipi_> I was afraid of this:  try one thing for me, please... in the makefile, just change all "cryptopp" paths/libs to "crypto++"
352 2012-01-15 16:24:05 <etotheipi_> sounds like, I need to get Ubuntu to start leveraging the included cryptopp dir
353 2012-01-15 16:25:12 <Joric> sipa is there a patch for generating privkey / sending bitcoins from a passphrase? could be handy
354 2012-01-15 16:28:04 <sipa> etotheipi_: python simply doesn't load libcrypto++.so
355 2012-01-15 16:28:10 <sipa> when doing that import
356 2012-01-15 16:28:20 <sipa> i've forced it to preload that library and it works
357 2012-01-15 16:28:36 <etotheipi_> okay, good to know... I'll look into a more-robust solution...
358 2012-01-15 16:29:04 <sipa> Joric: you generate a privkey by requesting a new address
359 2012-01-15 16:29:16 <sipa> Joric: and you can send coins using sendtoaddress?
360 2012-01-15 16:29:24 <hltv> shadders:you there?
361 2012-01-15 16:29:32 <sipa> possibly unlocking the wallet using walletpassphrase
362 2012-01-15 16:29:50 <Joric> sipa i mean generating privkey from passphrase
363 2012-01-15 16:32:17 <sipa> you mean determinstic keys? that's not implemented
364 2012-01-15 16:32:25 <sipa> etotheipi_: how does your key derivation work?
365 2012-01-15 16:32:38 <sipa> i'm impressed, by the way!
366 2012-01-15 16:33:31 <etotheipi_> it's the KDFRomix algorithm described in the scrypt-paper: http://www.tarsnap.com/scrypt/scrypt.pdf
367 2012-01-15 16:34:13 <sipa> oh, i don't mean how derivation from passphrase works; i know scrypt
368 2012-01-15 16:34:26 <sipa> but you have the ability to print the wallet to paper
369 2012-01-15 16:34:40 <sipa> how are keypairs derived from the information on that pahe?
370 2012-01-15 16:34:42 <etotheipi_> so it doesn't have quite the same flexibility as scrypt itself, but it's simpler than mashing together lots of different crypto algorithms
371 2012-01-15 16:34:43 <etotheipi_> ooh
372 2012-01-15 16:34:46 <sipa> root key / chain code
373 2012-01-15 16:35:52 <etotheipi_> root key is a BTC address private key... chaincode is 32-bytes of entropy....   C = hash256(pubKey) XOR chaincode;  PrivKey[i+1] = PrivKey[i[]*C mod N
374 2012-01-15 16:36:24 <etotheipi_> which is the gmaxwell-type-2 algorithm, meaning it can be applied with the public key alone, and that's how I enable watching-only wallets
375 2012-01-15 16:36:41 <sipa> aha, nice!
376 2012-01-15 16:36:57 <etotheipi_> and hence the magic behind offline-wallets :)
377 2012-01-15 16:40:01 <etotheipi_> so I've tested the wallets a lot... but if you plan to use real money ( --mainnet), please print off the paper wallet so that you can't lose any of it
378 2012-01-15 16:41:43 <sipa> etotheipi_: do you have support for compressed pubkeys?
379 2012-01-15 16:42:08 <sipa> (bitcoind 0.6 will use them)
380 2012-01-15 16:42:21 <etotheipi_> crap... no I don't
381 2012-01-15 16:42:38 <sipa> i've mailed some info to the mailinglist about them
382 2012-01-15 16:43:01 <etotheipi_> okay, I'll look into that...
383 2012-01-15 16:43:46 <sipa> etotheipi_: http://sourceforge.net/mailarchive/forum.php?thread_name=20111121114819.GB7261%40ulyssis.org&forum_name=bitcoin-development
384 2012-01-15 16:43:51 <etotheipi_> given that I can already do ECC math in my C++ code, how much effort do you think it is to add code to identify and compute the public key?
385 2012-01-15 16:44:05 <sipa> and http://sourceforge.net/mailarchive/forum.php?thread_name=CAPg%2BsBhDFCjAn1tRRQhaudtqwsh4vcVbxzm%2BAA2OuFxN71fwUA%40mail.gmail.com&forum_name=bitcoin-development
386 2012-01-15 16:44:37 <sipa> they are 33 bytes, and start with 0x02 or 0x03
387 2012-01-15 16:44:46 <sipa> instead of 65 bytes, and starting with 0x04
388 2012-01-15 16:45:25 <sipa> they are derived from identical private keys, but need some boolean flag in software to mark them as compressed, since they pubkey and hence address are difference
389 2012-01-15 16:45:27 <etotheipi_> ooh, so this has to go into the private-to-public ECC algorithm?
390 2012-01-15 16:45:33 <sipa> yes
391 2012-01-15 16:45:49 <sipa> you cannot tell whether an address corresponds to a compressed pubkey or not
392 2012-01-15 16:46:26 <sipa> and the base58 format for private key contains a marker 0x01 after the 32-byte secret to identify the corresponding pubkey to be compressed
393 2012-01-15 16:47:11 <etotheipi_> mathematically, how do I derive both keys:   if private key is a, then public key is a*G (where G is the generator point)
394 2012-01-15 16:47:21 <etotheipi_> what is the other key?
395 2012-01-15 16:47:29 <sipa> a public key is a point
396 2012-01-15 16:47:38 <sipa> compressed public keys are not different
397 2012-01-15 16:47:39 <etotheipi_> I meant, what is the other point
398 2012-01-15 16:47:44 <sipa> the same point
399 2012-01-15 16:47:48 <sipa> just a shorter serialization
400 2012-01-15 16:48:02 <mtrlt> compressed public keys only have the x coordinate and a bit to indicate which y coordinate is used right?
401 2012-01-15 16:48:04 <etotheipi_> ooh, it's the same X-value, but there's two possible Y values?
402 2012-01-15 16:48:08 <sipa> indeed
403 2012-01-15 16:48:10 <etotheipi_> gotcha
404 2012-01-15 16:48:22 <sipa> take bytes 1-33 of the normal pubkey, and prefix 0x02 if the y value is even, 0x03 if it is odd
405 2012-01-15 16:49:10 <etotheipi_> so I am replacing the y-value in the public key with 1-byte to identify which of the two possibilities it is
406 2012-01-15 16:49:25 <sipa> that's a possibility
407 2012-01-15 16:49:42 <etotheipi_> I'm just making sure I understand... and meant to add a '?' after that
408 2012-01-15 16:50:05 <etotheipi_> right now we have [0x04 | PubXBE(32) | PubYBE(32)]
409 2012-01-15 16:50:46 <etotheipi_> that is now becoming [0x02 | PubXBE(32)]    or     [0x03 | PubXBE(32)] .. ?
410 2012-01-15 16:51:14 <sipa> yes
411 2012-01-15 16:51:28 <etotheipi_> what is hashed for the address?
412 2012-01-15 16:51:38 <etotheipi_> err.. I guess that's hashed for the address
413 2012-01-15 16:51:38 <sipa> same formula
414 2012-01-15 16:51:45 <sipa> ripemd160(sha256(pubkey))
415 2012-01-15 16:51:55 <sipa> etotheipi_: the second link i gave links to a mail with some test vectors
416 2012-01-15 16:52:03 <etotheipi_> okay, thanks
417 2012-01-15 16:52:33 <etotheipi_> oh, I missed the seecond link
418 2012-01-15 16:52:37 <etotheipi_> that makes more sense
419 2012-01-15 16:55:07 <etotheipi_> how much time do you think I have before I'm going to have to support that?
420 2012-01-15 16:55:31 <etotheipi_> I'm scrambling to get stuff together for my client release... but clearly I'm going to have to push it back and rerun a bunch of unittests to support this
421 2012-01-15 16:55:56 <etotheipi_> (I've been so consumed by development, I haven't really paid much attention to mailing lists, etc)
422 2012-01-15 16:55:58 <sipa> i took me at most a few hours to get it running and tested in bitcoind
423 2012-01-15 16:56:10 <etotheipi_> oh, that's not bad
424 2012-01-15 16:56:29 <sipa> tested on mainnet, even
425 2012-01-15 16:56:39 <etotheipi_> are there compressed keys on mainnet right now?
426 2012-01-15 16:56:45 <sipa> yes
427 2012-01-15 16:56:50 <sipa> a few
428 2012-01-15 16:56:59 <etotheipi_> ugh... I bet they're all tucked away in my non-std-tx-map
429 2012-01-15 16:57:01 <sipa> i could find the txid if you like
430 2012-01-15 16:58:16 <etotheipi_> my problem will be updating my std-tx-detector to make sure they are caught and handled correctly... it sounds like actually doing the computation isn't hard
431 2012-01-15 16:58:45 <sipa> most openssl-based bitcoin code already supported them transparently
432 2012-01-15 16:58:59 <sipa> that's how they got accepted on mainnet
433 2012-01-15 16:59:01 <etotheipi_> unfortunately, I'm not using openssl... something I've come very close to switching too
434 2012-01-15 16:59:09 <etotheipi_> but I got kinda deep with cryptopp
435 2012-01-15 16:59:21 <sipa> i'm not very impressed by openssl
436 2012-01-15 16:59:44 <etotheipi_> well cryptopp isn't particularly fast... but I have liked using it (once you get over the learning curve)
437 2012-01-15 16:59:58 <sipa> i even had to implement creation of keys from a 32-byte secret myself
438 2012-01-15 17:00:15 <sipa> how long does a signature verification take you?
439 2012-01-15 17:00:19 <sipa> on what kind of hardware?
440 2012-01-15 17:01:19 <etotheipi_> I think I do about 150 sig-verifies per sec
441 2012-01-15 17:01:41 <etotheipi_> actually, I have a unit test that does the timing... I should run it again
442 2012-01-15 17:01:42 <sipa> ok, about 10x as slow as openssl
443 2012-01-15 17:01:50 <sipa> unless your cpu is ancient
444 2012-01-15 17:01:52 <etotheipi_> well there's some overhead with mine
445 2012-01-15 17:02:56 <etotheipi_> I mean, casting/copying data around... I never intended to do blockchain validation, so it didn't matter
446 2012-01-15 17:06:04 <CIA-100> libbitcoin: Kamil Domanski * r3e2c03e87873 / (2 files in 2 dirs): discovery: add handlers, move nick and channel name to class fields http://tinyurl.com/7o3h8x9
447 2012-01-15 17:06:05 <CIA-100> libbitcoin: Kamil Domanski * r6b7020336c3e / (3 files in 3 dirs): discovery: return present clients with handler http://tinyurl.com/7o59jpb
448 2012-01-15 17:06:38 <etotheipi_> OTOH, blockchain scanning was intended to be fast
449 2012-01-15 17:07:03 <etotheipi_> I got a full rescan of a wallet to 0.75s if the blockchain is in RAM
450 2012-01-15 17:07:22 <etotheipi_> about 10-15s if it has to be read from disk
451 2012-01-15 17:11:01 <etotheipi_> but you are enticing me to switch... it wouldn't hurt to use openssl, given that it's both faster, and more widely-suppoted
452 2012-01-15 17:31:16 <hltv> etotheipi_:and how did you put the blockchain in the ram exactly?
453 2012-01-15 17:39:47 <etotheipi_> hltv, you obviously have to have the RAM to begin wiht
454 2012-01-15 17:40:15 <etotheipi_> a future Armory release won't require it... but until then, Armory does a bulk copy from disk to RAM, then rescans all your wallets before startup
455 2012-01-15 17:41:01 <etotheipi_> there's no dependence on index files or anything of the sort... if you have the blockchain, loading Armory will rescan the blockchain for all your BTC
456 2012-01-15 17:52:16 <hltv> hltv:how much ram are we talking about here?
457 2012-01-15 17:55:14 <CIA-100> libbitcoin: genjix * rc99f4f425793 / (2 files in 2 dirs): fetch_block_depth(hash) http://tinyurl.com/7kcvbul
458 2012-01-15 18:15:09 <gmaxwell> So in my test, during syncup we cause 5.8 million writes to the media, writing 23 GiB in the process.
459 2012-01-15 18:17:01 <gmaxwell> Writing the blocks themselves are nice and neat, but before measuring it, I hadn't considered all the amplification we'd get from updating the index, but it makes perfect sense.
460 2012-01-15 18:20:33 <BlueMatt> gmaxwell: I was thinking, cblockstore would make delaying commitblock announcements till after the blocks were written to disk pretty easy...
461 2012-01-15 18:20:46 <BlueMatt> and you could do batch block writes
462 2012-01-15 18:22:12 <sipa> BlueMatt: not with the current mechanism
463 2012-01-15 18:22:58 <gmaxwell> Batch index writes appear to be the thing needed most though I haven't checked if bdb will actually conserve effort if you do a bunch of index updates in one transaction.
464 2012-01-15 18:23:51 <gmaxwell> (writing the blocks is almost certantly only about a GiB of that overall)
465 2012-01-15 18:57:09 <gmaxwell> I wonder why gavin just disabled the signature checking before the checkpoint rather than making it only validate the hash tree. That would cut down on a lot of IO.
466 2012-01-15 18:57:34 <sipa> the hash tree?
467 2012-01-15 18:58:06 <gmaxwell> the transaction hashes and merkle root
468 2012-01-15 18:58:54 <sipa> well, you still need to update the transaction index
469 2012-01-15 18:58:57 <sipa> that is most of the work
470 2012-01-15 18:59:34 <gmaxwell> Indeed. I don't know any way out of that.
471 2012-01-15 19:00:12 <gmaxwell> That think was mostly inspired by the fact that we've had a few incidents of people with corrupted chains on disk, and the only way to fix it is to erase it, because we don't have any hash validating rescan option.
472 2012-01-15 19:01:45 <genjix> hey my bitcoind is getting spammed with lots of orphan txs
473 2012-01-15 19:02:11 <genjix> weird huh
474 2012-01-15 19:04:04 <gmaxwell> I don't see them.
475 2012-01-15 19:04:09 <gmaxwell> have an ID number for one?
476 2012-01-15 19:04:36 <gmaxwell> oh maybe I do have some.
477 2012-01-15 19:06:55 <genjix> ok it stopped now
478 2012-01-15 19:07:06 <sipa> were you synced?
479 2012-01-15 19:07:11 <genjix> yep
480 2012-01-15 19:07:27 <gmaxwell> genjix: can you give me one of their IDs so I can see if I got them?
481 2012-01-15 19:07:43 <gmaxwell> perhaps someone joined an altchain to the bitcoin network. :)
482 2012-01-15 19:09:00 <genjix> sure
483 2012-01-15 19:09:02 <genjix> one sec
484 2012-01-15 19:10:56 <genjix> gmaxwell: my node is always up and the first thing i checked was block count which was in sync with bitcoinwatch, http://privatepaste.com/download/97c5d51958
485 2012-01-15 19:11:17 <genjix> there's 2 more pages of this here
486 2012-01-15 19:11:43 <gmaxwell> 01/15/12 20:00:16 askfor tx 09030d4c6be1404661c1   0
487 2012-01-15 19:12:17 <sipa> genjix: maybe it depended on another transaction which you don't have yet
488 2012-01-15 19:12:27 <sipa> just because it is downloaded in a different order
489 2012-01-15 19:12:39 <genjix> AcceptToMemoryPool(): accepted 621563b158
490 2012-01-15 19:12:44 <genjix> yep probably
491 2012-01-15 19:13:02 <genjix> that above tx was before them.
492 2012-01-15 19:15:17 <CIA-100> libbitcoin: genjix * r970f0351c616 /include/bitcoin/utility/subscriber.hpp: BUGFIX: add to subscribe queue while inside function call causes infinite loop so make copy of queue before calling functions. http://tinyurl.com/86s6b36
493 2012-01-15 19:21:31 <genjix> soo.... anybody watching the good wife? :)
494 2012-01-15 19:22:20 <gmaxwell> genjix: isn't it not on until later?
495 2012-01-15 19:22:39 <diki> is there a reason
496 2012-01-15 19:22:44 <diki> poolservj crashes bitcoin-qt?
497 2012-01-15 19:23:10 <genjix> gmaxwell: ah dunno.
498 2012-01-15 19:25:24 <genjix> i wish g++ had colours in its output
499 2012-01-15 19:25:46 <genjix> but the g++ devs refuse to add colours because they are old schol
500 2012-01-15 19:26:14 <sipa> not the compiler's task, imho
501 2012-01-15 19:26:20 <sipa> you can write a colorizer if you want one
502 2012-01-15 19:27:12 <genjix> yeah that's what they say
503 2012-01-15 19:28:55 <genjix> however distro developers say it is a g++ problem and it should provide colourisation... kind of agree since most tools come with an internal colouriser today.
504 2012-01-15 19:57:49 <midnightmagic> i was thinking graph colorizer, but you are talking about error highlighting and stuff aren't you
505 2012-01-15 19:58:33 <gmaxwell> hah. yes. like clang
506 2012-01-15 19:58:52 <gmaxwell> My solution: Avoid languages with 40 page error messages that you need colorization to read.
507 2012-01-15 20:00:22 <CIA-100> libbitcoin: genjix * rc3e0738c2ba7 / (4 files in 2 dirs): fetch_spend(output_point) -> input_point http://tinyurl.com/77sorcr
508 2012-01-15 20:15:45 <genjix> anybody wanna play with my bot
509 2012-01-15 20:16:16 <sipa> ieeuw
510 2012-01-15 20:17:07 <genjix> grrr one sec
511 2012-01-15 20:17:59 <block-exploiter> malformed command: Invalid command specified
512 2012-01-15 20:17:59 <genjix> @last_block_depth
513 2012-01-15 20:18:05 <block-exploiter> 768
514 2012-01-15 20:18:05 <genjix> @last_depth
515 2012-01-15 20:18:29 <genjix> @fetch_block_depth(100)[hash, transactions, nonce, transactions(0)[hash]]
516 2012-01-15 20:18:30 <block-exploiter> malformed command: Invalid command specified
517 2012-01-15 20:18:37 <genjix> @block_depth(100)[hash, transactions, nonce, transactions(0)[hash]]
518 2012-01-15 20:18:38 <block-exploiter> hash=000000007bc154e0fa7ea32218a72fe2c1bb9f86cf8c9ebf9a715ed27fdb229a  transactions=1  nonce=1573057331  transactions(0)[hash]=[hash=2d05f0c9c3e1c226e63b5fac240137687544cf631cd616fd34fd188fc9020866  ]
519 2012-01-15 20:19:14 <genjix> @tx(2d05f0c9c3e1c226e63b5fac240137687544cf631cd616fd34fd188fc9020866)[outputs(0)[value], hash, locktime]
520 2012-01-15 20:19:15 <block-exploiter> outputs(0)[value]=[value=5000000000  ]  hash=2d05f0c9c3e1c226e63b5fac240137687544cf631cd616fd34fd188fc9020866  locktime=0
521 2012-01-15 20:19:31 <genjix> just a little experiment
522 2012-01-15 20:20:45 <genjix> irc block explorer
523 2012-01-15 20:23:09 <andyroo> @help
524 2012-01-15 20:23:09 <block-exploiter> malformed command: Invalid command specified
525 2012-01-15 20:23:55 <genjix> :p didn't do that yet. commands are last_depth, block_depth, block_hash, transaction/tx
526 2012-01-15 20:24:13 <genjix> stuff in ()s is arguments and stuff [] is what to show
527 2012-01-15 20:36:30 <gribble> New news from bitcoinrss: sipa opened issue 760 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/760>
528 2012-01-15 20:40:14 <CIA-100> bitcoin: p2k * r532fbcc1acd0 ecoinpool/apps/ecoinpool/src/ (3 files): MySQL Share Logger http://tinyurl.com/6qtzerc
529 2012-01-15 20:57:34 <sipa> how hard is it to generate/choose a .onion address?
530 2012-01-15 20:57:45 <sipa> just generating a new public key, i assume?
531 2012-01-15 21:00:58 <andyroo> yep
532 2012-01-15 21:01:29 <andyroo> i don't know exactly how, but presumably deleting the existing one would do
533 2012-01-15 21:01:37 <andyroo> in /var/lib/tor/whatever
534 2012-01-15 21:07:59 <gmaxwell> sipa: it's an RSA public key.. but thats it.
535 2012-01-15 21:08:12 <gmaxwell> sipa: there are vanity onion generating tools.
536 2012-01-15 21:08:42 <gmaxwell> (well the address itself is an 80 bit hash of an rsa public key, of course)
537 2012-01-15 21:09:04 <sipa> gmaxwell: i was wondering whether the entire onioncat ipv6 range should be considered equal to a /16 on ipv4, or that each single onion address should be considered a group
538 2012-01-15 21:09:21 <sipa> if it is easy to choose an onion address, i assume the first option is best
539 2012-01-15 21:10:08 <gmaxwell> Yes, the first option is what I was thinking of there.
540 2012-01-15 21:10:16 <sipa> actually, it must be the first option; otherwise you can pollute someone's the entire table by just generating enough onion addresses
541 2012-01-15 21:10:22 <sipa> -the
542 2012-01-15 21:10:38 <gmaxwell> Also for the source-groups for unknown addresses, I think IRC-sourced should be a single group.
543 2012-01-15 21:11:43 <sipa> and DNS, built-in peers, and configfile?
544 2012-01-15 21:12:25 <gmaxwell> built in peers, single group..   I don't now about config files.  For DNS I'd think it would be one group per domain. (or even apply the /16 source rule as if the domains were nodes)
545 2012-01-15 21:13:22 <gmaxwell> (oh, you probably don't know the NS record.. so you can't do the /16 source rule :) )
546 2012-01-15 21:13:30 <sipa> indeed
547 2012-01-15 21:14:09 <sipa> but this is a good idea
548 2012-01-15 21:15:13 <BlueMatt> sipa: well, no, not now, but having a nicer api there to modify makes it easier
549 2012-01-15 21:15:44 <gmaxwell> Bloop?
550 2012-01-15 21:16:20 <BlueMatt> (from much, much earlier)
551 2012-01-15 21:17:05 <sipa> BlueMatt: what is that a reply to?
552 2012-01-15 21:18:35 <BlueMatt> <sipa> BlueMatt: not with the current mechanism
553 2012-01-15 21:18:47 <BlueMatt> (cblockstore disk writes
554 2012-01-15 21:18:48 <BlueMatt> )
555 2012-01-15 21:19:14 <sipa> right; the current verification mechanism depends on a db transaction around all block operations, in order to be able to revert afterwards
556 2012-01-15 21:19:39 <sipa> so you need a db commit per block, unless that mechanism is changed (and that would be a good thing, imho)
557 2012-01-15 21:20:36 <BlueMatt> well my point was just that a nicer api could allow us to do disk writes apart from verification and not have to spend as much time looking at stuff not in main.cpp
558 2012-01-15 21:28:51 <BlueMatt> jgarzik...
559 2012-01-15 21:29:15 <BlueMatt> oh, OneFixit this time
560 2012-01-15 21:29:22 <BlueMatt> oh, OneFixt this time
561 2012-01-15 22:06:14 <etotheipi_> can someone clarify some Satoshi client behavior for me?  If I send a tx with too much input, I get a change output back to myself, but that output will have zero-conf and thus should appear "unconfirmed".  But the Satoshi client checks whether that txout was sent-to-self and allows it to be considered "confirmed" to be spent immediately.  And miners will process such zero-conf outputs as long as they received the first tx and c
562 2012-01-15 22:07:33 <etotheipi_> or does the zero-conf tx have to wait a block to be included?  if it's included in the same block, is it guaranteed to have an index higher than the one it is spending?
563 2012-01-15 22:07:58 <gmaxwell> etotheipi_: there is no wait required.
564 2012-01-15 22:08:14 <gmaxwell> You can have a block that includes transactions which spend the output of transactions in that block.
565 2012-01-15 22:08:41 <sipa> the satosi client indeed allows 0-conf outputs to be spend, if tey come from self
566 2012-01-15 22:08:47 <gmaxwell> The reason the client prefers confirmed outputs is not due to spendability, but to reduce risk/disruption due to forks.
567 2012-01-15 22:09:06 <sipa> seems my  key is broken
568 2012-01-15 22:09:57 <etotheipi_> I understand the risks involved... I'm more trying to figure out what is acceptable behavior for my client with regards to zero-conf tx... following Satoshi client on this one is probably preferred
569 2012-01-15 22:10:28 <gmaxwell> Yes, as far as what miners will do the 0-confirm using transaction will end up with a low priority most likely.
570 2012-01-15 22:11:37 <etotheipi_> finally, can I always expect the tx index to be higher than the tx being spent?
571 2012-01-15 22:12:53 <sipa> etotheipi_: if you are sure tat an output will not be attempted to be spent by anoter transaction, you can allow 0-conf
572 2012-01-15 22:13:28 <sipa> if it is your own, you can ave suc confidence
573 2012-01-15 22:13:44 <etotheipi_> sipa, you mean, as long as the person isn't running two clients at once and tries to spend at the same time?
574 2012-01-15 22:13:45 <gmaxwell> sipa: use 4 instead? :)
575 2012-01-15 22:14:04 <gmaxwell> etotheipi_: no, as long as you won't be victized by someone else.
576 2012-01-15 22:14:30 <gmaxwell> etotheipi_: say someone sends you 0.01 btc but decides to try to rip you off, and concurrently spends the 0.01 btc elsewhere.
577 2012-01-15 22:14:41 <etotheipi_> I'm not sure why there's a difference there... if you have a zero-conf txout from yourself vs someone else, you are still the only person that can spend it
578 2012-01-15 22:14:49 <gmaxwell> etotheipi_: meanwhile you're paying your rent and you use that unconfirmed 0.01 btc as an input.
579 2012-01-15 22:14:52 <etotheipi_> oh... double-broadcast
580 2012-01-15 22:15:30 <gmaxwell> The reason it accepts self-txn is that presumably you trust yourself to not cheat. But it wants txn from other people to be confirmed, because you don't trust them.
581 2012-01-15 22:16:17 <etotheipi_> okay, this makes perfect sense
582 2012-01-15 22:16:49 <etotheipi_> in fact I even have a double-broadcast detector built into my networking, but I'd have to become networking-independent to use it (I'm filtering everything through the Satoshi client)
583 2012-01-15 22:17:06 <etotheipi_> but that's a different story
584 2012-01-15 22:17:53 <gmaxwell> etotheipi_: well you can't really detect them well, even if you weren't behind a single node.
585 2012-01-15 22:18:05 <etotheipi_> well it detects the obvious ones
586 2012-01-15 22:18:11 <gmaxwell> simply because the network doesn't propagate them
587 2012-01-15 22:18:16 <etotheipi_> if the person attempting to double-broadcast has a separate network