1 2017-04-12 00:00:59	0|cfields|heh
  2 2017-04-12 01:55:06	0|jtimon|cfields: at the same time, I'm a sed newbie, there were no '\' in my teacher's blackboard or my "reduded-c" interpreter implemented in c++, please, don't laught to loud when you tell me what my mistake is in: https://0bin.net/paste/mHKVu6pkl2XopjAb#3S9s6vUOBTnlmnDMWRKH6Te6-oJAjdE3lBD0LtS45/s
  3 2017-04-12 01:55:08	0|gribble|https://github.com/bitcoin/bitcoin/issues/3 | Encrypt wallet · Issue #3 · bitcoin/bitcoin · GitHub
  4 2017-04-12 02:10:15	0|cfields|jtimon: i think you want something like: sed -i 's/BOOST_FOREACH(\(.*\),\(.*\))/for(\1 :\2)/' net_processing.cpp
  5 2017-04-12 02:10:16	0|cfields|?
  6 2017-04-12 02:11:13	0|jtimon|oh, yeah, the dot, thank you very much
  7 2017-04-12 02:12:44	0|cfields|np
  8 2017-04-12 02:13:53	0|cfields|jtimon: you'll need to filter some things out of that. iirc pairs are handled differently, at least.
  9 2017-04-12 02:15:31	0|jtimon|I shouldn't even need a pair I think, now I'm trying sed -i "s/BOOST_FOREACH(\(.*\), /for (${\1} :" src/net_processing.cpp
 10 2017-04-12 02:16:09	0|jtimon|bash: s/BOOST_FOREACH(\(.*\), /for (${\1} :: bad substitution
 11 2017-04-12 02:17:54	0|jtimon|it feels like it's something embarrasingly obvious
 12 2017-04-12 02:47:22	0|jtimon|ok, "git checkout -- ." was the first thing I was missing before trying again with something different
 13 2017-04-12 02:53:14	0|jtimon|alright, I think 'git checkout -- . ; sed -i 's/BOOST_FOREACH(\(.*\),/for (\1 :/' ./src/qt/*.cpp ./src/wallet/*.cpp' is enough to test your PR on travis
 14 2017-04-12 02:57:45	0|cfields|jtimon: does that actually build?
 15 2017-04-12 03:02:39	0|jtimon|cfields: sed does what I expect, and only with ./src/qt/*.cpp , it passes unittests
 16 2017-04-12 03:03:03	0|cfields|mm, neat
 17 2017-04-12 03:05:47	0|jtimon|now it's time to make it "fail" on purpose and open a PR, then add a fixup commit to be squashed once your pr is merged
 18 2017-04-12 03:06:32	0|jtimon|neat indeed, I expect this to be revolution in refactors, thanks again
 19 2017-04-12 03:09:07	0|cfields|:) happy to help
 20 2017-04-12 03:10:55	0|cfields|I've had this one (the cnode change) done on a ton of branches, but never felt like dealing with the process of pushing it through. So yea, I can see how it could be helpful for lots of similar changes.
 21 2017-04-12 03:11:52	0|jtimon|at the very least, it revolutionized the way I think about refactors, maybe it was obvious to use sed for rebase and review for everyone else but certainly not for me
 22 2017-04-12 03:12:43	0|jtimon|yeah, not only painful simple changes will stop to be painful
 23 2017-04-12 03:12:57	0|jtimon|which is the fisrt use case
 24 2017-04-12 03:15:04	0|jtimon|but also some painful changes that authors don't even open as PR because they're too disruptive will be open now
 25 2017-04-12 03:15:29	0|cfields|awesome
 26 2017-04-12 03:15:33	0|jtimon|and more importantly, reviewed too
 27 2017-04-12 03:15:53	0|cfields|jtimon: you might look at pairing it with "git rebase -i --exec <script>" too :)
 28 2017-04-12 03:16:04	0|cfields|for maintaining
 29 2017-04-12 03:17:05	0|jtimon|or maybe I'm over-excited about this, it is good enough to know I am not stupid for not thinking about this by myself beforehand
 30 2017-04-12 03:17:38	0|jtimon|-exec was failing locally for some reason
 31 2017-04-12 03:18:17	0|cfields|heh
 32 2017-04-12 03:18:28	0|cfields|headed off, nnite
 33 2017-04-12 04:03:47	0|bitcoin-git|[13bitcoin] 15jtimon opened pull request #10193: scripted-diff: sed -i 's/BOOST_FOREACH(\(.*\),/for (\1 :/' ./src/qt/*.cpp (06master...06b14-10189-scripted-qt-foreach) 02https://github.com/bitcoin/bitcoin/pull/10193
 34 2017-04-12 04:05:43	0|cfields|jtimon: you didn't format the commit message in a way that it will be picked up
 35 2017-04-12 04:06:00	0|cfields|jtimon: see https://github.com/bitcoin/bitcoin/pull/10193/commits/d04198309e7e9b21de1604cc4321148b37a46347
 36 2017-04-12 04:16:19	0|jtimon|cfields: np, updated https://github.com/bitcoin/bitcoin/pull/10189#issuecomment-293468978 and https://github.com/bitcoin/bitcoin/pull/10193
 37 2017-04-12 04:17:30	0|cfields|that looks better, thanks
 38 2017-04-12 09:30:36	0|wumpus|taking another look at #9694, really want to move forward multiwallet support
 39 2017-04-12 09:30:44	0|wumpus|#8694 sorry
 40 2017-04-12 09:31:39	0|gribble|https://github.com/bitcoin/bitcoin/issues/9694 | Importmulti cannot import bare private keys · Issue #9694 · bitcoin/bitcoin · GitHub
 41 2017-04-12 09:31:40	0|gribble|https://github.com/bitcoin/bitcoin/issues/8694 | Basic multiwallet support by luke-jr · Pull Request #8694 · bitcoin/bitcoin · GitHub
 42 2017-04-12 10:28:15	0|bitcoin-git|[13bitcoin] 15bulldozer00 opened pull request #10194: Remove unecessary friend keyword from the class definition (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/10194
 43 2017-04-12 10:46:41	0|wumpus|what's the problem with travis today?
 44 2017-04-12 10:52:20	0|wumpus|nm, no travis issue today :)
 45 2017-04-12 12:37:34	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #10195: Switch chainstate db and cache to per-txout model (06master...06pertxoutcache) 02https://github.com/bitcoin/bitcoin/pull/10195
 46 2017-04-12 13:43:52	0|bitcoin-git|[13bitcoin] 15jnewbery reopened pull request #10191: [trivial] Remove unused submit block parameters argument (06master...06remove_submit_block_params) 02https://github.com/bitcoin/bitcoin/pull/10191
 47 2017-04-12 14:36:42	0|bitcoin-git|[13bitcoin] 15sdaftuar opened pull request #10196: Bugfix: PrioritiseTransaction updates the mempool tx counter (06master...062017-04-prioritise-transaction) 02https://github.com/bitcoin/bitcoin/pull/10196
 48 2017-04-12 15:12:36	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #10197: Functional test warnings (06master...06functional_test_warnings) 02https://github.com/bitcoin/bitcoin/pull/10197
 49 2017-04-12 16:08:39	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #10198: [tests] Remove is_network_split from functional test framework (06master...06remove_is_network_split) 02https://github.com/bitcoin/bitcoin/pull/10198
 50 2017-04-12 16:09:08	0|bitcoin-git|[13bitcoin] 15jnewbery closed pull request #10198: [tests] Remove is_network_split from functional test framework (06master...06remove_is_network_split) 02https://github.com/bitcoin/bitcoin/pull/10198
 51 2017-04-12 17:01:47	0|arubi|0.13.99) looks promising, but I'm not sure what to set it to.  would love a hint on what I should look for
 52 2017-04-12 17:01:47	0|arubi|is there a way to get bitcoind to not complain about any non-standardness?  I'd still like for it to error on operations with invalid transactions, but for example I'd like it to not care about DER strictness, or to ignore the P2SH requirement for a valid redeemscript (provided some preimage to p2sh, it should pass, no matter if the preimage parses as a script at all).  "SCRIPT_VERIFY_NONE = 0;" in script/interpreter.h (I'm on some
 53 2017-04-12 17:03:25	0|arubi|this is for testnet \ regtest use by the way
 54 2017-04-12 17:06:25	0|arubi|maybe I should just set all verify flags to 0 :)
 55 2017-04-12 17:10:16	0|Chris_Stewart_5|arubi: Like you mentioned you can tinker with the verify flags: https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.h#L52
 56 2017-04-12 17:10:29	0|Chris_Stewart_5|but I'm not sure if you can do this from the command line :/
 57 2017-04-12 17:10:46	0|arubi|oh no command line, these flags are not enough though
 58 2017-04-12 17:11:23	0|arubi|it's letting it advance, I can send non standard transactions with some of these flags disabled, but getblocktemplate fails
 59 2017-04-12 17:11:49	0|arubi|I don't wanna say that it's related, I already mauled this specific code to death
 60 2017-04-12 17:11:50	0|Chris_Stewart_5|hmmm, perhaps you need to tinker with relay policy? Not sure where that is set in the codebase though
 61 2017-04-12 17:12:00	0|arubi|other nodes drop the transaction
 62 2017-04-12 17:12:05	0|arubi|actually I think they're banning me
 63 2017-04-12 17:12:40	0|arubi|I'll be able to mine it myself eventually on testnet, when the diff drops, I just need getblocktemplate to work :)  setting all verify flags to 0 now
 64 2017-04-12 17:17:26	0|arubi|muhaha it's working
 65 2017-04-12 17:18:41	0|bitcoin-git|[13bitcoin] 15morcos opened pull request #10199: Better fee estimates (06master...06smarterfee) 02https://github.com/bitcoin/bitcoin/pull/10199
 66 2017-04-12 17:20:50	0|Chris_Stewart_5|setting all the flags to zero worked?
 67 2017-04-12 17:21:00	0|arubi|yep
 68 2017-04-12 17:21:12	0|Chris_Stewart_5|you couldn't just unset STRICTDER?
 69 2017-04-12 17:21:44	0|arubi|well I noticed script_verify_p2sh is used even with this tx's bare p2pk
 70 2017-04-12 17:22:18	0|arubi|I did unset strictder to even be able to relay it... I think checking block validity is even more strict than that
 71 2017-04-12 17:22:41	0|arubi|if you saw the tx in #-dev, it's also a hybrid pubkey, so maybe more relaxed flags are needed
 72 2017-04-12 17:26:08	0|Chris_Stewart_5|arubi: Is p2pk scripts considered non standard?
 73 2017-04-12 17:26:38	0|arubi|if it's a hybrid pubkey, probably
 74 2017-04-12 17:27:41	0|arubi|also the signature itself is weird.  uses 0x01000000 as the sighash when the sig is passed as input
 75 2017-04-12 17:28:29	0|arubi|so it's actually passed with a 4 byte value instead of just 0x01.. I think it should still be valid?
 76 2017-04-12 17:34:25	0|instagibbs|morcos, for #10199 did you look at how it handles chain limits? There was some speculation during last spam attack that the chain limits were causing high-fee transactions to "fail" to get into blocks, spiking fees randomly
 77 2017-04-12 17:34:26	0|gribble|https://github.com/bitcoin/bitcoin/issues/10199 | Better fee estimates by morcos · Pull Request #10199 · bitcoin/bitcoin · GitHub
 78 2017-04-12 17:35:47	0|morcos|instagibbs: the estimates don't consider txs that are dependent on other txs
 79 2017-04-12 17:35:57	0|morcos|i don't think i saw that speculation, but it makes no sense
 80 2017-04-12 17:36:01	0|Chris_Stewart_5|arubi: Look at this function if you haven't seen it yet: https://github.com/bitcoin/bitcoin/blob/b83264d9c7a8ddb79f64bd9540caddc8632ef31f/src/script/interpreter.cpp#L186
 81 2017-04-12 17:36:15	0|Chris_Stewart_5|to see if the hash type is valid
 82 2017-04-12 17:36:37	0|arubi|being defined != being valid :)
 83 2017-04-12 17:37:10	0|arubi|the famous amount overflow transaction used 0xA8 as sighash iirc, weird, but it resolves to ALL
 84 2017-04-12 17:38:13	0|arubi|interpreter.cpp has the rules for setting up the sighash, it does a bunch of bitwise and's with 1F and flags it knows.  really I think 32 bits can be used.  sighashv2 uses 32 bits
 85 2017-04-12 17:39:21	0|instagibbs|morcos, ok good to know. One less idea why someone was doing that then.
 86 2017-04-12 17:40:18	0|arubi|er, it uses 16 bits.
 87 2017-04-12 17:42:55	0|arubi|was just informed that I may be wrong re. 4 bytes sighash value :)
 88 2017-04-12 17:45:18	0|arubi|bip66 might be causing testnet failures where it works on regtest.  will stop spamming :)
 89 2017-04-12 17:45:25	0|Chris_Stewart_5|Yeah when checking the signature you have to prepend? the extra bytes?
 90 2017-04-12 17:45:46	0|arubi|(-dev)
 91 2017-04-12 17:58:12	0|bitcoin-git|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/b44adf92342a...350b22497c7c
 92 2017-04-12 17:58:13	0|bitcoin-git|13bitcoin/06master 144d9950d 15John Newbery: Set BCLog::LIBEVENT correctly for old libevent versions.
 93 2017-04-12 17:58:13	0|bitcoin-git|13bitcoin/06master 145255aca 15John Newbery: [rpc] Add logging RPC...
 94 2017-04-12 17:58:14	0|bitcoin-git|13bitcoin/06master 147fd50c3 15John Newbery: allow libevent logging to be updated during runtime
 95 2017-04-12 17:58:37	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10150: [rpc] Add logging rpc (06master...06logging_rpc) 02https://github.com/bitcoin/bitcoin/pull/10150
 96 2017-04-12 17:58:59	0|gmaxwell|neat
 97 2017-04-12 18:15:59	0|bitcoin-git|13bitcoin/06master 148c3e6c6 15KibbledJiveElkZoo: Changed "Send" button default status from true to false...
 98 2017-04-12 18:15:59	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/350b22497c7c...de01da7cad32
 99 2017-04-12 18:16:00	0|bitcoin-git|13bitcoin/06master 14de01da7 15Wladimir J. van der Laan: Merge #10177: Changed "Send" button default status from true to false...
100 2017-04-12 18:16:21	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10177: Changed "Send" button default status from true to false (06master...06ui_fixes) 02https://github.com/bitcoin/bitcoin/pull/10177
101 2017-04-12 18:25:59	0|BlueMatt|wumpus: can we give that guy an award for "most humorous bug report"?
102 2017-04-12 18:40:34	0|bitcoin-git|[13bitcoin] 15bulldozer00 closed pull request #10194: Remove unecessary friend keyword from the class definition (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/10194
103 2017-04-12 19:18:00	0|BlueMatt|#9942 looks mergeable
104 2017-04-12 19:18:01	0|gribble|https://github.com/bitcoin/bitcoin/issues/9942 | Refactor CBlockPolicyEstimator by morcos · Pull Request #9942 · bitcoin/bitcoin · GitHub
105 2017-04-12 19:18:38	0|BlueMatt|same with #9480, maybe jeremyrubin should change the commit message, but has like 5 acks
106 2017-04-12 19:18:39	0|gribble|https://github.com/bitcoin/bitcoin/issues/9480 | De-duplicate SignatureCacheHasher by JeremyRubin · Pull Request #9480 · bitcoin/bitcoin · GitHub
107 2017-04-12 19:59:24	0|bitcoin-git|[13bitcoin] 15sdaftuar opened pull request #10200: Mining: Skip recent transactions if fee difference is small (06master...062017-04-dont-mine-recent-tx) 02https://github.com/bitcoin/bitcoin/pull/10200
108 2017-04-12 20:12:12	0|gmaxwell|sdaftuar: wow, that is much more complicated than I expected.  What I had just expected it to do is to simply skip very new transactions unless they paid a high feerate, just like we skip transactions that there aren't room in the block for.
109 2017-04-12 20:12:28	0|gmaxwell|sdaftuar: is there a big fee income difference from doing a simple thing like that?
110 2017-04-12 20:14:35	0|BlueMatt|cfields: wait, we really want random bash snippets in git history run by a script in #10189? I'm unsure about the wisdom of that?
111 2017-04-12 20:14:36	0|gribble|https://github.com/bitcoin/bitcoin/issues/10189 | devtools/net: add a verifier for scriptable changes. Use it to make CNode::id private. by theuni · Pull Request #10189 · bitcoin/bitcoin · GitHub
112 2017-04-12 20:14:49	0|BlueMatt|i mean its super nice to have, but also...running bash scripts out of git messages :/
113 2017-04-12 20:16:02	0|cfields|BlueMatt: arguably if a script is used to transform a large chunk of code, it should be saved with the commit for future reference. Why not use it too?
114 2017-04-12 20:16:14	0|BlueMatt|yea......
115 2017-04-12 20:17:00	0|BlueMatt|cfields: do merge tools show commit messages very clearly for sign-off?
116 2017-04-12 20:17:13	0|BlueMatt|would need to if they dont for this, i suppose
117 2017-04-12 20:17:23	0|cfields|BlueMatt: "git notes" is what you're asking about, i think :)
118 2017-04-12 20:17:43	0|BlueMatt|hmm?
119 2017-04-12 20:18:33	0|cfields|BlueMatt: i suppose I don't understand your question
120 2017-04-12 20:19:01	0|BlueMatt|cfields: contrib/devtools/github-merge.py
121 2017-04-12 20:19:21	0|BlueMatt|i would expect them to clearly query the merger to read each commit's commitmsg
122 2017-04-12 20:21:30	0|cfields|unsure. Wouldn't change anything there, though. the merge script could just run the verifier first.
123 2017-04-12 20:22:08	0|BlueMatt|cfields: oh dear god lets not default to running random peoples' commitmsg scripts on wumpus' computer
124 2017-04-12 20:22:43	0|BlueMatt|cfields: my point is that many people dont read commitmsgs in enough detail and might miss such scripts esp if they're replaced last-minute in a "title-only rebase"
125 2017-04-12 20:24:40	0|cfields|BlueMatt: travis runs the script and fails if it doesn't transform 1:1. It can be done locally as well....
126 2017-04-12 20:25:00	0|cfields|BlueMatt: I don't see what's so terrible about automating this checking: https://github.com/bitcoin/bitcoin/pull/9902/commits/bac5c9cf643e9333479ac667426d0b70f8f3aa7f
127 2017-04-12 20:25:36	0|BlueMatt|cfields: insmod cool_thing.ko && sed s/BOOST_FOREACH/for/
128 2017-04-12 20:25:51	0|BlueMatt|it'll transform 1:1 still?
129 2017-04-12 20:25:55	0|BlueMatt|this is not a sufficient check
130 2017-04-12 20:26:01	0|BlueMatt|automating on travis whatever
131 2017-04-12 20:26:24	0|BlueMatt|putting yet more scripts in a place that people might not see it is bad...I'm only suggesting we make it more apparent at least to people pressing the merge button
132 2017-04-12 20:26:36	0|BlueMatt|as many of us primarily just look at the diff itself
133 2017-04-12 20:28:32	0|BlueMatt|probably not
134 2017-04-12 20:29:17	0|cfields|BlueMatt: the person pressing the merge button on bac5c9cf643e9333479ac667426d0b70f8f3aa7f should be running that sed script to be sure all occurances have been caught. Again, this should only be automatiting cases where mass transforms need to be checked anyway.
135 2017-04-12 20:29:51	0|BlueMatt|cfields: yes, but the person pressing the merge button should also be reading the script before it gets automatically run on their system
136 2017-04-12 20:29:57	0|BlueMatt|I think we're talking past each other somehow
137 2017-04-12 20:30:01	0|cfields|so yea, maybe not make it part of the merge script, but i don't see how having c-i do it could be a bad thing
138 2017-04-12 20:30:13	0|BlueMatt|I didnt say having c-i do it is bad?
139 2017-04-12 20:30:17	0|BlueMatt|i agree, travis should do it?
140 2017-04-12 20:30:33	0|BlueMatt|my only point was that the person pressing the merge button MUST be forced to read commit messages now
141 2017-04-12 20:30:44	0|BlueMatt|<BlueMatt> I think we're talking past each other somehow
142 2017-04-12 20:32:23	0|cfields|ok, fair enough. I thought you point was that the person hitting the button should be verifying as well if it's going to live in the commit message..
143 2017-04-12 20:32:57	0|BlueMatt|oh i mean maybe, i dont care much either way there, travis should run it so thats good
144 2017-04-12 20:33:13	0|BlueMatt|my only point is something should be done because many of us dont read commit messages as part of review (much)
145 2017-04-12 20:33:50	0|cfields|BlueMatt: jtimon suggested a prefix: "scripted-diff: commit msg here". I suppose for those, the merge-tool could interrupt and present the full message, if it doesn't already
146 2017-04-12 20:34:01	0|BlueMatt|that may help, i suppose
147 2017-04-12 20:34:05	0|BlueMatt|long prefix sucks though
148 2017-04-12 20:34:09	0|BlueMatt|scripted:
149 2017-04-12 20:34:24	0|cfields|well it could also just detect the script begin/end
150 2017-04-12 20:34:31	0|BlueMatt|but, yea, putting it in the commit title itself is probably good
151 2017-04-12 20:34:38	0|BlueMatt|no, i like jtimon's suggestion
152 2017-04-12 20:35:04	0|jtimon|yep, look at https://github.com/bitcoin/bitcoin/pull/10193 for an example (needs some squashing after completing it)
153 2017-04-12 20:36:58	0|cfields|jtimon: btw, I think you're looking for: sed -i '/#include <boost\/foreach.hpp>/d' file
154 2017-04-12 20:36:59	0|cfields|:)
155 2017-04-12 20:37:05	0|jtimon|btw, how can I do sed -i ':a;N;$!ba;s/#include <boost\/foreach.hpp>\n//' ./src/*.cpp but excluding some specific files ?
156 2017-04-12 20:43:10	0|jtimon|yeah, for qt and wallet  I have it done, but some places use BOOST_REVERSE_FOREACH so they need to maintain the include for now
157 2017-04-12 20:43:31	0|jtimon|that's why I need to exclude specific files
158 2017-04-12 20:44:30	0|sdaftuar|gmaxwell: yeah it is certainly possible i overlooked something simple
159 2017-04-12 20:44:45	0|sdaftuar|gmaxwell: but with what you describe, i don't see how you could bound the income difference?
160 2017-04-12 20:44:54	0|sdaftuar|without making assumptions about the fee distribution
161 2017-04-12 20:44:56	0|cfields|jtimon: how about just changing those to rbegin/rend iterators in a prior commit?
162 2017-04-12 20:46:11	0|jtimon|yeah, that would be another option, at first I was thinking of only removing it from qt and wallet for now, but if I can completely remove them using this, it doesn't look as disruptive as I expected
163 2017-04-12 20:46:45	0|sdaftuar|gmaxwell: one way to implement what you describe might be, fill up the first X% of the block, and if no recent transactions were chosen, then exclude recent transactions from the remainder of the block
164 2017-04-12 20:47:11	0|sdaftuar|but if fee distributions were close to flat, then you might give up a lot of income unless X is large
165 2017-04-12 20:47:17	0|jtimon|I mean, if people are ok with doing it all at once, I would prefer it
166 2017-04-12 20:51:21	0|BlueMatt|jtimon: please. kill boost
167 2017-04-12 20:52:19	0|jtimon|BlueMatt: alright, that feeback is useful
168 2017-04-12 20:52:52	0|BlueMatt|:)
169 2017-04-12 20:53:07	0|sdaftuar|gmaxwell: and conversely, i think you could also have the problem of including recent transactions too frequently -- a small high feerate transactions that was recently received should almost certainly not be included
170 2017-04-12 20:53:50	0|sdaftuar|because block reward is still high enough that it dominates
171 2017-04-12 21:28:43	0|bincap|is it possible to write a script that executes or not depending on version bits of current block? (e.g. a payment locked by activation of segwit)?
172 2017-04-12 21:28:55	0|bincap|(or of other block)
173 2017-04-12 21:38:24	0|sipa|no, transactions cannot observe what block they are in
174 2017-04-12 21:38:40	0|sipa|otherwise you couldn't validate them before being confirmed
175 2017-04-12 21:39:01	0|bincap|sipa: in previous block(s) then
176 2017-04-12 21:53:03	0|sipa|no, transactions cannot observe what block they are in
177 2017-04-12 21:57:24	0|gmaxwell|sdaftuar: income difference is bound by amount_you_will_skip times transactions.
178 2017-04-12 22:00:57	0|bincap|sipa: could they instead observe e.g. version bits of block defined in script by it's height?
179 2017-04-12 22:01:30	0|bincap|that could allow to set up some incentives for users promising to support given BIP to actually do that
180 2017-04-12 22:04:25	0|gmaxwell|sdaftuar: I agree that what you propose is more 'correct', but it is non-trivially more complex. I'm doubtful that it increases income a meaningful amount, we've also not seen miners working especially hard in increasing their work update speed.. which causes similar losses.
181 2017-04-12 22:06:20	0|jtimon|would adding something like https://gist.github.com/arvidsson/7231973 be acceptable for getting rid of BOOST_REVERSE_FOREACH ?
182 2017-04-12 22:12:44	0|sipa|bincap: transactions don't observe blocms
183 2017-04-12 22:12:53	0|sipa|transactions exist before they're in a block
184 2017-04-12 22:13:09	0|sipa|their validity is independent of what chain they are included in
185 2017-04-12 22:13:11	0|sipa|so no
186 2017-04-12 22:15:09	0|bincap|I see. I thought of something like NLockTime
187 2017-04-12 22:24:20	0|bincap|can you otherwise create now a transaction, that will be very expensive to spend without segwit, but easy with segwit? (for example some setup of creating dust transactions and collecting them in segwit)
188 2017-04-12 22:34:43	0|gmaxwell|bincap: such things would create terrible incentives to lie about your rule support. These kinds of proposals have been rehashed many times before...
189 2017-04-12 22:42:09	0|berndj|gmaxwell, i think i started this line of thinking in #bitcoin, my version was only slightly different, where the coins become redeemable by anyone (i.e. probably a miner) if SW should fail to be active
190 2017-04-12 22:42:15	0|berndj|so blame me for that :)
191 2017-04-12 23:31:46	0|sdaftuar|gmaxwell: i don't think the PR is all that complex, it may appear to be because i broke things out into lots of small commits (hopefully, to help review).  but admittedly i introduced some complexity in order to shave a few milliseconds off the runtime
192 2017-04-12 23:32:07	0|gmaxwell|sdaftuar: to confess, I didn't review it yet but you made it _sound_ complex.
193 2017-04-12 23:32:13	0|sdaftuar|gmaxwell: conceptually, i could have kept things very simple if i just ran CNB twice, once allowing recent transacitons in, and once without them
194 2017-04-12 23:32:39	0|gmaxwell|yes, but that would have pretty poor performance.
195 2017-04-12 23:32:54	0|sdaftuar|not terribly poor, if you avoided the TBV call
196 2017-04-12 23:32:59	0|sdaftuar|er, redundant TBV call
197 2017-04-12 23:33:18	0|sdaftuar|basically you would just call addPackageTxs twice... average runtime of 7-8ms
198 2017-04-12 23:33:35	0|sdaftuar|so that times two, versus the optimization i did, which gets down to about 10ms instead
199 2017-04-12 23:34:34	0|sdaftuar|i do want to save further optimization for a future PR.  but i could back out the optimization in this one, if it would aid review
200 2017-04-12 23:35:15	0|gmaxwell|Do you have a benchmark for this, that lets you measure how often it picks each option and how much fees it loses on consistent traffic?
201 2017-04-12 23:36:00	0|gmaxwell|e.g. that you could also try a braindead simple patch that just skips txn you've had less than X seconds, unless they have astronomic fees?
202 2017-04-12 23:36:13	0|sdaftuar|yeah i have simulated this a bunch.  i think with 10seconds of recency and 1% threshold, it almost never will include recent transactions.
203 2017-04-12 23:36:42	0|sdaftuar|my most recent run was with 30 seconds/0.5% threshold, and it still very rarely included recent transactions... maybe a handful of times out of more than 1000 samples
204 2017-04-12 23:37:20	0|gmaxwell|I made measurements of cross node mempool consistency a while back, but cdecker tells me that propagation has become much slower (which was intentional) so those numbers probably should be redone.
205 2017-04-12 23:39:11	0|sdaftuar|so the toggles in that model would be X (number of seconds) and fee (feerate?) threshold?
206 2017-04-12 23:39:15	0|cdecker|Yeah, TX propagation has slowed down considerably (http://bitcoinstats.com/network/propagation/), but blocks have sped up a lot
207 2017-04-12 23:39:49	0|sdaftuar|cdecker: thats great data, thanks!
208 2017-04-12 23:40:43	0|gmaxwell|(It slowed down because we unbroke trickling)
209 2017-04-12 23:43:08	0|midnightmagic|+1 unbreaking trickling