1 2013-08-25 00:47:08 <jgarzik> sipa, given the ACKs I'd say it's ok to merge block blacklisting RPC (#2839) whenever you are happy with it
2 2013-08-25 00:48:48 <gmaxwell> No point.
3 2013-08-25 00:48:57 <gmaxwell> jgarzik: it needs to be rewritten relative to headers first.
4 2013-08-25 00:49:32 <gmaxwell> (and I expect it would have ~no code in common with an implementation over headers first)
5 2013-08-25 00:49:57 <gmaxwell> (if I'm wrong and sipa doesn't agree with me, than I retract and it can be merged away!)
6 2013-08-25 00:51:28 <gmaxwell> I suppose its less bad when you've obsoleted your own commits. :)
7 2013-08-25 01:44:33 <jgarzik> petertodd, would you mind re-reviewing #2738 (OP_RETURN)?
8 2013-08-25 02:00:00 <petertodd> jgarzik: sure
9 2013-08-25 02:00:24 <petertodd> jgarzik: Also, I've gotten all the script_(in)valid.json tests working: https://github.com/petertodd/python-bitcoinlib/tree/pythonize
10 2013-08-25 02:00:48 <petertodd> jgarzik: Along with plenty of other stuff...
11 2013-08-25 02:01:16 <gmaxwell> jgarzik: would you like to merge that soon? I was sort of hoping to delay it until after removing unspendables and payment protocol were in the wild a bit first.
12 2013-08-25 02:03:20 <gmaxwell> (in order to give modalities that don't require craming crap in transaction in cases where there is a choice time to get some traction first)
13 2013-08-25 02:07:49 <jgarzik> gmaxwell, my answer is very amorphous
14 2013-08-25 02:08:09 <jgarzik> gmaxwell, I try to be "a catalyst", and in general keep pushing things I want forward
15 2013-08-25 02:08:20 <gmaxwell> okay, well amorphous reflects my thoughts too.
16 2013-08-25 02:08:37 <jgarzik> gmaxwell, so.. soon? I would be nice, but it's not necessary by date X or release Y
17 2013-08-25 02:08:41 <jgarzik> *It
18 2013-08-25 02:08:43 <gmaxwell> Fair enough.
19 2013-08-25 02:12:56 <petertodd> jgarzik: Same comment as last time: harm reduction, so make sure there is an incentive to use OP_RETURN rather than other crap, because right now if I want to put data in the blockchain I might as well just use <33-120 bytes of junk> OP_CHECKSIG/MULTISIG after I've used up my free OP_RETURN txout.
20 2013-08-25 02:13:40 <petertodd> jgarzik: Also, 80 bytes is too small for a announce/commit sacrifice for instance.
21 2013-08-25 02:24:45 <Diablo-D3> http://gifdanceparty.com/
22 2013-08-25 02:26:59 <gmaxwell> petertodd: it isn't if you define the right kind of encoding for one and make it well known.
23 2013-08-25 02:27:19 <jgarzik> petertodd, at first glance, most of the python-bitcoinlib changes from today seem mergeable
24 2013-08-25 02:28:24 <petertodd> gmaxwell: signatures are 73 bytes, so you're going to have to be pretty damn clever and convoluted. 120 bytes on the other hand is enough - I've done announce/commit via CHECKMULTISIG
25 2013-08-25 02:28:55 <petertodd> jgarzik: kinda surprises me that'd you'd think that :) I've changed the API on stuff
26 2013-08-25 02:29:21 <gmaxwell> petertodd: ecdsa signatures are 65 bytes. If you have 8 bytes of identifer for the txout you're going to spend, and then a signature, and the transaction in question has a known in advance form, thats enough.
27 2013-08-25 02:29:33 <jgarzik> petertodd, people /do/ use pynode, so it would be nice to not break (or fix) the one user we have
28 2013-08-25 02:30:29 <petertodd> gmaxwell: It makes no sense to hyper-optimize one application like that at great expense to implementation complexity when so many others aren't.
29 2013-08-25 02:30:43 <petertodd> jgarzik: Do they use pynode in stock form or highly modified?
30 2013-08-25 02:31:13 <jgarzik> petertodd, tends to be stock form + site-specific code that is easily hooked in
31 2013-08-25 02:31:33 <jgarzik> petertodd, thus, both. the stock form is widely used, then added upon.
32 2013-08-25 02:31:47 <jgarzik> well, FSVO "widely"
33 2013-08-25 02:31:51 <gmaxwell> petertodd: maybe, just saying that 80 bytes probably is enough.
34 2013-08-25 02:31:54 <petertodd> jgarzik: Hmm... Well I think it makes sense to merge if I can port pynode over, but equally call it v0.2 and accept that the API's changed.
35 2013-08-25 02:33:12 <petertodd> gmaxwell: Frankly, I'm just as soon to say the announce/commit protocol is if you get a tx with a pushdata, or sequential series of pushdata's, that happen to be a valid tx it's a valid announce commit.
36 2013-08-25 02:33:38 <jgarzik> petertodd, sure that's fine. Just saying that pynode would appreciate an update to any new API, as it depends on python-bitcoinlib
37 2013-08-25 02:33:51 <jgarzik> no need to bother with compat
38 2013-08-25 02:34:00 <petertodd> jgarzik: Good - can't do API's in a vacuum anyway.
39 2013-08-25 02:34:17 <gmaxwell> petertodd: encoding a transaction does require encoding a lot more data than is strictly required for an effective protocol.
40 2013-08-25 02:35:33 <gmaxwell> petertodd: esp compared to a fairly modest softfork that helps out that case with an OP_ANNOUNCE
41 2013-08-25 02:36:22 <gmaxwell> (embed the transaction hash, OP_ANNOUNCE it... block isn't valid at the chain tip unless you've seen the preimage to the OP_ANNOUNCE)
42 2013-08-25 02:36:43 <petertodd> gmaxwell: If you want to soft-fork, do OP_BLOCKHEIGHT... announce/commit is fundementally dodgy given how it could encourage hashpower centralization, while blockheight can push things back to the point where it's hard to know of a pool will even be in business.
43 2013-08-25 02:37:23 <gmaxwell> petertodd: oh, not redeemable until after height X? I suppose.
44 2013-08-25 02:37:33 <gmaxwell> thats more elegant, indeed, makes the proof smaller too.
45 2013-08-25 02:38:01 <gmaxwell> though not as useful if you want to do other kinds of announcement other than provably throw away.
46 2013-08-25 02:38:26 <petertodd> gmaxwell: Much smaller, and I really don't think the worries about re-orgs re: state matter - we already have the exact same issue with anyone-can-spend as well as txid mutability.
47 2013-08-25 02:39:14 <petertodd> gmaxwell: Oh, OP_ANNOUNCE as a parallel temporary UTXO?
48 2013-08-25 02:41:14 <gmaxwell> petertodd: OP_ANNOUNCE is basically the P2SH^2 idea made generic. Allows you to insert data which is provably a hash.. but the proof is ephemeral and only enforced at the tip of the chain... so the blockchain history isn't bloated.
49 2013-08-25 02:42:33 <petertodd> gmaxwell: Yeah, like we discussed before. I'm a bit dubious about the idea because it encourages more bandwidth usage - what's we're constrained by. It'd be tricky to come up with a reasonable pricing mechanism, and it's just as likely there will be strong pressure to not make it limited...
50 2013-08-25 02:42:38 <gmaxwell> though if you want to talk about rulechanges relative to throwing away coins, some facilitity for making efficient bonds that pay out over many blocks would be nice. I do worry about the risk of big bounties creating reorg incentives, esp when concentrating your tossed coin makes your proof smaller.
51 2013-08-25 02:43:22 <gmaxwell> petertodd: you can always impose limits on the size of the preimages. It's unconditionally better than having them inside the transactions, and can be made to use no more bandwidth (though with implementation complexity tradeoff)
52 2013-08-25 02:43:53 <gmaxwell> e.g. 'compress' the transaction + removable data by replacing the push with a 'replace with hash here' token... and then it's no larger than including the data directly.
53 2013-08-25 02:43:54 <petertodd> gmaxwell: Got any ideas on how to pull off multi-block bounties in a soft-fork though?
54 2013-08-25 02:44:15 <gmaxwell> petertodd: special form of anyone can spend transaction which has spending limited.
55 2013-08-25 02:44:48 <gmaxwell> e.g. anyone can pay into it, but you can only take funds out as fees at a particular rate and continue to pay along the chain.
56 2013-08-25 02:44:55 <petertodd> gmaxwell: Well, simpliest would be if the pre-image data is just 1:1 with regular tx data in terms of blocksize.
57 2013-08-25 02:45:35 <petertodd> gmaxwell: Problem is so much stuff assumes that if a txout is spent, that's it, but if you create dummy txouts with constrained scriptPubKeys why not just create multiple outputs in the first place?
58 2013-08-25 02:46:02 <gmaxwell> petertodd: makes the proof bigger.
59 2013-08-25 02:46:45 <gmaxwell> which was my concern: people will make really big atomic announce commits because it makes their proof small. And then that has an externalized cost of bountying reorgs.
60 2013-08-25 02:46:54 <jgarzik> create a route-through-coinbase magic sighash flag or somesuch. It is magically (a) decentralized P2P mixing and (b) block-locked for 100 blocks.
61 2013-08-25 02:48:30 <petertodd> gmaxwell: That doesn't work though, because providing only part of a transaction and a sha256 midstate doesn't prove anything because you can't know if what you think is an opcode wasn't just part of a big pushdata.
62 2013-08-25 02:48:47 <petertodd> gmaxwell: Sacrifice tx's need to be included in their entirety.
63 2013-08-25 02:50:28 <gmaxwell> petertodd: I have no clue what you're talking about there.
64 2013-08-25 02:52:35 <jgarzik> ACTION doesn't parse the latter either? but RE sacrifice transactions, the normal logic is that you are proving that the data is widely distributed, and that anyone had a chance to spend/mine the timelocked TX#2 embedded within TX#1
65 2013-08-25 02:53:02 <petertodd> gmaxwell: So I have a sacrifice tx, and I want to prove that the last CTxOut() had a value of 100BTC, and an anyone-can-spend scriptPubKey that is OP_BLOCKHEIGHT locked for 100+ blocks. How do I prove that the CTxOut is real rather than the end of a bigger CTxOut with a big PUSHDATA?
66 2013-08-25 02:53:22 <petertodd> jgarzik: we're past announce/commit sacrifices here :)
67 2013-08-25 02:53:47 <gmaxwell> petertodd: provide the whole transaction. Done. And thus you want to use only a single output to make it small. :)
68 2013-08-25 02:55:03 <petertodd> gmaxwell: Right, but we can't make a soft-fork that lets you spend that single txout multiple times in multiple blocks. The best you can do is make it so each tx spending it is constanted to only spend x% of the value, and include a txout with similar conditions for the other y% - not ideal from a blockchian size perspective.
69 2013-08-25 02:55:37 <petertodd> gmaxwell: A hard fork is possible of course, or a "SPV soft-fork" made possible because SPV nodes don't verify much...
70 2013-08-25 02:55:49 <jgarzik> ah, ok
71 2013-08-25 02:56:08 <gmaxwell> petertodd: oh I see how you misunderstood me.
72 2013-08-25 02:56:18 <gmaxwell> petertodd: no that isn't how what I was suggesting works.
73 2013-08-25 02:56:51 <gmaxwell> petertodd: you create an anyone can spend output, and there is a soft fork rule that says you can take a certan amount from such an output as fees and must pass the rest forward in another anyone can spend output.
74 2013-08-25 02:57:20 <gmaxwell> the proof only needs to show the first one, of course, and then the network will dole out the funds over a sufficient period.
75 2013-08-25 02:57:49 <gmaxwell> and if constructed right you could allow the forward transaction to merge multiple of these things, so it's only ever a single pay-forward transaction per block.
76 2013-08-25 02:57:49 <petertodd> gmaxwell: Er, right, we're on the same page there. The problem is again that while you've made your proof small, there's still a fair bit of blockchain bloat involved.
77 2013-08-25 02:58:07 <petertodd> gmaxwell: True, I guess merge rules are alright.
78 2013-08-25 02:58:27 <gmaxwell> petertodd: one transaction per block for all blocks forever... perhaps as jgarzik suggested it could be via the coinbase to simplify the input side.
79 2013-08-25 02:58:54 <gmaxwell> e.g. you'd merge via fees, and the pay forward has to be in the coinbase. but I think that doesn't quite get the incentives right. :(
80 2013-08-25 02:59:12 <gmaxwell> because you actually want the very next miner to collect some of the fees, otherwise he still may have an incentive to reorg.
81 2013-08-25 02:59:48 <petertodd> gmaxwell: Yeah, should be that whatever is in the magic txout you can spend n% of it for your block, maybe 1%?
82 2013-08-25 03:00:07 <gmaxwell> but I think this has no overhead vs the one time payment, except for one transaction per block in blocks that would otherwise have no sacrifices going into them.
83 2013-08-25 03:00:11 <petertodd> Maybe even a lot less? Try to spread the money out over multiple business cycles?
84 2013-08-25 03:00:57 <gmaxwell> I really think that a peroid of 2016 for complete consumption is fine (if you were to make it uniform) basically enough to keep you consuming so that the difficulty doesn't drop this cycle.
85 2013-08-25 03:01:20 <gmaxwell> maybe longer would make sense, but I think 2016 for uniform is probably the minimum that makes sense for adequate smoothing.
86 2013-08-25 03:01:48 <petertodd> gmaxwell: I was mainly trying to avoid perverse incentives where you sacrifice knowing that you'll get most of the sacrifice back in fees anyway because you have x% of the hashing power.
87 2013-08-25 03:02:15 <gmaxwell> even with an atomic sacrifice you have an x% _expectation_.
88 2013-08-25 03:02:58 <petertodd> gmaxwell: Not if the fees only become collectable far enough in the future that you have uncertainty as to whether your pool will even be in business.
89 2013-08-25 03:03:18 <petertodd> gmaxwell: My expectation of collecting a sacrifice 1000 years in the future is rather low. :P
90 2013-08-25 03:03:24 <gmaxwell> petertodd: sure but then I don't think the pacing matters on how it plays out. and too far in the future has other risks.
91 2013-08-25 03:03:42 <gmaxwell> e.g. you really don't want the economic hazard of sacrifices from transactions 100 years ago showing up.
92 2013-08-25 03:04:05 <gmaxwell> e.g. 1 BTC buys a planet, and then some 100 yr 100 btc sacrifices become payable...
93 2013-08-25 03:04:13 <petertodd> gmaxwell: Well you want the sacrifice to be a true sacrifice, and you *also* want sacrificed funds, once they finally come due, to be spread out enough tthey don't encourage re-orgs.
94 2013-08-25 03:04:39 <petertodd> gmaxwell: heh, there's an announce-commit for 1BTC set for 2030 or something in the chain IIRC
95 2013-08-25 03:04:44 <gmaxwell> I'm sure a whole paper can be written about the reorg incentives...
96 2013-08-25 03:04:53 <petertodd> gmaxwell: I already did. :P
97 2013-08-25 03:06:39 <gmaxwell> petertodd: honestly I wish the subsidy worked differently and it just constantly awarded some small amount of all non-existing coins. :(
98 2013-08-25 03:06:55 <gmaxwell> so then your sacrifice would just make the coins non-exist and done.
99 2013-08-25 03:07:19 <petertodd> gmaxwell: yeah, which is what OP_SACRIFICE does really...
100 2013-08-25 03:07:30 <petertodd> gmaxwell: just in a convoluted way :(
101 2013-08-25 03:08:16 <gmaxwell> if there was a utxo tree committed that showed a sum of existant coins, then the subsidy payment would be obvious from it.
102 2013-08-25 03:08:27 <petertodd> Yup
103 2013-08-25 03:09:11 <gmaxwell> I still havn't figured out of schemes that required part of fees to be paid forward made sense.
104 2013-08-25 03:09:44 <gmaxwell> e.g. half fees in the block go to the miner, have go back into the subsidy pool.
105 2013-08-25 03:10:18 <Diablo-D3> ACTION looks into channel
106 2013-08-25 03:10:20 <petertodd> One way to think about it is the pool is basically you saying "I don't just want one confirmation, I wasn n"
107 2013-08-25 03:10:29 <Diablo-D3> ACTION isnt sure if he wants to know
108 2013-08-25 03:11:04 <gmaxwell> right. though so does the coinbase locking for 100 blocks!
109 2013-08-25 03:12:01 <petertodd> gmaxwell: True!
110 2013-08-25 03:14:58 <gmaxwell> the problem I have with splitting schemes like that is they create incentives for backdoor payments.
111 2013-08-25 03:15:17 <gmaxwell> e.g. I give you a free transaction, and a child that pays directly to your private address.
112 2013-08-25 03:15:32 <gmaxwell> otherwise its elegant.
113 2013-08-25 03:15:45 <petertodd> gmaxwell: Maybe better would be to push your transaction checkpoints stuff first?
114 2013-08-25 03:16:15 <petertodd> gmaxwell: re-using nSequence is a good option for it
115 2013-08-25 03:16:36 <gmaxwell> I still don't really know how to do that as a resonably efficient soft fork. except perhaps stuffing the data in nlocktime with max serial number.
116 2013-08-25 03:17:21 <petertodd> What's wrong with nSequence and forcing it to match the last 32-bits of a recent block hash?
117 2013-08-25 03:18:17 <gmaxwell> petertodd: dunno. perhaps thats fine. I also don't know if it should deny the transaction entirely or make you burn (some?) fees.
118 2013-08-25 03:18:47 <petertodd> gmaxwell: I'd say deny entirely
119 2013-08-25 03:19:12 <petertodd> gmaxwell: Miners might have no fee related incentives too after all.
120 2013-08-25 03:19:16 <gmaxwell> thoug that would be more motivation to be really conservative with your checkpoints, e.g. never place one past funds you care about.
121 2013-08-25 03:19:45 <petertodd> past as in newer or older?
122 2013-08-25 03:20:39 <gmaxwell> if the highest transaction paying you is at X you put your checkpoints at X. Higher just increases your risk of non-confirmation without protecting your funds. (assuming a silly greedy-rational user model)
123 2013-08-25 03:21:10 <gmaxwell> (not that I'd think people would do that, would be better if there were less incentive to)
124 2013-08-25 03:21:19 <petertodd> True, but over a whole userbase that'll have people still moving forward with checkpoints.
125 2013-08-25 03:22:01 <gmaxwell> sure but txn already have that kind of checkpointing in a way... if you reverse my past txn, you don't get its later child fees.
126 2013-08-25 03:22:11 <petertodd> The "tx not allowed at all" rule helps discourage attackers who might want to try to rewrite a bunch of the chain to selectively delete some tx's too.
127 2013-08-25 03:22:57 <gmaxwell> yep thats part of the benefit. Turn personal protection into herd immunity.
128 2013-08-25 03:23:05 <petertodd> Yup
129 2013-08-25 03:23:42 <petertodd> Of course the counter argument is if we do this, we can't do a later soft-fork to make it a fee thing...
130 2013-08-25 03:23:55 <gmaxwell> yea, clamps one way.
131 2013-08-25 03:24:04 <gmaxwell> but if its a fee thing I have no clue what the rule should be.
132 2013-08-25 03:24:17 <gmaxwell> like, there isn't a fraction which is obvious to me.
133 2013-08-25 03:24:27 <petertodd> I *guess* you could just make it the fees get distroyed in that case, but it's not ideal.
134 2013-08-25 03:24:35 <petertodd> *destroyed
135 2013-08-25 03:25:04 <gmaxwell> that was my thinking. You could still do censorship reorgs, but there would be a cost in fees lost forever.
136 2013-08-25 03:25:28 <petertodd> Yeah, problem is the profit motive could easily be outweighed by the "do what we say" motive.
137 2013-08-25 03:25:41 <petertodd> Better if the whole system will go nuts if you try to pull your censorship crap.
138 2013-08-25 03:26:07 <gmaxwell> maybe, but it also means that "oh fuck, reorg to remove an exploit!" is viable, wherease if you deny it means double spending risk for some transactions.
139 2013-08-25 03:26:19 <gmaxwell> "censorship for GOOD!"
140 2013-08-25 03:27:08 <gmaxwell> e.g. the deny completely means you are forced to create doublespending risk, given that you're already going to do a reorg.
141 2013-08-25 03:27:51 <gmaxwell> I'd also be inclined to as a rule deny checkpoints that are too close, it actually hurts the fungibility of those coins.
142 2013-08-25 03:27:52 <petertodd> Yeah, although if it's easy to do such things maybe Bitcoin is less secure then we'd like anyway - why not just have those operators agree to not let double-spends through for awhile?
143 2013-08-25 03:28:27 <gmaxwell> e.g. I pay you with a coin that is checkpointed at the last block... uh.. that coin is worth less to you than other coins until several blocks pass.
144 2013-08-25 03:28:41 <petertodd> On the other hand in the future really close checkpoints may help remove reorg incentives, and you already should wait for confirmations anyway.
145 2013-08-25 03:28:57 <gmaxwell> petertodd: hm. I guess I agree there, they could just watch for 1:1 replacements and hopefully most parties could make them.
146 2013-08-25 03:29:05 <petertodd> Yup
147 2013-08-25 03:29:23 <gmaxwell> it's true, but again, I think really close checkpoints argue for fee burning insead of denial.
148 2013-08-25 03:29:38 <petertodd> And 1:1 replacements can be made a lot easier if there's a sighash version that only hashes the scriptSig's of the txins, rather than the hashes
149 2013-08-25 03:30:51 <gmaxwell> "don't force miners to expose you to double spends" keeping in mind that there might be additional consensus mechenisms incentivizing miners to mine feeless transactions. Or child pays parent.
150 2013-08-25 03:31:26 <gmaxwell> e.g. someone pays you with a checkpoint set too close to tip and vanishes. Child pays for parent to get it into the chain.
151 2013-08-25 03:31:49 <gmaxwell> vs be out funds forever and be constantly pissed when people pay you with funds that are near-tip-checkpointed.
152 2013-08-25 03:32:23 <gmaxwell> (in fact, that would be a possible theft strategy, constantly pay people with tip checkpointed funds and hope reorgs deny those transactions so you can just doublespend later)
153 2013-08-25 03:32:51 <petertodd> True, maybe all we can do is remove the fees?
154 2013-08-25 03:33:05 <petertodd> Anyway as I said, tightening only goes in one direction.
155 2013-08-25 03:33:10 <gmaxwell> I think either can be done, I'm just trying to reason out the best large scale implications.
156 2013-08-25 03:33:39 <gmaxwell> I think the most strict we should consider is removing all fees.
157 2013-08-25 03:34:10 <gmaxwell> (maybe if that proves out well then in the future people clamp it futher)
158 2013-08-25 03:35:05 <petertodd> With nSequence there is enough bits to have control over whether you want the fees to be 0%, 50%, 100% whatever.
159 2013-08-25 03:35:24 <gmaxwell> hm? there are 32, no?
160 2013-08-25 03:35:42 <petertodd> Exactly, and 32 is already 4 billion times harder to mine.
161 2013-08-25 03:36:32 <gmaxwell> kinda, I mean, over time there will be collissions. and so you can only checkpoint the earliest value of a specific id.
162 2013-08-25 03:36:48 <gmaxwell> thats one reason that ideally the checkpoint would include a height.
163 2013-08-25 03:36:56 <gmaxwell> then it would be 4 billion times harder.
164 2013-08-25 03:37:01 <petertodd> I think it's worth limiting how far back in time you can go with this - maybe the past 2016 blocks or something?
165 2013-08-25 03:37:32 <gmaxwell> no. :( I wish, doesn't work right.
166 2013-08-25 03:37:42 <petertodd> Because people re-org the whole chain?
167 2013-08-25 03:37:47 <gmaxwell> I produce one CPed 2016 back. Great.. reorg. Ooops.
168 2013-08-25 03:38:01 <gmaxwell> e.g. my txn slips a block forward and then its hosed.
169 2013-08-25 03:38:14 <gmaxwell> becomes a kind of inverted nlocktime.
170 2013-08-25 03:38:53 <petertodd> Ok, so include an absolute height variable % 2016, and then the rest of the bits are for matching.
171 2013-08-25 03:38:54 <gmaxwell> (because my checkpoint value is now 2017 blocks back and not found in the current chain)
172 2013-08-25 03:39:55 <gmaxwell> interesting notion. %2048. (because then its implementation is &2047 and it packs into 11 bits exactly)
173 2013-08-25 03:40:00 <petertodd> Er, sorry, not mod 2016, // 2016
174 2013-08-25 03:40:23 <petertodd> Yeah, 2048 is fine too.
175 2013-08-25 03:41:02 <gmaxwell> (oh // .. then >>11 .. but that isn't finite in size.)
176 2013-08-25 03:41:03 <petertodd> Numbers are pretty good on this stuff too: 100years/10minutes / 2048=2566
177 2013-08-25 03:44:04 <petertodd> Could also just do absolute height to keep it simple - 2^24 * 10 minutes is 319 years, and even that would be 256 times harder.
178 2013-08-25 03:47:22 <gmaxwell> or height&65535, 16 bits, and just avoid picking any collided blocks once you care about them.. it'll be eons before one exists.
179 2013-08-25 03:47:59 <petertodd> Yeah that works.
180 2013-08-25 03:48:23 <petertodd> 65535 times harder for my one txin is pretty damn good.
181 2013-08-25 03:48:42 <gmaxwell> well, all txin that depend on that particular block.
182 2013-08-25 03:49:09 <gmaxwell> thats one reason I might want more than 256... just because you could have thousands of txins there and it might actually make sense.
183 2013-08-25 03:49:12 <petertodd> I'm thinking that if everyone is using this you don't have to satisfy just the one txin, but a whole whack of them.
184 2013-08-25 03:49:42 <petertodd> If people don't pick precisely the same values the thing works even better.
185 2013-08-25 03:51:01 <petertodd> Though heck, might as well just do it with nLockTime setting which block the nSequences are trying to match.
186 2013-08-25 03:51:30 <petertodd> scriptSigs all sign nLockTime
187 2013-08-25 03:51:53 <petertodd> And that transitions nicely from my "set nLockTime on every tx" scheme.
188 2013-08-25 03:53:58 <gmaxwell> hm. how do you not break real nlocktime transactions there?
189 2013-08-25 03:54:25 <gmaxwell> the use is kinda conflicting, as for your scheme you want nlock to be in the future.
190 2013-08-25 03:54:28 <petertodd> gmaxwell: nSequence == 0xffffffff and nSequence == 0x0 just get treated as "no match"
191 2013-08-25 03:54:57 <gmaxwell> for my scheme it would have to be in the past. perhaps a fair bit (e.g. hours) in the past.
192 2013-08-25 03:55:24 <petertodd> gmaxwell: ok, hmm... ok, take 8-bits out as an offset?
193 2013-08-25 03:55:31 <gmaxwell> I was just typing the same thing.
194 2013-08-25 03:55:41 <petertodd> say-the-same-thing
195 2013-08-25 03:55:52 <gmaxwell> "oh how about nlocktime and signal a darn offset?"
196 2013-08-25 03:55:58 <petertodd> lol
197 2013-08-25 03:56:53 <gmaxwell> so nlocktime would have the absolute height, and then you'd have an offset, and a checkpoint in the sequence. interesting though.
198 2013-08-25 03:57:23 <petertodd> one thing I like about the nLockTime version, is it's reasonable to also put a limit on how far back you're going to force people to go to prove the tx was invalid or valid
199 2013-08-25 03:57:54 <gmaxwell> yes, its true, limits how much checking they have to do.
200 2013-08-25 03:58:13 <petertodd> say, if not nHeight - 2016 < nLockTime < nHeight + 2016 the rule is ignored
201 2013-08-25 03:58:24 <petertodd> or, really, should just be invalid
202 2013-08-25 03:58:30 <petertodd> ignored has issues...
203 2013-08-25 03:58:58 <petertodd> 4032*80 isn't much data...
204 2013-08-25 03:59:05 <gmaxwell> I'm not following you there.
205 2013-08-25 03:59:51 <petertodd> If a tx uses this feature it's only valid if the nLockTime chosen is reasonably close to the nHeight of the block it was mined in basically.
206 2013-08-25 04:00:36 <gmaxwell> meh, don't like txn becoming invalid.
207 2013-08-25 04:01:00 <gmaxwell> or at least thats a big change which should be considered on its own, not something you want as a side effect.
208 2013-08-25 04:01:18 <petertodd> hmm... well is it safe to assume everyone has a full set of block headers? I guess so
209 2013-08-25 04:01:34 <gmaxwell> you could be spv secure relative to this rule if you didn't in any case.
210 2013-08-25 04:01:44 <petertodd> true
211 2013-08-25 04:01:51 <petertodd> that's enough then
212 2013-08-25 04:02:23 <gmaxwell> I don't think this kind of rule really needs full security in any case. it could even be imposed as a discouragement rule expect that would be more complex to implement for no need.
213 2013-08-25 04:02:39 <petertodd> True, discouragement is ok.
214 2013-08-25 04:02:43 <gmaxwell> (well a stronger than usual discouragement rule)
215 2013-08-25 04:03:02 <gmaxwell> (since you do want to make sure some SOB that does a 6 block reorg doesn't get paid)
216 2013-08-25 04:03:06 <petertodd> A soft-fork rule change goes through a period of discouragement anyway.
217 2013-08-25 04:03:43 <gmaxwell> I'm just saying that if not all nodes enforce the rule, so long as its a small minority of mining nodes (or preferably not mining nodes at all) it's safe.
218 2013-08-25 04:04:02 <petertodd> Yeah
219 2013-08-25 04:04:04 <gmaxwell> and it's cheap to have all the headers and I think we'd like to require that regardless.
220 2013-08-25 04:04:39 <petertodd> Yeah, and a better long-term thing for those concerns is a merkle-mountain-range soft-fork for linking headers.
221 2013-08-25 04:04:59 <gmaxwell> so I did think of one downside of no fees vs disallow.
222 2013-08-25 04:05:12 <petertodd> ?
223 2013-08-25 04:06:05 <gmaxwell> If it is outright disallowed you can do proof compression. Say I want to prove two txn are in the chain to you. One at block 1000 one at 1020. The one at 2000 has a checkpoint at 1002.
224 2013-08-25 04:06:42 <gmaxwell> I prove 2000 is in the chain with some extra headers beyond it. and then if its checkpoint was a disallow type, then I only need two extra headers to prove 1000 is in the chain.
225 2013-08-25 04:06:55 <gmaxwell> but that seems like a really fringe optimization to me.
226 2013-08-25 04:07:03 <petertodd> Ha, clever though.
227 2013-08-25 04:07:53 <gmaxwell> well, it follows naturally from my CoinCovenants thread where I noted that getting the chain under SCIP requires some additional opcode or something to checkpoint the chain inside a txn.
228 2013-08-25 04:08:05 <petertodd> Ah, true
229 2013-08-25 04:08:30 <gmaxwell> though for that I think you might really perfer the full darn hash and not a little 24 bit jobbie.
230 2013-08-25 04:08:40 <petertodd> Hmm... I guess to implement this, what'd probably make sense is to bump the tx version number and apply the new rules to those tx's.
231 2013-08-25 04:09:01 <petertodd> gmaxwell: If it's nLockTime, make the first txin be the first 32 bits, the second txin be...
232 2013-08-25 04:09:27 <petertodd> gmaxwell: Doesn't play nice with SIGHASH stuff though.
233 2013-08-25 04:09:36 <gmaxwell> I was about to say, don't do that, each one should stand alone.
234 2013-08-25 04:10:18 <gmaxwell> esp because in a joint signature you might actually want to have different parties expressing different preferences. though you could nicely array them out over a span of blocks.
235 2013-08-25 04:10:39 <petertodd> gmaxwell: Heh, actually, make it so it's a match if *any* 32-bit part matches... Handles 0 nicely.
236 2013-08-25 04:11:00 <gmaxwell> nah, more complicated to implement.. and weird bugs.
237 2013-08-25 04:11:21 <gmaxwell> though hah on 0.
238 2013-08-25 04:11:33 <petertodd> Sadly that wouldn't work on Litecoin and other alts.
239 2013-08-25 04:11:51 <gmaxwell> I'd also suggest that it be setup so we steal a bit as don't care. e.g. if the first bit is a 1 this isn't a checkpoint.
240 2013-08-25 04:12:08 <petertodd> Sure, 2 billion is still fine. :P
241 2013-08-25 04:12:25 <gmaxwell> petertodd: hm? I thought we were going to code an offset in there too?
242 2013-08-25 04:12:58 <petertodd> gmaxwell: Oh right... 8 million
243 2013-08-25 06:11:19 <runeks> Why would Bitcoin say my -blocknotify script fails to run? When I execute it myself it works fine.
244 2013-08-25 06:12:00 <gmaxwell> runeks: not giving it the right path?
245 2013-08-25 06:12:22 <runeks> gmaxwell: I'm using an absolute path. And it worked for a while but stopped working suddenly.
246 2013-08-25 06:14:26 <runeks> I mean, bitcoind has been running for several days, executing the command in question without problems. And now it reports an error when executing the same command (which executes without errors when I do it manually and return 0).
247 2013-08-25 06:14:45 <runeks> But it looks like the return value of -1 has nothing to do with my command, but rather system()'s ability to execute my command.
248 2013-08-25 06:15:10 <runeks> Ouch. 37M free memory... that might have an effect :)
249 2013-08-25 06:17:38 <runeks> Damn my RPi and its minuscule 512 MB RAM.
250 2013-08-25 06:45:21 <runeks> That was the issue. It's running now consuming 42% of the available RAM. Before it was consuming 78.5%. Is this normal though? Consuming an additional 182.5MB of RAM after running for a couple of days?
251 2013-08-25 06:55:02 <runeks> What would be a good way of accessing the data of the best chain from the disk in Python? I'm considering opening the txdb, which I assume contains this information, but I was wondering if there's an easier method. bitcointools no longer works for this as far as I can see, it uses the Berkeley DB and "blkindex.dat".
252 2013-08-25 07:29:52 <runeks> I think I'll just build bitcoind from HEAD. I can pull full blocks via RPC that way. Reading bitcoind's database seems like a mess.
253 2013-08-25 08:59:12 <shripadk> Hey guys! :) What is your take on persistent notifications? What I mean is that transaction/block notifications are pushed to a list in a persistent store (like redis) and any client can consume notifications from that list (by performing a blocking pop). I've written an extremely simple implementation of this here: https://github.com/shripadk/bitcoin/compare/feature;persistent-notifications . Would a feature like this be accepted into the core?
254 2013-08-25 09:00:29 <SomeoneWeird> hey - that's neat
255 2013-08-25 09:00:34 <kinlo> shripadk: what's your intention, to store notifications -- basically blobs -- into the blockchain?
256 2013-08-25 09:01:02 <shripadk> kinlo: no. to push those notifications into a db store outside of the chain
257 2013-08-25 09:01:08 <kinlo> oh, no other way around - new blocks/transactions inside redis
258 2013-08-25 09:01:40 <kinlo> sounds like a good idea. Perhaps make the protocol redis-independant so other backends can be populated too....
259 2013-08-25 09:03:28 <shripadk> A client that consumes these notifications: https://gist.github.com/shripadk/6333258
260 2013-08-25 09:04:25 <shripadk> The idea is to ensure that even if the client disconnects/crashes due to some unknown reason, the notifications are not lost
261 2013-08-25 09:06:03 <shripadk> kinlo: how do i make it redis independent? know of any other store that has a LIST like data structure?
262 2013-08-25 09:07:41 <kinlo> shripadk: dunno, afaik there is no way to see when a new transaction is seen on the network, so any system that just notifies "there is a new transaction and its contents is xxxx" looks a win for everybody
263 2013-08-25 09:09:26 <shripadk> kinlo: well i presume there are some implementations that notify you whenever a transaction is seen on the network (i guess payment processors like bitpay/bips/coinbase don't poll) but i wanted a persistent one so that if my application dies i don't need to worry about lost notifications
264 2013-08-25 09:09:38 <runeks> shripadk: Isn't this a bit like the 0mq patch? https://github.com/bitcoin/bitcoin/pull/2415
265 2013-08-25 09:09:57 <runeks> Or at least, if this 0mq patch was included, you could write an external client that pushes it to any database you want.
266 2013-08-25 09:10:10 <shripadk> runeks: yes its inspired by the zmq patch.
267 2013-08-25 09:10:56 <runeks> shripadk: Cool. My impression is just that the 0mq patch is more versatile, and you can actually get what you want if the 0mq patch is pulled and your database-creation script pulls from the 0mq socket.
268 2013-08-25 09:11:38 <shripadk> runeks: true. if 0mq patch goes into the core then there is no need for this. however that would mean an extra service for persistence.
269 2013-08-25 09:12:24 <shripadk> runeks: absolutely. in fact i probably will push my modifications to the 0mq patch too. that one is almost 5 months old and a lot of changes have happened to the core since then.
270 2013-08-25 09:14:04 <runeks> shripadk: Yes it would mean an extra service for persistence. My take on it though is that it's a bit odd to include something as specific as a Redis notifier in core bitcoin. I think it makes sense to aim for something more general purpose, and people can use that to build whatever kind of database out the notifications that they want.
271 2013-08-25 09:15:39 <shripadk> runeks: agree. however i don't think there is any other DB that works the way Redis does. You can't classify it as a DB either ways! You can label it a data structure server if you would like to :)
272 2013-08-25 09:17:16 <shripadk> at least AFAIK there is no DB that provides for a LIST data structure with LPUSH+BRPOP combo. This simplifies things greatly. Just my two satoshis :)
273 2013-08-25 09:22:09 <sipa> jgarzik: my current headersfirst branch is based on the blacklisting and lockpushdown pathces, but the blacklisting one is almost rewritten entirrly i think
274 2013-08-25 09:22:51 <sipa> jgarzik: so feel free to mertge if you think it works (i think it does), but knowing that that logic will change again
275 2013-08-25 10:00:42 <Goonie> BlueMatt: ping
276 2013-08-25 11:13:30 <goodbtc> annoying thing on bitcoin-qt: I have the port open on my router and correctly forwarded to my desktop where I run bitcoin-qt that is connected to 25+ nodes
277 2013-08-25 11:14:35 <goodbtc> when my internet connection fail, I receive a new IP on the router, but then no more than 8 nodes are connected anymore, until I stop and start again the program
278 2013-08-25 11:16:07 <goodbtc> why isn't bitcoin-qt checking from time to time to see if he can accept connections from outside (or something like this)
279 2013-08-25 11:16:10 <gmaxwell> goodbtc: you sure? it won't rebroadcast its address again for 24 hours (unless you restart it), even if we have no issues relating to discovering the change.
280 2013-08-25 11:16:48 <goodbtc> so you say he does that after 24h?
281 2013-08-25 11:17:20 <goodbtc> maybe I should wait more then :)
282 2013-08-25 11:18:03 <gmaxwell> goodbtc: yea, it may not work still??? I have no clue if the upnp code will discover your new address... but if it does it'll likely take 24 hours to readvertise it.
283 2013-08-25 12:01:55 <jgarzik> sipa, just trying to clear out pull reqs
284 2013-08-25 12:02:16 <jgarzik> sipa, I don't need the feature. Trying to dispose of it by merge or closing.
285 2013-08-25 12:13:59 <runeks> With regards to multisig transactions. https://en.bitcoin.it/wiki/BIP_0011#Specification says that "OP_CHECKMULTISIG transactions are redeemed using a standard scriptSig" but as far as I can see it's not a standard scriptSig because it doesn't include the public keys. Am I wrong?
286 2013-08-25 12:14:47 <Luke-Jr> runeks: if it didn't inlcude the pubkeys, it wouldn't work!
287 2013-08-25 12:15:27 <runeks> Luke-Jr: It would it you fetch the pubkeys from the output.
288 2013-08-25 12:15:38 <runeks> s/it/if
289 2013-08-25 12:16:17 <Luke-Jr> runeks: oh, you mean without P2SH?
290 2013-08-25 12:16:36 <runeks> Luke-Jr: Yeah it's BIP 0011.
291 2013-08-25 12:17:20 <Luke-Jr> runeks: in that case, why would it need the pubkeys to be standard?
292 2013-08-25 12:17:47 <Luke-Jr> a standard scriptSig is simply defined as 1) push-only, 2) no additional pushes than required for scriptPubKey
293 2013-08-25 12:18:30 <runeks> Luke-Jr: Oh. I thought a standard scriptSig was the kind that redeems a Pay-by-Bitcoin-address TxOut
294 2013-08-25 12:18:39 <runeks> Then it makes sense.
295 2013-08-25 12:18:53 <Luke-Jr> runeks: there is no "pay-by-bitcoin-address" txout
296 2013-08-25 12:19:02 <runeks> I'm just trying to get bitcointools' extract_public_key() function to work to multisig scriptSigs
297 2013-08-25 12:19:26 <runeks> Luke-Jr: Pay-*to*-Bitcoin-address out then?
298 2013-08-25 12:19:52 <Luke-Jr> Bitcoin addresses can be converted to either pay-to-scripthash or pay-to-pubkeyhash scripts
299 2013-08-25 12:20:48 <jgarzik> runeks, bitcointools is python, right? I think petertodd just added P2SH/multisig support to python-bitcoinlib, which should do what you want.
300 2013-08-25 12:21:37 <runeks> jgarzik: Yes it is. I will check python-bitcoinlib out. bitcointools does seem like it's aging, and it hasn't been taken care of.
301 2013-08-25 12:21:58 <runeks> Luke-Jr: Uh, I'm just talking about the "OP_DUP OP_HASH160 <hash160> OP_EQUALVERIFY OP_CHECKSIG" type txOuts
302 2013-08-25 12:22:48 <Luke-Jr> pay-to-pubkeyhash then
303 2013-08-25 12:23:10 <jgarzik> runeks, indeed. bitcointools was written in the early days of bitcoin, as one of Gavin's first projects.
304 2013-08-25 12:23:33 <jgarzik> That txout isn't even multsig ;p
305 2013-08-25 12:25:45 <runeks> jgarzik: We went off a tangent. Look further up. It was my misunderstanding of what a "standard" scriptSig is that caused the confusion.
306 2013-08-25 12:26:14 <runeks> jgarzik: Does python-bitcoinlib let me extract destination addresses out of scriptPubKeys and scriptSigs?
307 2013-08-25 12:26:26 <runeks> That's what I'm using bitcointools for currently.
308 2013-08-25 12:27:56 <runeks> extract_public_key() analyzes the script and extracts the address from it: https://github.com/gavinandresen/bitcointools/blob/master/deserialize.py#L291
309 2013-08-25 14:35:17 <starsoccer> is there a way from the bitcoin client console to remove an address?
310 2013-08-25 14:35:32 <starsoccer> or lock in any funds in that address so they cant be spent
311 2013-08-25 14:42:51 <sipa> starsoccer: lockunspent
312 2013-08-25 16:33:18 <gribble> The operation succeeded.
313 2013-08-25 16:33:18 <michagogo> ;;later tell jgarzik Any ETA on the Bootstrap update for the new checkpoint?
314 2013-08-25 17:15:35 <Krellan> Question: When revising a commit that's in a pull request, what's best: add a new commit, squash new commit into existing commit, or close pull request and resubmit?
315 2013-08-25 17:15:52 <sipa> Krellan: no need to close and resubmit
316 2013-08-25 17:16:06 <sipa> adding a commit makes sense if it's intended to be a separate commit
317 2013-08-25 17:16:10 <sipa> otherwise, squash
318 2013-08-25 17:16:29 <Luke-Jr> Krellan: separate commits for separate logical changes; whatever it takes to get that :P
319 2013-08-25 17:16:58 <sipa> in particular, commits are intended to be standalone changes, for which unit tests work
320 2013-08-25 17:17:01 <Krellan> Thanks. Was thinking about https://github.com/bitcoin/bitcoin/pull/2929 = you're right, no need to construct new CAddress, can just use existing CService.
321 2013-08-25 17:17:13 <sipa> Krellan: definitely just revise the existing commit
322 2013-08-25 17:17:22 <Krellan> Will do since so trivial change.
323 2013-08-25 17:17:45 <sipa> thanks!
324 2013-08-25 17:18:07 <Krellan> I can see somebody using squash to slip something in, though: you submit something good, everybody says ACK, you squash another commit to it and add something sneakily bad.
325 2013-08-25 17:18:51 <sipa> indeed, there's a risk
326 2013-08-25 17:19:03 <sipa> but it's ultimately the responsability of the merger to check for things like that
327 2013-08-25 17:19:16 <Luke-Jr> sipa: not sure it's even possible to check with Github merging
328 2013-08-25 17:19:21 <Luke-Jr> there's always a race
329 2013-08-25 17:19:45 <Luke-Jr> Krellan: that's basically happened (no foul intention I think though) with the LevelDB merge
330 2013-08-25 17:20:00 <Krellan> wow, you're right about that: somebody could perform a squash and push -f that squash, right as the moment the upstream maintainer clicks "accept" on the pull req!
331 2013-08-25 17:20:02 <sipa> if you're making non-trivial changes after getting an ACK, it's friendly to make a comment about it on the pullreq page
332 2013-08-25 17:20:45 <Luke-Jr> GitHub does reorder the events
333 2013-08-25 17:21:16 <Luke-Jr> if you push -f, it will list the commits after the ACKs
334 2013-08-25 17:21:27 <Krellan> that's good to know
335 2013-08-25 17:21:43 <sipa> and it's of course also possible to verify after merging
336 2013-08-25 17:21:48 <jouke> So, may 15th fork finaly happened? :)
337 2013-08-25 17:22:12 <Luke-Jr> yep
338 2013-08-25 17:22:16 <Luke-Jr> a few days ago
339 2013-08-25 17:22:29 <petertodd> Luke-Jr: Ever figure out why that block that forked it was so small?
340 2013-08-25 17:22:37 <Luke-Jr> nope :/
341 2013-08-25 17:22:40 <jouke> hadn't noticed until now :)
342 2013-08-25 17:22:44 <Luke-Jr> I can only conclude the diagnosis was wrong :|
343 2013-08-25 17:22:49 <petertodd> eek
344 2013-08-25 17:22:53 <jouke> pierre`: 800+ kilobyte?
345 2013-08-25 17:23:00 <Luke-Jr> jouke: no, it was like 172 kB IIRC
346 2013-08-25 17:23:22 <jouke> afaik it is this block: 0000000000000024b58eeb1134432f00497a6a860412996e7a260f47126eed07
347 2013-08-25 17:24:29 <Luke-Jr> [Thursday, August 22, 2013] [12:48:33 AM] <Luke-Jr> 253451 http://blockchain.info/block/0000000000000028d6ae33b846dbbe9a3f6cd82819844a29630366e5cc984c43
348 2013-08-25 17:25:08 <jouke> huh.
349 2013-08-25 17:25:10 <Luke-Jr> hmm
350 2013-08-25 17:25:40 <jouke> 252451
351 2013-08-25 17:25:56 <jouke> I have two nodes that are stuck on 252450
352 2013-08-25 17:26:20 <sipa> so, 252451 caused the fork :)
353 2013-08-25 17:27:01 <Luke-Jr> ACTION facepalms
354 2013-08-25 17:27:05 <Luke-Jr> I got the number wrong
355 2013-08-25 17:27:10 <Luke-Jr> now it all makes sense XDF
356 2013-08-25 17:27:12 <Luke-Jr> XD*
357 2013-08-25 17:27:15 <jgarzik> whee
358 2013-08-25 17:27:15 <jouke> yes, so block 0000000000000024b58eeb1134432f00497a6a860412996e7a260f47126eed07 which is 805 KB and had 1486 transactions
359 2013-08-25 17:27:28 <sipa> oh :)
360 2013-08-25 17:27:34 <sipa> i didn't check the link
361 2013-08-25 17:27:39 <sipa> jgarzik: ?
362 2013-08-25 17:27:56 <jgarzik> sipa, so we finally hard-forked away 0.7?
363 2013-08-25 17:27:59 <sipa> yes
364 2013-08-25 17:28:11 <petertodd> Luke-Jr: good!
365 2013-08-25 17:28:26 <jouke> No worry Luke-Jr. We are not mad. Just a little disappointed.
366 2013-08-25 17:28:31 <sipa> ?
367 2013-08-25 17:28:34 <petertodd> Luke-Jr: ha, eligius earned $58 for forking Bitcoin.:P
368 2013-08-25 17:28:39 <Luke-Jr> jgarzik: and confirmed stable backports work :p
369 2013-08-25 17:28:57 <Luke-Jr> petertodd: investigating new spammer to block already :P
370 2013-08-25 17:29:12 <petertodd> Luke-Jr: ha, what now?
371 2013-08-25 17:29:12 <sipa> jouke: disappointed because?
372 2013-08-25 17:29:18 <Luke-Jr> "BetCoin Dice" apparently
373 2013-08-25 17:29:25 <petertodd> Luke-Jr: lovely...
374 2013-08-25 17:29:28 <Luke-Jr> sipa: because I should have thought to double check tht
375 2013-08-25 17:29:41 <jouke> ^
376 2013-08-25 17:29:46 <jouke> but I was just joking :P
377 2013-08-25 17:30:11 <jouke> anyway. Ok. Time to shut down some nodes.
378 2013-08-25 17:31:02 <jouke> I still have some .7-nodes connected as it seems.
379 2013-08-25 17:32:11 <Krellan> sipa: Nice, I found it still works when reusing the existing CService, so this trivial patch gets even shorter. And, I found that squashing in a change causes the commit hash to change, so that's a good way to defend against a sneaky squash.
380 2013-08-25 17:33:00 <sipa> Krellan: sure, git commits are cryptographic hashes
381 2013-08-25 17:33:24 <Luke-Jr> jouke: or upgrade them ;p
382 2013-08-25 17:33:25 <jcorgan> git branchs are hashchains of commits
383 2013-08-25 17:33:42 <jouke> Luke-Jr: better idea indeed :)
384 2013-08-25 17:33:45 <sipa> a branch is just a pointer to a commit
385 2013-08-25 17:33:56 <sipa> it's the commits themselves that commit to the chain of changes
386 2013-08-25 17:34:15 <sipa> a branch doesn't have a hash
387 2013-08-25 17:34:37 <sipa> (or at least not a stable one)
388 2013-08-25 17:36:06 <lianj> a chain or commits (eg prev_block) and the tree root (eg merkle_root) :P
389 2013-08-25 17:36:13 <lianj> s/or/of
390 2013-08-25 17:36:32 <Krellan> and an especially good commit is one that starts with 0000000.... :)
391 2013-08-25 17:36:48 <sipa> unfortunately, git uses sha1, not double-sha256 :)
392 2013-08-25 17:38:06 <sipa> Krellan: coding nit: no need for () around stats.addrLocal.empty()
393 2013-08-25 17:38:27 <petertodd> heh, it'd be fun to write a git commit hook that makes all your commits start with 0000000...
394 2013-08-25 17:38:53 <Krellan> PoW commits = slow down people and make them think before committing silly things
395 2013-08-25 17:38:59 <sipa> Krellan: . binds tighter than !
396 2013-08-25 17:39:21 <Luke-Jr> petertodd: or the current date ;)
397 2013-08-25 17:39:31 <Luke-Jr> (in tonal of course)
398 2013-08-25 17:39:53 <petertodd> Luke-Jr: lol
399 2013-08-25 17:40:06 <petertodd> Luke-Jr: Oh, I know: make the commits be incrementing numbers, svn style!
400 2013-08-25 17:40:13 <Luke-Jr> <.<
401 2013-08-25 17:41:04 <Krellan> sipa: thanks, I've historically been paranoid about precedence order, don't mind using more parens than strictly necessary
402 2013-08-25 17:41:14 <jgarzik> svn? sigh
403 2013-08-25 17:41:24 <jgarzik> "we'll do cvs better!" what a mess.
404 2013-08-25 17:41:37 <Luke-Jr> jgarzik: otoh, it still has features git lacks :/
405 2013-08-25 17:41:51 <jgarzik> yes, like easy corruption
406 2013-08-25 17:41:56 <Luke-Jr> git corrupts easy
407 2013-08-25 17:42:04 <Luke-Jr> I was thinking more like real cherry-picking
408 2013-08-25 17:42:05 <jgarzik> or hacker-friendly lack of crypto hashed data
409 2013-08-25 17:42:13 <sipa> i've never seen either SVN or git corrupt :)
410 2013-08-25 17:42:25 <sipa> but i've heard SVN corruption was commonly caused by their BDB backend :p
411 2013-08-25 17:42:28 <Luke-Jr> sipa: you obviously don't have 4.5 GB packed git repos ;)
412 2013-08-25 17:42:32 <jgarzik> sipa, yep
413 2013-08-25 17:42:35 <Krellan> I'm rather liking the cherry pick feature of git. Haven't used a lot of git before, but use svn at my day job.
414 2013-08-25 17:42:42 <Luke-Jr> oh, svn also has append-only storage
415 2013-08-25 17:42:43 <jcorgan> svn is for organizations married to the idea that there must be one true "official" revision
416 2013-08-25 17:42:43 <Luke-Jr> one thing I liked
417 2013-08-25 17:42:58 <Luke-Jr> Krellan: git's cherry-pick is just a hack; svn has real cherry-picking
418 2013-08-25 17:42:59 <jgarzik> in the Linux kernel community, the kernel repo itself exercises git so well, it has been used as a detector for hard drive failure
419 2013-08-25 17:43:02 <jcorgan> instead of a community consensus
420 2013-08-25 17:43:05 <jgarzik> git corrupted -> check hardware
421 2013-08-25 17:43:10 <sipa> Luke-Jr: what do you mean by real cherry picking?
422 2013-08-25 17:43:23 <Luke-Jr> jgarzik: I think my corruption is just kernel hanging
423 2013-08-25 17:43:36 <Luke-Jr> sipa: svn merge is aware the commit was cherry-picked, and skips over it
424 2013-08-25 17:43:43 <Krellan> I split up some work I did into two separate branches, after they had been comingled, and was able to do so without loss of data or duplicating work.
425 2013-08-25 17:43:48 <Luke-Jr> sipa: git doesn't know it's related at all
426 2013-08-25 17:43:53 <sipa> right
427 2013-08-25 17:44:17 <sipa> indeed, it's just generating a patch a cherry-pick time and applying it to another branch
428 2013-08-25 17:44:23 <sipa> *at
429 2013-08-25 17:45:03 <jgarzik> ACTION finally started his C++ pool server. json-rpc server over http for control. json-rpc client upstream to bitcoind for work. json-rpc over tcp for stratum.
430 2013-08-25 17:46:28 <Luke-Jr> jgarzik: I thought you were going to do ZeroMQ upstream?
431 2013-08-25 17:46:47 <petertodd> jgarzik: what do you want a pool server for?
432 2013-08-25 17:47:04 <jgarzik> Luke-Jr, v0 needs to work out of the box on current software. v1 can have bells and whistles based on user feedback in the field.
433 2013-08-25 17:47:05 <sipa> don't pool servers already exist?
434 2013-08-25 17:47:25 <jgarzik> petertodd, I wrote pushpool, the original pool server. Now it's old and creaky, but amazingly still has users.
435 2013-08-25 17:47:33 <Luke-Jr> sipa: just Eloipool at this point - although it does work fine
436 2013-08-25 17:47:48 <jgarzik> pool server universe could use some competition
437 2013-08-25 17:47:49 <Luke-Jr> jgarzik: I think just scamcoin users who can't use SHA256d-based code
438 2013-08-25 17:48:14 <Luke-Jr> jgarzik: heh, most likely you'll just kill Eloipool ;)
439 2013-08-25 17:48:21 <Luke-Jr> everyone seems to prefer C++ over Python, including myself
440 2013-08-25 17:48:34 <sipa> to each their own
441 2013-08-25 17:48:45 <petertodd> jgarzik: ah
442 2013-08-25 17:49:04 <jgarzik> I hate to admit it , but C++ is starting to come out on top, with RAII. It's a bit easier to write secure + fast code in C++. You just have to ignore or turn off a bunch of C++ crap.
443 2013-08-25 17:50:19 <petertodd> OTOH C++ is still painful as fuck: why does it have to be so hard to do simple things like print an object to look at it in the debugger without getting a bunch of low-level internals crap?
444 2013-08-25 17:50:24 <jgarzik> boost is a bunch of annoyingly verbose crap. in python or JS, you can be a lot more terse, distilling the code down to its essence. With boost, it takes 4x80 chars of ::bind this and ::static_cast_my_ass that to accomplish anything, especially in boost.asio.
445 2013-08-25 17:50:41 <jgarzik> it needs to be shot in the head, not adopted by C++x11 or whatever it is called
446 2013-08-25 17:51:00 <Luke-Jr> jgarzik: meh, refcounted pointers work nicely
447 2013-08-25 17:51:05 <Luke-Jr> even if other parts are crazy
448 2013-08-25 17:51:13 <jgarzik> boost.asio is particularly bad
449 2013-08-25 17:51:44 <sipa> c++11 seems quite careful about which features they adopt
450 2013-08-25 17:51:48 <jgarzik> See this project, just to do a skeleton JSON-RPC in boost.asio: https://github.com/jgarzik/rpcsrv
451 2013-08-25 17:51:52 <sipa> and boost has some commonly-accepted good ideas
452 2013-08-25 17:51:58 <sipa> doesn't mean all of it is :)
453 2013-08-25 17:53:32 <petertodd> sigh, all I really want is a language like C++ but with python syntax, and especially list/tuple/repr etc. and garbage collection - is that too much to ask?
454 2013-08-25 17:53:58 <jcorgan> boost headers do so much preprocessor-time crunching that one day the act of including a boost header will make the compiler gain sentience and the singularity will begin
455 2013-08-25 17:57:11 <michagogo> [22:38:27] <petertodd> heh, it'd be fun to write a git commit hook that makes all your commits start with 0000000...
456 2013-08-25 17:57:11 <michagogo> That's a thing: https://github.com/vog/beautify_git_hash is one implementation.
457 2013-08-25 18:00:07 <runeks> petertodd: So what's left of C++ if it has Python syntax and garbage collection?
458 2013-08-25 18:00:20 <petertodd> runeks: What do you mean "what's left"?
459 2013-08-25 18:00:39 <jgarzik> petertodd, (RE all I want) +1000
460 2013-08-25 18:01:15 <petertodd> jgarzik: I'll even let you have your tabs :P
461 2013-08-25 18:01:26 <runeks> petertodd: I mean what features of C++ would you like that Python doesn't have?
462 2013-08-25 18:01:30 <jgarzik> regex/list/dictionary is my list, with the ability to declare complex objects a la python/JS
463 2013-08-25 18:01:46 <jgarzik> using {} and [] notation
464 2013-08-25 18:02:10 <Luke-Jr> C++11 can do that for vectors I think
465 2013-08-25 18:02:14 <Luke-Jr> not sure about maps
466 2013-08-25 18:02:28 <Luke-Jr> too bad they didn't add operator=~
467 2013-08-25 18:03:50 <petertodd> runeks: Oh, I want my language to be possible to compile, and I want it to have strong typing. (preferably with the fancy type inferrence stuff)
468 2013-08-25 18:04:10 <jgarzik> Anyway, my point is that? I don't really like C++, but am reluctantly concluding that it is the best language to implement Serious Secure Software ;p
469 2013-08-25 18:04:17 <petertodd> runeks: FWIW Cython is actually pretty close to what I want, although it's object model forces pointers often where you don't want to have pointers.
470 2013-08-25 18:04:31 <petertodd> jgarzik: yup, that's pragmatism
471 2013-08-25 18:04:49 <jcorgan> runeks: multithreading without the PIL
472 2013-08-25 18:04:55 <jgarzik> RAII and such (which of course JS/python have) are superior to C, but python and JS are both slow, single process and have many warts of their own
473 2013-08-25 18:04:55 <petertodd> jgarzik: I mean, Cython would be what I want nearly, but it seems to still have the odd compiler bug which is unacceptable.
474 2013-08-25 18:05:25 <jgarzik> so for python, I want python with static typing and static compiles and no virtual machine limiting my threading
475 2013-08-25 18:05:43 <jgarzik> sandboxes / virtual machines always just get in the way
476 2013-08-25 18:06:46 <runeks> petertodd: Ah, I see. I wonder how much it would take to produce a standalone Python executable.
477 2013-08-25 18:06:59 <jgarzik> JS warts around lack of threading with fancy async-ery, but it is still a gross hack. Any language that cannot fully multi-thread in 2013 is shite. I'm talking to you, python, node.js and perl.
478 2013-08-25 18:07:10 <runeks> jcorgan: Python Imaging Library?
479 2013-08-25 18:07:19 <jcorgan> python interpreter lock
480 2013-08-25 18:07:20 <petertodd> runeks: There's already systems to do that actually, it's just that they consist of a python bytecoin interpreter and some bytecoin embedded...
481 2013-08-25 18:08:09 <runeks> petertodd: Yeah I think that's the only option. But what do you think that solution lacks? I mean, why do you want a standalone executable in the first place?
482 2013-08-25 18:08:30 <petertodd> runeks: I don't care about standalone executables - I care about my code being fast an compiled.
483 2013-08-25 18:09:05 <petertodd> runeks: For instance IIRC Cython *can't* actually produce a standalone executable, but it can create a compiled library from your cython code which gets called by python code - plenty good enough.
484 2013-08-25 18:09:30 <petertodd> runeks: Or look at some Lisp implementations which did compilation on the fly... and can be blazingly fast.
485 2013-08-25 18:10:57 <runeks> petertodd: I see. I guess I don't know enough about the virtual machine approach vs just producing native binary code to know how easy that is. Wouldn't garbage collection require some kind of VM though?
486 2013-08-25 18:11:43 <petertodd> runeks: GC has nothing to do with VM's
487 2013-08-25 18:12:30 <runeks> petertodd: So who's there to clean up if there is no VM?
488 2013-08-25 18:12:55 <Luke-Jr> runeks: the standard library
489 2013-08-25 18:13:01 <Diablo-D3> ACTION facepalms
490 2013-08-25 18:13:38 <runeks> Yeah I guess I don't know enough about the internals to figure that out.
491 2013-08-25 18:13:40 <petertodd> Interesting: 98c4cdffdd2aaf1c2280b2d22d4b59839c937f1a3dc9daf6fd7db077de90592d blockchain.info is now showing unconfirmed multisig tx's - they used to block them.
492 2013-08-25 18:13:40 <sipa> runeks: you can even have GC in C by using a Boehm collector
493 2013-08-25 18:15:09 <petertodd> also this one, multisig spend to multisig output: 369db9a12f12eb930912f7b496f884ea6798952be7ef457faadb74655671208d
494 2013-08-25 18:15:33 <petertodd> oh, wait, no that's confirmed...
495 2013-08-25 18:17:04 <runeks> petertodd: I ran across several confirmed multisig tx's when trying to build an address-to-txid database.
496 2013-08-25 18:17:34 <petertodd> runeks: just several?
497 2013-08-25 18:18:26 <runeks> petertodd: Yeah I only noticed several because once I updated bitcointools they didn't throw an error.
498 2013-08-25 18:18:51 <Diablo-D3> [04:13:39] <sipa> runeks: you can even have GC in C by using a Boehm collector
499 2013-08-25 18:18:56 <Diablo-D3> lol boehmgc
500 2013-08-25 18:19:12 <petertodd> runeks: ah, yeah I've made hundreds (thousands?) of them with my timestamper
501 2013-08-25 18:19:35 <runeks> petertodd: timestamper?
502 2013-08-25 18:19:56 <petertodd> runeks: https://github.com/opentimestamps/opentimestamps-server
503 2013-08-25 18:20:02 <petertodd> runeks: down right now though
504 2013-08-25 18:21:37 <Diablo-D3> hey guys, serious question
505 2013-08-25 18:21:39 <Diablo-D3> vim or emacs?
506 2013-08-25 18:21:57 <sipa> EDLIN
507 2013-08-25 18:22:05 <petertodd> vim - it's why RSI hasn't forced me to quit this stuff
508 2013-08-25 18:22:26 <petertodd> that and my typing bitch
509 2013-08-25 18:22:45 <Diablo-D3> Ive been using vim for like 15 years
510 2013-08-25 18:22:53 <Diablo-D3> but Im wondering if I'd actually be happier with emacs
511 2013-08-25 18:23:07 <jgarzik> Diablo-D3, wonder no longer. Answer: no
512 2013-08-25 18:23:14 <jgarzik> Reason: lisp sucks
513 2013-08-25 18:23:21 <Diablo-D3> jgarzik: I actually like lisp
514 2013-08-25 18:23:26 <petertodd> Diablo-D3: I started on emacs, wrists started getting sore, then switched to vim
515 2013-08-25 18:23:42 <sipa> ACTION uses mcedit...
516 2013-08-25 18:23:44 <Diablo-D3> petertodd: well, if your wrists are getting sore, you're doing something radically wrong
517 2013-08-25 18:23:55 <runeks> No love for gedit?
518 2013-08-25 18:23:59 <petertodd> Diablo-D3: yeah, like using emacs...
519 2013-08-25 18:24:19 <sipa> runeks: i use gedit when i need to copy-paste code
520 2013-08-25 18:24:39 <Diablo-D3> I dunno, I heard emacs had a much more flexible screen writing system
521 2013-08-25 18:24:46 <runeks> sipa: And doesn't it do the job wonderfully?
522 2013-08-25 18:24:53 <jgarzik> ACTION misses cooledit, which preserved the glorious wordstar shortcuts from the dos days
523 2013-08-25 18:25:03 <Diablo-D3> so doing shit like having an xterm compliant term as an emacs view window thingy can happen
524 2013-08-25 18:25:12 <jgarzik> emacs is a system for writing systems
525 2013-08-25 18:25:20 <jgarzik> it can be a login shell -> not an editor
526 2013-08-25 18:25:22 <petertodd> Diablo-D3: meh, moded interfaces are the way to go - I also use xmonad with stickeykeys
527 2013-08-25 18:25:36 <petertodd> jgarzik: yeah, I just wish emacs had a decent editor
528 2013-08-25 18:25:38 <Diablo-D3> petertodd: well Ive considered a tiling wm
529 2013-08-25 18:25:43 <petertodd> Diablo-D3: do it
530 2013-08-25 18:25:55 <Diablo-D3> but I just fullscreen urxvt and use tmux
531 2013-08-25 18:26:39 <petertodd> Diablo-D3: ...so you use a tiling WM...
532 2013-08-25 18:26:46 <Diablo-D3> not in X I dont =P
533 2013-08-25 18:27:24 <Diablo-D3> I dunno, I guess I was just looking for something that I could configure more
534 2013-08-25 18:27:47 <petertodd> Diablo-D3: you mean dick around with more rather than doing real work? :/
535 2013-08-25 18:28:04 <petertodd> ACTION isn't exactly leading a good example...
536 2013-08-25 18:28:34 <Diablo-D3> petertodd: well, like, I dunno
537 2013-08-25 18:28:55 <lianj> Diablo-D3: tmux is the best zsh tiling wm ever, stay wit hit
538 2013-08-25 18:29:21 <lianj> no use in using xorg windows that tile if you just need shell windows
539 2013-08-25 18:29:36 <Diablo-D3> maybe I should just try emacs
540 2013-08-25 18:29:42 <Diablo-D3> and then if I dont like it, go back to vim
541 2013-08-25 18:29:48 <lianj> also you can script the hell out tmux
542 2013-08-25 18:30:01 <lianj> haha you will come back :)
543 2013-08-25 18:30:12 <Diablo-D3> lianj: the farthest Ive scripted it is making it do vim window movement keys intelligently
544 2013-08-25 18:30:24 <Diablo-D3> ie, if Im in vim, dont snoop them
545 2013-08-25 18:30:40 <Diablo-D3> unless Im at the edge of a vim window layout in the direction I want to go
546 2013-08-25 18:30:49 <Diablo-D3> and I didnt even code that, its from someone else