1 2015-05-13 00:49:32 <akrmn> Is it possible to store only a subset of transactions that are relevant to you but still be able to validate that all your transactions actually happened, starting from the satoshi block? I think you need the full blocks right?
  2 2015-05-13 00:50:13 <sipa> you do not need to a store any transactions
  3 2015-05-13 00:50:37 <sipa> but you do need to process them all, as you don't know in advance which ones may ultimately matter for the validity of the ones you are receiving
  4 2015-05-13 00:51:18 <akrmn> ok I see what you mean, you just trust that your past validation was good, so you don't worry about storing the old stuff
  5 2015-05-13 00:51:25 <akrmn> I still don't think it's ideal
  6 2015-05-13 00:53:13 <sipa> akrmn: no, you don't understand
  7 2015-05-13 00:53:38 <sipa> akrmn: bitcoin core does not care about old transactions on disk, they're not used for validation at all
  8 2015-05-13 00:53:54 <akrmn> I kind of mentioned something on the dev list about how to scale without increasing the block limit. I think one way it can be done (and still be able to store all your transactions) is keep our original blockchain, then make 10 blockchains (sidechains) with 10 MB block, so each transaction goes randomly into one of them.
  9 2015-05-13 00:54:12 <sipa> that does not help at all
 10 2015-05-13 00:54:35 <sipa> you're introducing a weak security transfer mechanism between chains, in order to get better scalability, but still require everyone to validate all of them
 11 2015-05-13 00:54:50 <akrmn> so you just keep track of only the few chains that have 10 MB blocks (the ones that have your transactions)
 12 2015-05-13 00:55:05 <sipa> (i'm a co-author of the sidechains paper, btw)
 13 2015-05-13 00:55:17 <akrmn> Yes I saw your name on it :)
 14 2015-05-13 00:55:31 <akrmn> The only thing I did was a paper wallet maker
 15 2015-05-13 00:55:38 <sipa> thinking of sidechains as a direct means to improve scalability is a really bad idea
 16 2015-05-13 00:55:43 <akrmn> but I dont know the protocol so much
 17 2015-05-13 00:55:57 <sipa> what they're good for is introducing means for experimentation without needing to introduce a new currency first
 18 2015-05-13 00:56:08 <sipa> new technology, which can offer better scalability, perhaps
 19 2015-05-13 00:56:27 <akrmn> how is it a weak security transfer mechanism?
 20 2015-05-13 00:56:45 <sipa> bitcoin does not fully validate transfers back from the sidechains
 21 2015-05-13 00:56:51 <sipa> and relies on hash power security
 22 2015-05-13 00:57:34 <sipa> 1 MB bitcoin blocks + 10x 10 MB sidechains (especially random ones, wtf?) seems a worse deal in every possible way than just 101 MB bitcoin blocks
 23 2015-05-13 00:58:17 <akrmn> people can mine the sidechains and
 24 2015-05-13 00:58:48 <akrmn> merged mining I guess
 25 2015-05-13 00:58:56 <sipa> yes so? people can mine bitcoin too
 26 2015-05-13 00:59:07 <sipa> but at least within bitcoin everything is fully validatable
 27 2015-05-13 00:59:14 <akrmn> but the sidechains store bitcoin also I thought
 28 2015-05-13 00:59:40 <sipa> sorry, no time to explain this further
 29 2015-05-13 00:59:45 <akrmn> ok no problem
 30 2015-05-13 00:59:50 <akrmn> I will try to write it up
 31 2015-05-13 01:00:13 <sipa> no, please just stop thinking of sidechains as a means to introduce scalability
 32 2015-05-13 01:01:35 <Adlai> akrmn: sidechains are a way to temporarily manipulate portions of the utxo set with alternative consensus rules, and be able to add or remove utxos from the alternative consensus portion without destroying or inflating coins
 33 2015-05-13 01:05:06 <akrmn> Well my general idea is that you have a 1 MB chain validating all the aggregate transactions of the 10 MB chains, which validate the aggregate transactions of the 100 MB chains, etc...
 34 2015-05-13 01:05:28 <akrmn> I feel like it is possible, but I need to dig into the protocol it seems
 35 2015-05-13 01:07:30 <sipa> akrmn: to get the same security, you would need to validate the transactions in those 10 MB chains too
 36 2015-05-13 01:07:41 <sipa> to know the 'aggregates' are correct
 37 2015-05-13 01:08:21 <akrmn> yes the 10 MB chain is independent and does its own validation, you can trust it if you think it is decentralized enough and forget about the 1 MB chain
 38 2015-05-13 01:08:41 <akrmn> though there should be some incentive to keep the 1 MB chain, I think that's the problem
 39 2015-05-13 01:09:04 <akrmn> but if everyone comes to consensus to mine any chain's parent chain, then it can work
 40 2015-05-13 01:09:35 <sipa> not with the same security
 41 2015-05-13 01:13:20 <hulkhogan_> akrmn: try to answer this within the context of your idea, why trust any other chain over the bitcoin chain , when it will always have a lower hashpower than the main chain?
 42 2015-05-13 01:13:58 <hulkhogan_> it'll always have less hashpower, and thats the weaker guarantee
 43 2015-05-13 01:14:27 <akrmn> Yes but the main chain will only have aggregate transactions
 44 2015-05-13 01:14:36 <akrmn> it cannot fit all the coffees people buy
 45 2015-05-13 01:14:48 <akrmn> it will have them all as one big transaction
 46 2015-05-13 01:14:49 <akrmn> it will have them all as one big transaction
 47 2015-05-13 01:15:17 <akrmn> it will have less hashpower but at least it is better than nothing
 48 2015-05-13 01:16:31 <hulkhogan_> better than nothing ? i can submit my coffee tx to the main blockchain and not worry about double spends, or i can use some third party chain with unknown security of my funds, i don't know why i would ever use the third party system
 49 2015-05-13 01:17:03 <akrmn> Yes but you will not submit your coffee if the chain gets too full, the fee will be enormous
 50 2015-05-13 01:17:39 <hulkhogan_> so i accept that my money might be double spent, as a cost to maybe having a lower fee? how do you plan on validating transactions on separate chains, anyway
 51 2015-05-13 01:18:43 <hulkhogan_> i think that you never want to put someone in a situation where they might get double-spent out of their funds
 52 2015-05-13 01:18:57 <akrmn> I don't know the details yet, if someone experienced, likes my idea, then tell me, if not I will have to dig deeper. I have patience. And I definitely want to see bitcoin stay P2P and not just big organizations running full nodes.
 53 2015-05-13 01:20:42 <hulkhogan_> well, i wouldnt do any real transaction validation on those sidechains, because the security of those chains rests on whoever is merge mining it, which will always be lower hashrate than the parent (bitcoin)
 54 2015-05-13 01:23:05 <hulkhogan_> i would look into off-chain processing for the coffee use case, my bitcentz
 55 2015-05-13 01:28:08 <akrmn> by the way I don't mean each transaction goes randomly, I mean, each address (or input) will go into a unique chain. So that you can keep track of the transactions of that address in just one of the 10 MB chains. So you can keep generating addresses until you get one that corresponds to the chain you want to use for your transactions.
 56 2015-05-13 01:29:24 <akrmn> no wait
 57 2015-05-13 01:29:35 <akrmn> you partition the 10 MB chain into 10 1MB chains
 58 2015-05-13 01:29:55 <akrmn> so you just store your 1 MB chain and one of the 10 1 MB chains
 59 2015-05-13 01:30:38 <akrmn> sorry for the confusion, maybe that makes more sense
 60 2015-05-13 01:31:09 <hulkhogan_> you should see if it makes sense to even use a blockchain, since we don't seem to want to think about hashrate security
 61 2015-05-13 01:31:26 <hulkhogan_> off chain transactions would mean you can do any number of transactions
 62 2015-05-13 01:31:42 <hulkhogan_> sharded however you like
 63 2015-05-13 01:33:05 <akrmn> ya and what is off-chain transactions? A company storing stuff in a database?
 64 2015-05-13 01:33:05 <hulkhogan_> so the blockchain is secured by petahashes or more, those sidechains have only a fraction of that
 65 2015-05-13 01:33:18 <hulkhogan_> most of them are probably using off chain transactions to a degree
 66 2015-05-13 01:33:34 <akrmn> If you want instantaneos transactions, there is lightning
 67 2015-05-13 01:33:52 <akrmn> also complementary to the sidechains
 68 2015-05-13 01:34:57 <hulkhogan_> but even if there was a valid use case for sidechains, you wouldnt want to secure real world stuff with it since it offers less of a guarantee of the security of your funds
 69 2015-05-13 01:37:39 <hulkhogan_> so for stock trades, you could do it on a sidechain, but you would want off chain processing security (like a nasdaq database)
 70 2015-05-13 01:38:45 <hulkhogan_> you might want rollbacks and other things to offset the weaker security, of course
 71 2015-05-13 01:39:30 <hulkhogan_> its more centralized but the point is the same, you can't just rely on the sidechain hashpower to secure those coffees
 72 2015-05-13 01:52:03 <Adlai> akrmn: http://lightning.network
 73 2015-05-13 02:55:25 <fanquake> ;;blocks
 74 2015-05-13 02:55:26 <gribble> 356175
 75 2015-05-13 02:57:13 <leakypat> Coffees again...
 76 2015-05-13 02:57:14 <leakypat> Coffees again...
 77 2015-05-13 04:18:32 <intx> does bitcointools work if I only have the wallet.dat file?
 78 2015-05-13 04:28:34 <fishbowl> hey, I have a reproducible crash in 0.10.1
 79 2015-05-13 04:28:38 <fishbowl> on OSX
 80 2015-05-13 04:28:47 <fishbowl> Assertion failed: (hashPrevBlock == view.GetBestBlock()), function ConnectBlock, file main.cpp, line 1660.
 81 2015-05-13 04:30:57 <fishbowl> I think it is because my blockchain was corrupted so I deleted it, apparently the client doesn't deal with missing information in the filesystem gracefully.
 82 2015-05-13 04:32:10 <fishbowl> My question is, would this be considered a bug? Am I right to report it here, or is there a better place? Thanks and I'll shut up now.
 83 2015-05-13 04:39:58 <fanquake> fishbowl open a ticket here https://github.com/bitcoin/bitcoin/issues
 84 2015-05-13 04:40:09 <fanquake> Include as much information as possible
 85 2015-05-13 04:41:29 <fanquake> Actually, are you sure you didn't run out of memory? Looking at some related tickets that could have been the problem
 86 2015-05-13 04:43:02 <fishbowl> fanquake: I'm quite sure I'm not running out of memory, bitcoin crashes on startup
 87 2015-05-13 04:43:05 <fishbowl> or asserts
 88 2015-05-13 04:50:39 <Luke-Jr> fishbowl: uh, it's not supported to just arbitrarily delete files, no.
 89 2015-05-13 04:50:40 <Luke-Jr> fishbowl: uh, it's not supported to just arbitrarily delete files, no.
 90 2015-05-13 04:51:32 <fishbowl> ok
 91 2015-05-13 04:52:00 <fishbowl> I experimented with putting the blockchain on a different fs because it grew too big
 92 2015-05-13 04:52:01 <fishbowl> I experimented with putting the blockchain on a different fs because it grew too big
 93 2015-05-13 04:52:24 <fishbowl> any idea how to recover without losing other information?
 94 2015-05-13 04:53:52 <Luke-Jr> backup and reindex is safest I guess
 95 2015-05-13 04:55:22 <fishbowl> anything I have to keep other than the wallet?
 96 2015-05-13 04:55:48 <Luke-Jr> at least the database/ directory
 97 2015-05-13 04:55:55 <Luke-Jr> I'd back it all up just in case
 98 2015-05-13 04:56:07 <fishbowl> the database/ directory is empty.
 99 2015-05-13 04:58:39 <fishbowl> ah, after deleting more it started again (I backed up everything I still had)
100 2015-05-13 04:58:43 <fishbowl> thanks.
101 2015-05-13 04:59:23 <Luke-Jr> it will crash again
102 2015-05-13 04:59:31 <fishbowl> when?
103 2015-05-13 04:59:37 <Luke-Jr> when a peer asks you for the data
104 2015-05-13 04:59:59 <Luke-Jr> delete the blocks/ directory and run with -reindex once
105 2015-05-13 05:00:13 <fishbowl> ok
106 2015-05-13 05:00:16 <fishbowl> thanks
107 2015-05-13 05:02:14 <fishbowl> I guess I stupidly assumed bitcoin would be able to recover automatically
108 2015-05-13 05:03:48 <Luke-Jr> it used to handle ordinary corruption, but 0.10 is a regression in that area unfortunately.
109 2015-05-13 05:05:34 <fishbowl> thanks for all that information, have a good day
110 2015-05-13 08:06:14 <btcwalletuser> hi, using bitcoin core wallet, I've gotten an assertion twice now, first in 0.9.unknown, then updated to 0.10.1, happened again, both times during block chain sync. anything I can do to help eradicate it?
111 2015-05-13 08:06:17 <btcwalletuser> Program: C:\Program Files\Bitcoin\bitcoin-qt.exe, File: main.cpp, Line 1660, Expression: hashPrevBlock == view.GetBestBlock()
112 2015-05-13 10:17:36 <timothy> hi, I have a problem to validate bitcoin-0.10.1.tar.gz
113 2015-05-13 10:19:00 <timothy> oh nothing, my fauly
114 2015-05-13 10:19:02 <timothy> fault
115 2015-05-13 10:54:31 <warren> If anyone is interested in helping the development of a self-deployable, bitcoind based payment processor please join us in #baronpay.  Live demo is online again.  It's super basic for now but working with no known flaws.
116 2015-05-13 10:55:19 <timothy> with no known flaws.
117 2015-05-13 10:57:09 <warren> (That's an invitation to break it.)
118 2015-05-13 11:23:52 <jonasschnelli> are the 0.10.2rc1 osx signatures already available?
119 2015-05-13 11:24:29 <jonasschnelli> i mean the signature.tar.gz
120 2015-05-13 12:18:06 <fanquake> Don't think so.
121 2015-05-13 12:18:30 <fanquake> Corey has only committed unsigned. Do we even to signed for rcs ?
122 2015-05-13 12:51:41 <jonasschnelli> fanquake: yes. I think we have. Let's wait then. :)
123 2015-05-13 12:52:17 <jonasschnelli> fanquake: mind doing a final test of: https://github.com/bitcoin/bitcoin/pull/6116?
124 2015-05-13 12:52:29 <jonasschnelli> binaries are here if you like to check the .dmg: https://builds.jonasschnelli.ch/pulls/6116/
125 2015-05-13 12:53:47 <fanquake> jonasschnelli Sure, ill check it out shortly.
126 2015-05-13 12:54:01 <jonasschnelli> Thanks!
127 2015-05-13 12:54:23 <fanquake> You might want to add a comment explaining the build failure if you haven't already.
128 2015-05-13 12:58:00 <jonasschnelli> fanquake: this is a strange travis issue i can't solve myself. Check https://github.com/bitcoin/bitcoin/pull/6116#issuecomment-101255487
129 2015-05-13 12:58:36 <fanquake> ah ok. I thought it was related to changes in the pull.
130 2015-05-13 12:59:14 <jonasschnelli> i try to rebase and force-push again...
131 2015-05-13 13:43:26 <wumpus> up until now we've always signed rcs, I'm not sure that is necessary though - I leave it up to cfields. Due to the small number of changes I expect this is at least the only rc necessary for this version
132 2015-05-13 13:44:35 <jonasschnelli> If we merge https://github.com/bitcoin/bitcoin/pull/6116 for 0.11.0rc1 signing would be welcome because 6116 could have a impact on signing
133 2015-05-13 13:50:33 <wumpus> the travis error in #6116 is strange, it happens for the second time so it's *probably* not a transient issue
134 2015-05-13 13:50:54 <wumpus> or are all travis tested pulls failing?
135 2015-05-13 13:51:14 <fanquake> Not all.
136 2015-05-13 13:51:31 <fanquake> #6126 was opened recently and is passing fine.
137 2015-05-13 14:05:15 <jonasschnelli> wumpus: no. Other PRs are fine. I also force pushed 6116 multiple times to enforce a travis rebuild. But no luck at all.
138 2015-05-13 14:05:41 <jonasschnelli> built 6116 over gitian, on linux, etc. Works fine.
139 2015-05-13 14:10:44 <wumpus> curious.
140 2015-05-13 14:12:22 <jonasschnelli> wumpus: this commit message is more or less wrong: https://github.com/bitcoin/bitcoin/commit/ff325032678df25920fe0345701f714ad2f21c61#diff-ef76fd6674f07db88c3422fdbf0bcf9fR68 i think theres no chance to change this. I guess we won't do git rebases -i on master?
141 2015-05-13 14:12:30 <jonasschnelli> my fault. sorry.
142 2015-05-13 14:12:51 <wumpus> absolutely not
143 2015-05-13 14:13:32 <wumpus> what is wrong?
144 2015-05-13 14:15:13 <wumpus> if it's just a mistake in the release notes you can submit a patch to that
145 2015-05-13 14:15:23 <wumpus> no need to mess around with git history
146 2015-05-13 14:15:32 <morcos> wumpus: sorry for agitating on #5159, but it has an ACK from sdaftuar and a "code review and lightly tested ACK" from gavinandresen, should i beg someone for another review or is that mergeable?
147 2015-05-13 14:17:12 <wumpus> morcos: depends on the risk. what is the worst thing that could happen if we merge it?
148 2015-05-13 14:17:24 <jonasschnelli> wumpus: It (the commit msg) just don't exactly reflect the changes from 6093. But it's okay i think, just a very tiny detail. :)
149 2015-05-13 14:18:13 <morcos> morcos: realistically the worst thing that could happen is it gives bad estimates in some edge case that hasn't been flushed out in testing, but i don't see how we find that without more people running it
150 2015-05-13 14:18:25 <morcos> ha, i'm speaking to myself
151 2015-05-13 14:18:52 <morcos> jtimon also checked that it didn't mess with other parts of the code base
152 2015-05-13 14:20:03 <jtimon> yes, I payed attention that it was all policy-related, and it is, more concretely fee-policy-related
153 2015-05-13 14:21:13 <jtimon> it also moves the estimator  out of txmempool which is useful for policy encapsulation in itself, rewardless of the internal changes to the estimator
154 2015-05-13 14:21:46 <jtimon> I really hope it gets in for 0.11
155 2015-05-13 14:22:39 <jtimon> if it doesn't I will create another PR only moving it without touching  it (I had that ready long before I saw that PR)
156 2015-05-13 14:23:27 <morcos> wumpus: the big downside is whether the code is too complicated and messy, but i'd argue its better to have a complicated estimator that gives good estimates than a simple broken one...
157 2015-05-13 14:23:54 <gavinandresen> wumpus: I agree with morcos, worst case for the fee-estimate changes is pretty mild. I think it should be merged.
158 2015-05-13 14:24:09 <wumpus> code changes look ok to me on first glance
159 2015-05-13 14:24:19 <jtimon> btw, morcos, for the next time, I would advice to do the code movement before or after the code changes, but not at the same time (to simlify review)
160 2015-05-13 14:24:33 <wumpus> jtimon: agreed
161 2015-05-13 14:24:35 <jtimon> s/simlify/simplify
162 2015-05-13 14:24:56 <morcos> ok, makes sense
163 2015-05-13 14:24:57 <morcos> ok, makes sense
164 2015-05-13 14:25:25 <wumpus> would have been better to do the code moves in a commit first, and then make the changes, at least then the changes can be reviewed separately.
165 2015-05-13 14:25:58 <wumpus> now it's like you add a *lot* of code
166 2015-05-13 14:26:27 <jtimon> I rebased the patch on top of my moveonly version once, but then I git pruned it, I should kept that branch around and post it on the PR or something
167 2015-05-13 14:27:16 <morcos> but it is a lot of code, i don't think there should be much (if any) code that is deleted and then added in a new file
168 2015-05-13 14:28:17 <jtimon> still, better separate movements from changes
169 2015-05-13 14:29:06 <jtimon> actually, the more code, the more important it is, for a small function is not so bad to do both at the same time as people will be able to tell the difference more easily
170 2015-05-13 14:29:19 <morcos> so actually move the old estimator out to a separate file first, yeah i guess that makes sense, then its at least clear how much of it i'm replacing
171 2015-05-13 14:29:40 <wumpus> morcos: btw there is still a language nit by sdaftuar in a log message  :)
172 2015-05-13 14:29:58 <morcos> ok will push
173 2015-05-13 14:30:05 <jtimon> yep, I mean, I wouldn't change it at this point, just saying for the next time
174 2015-05-13 14:30:28 <wumpus> yes, no need to revise history history
175 2015-05-13 14:30:48 <fanquake> morcos there's also a couple license corrections if your going to push again.
176 2015-05-13 14:30:50 <morcos> no i meant i'll fix the nit...
177 2015-05-13 14:31:08 <jtimon> yeah, sure
178 2015-05-13 14:31:40 <morcos> in general i've been ignoring all the copyright stuff b/c i thought we were changing wholesale to referring to one file, but should i correct them?
179 2015-05-13 14:32:11 <fanquake> Yes, pretty sure we've made all the wholesale corrections
180 2015-05-13 14:32:24 <Diablo-D3> https://www.kickstarter.com/projects/theplanetarysociety/lightsail-a-revolutionary-solar-sailing-spacecraft/
181 2015-05-13 14:32:24 <fanquake> There's no mention of x11 anywhere in the codebase now
182 2015-05-13 14:43:45 <morcos> wumpus: ok just squashed back in the nit fixes, thanks everyone
183 2015-05-13 14:52:00 <wumpus> morcos: thanks!
184 2015-05-13 15:02:05 <cfields> jonasschnelli: i'd rather not pull in #6116 for a bugfix release. That's not the kind of thing people anticipate
185 2015-05-13 15:02:30 <jonasschnelli> cfields: right. I think it makes only sense for 0.11
186 2015-05-13 15:02:37 <cfields> as for the build failure, that's strange. I suspect it'd be fixed by clearing Travis's cache. Hate to see that, though :\
187 2015-05-13 15:03:27 <cfields> jonasschnelli: ah sorry, i misread. Thought you wanted it in 0.10.2 due to the signing discussion
188 2015-05-13 15:03:57 <cfields> as for that, they can be ready in just a few min. There just weren't enough sigs last night
189 2015-05-13 15:04:20 <wumpus> cfields: I don't think he was proposing pulling it for a bugfix release, but for 0.11
190 2015-05-13 15:04:34 <wumpus> cfields: I certainly agree though
191 2015-05-13 15:04:55 <cfields> wumpus: roger. sounds good.
192 2015-05-13 15:05:25 <cfields> wumpus: mind clearing the Travis cache for that build and see if that fixes? That's the only explanation I can come up with
193 2015-05-13 15:05:26 <jonasschnelli> what about https://github.com/bitcoin/bitcoin/pull/6110 for 0.11?
194 2015-05-13 15:06:29 <cfields> If that fixes the problem, I'll see about adding a new check to the depends so that the hash is also tested before extraction
195 2015-05-13 15:08:25 <wumpus> cfields: "delete all repository caches"?
196 2015-05-13 15:10:11 <cfields> wumpus: should be able to nuke just the one
197 2015-05-13 15:10:49 <wumpus> master? or for the specific pull request?
198 2015-05-13 15:10:50 <wumpus> master? or for the specific pull request?
199 2015-05-13 15:11:44 <cfields> sec, seeing which one it is
200 2015-05-13 15:11:53 <jonasschnelli> 6116
201 2015-05-13 15:12:27 <wumpus> (deleted; I had no clue that pull requests had their own caches)
202 2015-05-13 15:12:48 <jonasschnelli> i assume i need to push something to trigger travis?
203 2015-05-13 15:12:49 <wumpus> (it makes sense though)
204 2015-05-13 15:12:58 <wumpus> I'll respin it
205 2015-05-13 15:13:18 <cfields> wumpus: er.. they shouldn't. Each PR pulls in the cache from the branch it's being merged to
206 2015-05-13 15:13:22 <cfields> unless that's changed very recently
207 2015-05-13 15:13:44 <wumpus> cfields: I'll make a screenshot of the page
208 2015-05-13 15:14:00 <cfields> thanks. having a look at the current docs
209 2015-05-13 15:32:08 <ajweiss> i'm moving a log message.  does that head into trivial or master?
210 2015-05-13 15:35:01 <wumpus> *changing* a log message should go into trivial, moving it to another place in the code shouldn't
211 2015-05-13 15:37:39 <cfields> wumpus: ah, that reminds me. trivial merge coming up in a few hours. I checked when you suggested the other day, no translation changes that I could see.
212 2015-05-13 15:38:29 <wumpus> cfields: great
213 2015-05-13 15:46:44 <cfields> osx signature is up: https://bitcoincore.org/cfields/bitcoin-0.10.2rc1/signature.tar.gz
214 2015-05-13 15:49:10 <cfields> wumpus: imo it's worth doing the signing at the rc stage so that people can use the same process for testing them as they'd use for final. It'd help catch problems with for ex, osx updates
215 2015-05-13 15:49:43 <cfields> iirc even the simple 10.10.1 broke signing for some progs
216 2015-05-13 15:54:14 <wumpus> cfields: agree
217 2015-05-13 15:59:11 <jtimon> oh, I missed the trivial thing again, I had some missing includes here and there, includes alhabetic order, makefile alphabetic order...
218 2015-05-13 15:59:57 <jtimon> how can I know when the trivial branch will be merged to have things prepare earlier? is it periodic or something?
219 2015-05-13 16:00:03 <jtimon> cfields^
220 2015-05-13 16:00:04 <jtimon> cfields^
221 2015-05-13 16:00:59 <cfields> jtimon: it's not atm, but suggestions welcome. go ahead and send those along if you'd like, i have some other things to finish up before PR'ing to master
222 2015-05-13 16:01:28 <jtimon> ok, maybe I have time then
223 2015-05-13 16:01:53 <cfields> jtimon: sure, i'll wait
224 2015-05-13 16:01:54 <cfields> jtimon: sure, i'll wait
225 2015-05-13 16:02:10 <jtimon> great, thanks
226 2015-05-13 16:57:46 <gavinandresen> wumpus: I’d like to see https://github.com/bitcoin/bitcoin/pull/5964 in 0.11
227 2015-05-13 16:58:24 <michagogo> So, would anyone mind taking a quick look at https://gist.github.com/Michagogo/e4879305bb0c8271573e and telling me exactly how horrible it is?
228 2015-05-13 17:01:40 <timothy> on BSD bash is not in /bin :P
229 2015-05-13 17:08:18 <michagogo> Okay, I have it running as $ Desktop/gitian-build.sh -Av 0.10.2rc1
230 2015-05-13 17:08:35 <michagogo> At least the getopts part seems to have worked, I think...
231 2015-05-13 17:09:10 <michagogo> (I had no idea how to do that... did a bunch of googling. Same with a bunch of other things in this script...)
232 2015-05-13 17:09:22 <michagogo> I mean, it seems that the right variables got set
233 2015-05-13 17:09:32 <michagogo> And it's building for linux...
234 2015-05-13 17:09:41 <Luke-Jr> gavinandresen: do you know if anyone has tested that on Debian stable by chance?
235 2015-05-13 17:10:13 <michagogo> 
ACTION wonders if the new Debian stable is any better for us in terms of compatability

236 2015-05-13 17:10:24 <michagogo> compatibility*
237 2015-05-13 17:11:46 <gavinandresen> Luke-Jr: I don’t know. If you can test and ACK/NACK, that’d be spiffy.
238 2015-05-13 17:13:49 <temujin> what is the max standard OP_RETURN payload size on testnet? 80 bytes?
239 2015-05-13 17:15:07 <michagogo> temujin: no
240 2015-05-13 17:15:15 <michagogo> Pretty sure 80 bytes is standardness
241 2015-05-13 17:15:21 <michagogo> Testnet has no standardness
242 2015-05-13 17:16:16 <Luke-Jr> temujin: testnet miners usually have no script whitelist policy (IsStandard), so anything should be fine
243 2015-05-13 17:20:13 <temujin> Luke-Jr: is it possible that all the miners can agree to set the limit on OP_RETURN to 500 bytes, for example? or is there a strict limit enforced by the protocol?
244 2015-05-13 17:20:38 <temujin> (ignoring the fact that other nodes won't relay these transactions)
245 2015-05-13 17:20:44 <Luke-Jr> temujin: pushes have a strict limit of (IIRC) 520 bytes, but you can just do multiple pushes on testnet too
246 2015-05-13 17:20:53 <Luke-Jr> testnet nodes probably WILL relay them too
247 2015-05-13 17:21:13 <temujin> ah yeah, i meant mainnet miners/nodes in that example, i should have clarified
248 2015-05-13 17:22:06 <Luke-Jr> temujin: feel free to do whatever you want on testnet, but I'm curious: do you have a real-world use case for OP_RETURN over 40 bytes?
249 2015-05-13 17:22:48 <temujin> Luke-Jr: no, I am using it as an example to learn how testnet and mainnet are different (trying to wrap my head around it)
250 2015-05-13 17:23:08 <temujin> but i am curious about OP_RETURN and standardness
251 2015-05-13 17:23:10 <temujin> in general
252 2015-05-13 17:23:26 <Luke-Jr> temujin: oh, the only significant protocol difference I am aware of is the difficulty 20-minute rule. everything else is merely policy that nodes/miners choose
253 2015-05-13 17:27:03 <wumpus> gavinandresen: sure, I'll take a look
254 2015-05-13 17:29:21 <wumpus> temujin: right, the difference is that testnet nodes don't enforce isStandard, so will relay any valid transaction
255 2015-05-13 17:30:25 <jtimon> theuni https://github.com/theuni/bitcoin/pull/23
256 2015-05-13 17:33:30 <temujin> that is a lot more simple than i thought. thank you all for the info
257 2015-05-13 17:33:31 <temujin> that is a lot more simple than i thought. thank you all for the info
258 2015-05-13 17:34:42 <jtimon> michagogo testnet has some stadardness (for example, minRelayFee), but yes, no max opreturn
259 2015-05-13 17:36:45 <cfields> jtimon: mm, the makefile looks good, but i think we've pretty much decided to stop enforcing alphabetic include order
260 2015-05-13 17:37:00 <wumpus> yes, we don't do that anymore
261 2015-05-13 17:37:05 <jtimon> mhmm, why?
262 2015-05-13 17:37:15 <wumpus> because it gave too much churn
263 2015-05-13 17:37:17 <Luke-Jr> jtimon: meh, "standardness" is misused here; OP_RETURN is never standard (unless we consider XCP's documentation as a standard I guess), just happens to pass the (poorly named) IsStandard whitelisting ;)
264 2015-05-13 17:37:22 <gavinandresen> because we like randomness, it is more secure
265 2015-05-13 17:37:23 <jtimon> if everybody does it, we will have smaller diffs and less forced rebases
266 2015-05-13 17:37:27 <cfields> jtimon: because sometimes people forget, someone follows up to fix, and it breaks PRs in the process
267 2015-05-13 17:37:33 <Luke-Jr> gavinandresen: lol
268 2015-05-13 17:37:38 <wumpus> alphabetical makefile sort is good, though
269 2015-05-13 17:38:04 <gavinandresen> Luke-Jr: (glad SOMEBODY realized I was joking!)
270 2015-05-13 17:38:13 <wumpus> hehe
271 2015-05-13 17:38:15 <Luke-Jr> gavinandresen: getting a warning about CScheduler stuff - you want me to post to the github, or just tell you here?
272 2015-05-13 17:38:31 <gavinandresen> Luke-Jr: post to github, or I’m likely to forget
273 2015-05-13 17:38:41 <Luke-Jr> k
274 2015-05-13 17:38:58 <jtimon> well, we have the trivial branch for things that people forget like this, no?
275 2015-05-13 17:39:00 <cfields> jtimon: also, because it was a constant source of "nit: include order" rather than substantive review comments. Either that, or ignore the order and know that someone would fix it up later
276 2015-05-13 17:39:28 <wumpus> jtimon: yes, but we don't bother with that anymore - it's been removed from the code style document too
277 2015-05-13 17:39:46 <jtimon> I had those nits myself, and I just started to use M-x sort-lines, other IDEs have equivalent things, is not that hard
278 2015-05-13 17:39:50 <wumpus> it's only useless busywork anyway
279 2015-05-13 17:40:32 <jtimon> whatever, more include conflicts...but at least I can stop worrying about that
280 2015-05-13 17:40:47 <wumpus> you were *worrying* about that?
281 2015-05-13 17:40:57 <jtimon> it's not useless and you can configure that on safe, so it can be not busywork as well
282 2015-05-13 17:41:02 <wumpus> let's worry about things that affect users
283 2015-05-13 17:41:17 <jtimon> wumpus yes, I didn't wanted the nits and the conflicts
284 2015-05-13 17:41:29 <jtimon> ehhh, no
285 2015-05-13 17:41:36 <wumpus> ah yes, diapolonits :)
286 2015-05-13 17:41:42 <jtimon> let's worry about things that affect developers tooo
287 2015-05-13 17:41:45 <cfields> the only header-order changes i accepted this time around were ones to force #include "foo" before #include <foo>, because the system ones can differ and cause breakage on platforms that do a better job of forwarding
288 2015-05-13 17:41:54 <cfields> (libc++ mostly)
289 2015-05-13 17:41:56 <wumpus> I'm not going to argue this anymore, case closed
290 2015-05-13 17:43:32 <jtimon> sure, just saying that I extremely disagree with "let's only worry about things that affect users", this is not the best example, but other times very imporant things don't affect users directly (like having everything on main.cpp, circular dependencies, unnecessary couplings...)
291 2015-05-13 17:44:13 <jtimon> I just missed this conversation before, but if it's case close, case closed it is, not a big deal
292 2015-05-13 17:44:13 <wumpus> I didn't use 'only'
293 2015-05-13 17:45:49 <wumpus> it's just that *bikeshedding* about things that only affect developers, in a very limited way (most developers on the project do not care about sorted includeds) is a DoS attack on our time :)
294 2015-05-13 17:46:02 <michagogo> Dammit
295 2015-05-13 17:46:08 <michagogo> That grub issue with gitian is back
296 2015-05-13 17:47:01 <Luke-Jr> michagogo: rebuilding the VM is a workaround, not a fix ☺
297 2015-05-13 17:47:02 <Luke-Jr> michagogo: rebuilding the VM is a workaround, not a fix ☺
298 2015-05-13 17:47:06 <michagogo> Luke-Jr: I know that
299 2015-05-13 17:47:47 <michagogo> devrandom was saying that it was just a matter of having the VM built before a certain change
300 2015-05-13 17:47:56 <michagogo> ...which apparently is not true
301 2015-05-13 17:48:02 <michagogo> https://github.com/devrandom/gitian-builder/issues/86
302 2015-05-13 17:49:18 <Luke-Jr> michagogo: well, I'd expect every grub update to reproduce it
303 2015-05-13 17:49:33 <michagogo> Luke-Jr: I don't know that there was a grub update
304 2015-05-13 17:49:43 <Luke-Jr> probably you/someone should look into how official Ubuntu LXCs work
305 2015-05-13 17:50:06 <michagogo> Unless I'm misunderstanding something, it seems something else is pulling grub back in when it updates
306 2015-05-13 17:50:21 <wumpus> jtimon: I agree that only worrying about user-facing issues is dangerous on the long term, at a company I worked at any kind of refactoring or code improvement was effectively forbidden, resulting in a minefield of unmaintainable code, but that's hardly the case here :)
307 2015-05-13 17:51:38 <wumpus> Luke-Jr: we should probably - in some way - ignore the package that causes the problem during upgrades
308 2015-05-13 17:51:57 <jtimon> wumpus that sounds familiar ;)
309 2015-05-13 17:53:31 <Luke-Jr> wumpus: also a workaround: some day, we will have a dependendency that indirectly requires grub :P
310 2015-05-13 17:53:46 <jtimon> although to be fair (and again, not blaming anyone) this is not precisely a project that is very receptive to refactorings, even when they're necessary for future features (ie libbitcoin and standard/testnet policy selection)
311 2015-05-13 17:53:56 <wumpus> jtimon: the answer to supporting different scenarios, like variants of hardware was almost always 'just copy the code', refactoring the existing code to support multiple platforms was considered too risky
312 2015-05-13 17:54:24 <wumpus> we're also very conservative here, sure
313 2015-05-13 17:54:34 <jtimon> well, separating the consensus code will hopefully help with this annoying "too risky" meme
314 2015-05-13 17:54:45 <gmaxwell> jtimon: tolerabity of refactorings is inversely proportional to how convincing the tests are. :)
315 2015-05-13 17:55:26 <gmaxwell> If the consensus code was tested in the way libsecp256k1 is; it would be much safer to change.
316 2015-05-13 17:55:37 <jtimon> gmaxwell even commits that would have resulted in identical builds (thus no testing needed) have been rejected
317 2015-05-13 17:56:04 <wumpus> jtimon: oh?
318 2015-05-13 17:56:13 <michagogo> gmaxwell: inversely?
319 2015-05-13 17:56:20 <wumpus> jtimon: probably due to other reasons than riskyness, than
320 2015-05-13 17:56:35 <gmaxwell> Don't intermix different reasons; you know sometimes other people actually don't think some changes are an improvement.  But if things actually resulted in bit identical output they shouldn't have been bounced for being a risk of changing behavior.
321 2015-05-13 17:56:56 <wumpus> in a way refactoring has a subjective component, other developers may not agree that a certain structure is better
322 2015-05-13 17:56:58 <jtimon> I'm putting a lot of effort in presenting the refactorings in a way that are obviously non-risky, I think that adding tests for commits that are oviously functionaly equivalent is aa waste of time
323 2015-05-13 17:56:59 <wumpus> it's not *measurable*
324 2015-05-13 17:57:17 <gmaxwell> michagogo: intended an intolerability. :)
325 2015-05-13 17:57:41 <gmaxwell> jtimon: thats not a waste of time; the code is currentl massively under tested.
326 2015-05-13 17:57:42 <gmaxwell> jtimon: thats not a waste of time; the code is currentl massively under tested.
327 2015-05-13 17:57:52 <wumpus> adding tests is always good
328 2015-05-13 17:58:01 <wumpus> (unless of course it just duplicates existing ones)
329 2015-05-13 17:58:05 <gmaxwell> And there have been many "obviously correct" changes that weren't (both in this project and in the history of programming)
330 2015-05-13 17:58:29 <jtimon> gmaxwell: s/waste of time/unnecessary barrier for improvement
331 2015-05-13 17:59:03 <gmaxwell> Personally someone saying something that doesn't produce identical binaries saying "obviously correct" is usually a red flag that says they're not taking it seriously, doubly so if its code that isn't comprehensively tested.
332 2015-05-13 17:59:44 <gmaxwell> jtimon: I disagree strongly; we are massively behind where we should be with respect to assurance considering the role and application of the system.  It's an _unfortunate_ barrier for improvement, but not an unnecessary one.
333 2015-05-13 18:00:02 <jtimon> about identical builds, I'm talkingabout #5153 and an equivalent for main::ProcessMessage like in jgarzik's #4646
334 2015-05-13 18:00:16 <gmaxwell> especially since just switching around failure modes is not acceptable due to consensus.
335 2015-05-13 18:01:06 <wumpus> jtimon: reading the comments there, people just didn't agree on the new code
336 2015-05-13 18:01:09 <jtimon> gmaxwell: when the changes are obviously harmless I consider it unnecesary
337 2015-05-13 18:01:12 <gmaxwell> 5153 does not produce identical code. And it's changing around undertested stuff.
338 2015-05-13 18:01:26 <wumpus> jtimon: that's a case where 'better' is subjective
339 2015-05-13 18:01:27 <wumpus> jtimon: that's a case where 'better' is subjective
340 2015-05-13 18:01:42 <gmaxwell> We have consensus behavior that would have been broken by changes far more subtle than 5153.