1 2016-01-07 00:09:17 <Luke-Jr> stevenrooseyes
  2 2016-01-07 00:53:05 <harding> Hey I have a BIP68 question.  If I use an nSequence of 0xfeffffff with locktime like Bitcoin Core >0.11.0 does, will that trigger relative locktime?
  3 2016-01-07 00:59:07 <stevenroose> Luke-Jr: how? I use cgminer on testnet now and it says longpolling disabled
  4 2016-01-07 01:04:32 <Luke-Jr> stevenroose: cgminer's GBT "support" is a hack and probably broken. try BFGMiner.
  5 2016-01-07 01:47:58 <maaku> harding: no
  6 2016-01-07 01:48:21 <maaku> harding: bit 0x80000000 (1 << 31) disables relative locktime
  7 2016-01-07 01:50:16 <harding> maaku: thanks!  I wanted to make sure I was understanding it correctly.
  8 2016-01-07 01:50:53 <maaku> harding: note that Bitcoin Core >0.11.0 defaults to opt-in RBF ... I'm surprised no one has mae a fuss about this
  9 2016-01-07 01:51:48 <harding> maaku: no, opt-in RBF is less than MAX-1 and Bitcoin Core is at MAX-1
 10 2016-01-07 05:48:49 <wiretap> u know a channel to get started with bitcoin?
 11 2016-01-07 05:48:58 <wiretap> sorry hello lol
 12 2016-01-07 05:51:38 <sipa> #bitcoin
 13 2016-01-07 05:52:11 <wiretap> ty!
 14 2016-01-07 05:52:26 <wiretap> nomaste
 15 2016-01-07 08:44:59 <pcx> join
 16 2016-01-07 10:12:14 <rusty> So, if I want to generate a tx using bitcoind's wallet facility, but not broadcast it yet, I need to do:  estimatefee (to decide what fee to use), getaddress (for change), getunspent, figure out what inputs from that give me sufficient funds, figure out how much to go to change, createrawtransaction then signrawtransaction?
 17 2016-01-07 10:31:00 <gijensen> rusty: that or set walletbroadcast=0 and use sendtoaddress to generate a tx
 18 2016-01-07 10:31:27 <gijensen> But I don't know how to get rid of that TX without zapwallettxes atm
 19 2016-01-07 10:33:04 <rusty> gijensen: hmm, maybe that's OK for the first cut.  It's certainly simpler!
 20 2016-01-07 10:35:24 <rusty> gijensen: hmm, there's no api to figure out if they've set walletbroadcast=0, either.
 21 2016-01-07 10:37:06 <gijensen> Oh I never thought about that. Yeah :/
 22 2016-01-07 10:37:59 <rusty> gijensen: yeah, I think I'll grep the default config location and warn if it's not set for now.
 23 2016-01-07 10:38:06 <rusty> gijensen: thanks!
 24 2016-01-07 10:38:12 <gijensen> No problem!
 25 2016-01-07 12:23:34 <JackH> would it be possible to get soft-fork introduction that does not apply to all miners and nodes? for example, if I want a soft-fork introduced between myself and my 10 buddies, and I can find 1 miner to mine it, but the rest of the network will refuse this "soft fork" feature
 26 2016-01-07 12:23:49 <JackH> is that a feature that could be added, or wont this type of sharding of features work?
 27 2016-01-07 12:28:53 <wumpus> JackH: if it's a softfork then it is allowed by current consensus by definition; softforks only narrow down allowed blocks/transactions by adding additional constraints. So sure, you and your 10 buddies can decide on some 'secret rules' that no one else will enforce, and miners will still mine blocks that don't adhere to them, so if you regirously enforce the new rules thus refuse those blocks you will get forked off the chain
 28 2016-01-07 12:29:53 <wumpus> this is why the thresholds exist, e.g. 75% to start enforcing the rules for new version blocks, 95% to only accept new version blocks
 29 2016-01-07 12:30:20 <wallet42> a soft-fork usually puts bitcoin into a "anyone-can-spend" output script. in the soft-fork the rules are stricter (eg. P2SH not only verified to hash to the output but is also executed) and after the miners voted to enable it, a block not using the strict rules becomes invalid. so anyone can steal those bitcoin you are sending between you and your 10 buddies.
 30 2016-01-07 12:30:29 <wumpus> if only one miner would go along without caring about thresholds, he'd be forked off from the rest
 31 2016-01-07 12:30:43 <JackH> yep, I follow you on this wumpus
 32 2016-01-07 12:30:46 <JackH> but, what I mean is
 33 2016-01-07 12:31:15 <JackH> say I propose a softfork, and this never gets accepted by the miners, thus it never reaches consensus
 34 2016-01-07 12:32:00 <wumpus> then it failed and you should probably abandon it, as wallet42 says, others are free to ignore your new rules
 35 2016-01-07 12:32:13 <wallet42> in that case your bitcoins aren't safe because the majority of the network does not agree to the new rules
 36 2016-01-07 12:32:46 <JackH> hmm I have to think a bit more about how I wanted to explain this
 37 2016-01-07 13:34:35 <btcdrak> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012195.html
 38 2016-01-07 13:37:06 <jonasschnelli> Nice work sipa, CodeShark, morcos, jl2012!
 39 2016-01-07 14:07:44 <wumpus> woohoo!
 40 2016-01-07 14:08:30 <wumpus> doesn't it need steps on how to connect to the segwit testnet?
 41 2016-01-07 14:09:21 <wumpus> (e.g. at least until it has a DNS seed it needs manual connect=, right?)
 42 2016-01-07 14:15:55 <wumpus> my node still only has 3 connections
 43 2016-01-07 14:27:09 <btcdrak> bitcoind -segnet -daemon -addnode=46.101.235.82:28333;
 44 2016-01-07 15:01:35 <wumpus> yea I know :) but I mean for people on the mailing list
 45 2016-01-07 16:38:38 <jonasschnelli> ^^ connected to 4 segnet nodes.
 46 2016-01-07 17:17:46 <btcdrak> Luke-Jr: BIP100 was never submitted as a PR to bips afaik,
 47 2016-01-07 17:20:51 <BlindSeer> do you guys do tech support here or no
 48 2016-01-07 17:20:51 <Luke-Jr> is Chris Priest here? his Uni's mail server is broken/bouncing..
 49 2016-01-07 17:20:57 <Luke-Jr> BlindSeer: no, that's in #Bitcoin
 50 2016-01-07 17:21:00 <BlindSeer> ok
 51 2016-01-07 18:27:20 <Chris_Stewart_5> Inside of script.cpp why are we using negative integers to find elements in the stack
 52 2016-01-07 18:27:22 <Chris_Stewart_5> i.e.
 53 2016-01-07 18:27:30 <Chris_Stewart_5> stacktop(-1)
 54 2016-01-07 18:27:48 <sipa> Chris_Stewart_5: ask satoshi :)
 55 2016-01-07 18:28:05 <Chris_Stewart_5> sipa: brb
 56 2016-01-07 18:28:15 <Chris_Stewart_5> ok he said it was to confuse noobs like me :-)
 57 2016-01-07 18:28:54 <Chris_Stewart_5> is stacktop(-1) the same thing as stacktop.pop()?
 58 2016-01-07 18:29:05 <sipa> (that's an annoying answer, i'm aware, but it's correct: there is no reason to change perfectly functional consensus-critical code, so the reason why things are as they are is the same as the reason why they were done in the first place, which we don't know)
 59 2016-01-07 18:31:10 <Chris_Stewart_5> sipa: the bullet is going to have to be bit as some point though, won't it? Obviously not today or within the next year but something like this needs to be done at some point. Test beds like sidechains seem to make this more likely as well
 60 2016-01-07 18:33:24 <sipa> what bullet?
 61 2016-01-07 18:33:40 <sipa> it's perfectly functional code
 62 2016-01-07 18:35:07 <Chris_Stewart_5> Isn't that a dangerous thing to say though? Essentially, "the code works, why should it be improved?"
 63 2016-01-07 18:35:36 <wallet42> welcome to consensus critical code :-)
 64 2016-01-07 18:35:49 <MarcoFalke> Would adding a comment help?
 65 2016-01-07 18:36:01 <BlueMatt> -> #bitcoin-core-dev
 66 2016-01-07 18:36:16 <Chris_Stewart_5> wallet42: haha yes, I guess that is the arguement at hand.
 67 2016-01-07 18:57:34 <sipa> jonasschnelli: we are likely going to reset the chain soonish, though
 68 2016-01-07 18:58:23 <jonasschnelli> sipa: okay,.. reset = new genesis?
 69 2016-01-07 18:58:42 <sipa> yeah
 70 2016-01-07 18:59:52 <wumpus> meeting start time?
 71 2016-01-07 19:00:10 <jonasschnelli> yes
 72 2016-01-07 19:00:19 <lightningbot`> Meeting started Thu Jan  7 19:00:19 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 73 2016-01-07 19:00:19 <lightningbot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
 74 2016-01-07 19:00:19 <wumpus> #startmeeting
 75 2016-01-07 19:00:21 <sipa> oh!
 76 2016-01-07 19:00:57 <jonasschnelli> any topics?
 77 2016-01-07 19:01:01 <wumpus> topic: anything still needs to be merged before 0.12.0rc1?
 78 2016-01-07 19:01:07 <MarcoFalke> the wallet stuff
 79 2016-01-07 19:01:18 <wumpus> yeah besides what already has 0.12 milestone
 80 2016-01-07 19:01:56 <wumpus> oh, probably not be a busy meeting then
 81 2016-01-07 19:01:57 <Luke-Jr> >_<
 82 2016-01-07 19:02:27 <jonasschnelli> 0.12.0rc needs some more infos in the release notes
 83 2016-01-07 19:02:28 <Luke-Jr> https://github.com/bitcoin/bitcoin/pull/7151 for 0.12.0 <.<
 84 2016-01-07 19:02:29 <morcos> wumpus: you didn't add #7312 to 0.12 milestone.  i guess there is disagreement
 85 2016-01-07 19:02:43 <Luke-Jr> https://github.com/bitcoin/bitcoin/pull/7149 is a bugfix for 0.12.0 also
 86 2016-01-07 19:02:46 <morcos> but i feel pretty strongly that releasing 0.12 as is, is pretty bad
 87 2016-01-07 19:03:01 <cfields> wumpus: if i work out a quick fix for #7098, ok for 0.12 ?
 88 2016-01-07 19:03:16 <MarcoFalke> jonas, I have a pull open for the release notes.
 89 2016-01-07 19:03:28 <MarcoFalke> Maybe someone can do the rbf part
 90 2016-01-07 19:03:30 <jonasschnelli> MarcoFalke: yes. But some things are missing.
 91 2016-01-07 19:03:48 <MarcoFalke> and morcos the txconfirmtarget part?
 92 2016-01-07 19:03:52 <wumpus> cfields: well I do intend to release rc1 tomorrow, so this was kind of a last minute call
 93 2016-01-07 19:03:58 <jonasschnelli> missed: wallet+prune, setban/banlist
 94 2016-01-07 19:04:02 <jonasschnelli> *misses
 95 2016-01-07 19:04:04 <cfields> ok
 96 2016-01-07 19:04:31 <jonasschnelli> 7312 is nice,.. but not urgent for 0.12 IMO.
 97 2016-01-07 19:04:31 <wumpus> #action look at #7151 #7149 #7312 for 0.12
 98 2016-01-07 19:05:08 <sdaftuar> i think 7312 is a bugfix?  not being able to spend coins after mempool eviction seems like a bad regression
 99 2016-01-07 19:05:10 <wumpus> 7312 is a feature, too late for 0.12.0 I'd think
100 2016-01-07 19:05:27 <sdaftuar> (i still need to review it)
101 2016-01-07 19:05:36 <Luke-Jr> sdaftuar: it has always been true that transactions with too little fee get stuck
102 2016-01-07 19:05:55 <wumpus> if it adds new strings or new RPC functionality that's really hard to put under the bugfix umbrella
103 2016-01-07 19:05:56 <Luke-Jr> … until they gain sufficient priority, at least
104 2016-01-07 19:05:57 <sdaftuar> previously those tx's could eventually get mined though
105 2016-01-07 19:06:02 <Luke-Jr> which may not work anymore in 0.12
106 2016-01-07 19:06:20 <Luke-Jr> sdaftuar: they can still eventually get mined
107 2016-01-07 19:06:26 <wumpus> cfields: but this is only rc1, it's quite certain we'll have a rc2, so still worth working on
108 2016-01-07 19:06:32 <Luke-Jr> sdaftuar: just your local node will fail to broadcast them, which I agree is a bug..
109 2016-01-07 19:06:51 <morcos> wumpus: the situation for 0.12 will be significantly worse with respect to stuck txs than prior releases
110 2016-01-07 19:06:53 <cfields> wumpus: ok, will do
111 2016-01-07 19:07:14 <morcos> in prior releases, txs were eventually mined because the network didn't forget them
112 2016-01-07 19:07:17 <Luke-Jr> morcos: abandontransaction is IMO not a solution to that though
113 2016-01-07 19:07:28 <Luke-Jr> it does not guarantee the transaction won't get mined
114 2016-01-07 19:07:36 <morcos> or if they were not in your mempool for some other reason, like you never broadcast them, then they didn't tie up inputs (this is a NEW change)
115 2016-01-07 19:07:39 <sipa> do we currently rebroadcast a txn that is not accepted to our mempool?
116 2016-01-07 19:07:41 <jonasschnelli> morcos: but due to the smartfee (+GUI) changes stuck tx should happen really rare? not?
117 2016-01-07 19:07:44 <Luke-Jr> which means people will easily be tricked into double-sends
118 2016-01-07 19:07:45 <wumpus> morcos: I agree it's worse, but I' not sure what to do about that on such short notice
119 2016-01-07 19:07:47 <Luke-Jr> far worse than stuck
120 2016-01-07 19:08:09 <Luke-Jr> sipa: I don't think so, but that would be a quick hack that would work I think
121 2016-01-07 19:08:25 <morcos> also in 0.11, you could probably trick your node to start up with a high relay fee so the tx wouldn't be in yhour mempool any more if it was just taking a long time to mine, and then respend it
122 2016-01-07 19:08:28 <sipa> i think that's a bad position to be in
123 2016-01-07 19:08:44 <morcos> the only solution discussed for 0.12, is -zapwallettxes which sounds crazy to me
124 2016-01-07 19:08:46 <sipa> as it relies on the rest of the world using a policy you're not following yourself
125 2016-01-07 19:08:52 <sipa> agree with morcos
126 2016-01-07 19:08:55 <Luke-Jr> how about adding local priority to wallet transactions so they never get pruned?
127 2016-01-07 19:09:07 <wumpus> yes, -zapwallettxes is crazy
128 2016-01-07 19:09:09 <sipa> Luke-Jr: privacy leak
129 2016-01-07 19:09:18 <jonasschnelli> Luke-Jr: yes, open fingerprintig attacks
130 2016-01-07 19:09:20 <wumpus> so, you want to postpone rc1 then?
131 2016-01-07 19:09:22 <Luke-Jr> sipa: any solution is a privacy leak?
132 2016-01-07 19:09:36 <sipa> Luke-Jr: abandontransaction is not a privacy leak
133 2016-01-07 19:09:39 <jonasschnelli> call mempool p2p message and compare
134 2016-01-07 19:09:49 <Luke-Jr> abandontransaction is *worse* than a privacy leak..
135 2016-01-07 19:09:50 <sipa> a GUI way to do "respend with higher fee" is even better
136 2016-01-07 19:09:50 <wumpus> mempool p2p message is a privacy leak :(
137 2016-01-07 19:09:55 <morcos> sipa: i think jonasschnelli is right that there will not be too many txs that are not accepted to the mempool in the first place, but more txs that are evicted.
138 2016-01-07 19:10:01 <Luke-Jr> sipa: +1
139 2016-01-07 19:10:55 <Luke-Jr> IMO the rare stuck transactions are still rare enough to not be a blocker for 0.12.0
140 2016-01-07 19:11:07 <jonasschnelli> I think a GUI fix that would re-broadcast the tx would be trivial... but respend with height fees might included some UX changes.
141 2016-01-07 19:11:16 <morcos> yes there are a lot of options to improve this that will have to wait for 0.13
142 2016-01-07 19:11:16 <wumpus> that's much nicer, but not realistic for 0.12, we need something that can be written ,tested and reviwed on short notice. abandontransaction could be such if everyone focuses on it I guess.
143 2016-01-07 19:11:28 <Luke-Jr> we can add a respend option in 0.12.1 or something
144 2016-01-07 19:11:35 <sipa> agree
145 2016-01-07 19:11:37 <morcos> but #7312 as is should be reviewable and mergeable quickly
146 2016-01-07 19:11:46 <Luke-Jr> morcos: but it creates worse problems
147 2016-01-07 19:11:53 <morcos> its a manual operation
148 2016-01-07 19:11:59 <morcos> if you don't use it, it doesn't create any problems
149 2016-01-07 19:12:06 <Luke-Jr> …
150 2016-01-07 19:12:13 <jonasschnelli> morcos: but won't help the people that have stuck tx... they are mostly GUI users i guess.
151 2016-01-07 19:12:20 <wumpus> morcos: right
152 2016-01-07 19:12:22 <morcos> if you want to put a big fat "WARNING: this may cause non opt-in double spends!" thats fine by me
153 2016-01-07 19:12:32 <Luke-Jr> morcos: we intentionally make dumping private keys hard, and people STILL do it.
154 2016-01-07 19:12:37 <Luke-Jr> morcos: that's not the problem
155 2016-01-07 19:12:49 <morcos> jonasschnelli: but when they are asking on #bitcoin, we can tell them to type something into their debug console to clear their tx
156 2016-01-07 19:12:52 <wumpus> well the GUI could also add a "abandon transaction" in the tx dropdown
157 2016-01-07 19:13:05 <Luke-Jr> they will abandon a payment to Fred, then resend it to Fred with a higher fee and the wallet will use different inputs
158 2016-01-07 19:13:07 <morcos> i just tried to rush out the bare bones functionality
159 2016-01-07 19:13:09 <Luke-Jr> Fred will bribe a miner to mine both
160 2016-01-07 19:13:11 <wumpus> not sure that's a good idea but heh...
161 2016-01-07 19:13:14 <jonasschnelli> morcos: yes. almost as quick as tell them to use -zapwallettxes... but i agree, thats worse.
162 2016-01-07 19:13:18 <wumpus> and that will add strings so definitely not for 0.12.0
163 2016-01-07 19:13:19 <morcos> it is really annoyingly difficult to deal with stuck txs without this
164 2016-01-07 19:13:21 <Luke-Jr> and Fred now has 2x the intended payment
165 2016-01-07 19:13:25 <sdaftuar> Luke-Jr: it can only be used on not-in-mempool transactions i think
166 2016-01-07 19:13:41 <Luke-Jr> sdaftuar: not-in-YOUR-mempool does not mean someone else does not have it
167 2016-01-07 19:13:54 <Luke-Jr> sdaftuar: if it was NEVER broadcast, it wouldn't have been completed in the first place
168 2016-01-07 19:14:38 <morcos> Luke-Jr: if could be never broadcast due to fee estimation error, or due to have broadcast off
169 2016-01-07 19:14:40 <Luke-Jr> making it possible for Fred to receive 2x payment is far worse than stuck transactions; and I suspect will become far more common than the rare stuck txs would have been
170 2016-01-07 19:15:05 <Luke-Jr> morcos: the former case, will prevent the tx from ever being completed in the wallet
171 2016-01-07 19:15:15 <morcos> Fred can just as easily tell people to send the tx twice and say that the old one is stuck now, what difference is there
172 2016-01-07 19:15:24 <morcos> Luke-Jr: no it wont
173 2016-01-07 19:15:39 <Luke-Jr> morcos: the difference is Fred has a much more convincing case if the user is told to abandon the old one
174 2016-01-07 19:15:51 <Luke-Jr> morcos: it should!
175 2016-01-07 19:15:54 <wumpus> ok... let's discuss this outside the meeting, I think it's clear what pulls still need to be looked at...  any other topics?
176 2016-01-07 19:15:56 <Luke-Jr> pretty sure it has in the past
177 2016-01-07 19:15:59 <Luke-Jr> k
178 2016-01-07 19:16:01 <jonasschnelli> Should't time be involved in abandoning txes? A min delay?
179 2016-01-07 19:16:12 <wumpus> sounds like overdesign to me
180 2016-01-07 19:16:22 <jonasschnelli> hmm..
181 2016-01-07 19:16:27 <Luke-Jr> next topic: BIPs not in bitcoin/bips need to be told to me
182 2016-01-07 19:16:36 <morcos> We can hide the rpc and/or make a more stern warning
183 2016-01-07 19:16:37 <wumpus> this is meant to be a quick, advanced fix for people messing up transactions
184 2016-01-07 19:16:46 <morcos> but not having the functionality is just risking a problem imo
185 2016-01-07 19:16:52 <morcos> we agreed to put this in back in november
186 2016-01-07 19:16:58 <wumpus> #topic Luke-jr new BIP editor
187 2016-01-07 19:17:07 <wumpus> morcos: agree
188 2016-01-07 19:17:21 <Luke-Jr> morcos: hidden RPC is maybe okay
189 2016-01-07 19:17:31 <Luke-Jr> morcos: I thought we were talking about GUI exposed somehow
190 2016-01-07 19:17:44 <wumpus> no, no, this is not GUI, just a RPC pull
191 2016-01-07 19:18:06 <jonasschnelli> GUI's def. to late.. ok: #topic Luke-jr new BIP editor
192 2016-01-07 19:18:15 <petertodd> ACK!
193 2016-01-07 19:18:18 <jonasschnelli> what's the reason for gmaxwells step back?
194 2016-01-07 19:18:34 <jonasschnelli> (but maybe this is not the topic)
195 2016-01-07 19:18:38 <wumpus> jonasschnelli: I don't think we need to discuss that publically, you can ask him
196 2016-01-07 19:18:51 <jonasschnelli> Right.
197 2016-01-07 19:18:52 <morcos> i think there are no objections to Luke-Jr being bip editor, especially given gmaxwell asked him
198 2016-01-07 19:19:02 <Luke-Jr> I don't know, and don't think we should pry into gmaxwell's private reasons in a meeting.
199 2016-01-07 19:19:06 <wumpus> right
200 2016-01-07 19:19:13 <petertodd> yeah, why gmaxwell doesn't want to do it isn't relevant to how good Luke-Jr will be
201 2016-01-07 19:19:32 <petertodd> and Luke's email to the list earlier is good evidence he'll do a good job
202 2016-01-07 19:19:48 <wumpus> he's been active with the repository at least
203 2016-01-07 19:20:09 <Luke-Jr> so far I haven't had any emails on missing BIP assignments, although it's only been an hour or two
204 2016-01-07 19:20:37 <wumpus> what do you mean with "BIPs not in bitcoin/bips"? are there BIPs somewhere else?
205 2016-01-07 19:20:51 <Luke-Jr> wumpus: there are assignments with no draft in the repo, I suspect
206 2016-01-07 19:20:54 <wumpus> yes, now the difficult task of allocating numbers falls to you
207 2016-01-07 19:21:30 <MarcoFalke> BIP100 is not in bitcoin/bips
208 2016-01-07 19:22:01 <wumpus> first priority regarding number assignment is probably the segwit BIP
209 2016-01-07 19:22:05 <petertodd> MarcoFalke: do we know if BIP100 was ever officially assigned?
210 2016-01-07 19:22:20 <sipa> it was not
211 2016-01-07 19:22:32 <MarcoFalke> You can't "unassign" it now
212 2016-01-07 19:22:47 <sipa> agree
213 2016-01-07 19:22:47 <wumpus> well at least you can't allocate anything else to it anymore
214 2016-01-07 19:23:21 <petertodd> pity leaving it off the index will be taken politically
215 2016-01-07 19:23:32 <Luke-Jr> I'll give people 24 hours to notify me of missing assignments, then I'll get to some priority ones (like BIP 100 and segwit) and wait a little more to go through the rest of the pending ones
216 2016-01-07 19:23:42 <wumpus> there's no strong need to leave it off the index
217 2016-01-07 19:23:51 <morcos> suggested topic: more detailed roadmap for next few major projects
218 2016-01-07 19:24:10 <wumpus> though it should be clear that people should not self-assign numbers, gmaxwell by definition assigned a different number if people claimed their own
219 2016-01-07 19:24:23 <Luke-Jr> does jgarzik's bips repo have a current BIP 100 draft I can PR?
220 2016-01-07 19:24:31 <MarcoFalke> yes
221 2016-01-07 19:24:37 <jgarzik> on a branch
222 2016-01-07 19:24:39 <Luke-Jr> wumpus: I'll give "202" a different number for that..
223 2016-01-07 19:24:43 <wumpus> but it's too late to do that for bip100
224 2016-01-07 19:24:45 <Luke-Jr> jgarzik: can you PR it? ;)
225 2016-01-07 19:24:48 <wumpus> right
226 2016-01-07 19:24:50 <jgarzik> Luke-Jr, sure
227 2016-01-07 19:24:51 <petertodd> Luke-Jr: ack on 202
228 2016-01-07 19:25:35 <jgarzik> Luke-Jr, with "202", I tried to do a new method of (1) put in drafts/ dir with no number assigned, (2) have BIP editor move-and-assign-num-and-update-index
229 2016-01-07 19:25:47 <jgarzik> to respond to self-assignment complaints
230 2016-01-07 19:25:49 <Luke-Jr> jgarzik: thanks; that sounds reasonable
231 2016-01-07 19:26:39 <petertodd> re: detailed plans, is everyone aware of my segwit previous block proof? I don't think there are any outstanding objections to it if it's structured as a tree for the sake of fraud proofs
232 2016-01-07 19:26:51 <wumpus> #topic  more detailed roadmap for next few major projects
233 2016-01-07 19:27:49 <morcos> thanks, i just wanted to make a request for a bit of direction (like your response to gmaxwell's email) on what sort of timelines are and order of implemntation of various work: segwit, versionbits (if its still happening), BIP 68,112,113
234 2016-01-07 19:28:11 <morcos> And other major features we might want for 0.13, such as RBF functionality in the wallet?
235 2016-01-07 19:28:35 <petertodd> morcos: anyone willing to work on RBF wallet functionality?
236 2016-01-07 19:28:35 <wumpus> would be best to ask the people working on those
237 2016-01-07 19:28:37 <morcos> Seems like we have a lot of things on our plate and having some concentration of effort on various things might be helpful
238 2016-01-07 19:28:50 <Luke-Jr> morcos: for fee bumping at least
239 2016-01-07 19:28:56 <jonasschnelli> petertodd: I will work on the RBF features for the wallet.
240 2016-01-07 19:29:08 <wumpus> nice jonasschnelli!
241 2016-01-07 19:29:11 <petertodd> jonasschnelli: great, thanks! feel free to ask me any questions
242 2016-01-07 19:29:12 <sipa> good
243 2016-01-07 19:29:33 <sipa> i apologize for pretty absent lately
244 2016-01-07 19:29:38 <Luke-Jr> jonasschnelli: keep in mind some merchants explicitly plan to *reject* RBF-optin transactions
245 2016-01-07 19:29:50 <morcos> wumpus: i was thinking that perhaps you, sipa, and gmaxwell might have a list of goals for 0.13 , we could obviously give feedback.  but i'm willing to work on many of those things but would appreciate knowing where the effort is requested.
246 2016-01-07 19:29:57 <Luke-Jr> jonasschnelli: so you may need to implement a "disable RBF for this tx and retry" logic
247 2016-01-07 19:30:08 <morcos> or not just for 0.13 as there will be SF's before then?
248 2016-01-07 19:30:11 <wumpus> well you made great progress on segwit sipa
249 2016-01-07 19:30:28 <sipa> wumpus: thanks, but other things can't be put on hold either
250 2016-01-07 19:30:33 <jonasschnelli> Luke-Jr: Yes. We need to focus that. And wisely choose the default.
251 2016-01-07 19:30:34 <petertodd> Luke-Jr: I'd be inclined to wait and see on that; solution may be to just turn the bit off, with logic otherwise unchanged
252 2016-01-07 19:30:49 <Luke-Jr> jonasschnelli: default IMO should be to attempt RBF, and if rejected, retry without it ;)
253 2016-01-07 19:31:01 <cfields> i'm planning to post an rfc for a network stack overhaul in the next week or so as well, i realize it's getting a bit late for that
254 2016-01-07 19:31:14 <petertodd> sipa: you you planning on working on segwit relative to the v0.12 branch, or v0.13?
255 2016-01-07 19:31:23 <sipa> petertodd: 0.12
256 2016-01-07 19:31:31 <Luke-Jr> jonasschnelli: otoh, BIP70 txs already imply the merchant is responsible for getting it mined, so maybe RBF is less important there
257 2016-01-07 19:31:31 <petertodd> sipa: ok good, that's probably faster
258 2016-01-07 19:31:34 <sipa> i should stop rebasing on master
259 2016-01-07 19:31:35 <morcos> cfields: perfect example.  it would be nice to know when we should all spend time looking at that, so we can get it in and merged
260 2016-01-07 19:31:55 <wumpus> sipa: may be better to rebase on 0.12 branch then :)
261 2016-01-07 19:32:09 <sipa> wumpus: yes, will do soon
262 2016-01-07 19:32:15 <cfields> morcos: yup. i've held off on requesting review so far. i'll begin that very soon.
263 2016-01-07 19:32:26 <jonasschnelli> cfields: nice. And sorry,... I still own you some reviews of the current code.
264 2016-01-07 19:32:37 <Luke-Jr> anything based on 3cd836c1d855b92e7c73ab31979f471c4f8dad68 should merge into 0.12 and master
265 2016-01-07 19:32:40 <sipa> i think our choice of efforts for working towards consensus changes is independent from releases
266 2016-01-07 19:32:55 <cfields> jonasschnelli: nah, i just poked you for an idea, wasn't looking for review yet
267 2016-01-07 19:33:18 <jonasschnelli> Okay. Poke me again if it's time...
268 2016-01-07 19:33:32 <cfields> will do, thanks
269 2016-01-07 19:33:47 <morcos> sipa: sure.  i just mean an overall game plan.  for instance i reviewed versionbits, found a bug, got no feedback, and now am not sure we're even doing versionbits.  thats fine, things change.  but it would be nice if other people knew that maybe they shouldn't go review versionbits right now
270 2016-01-07 19:33:51 <Luke-Jr> gotta run, bbiab
271 2016-01-07 19:34:13 <wumpus> but yes it makes sense to make a list of goals for 0.13, although as the releases are time-based it's conditional on things being ready on time
272 2016-01-07 19:34:18 <sipa> ok, i think bip9 is moved a bit back in priority
273 2016-01-07 19:34:38 <morcos> sipa: yes thats all i'm saying a bit more communication on priorities
274 2016-01-07 19:34:56 <sipa> agree with that choice?
275 2016-01-07 19:34:57 <jonasschnelli> agree with morcos. A clear plan could result in investing resources into the right parts.
276 2016-01-07 19:35:49 <petertodd> morcos: whether or not we definitely need versionbits will depend on whether or not there is a competing fork on the network
277 2016-01-07 19:36:00 <morcos> sipa: sure. more like no objection. there are many plans that are all good plans.  having one of them though is better than not.
278 2016-01-07 19:36:09 <wumpus> well I suggest that everyone that is working on something that they plan to have finished for 0.13 sends me proposals, I can merge it into a plan
279 2016-01-07 19:36:28 <morcos> +1
280 2016-01-07 19:36:28 <petertodd> morcos: also, in that case, we can do my pseudo-versionbits with very little code
281 2016-01-07 19:37:49 <btcdrak> petertodd: there are currently two implementations of version bits. one by codeshark and one by rusty
282 2016-01-07 19:38:00 <sipa> and neither is maintaines at this point
283 2016-01-07 19:38:11 <sipa> afaik
284 2016-01-07 19:38:16 <petertodd> btcdrak: I know, I just mean, if we're in a position where we need it ASAP and the actual versionbits isn't production quality
285 2016-01-07 19:38:48 <petertodd> btcdrak: my version is about two lines of code, at the cost of theoretically being a hardfork in cases where the fork fails
286 2016-01-07 19:40:14 <Luke-Jr> pfft freenode
287 2016-01-07 19:40:24 <wumpus> I think we've drifted off topic a bit. versionbits as new topic? or something else?
288 2016-01-07 19:40:27 <sipa> there is a moral obligation to have VB or something with similar functionality available
289 2016-01-07 19:40:43 <wumpus> #topic versionbits (BIP9)
290 2016-01-07 19:40:51 <morcos> sipa:  there is?  or is that a question?
291 2016-01-07 19:41:13 <morcos> sorry, i read "objection"
292 2016-01-07 19:41:18 <sdaftuar> sipa: agreed
293 2016-01-07 19:41:24 <Luke-Jr> "Pieter Wuille proposes a moral requirement to rewrite Bitcoin in Visual Basic."
294 2016-01-07 19:41:41 <wumpus> heh
295 2016-01-07 19:41:43 <cfields> haha
296 2016-01-07 19:41:46 <sipa> hahaha
297 2016-01-07 19:42:14 <Luke-Jr> gotta go back to VB 4.0 for that I think
298 2016-01-07 19:42:21 <sipa> back to topic?
299 2016-01-07 19:42:23 <btcdrak> urgh, is there a freenode netsplit going on atm?
300 2016-01-07 19:42:24 <Luke-Jr> sorry
301 2016-01-07 19:43:05 <sipa> i think there are a few long-lasting things that need a scheduled time to do: consensus refactoring (just moving things to one directory is already a great step)
302 2016-01-07 19:43:09 <sipa> another is c++11
303 2016-01-07 19:43:11 <wumpus> agree as well that something like versionbits is "a moral obligation", but indeed not the first priority
304 2016-01-07 19:43:15 <sipa> another is clang-format
305 2016-01-07 19:43:23 <petertodd> anyway, I agree that versionbits is a moral requirement, but we also have a moral requirement to release code that works and is well-tested
306 2016-01-07 19:43:23 <wumpus> bleh clang-format
307 2016-01-07 19:43:33 <jonasschnelli> +1 for c+11, -1 for clang format
308 2016-01-07 19:43:41 <sipa> ok, good to hear
309 2016-01-07 19:43:51 <jonasschnelli> it's just not worth it.
310 2016-01-07 19:43:55 <wumpus> but yes, jtimon's libconsensus refactoring and c++11 would be nice to do for 0.13
311 2016-01-07 19:44:01 <sipa> but people still have an epectation that clang-format wilk happen at some point
312 2016-01-07 19:44:04 <jonasschnelli> MarcoFalkes git diff format script should be recommended.
313 2016-01-07 19:44:11 <morcos> if there is a spell checker, i could use that so i stop getting so many comment fixups to my pulls.
314 2016-01-07 19:44:19 <sipa> we need to communicate that it will not happen then
315 2016-01-07 19:44:34 <wumpus> morcos: there's a way to run spellcheck on your source code and it will check only comments I think
316 2016-01-07 19:44:41 <Luke-Jr> if we're going to begin using C++11 in 0.13, then I think we should have configure use C++11 to compile 0.12 by default (and fail loudly if unavailable)
317 2016-01-07 19:44:58 <wumpus> don't know exctly how though :-)
318 2016-01-07 19:45:04 <Luke-Jr> because once we start actually /using/ C++11, it will be difficult to go back
319 2016-01-07 19:45:20 <cfields> Luke-Jr: that's not a bad idea.
320 2016-01-07 19:45:24 <sipa> Luke-Jr: weak nak; i suggest compiling masting in both c++11 and c++03 in master now
321 2016-01-07 19:45:33 <sipa> *compiling
322 2016-01-07 19:45:42 <wumpus> I think we should just make the decision to use c++11
323 2016-01-07 19:45:53 <Luke-Jr> sipa: that's fine, as long as C++11 isn't required for 0.13
324 2016-01-07 19:45:53 <wumpus> there's no way to go back, and that's ok
325 2016-01-07 19:46:04 <jonasschnelli> how is c++11 related to a full remove of boost?
326 2016-01-07 19:46:13 <cfields> wumpus: i believe Luke-Jr was talking about backporting
327 2016-01-07 19:46:17 <sipa> cfields: after your PR, does c++11 compile?
328 2016-01-07 19:46:18 <Luke-Jr> wumpus: that's okay, IF it actually is workable. which is far from clear.
329 2016-01-07 19:46:23 <wumpus> jonasschnelli: c++11 takes over some parts that boost is now used for
330 2016-01-07 19:46:31 <sipa> are we _ready_ with c++ for gitian/depends/...?
331 2016-01-07 19:46:52 <wumpus> travis still needs a c++11 compiler
332 2016-01-07 19:47:00 <cfields> sipa: yes. from my tests, all platforms compile bitcoin 100% now.
333 2016-01-07 19:47:09 <cfields> sipa: still need to do depends, yes. i have that patch ready
334 2016-01-07 19:47:23 <Luke-Jr> Users running the latest stable versions of major distros should not need to use depends/ to compile working dynamic binaries.
335 2016-01-07 19:47:32 <cfields> yes, was working on getting travis in shape first. looking at options. looks like the easiest it just to install an updated gcc :\
336 2016-01-07 19:47:42 <sipa> ugh
337 2016-01-07 19:47:46 <droark> sipa: Armory used some C++11 code with Gitian and worked fine. I don't think the Core codebase needs to make Gitian-specific changes.
338 2016-01-07 19:47:48 <wumpus> travis still can't do a newer distro?
339 2016-01-07 19:47:52 <cfields> Luke-Jr: they don't. works with system libs
340 2016-01-07 19:48:02 <morcos> cfields: that should be new Travis success message "all platforms compile bitcoin 100%"
341 2016-01-07 19:48:04 <cfields> wumpus: yes, but not with caching
342 2016-01-07 19:48:10 <jonasschnelli> travis can use docker
343 2016-01-07 19:48:15 <cfields> jonasschnelli: ^^
344 2016-01-07 19:48:18 <wumpus> cfields: bleh :/
345 2016-01-07 19:48:21 <sipa> well, the first point is we need travis to build *something* in c++11
346 2016-01-07 19:48:37 <jonasschnelli> one of my bitcoin-core clone projects is now using c++11 with travis and gitian: https://github.com/digitalbitbox/dbb-app/blob/master/.travis.yml
347 2016-01-07 19:48:40 <Luke-Jr> cfields: GCC 4.x at least has serious ABI problems that suggest that is unlikely.. and last I checked, I couldn't even compile Bitcoin Core with C++11
348 2016-01-07 19:48:40 <wumpus> without caching it'd be useless, building depends every time
349 2016-01-07 19:48:43 <cfields> i can have travis updated today using gcc 4.8, same as release builds
350 2016-01-07 19:48:44 <sipa> once that is done and merged, i am fine with deciding whether to full switch or not
351 2016-01-07 19:48:49 <wumpus> cfields: SGTM
352 2016-01-07 19:49:06 <sipa> #action cfields enables c++11 build in travis
353 2016-01-07 19:49:09 <cfields> Luke-Jr: see master as of ~12h ago
354 2016-01-07 19:49:37 <Luke-Jr> cfields: cool, will try
355 2016-01-07 19:50:09 <cfields> Luke-Jr: please report any build issues. i tried to ensure that any local setup will work
356 2016-01-07 19:50:44 <Luke-Jr> cfields: report on github, or IRC?
357 2016-01-07 19:50:47 <cfields> morcos: you can add that to the success message :)
358 2016-01-07 19:51:18 <Luke-Jr> httpserver.cpp:255:36: warning: ‘auto_ptr’ is deprecated (declared at /usr/lib/gcc/i686-pc-linux-gnu/4.8.5/include/g++-v4/backward/auto_ptr.h:87) [-Wdeprecated-declarations]
359 2016-01-07 19:51:24 <cfields> Luke-Jr: #7302 would be good, for posterity
360 2016-01-07 19:51:51 <wumpus> Luke-Jr: ignore that just a warning, we can't replace that without breaking c++03 compat
361 2016-01-07 19:52:00 <sipa> Luke-Jr: it is a harmless warning; unique_ptr is compatible with auto_ptr's interface, but suoerior
362 2016-01-07 19:52:07 <cfields> Luke-Jr: deprecated in c++11, but not removed. auto_ptr -> unique_ptr will be one of the first changes after c++11 is enabled
363 2016-01-07 19:52:09 <Luke-Jr> makes sense
364 2016-01-07 19:52:16 <Luke-Jr> /usr/include/boost/thread/future_error_code.hpp:36:53: error: ‘enum_type’ is not a member of ‘boost::future_errc’
365 2016-01-07 19:52:17 <wumpus> but that gets too detailed, any other topics for the meeting?
366 2016-01-07 19:52:22 <Luke-Jr> maybe my system boost at fault though
367 2016-01-07 19:52:35 <Luke-Jr> will move this to -core-dev
368 2016-01-07 19:52:38 <wumpus> whow, future_error_code
369 2016-01-07 19:53:08 <sipa> small status update: segnet will do a backwark incompatible change soon, to change the commitment structure; after that, first priority is getting mining code to work with it
370 2016-01-07 19:53:16 <cfields> can we get a very quick/general segwit status update. i've seen a few things flying around
371 2016-01-07 19:53:27 <cfields> heh, thanks :)
372 2016-01-07 19:53:27 <sipa> cfields: ^
373 2016-01-07 19:53:28 <wumpus> #topic segwit status update
374 2016-01-07 19:53:42 <CodeShark> segnet has been up since dec 31
375 2016-01-07 19:53:51 <Luke-Jr> sipa: still working on that
376 2016-01-07 19:53:54 <sipa> i will also produce a separate branch with just consensus changes
377 2016-01-07 19:54:25 <sipa> which could be perhaos backportable further back than 0.12
378 2016-01-07 19:55:23 <sipa> jtimon: what is the advantage over using 0.12?
379 2016-01-07 19:55:32 <sipa> ah, 0.12 is still moving
380 2016-01-07 19:55:41 <sipa> ok, will rebase on that
381 2016-01-07 19:55:44 <Luke-Jr> sipa: 0.12 won't merge into master nicely
382 2016-01-07 19:55:48 <wumpus> yes, 0.12 is still moving
383 2016-01-07 19:55:54 <sipa> jtimon: ack
384 2016-01-07 19:56:41 <sipa> 4 min
385 2016-01-07 19:56:57 <btcdrak> sipa: nothing more on segwit?
386 2016-01-07 19:57:18 <CodeShark> it works? :)
387 2016-01-07 19:57:48 <jonasschnelli> hah
388 2016-01-07 19:58:27 <Luke-Jr> meeting over then?
389 2016-01-07 19:58:32 <wumpus> #endmeeting
390 2016-01-07 19:58:33 <lightningbot`> Log:            http://www.erisian.com.au/meetbot/bitcoin-dev/2016/bitcoin-dev.2016-01-07-19.00.log.html
391 2016-01-07 19:58:33 <lightningbot`> Meeting ended Thu Jan  7 19:58:32 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
392 2016-01-07 19:58:33 <lightningbot`> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-dev/2016/bitcoin-dev.2016-01-07-19.00.html
393 2016-01-07 19:58:33 <lightningbot`> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-dev/2016/bitcoin-dev.2016-01-07-19.00.txt
394 2016-01-07 19:58:51 <Luke-Jr> k, bbiab again
395 2016-01-07 20:28:40 <jonasschnelli> CodeShark: re: https://github.com/CodeShark/BitcoinScriptExperiments, .. did you push segwit compat. CoinCore code somewhere?
396 2016-01-07 20:28:45 <jonasschnelli> Stuff like .getSerializedWithWitness()?
397 2016-01-07 20:28:59 <jonasschnelli> or TxInWitness
398 2016-01-07 20:30:08 <CodeShark> Ah, yes - it's the segwit branch of https://github.com/ciphrex/mSIGNA
399 2016-01-07 20:30:47 <CodeShark> Although I just made some more changes to it I have not pushed yet
400 2016-01-07 20:31:20 <jonasschnelli> np... thanks
401 2016-01-07 20:31:40 <jtimon> sipa to rebase from last-0.12.99 3cd836c1 to master you don't need to remove some commits like you would need if rebasing from 0.12 to master
402 2016-01-07 20:33:30 <MarcoFalke> If a brach rebased on 3cd836c1 merges fine into master and 0.12, that should be preferred, always.
403 2016-01-07 20:33:45 <sipa> jtimon: ok
404 2016-01-07 21:26:20 <Chris_Stewart_5> Is this documentation explaining how OP_CHECKSIG works still relevant?
405 2016-01-07 21:26:23 <Chris_Stewart_5> https://en.bitcoin.it/w/images/en/7/70/Bitcoin_OpCheckSig_InDetail.png
406 2016-01-07 21:26:59 <Chris_Stewart_5> also, is this transaction type specific? I.e. this is how it works for p2pkh only
407 2016-01-07 22:26:06 <jtimon> by the way, would it make sense to create a git label on 3cd836c1 (maybe called last-0.12.99 ) like we do, for example, with release candidates like v0.9.0rc2 ?
408 2016-01-07 22:27:20 <Luke-Jr> branch- makes more sense than last-
409 2016-01-07 22:27:33 <Luke-Jr> but a non-annotated tag may make sense
410 2016-01-07 22:30:14 <jcorgan> do any of the block explorers offer their calculated hashrate distribution figures as part of an API?
411 2016-01-07 22:30:44 <jcorgan> or somewhere else i can get at the numbers underneath something like this: https://www.blocktrail.com/BTC/pools
412 2016-01-07 22:33:41 <jtimon> Luke-Jr: sure, branch-0.12.99, last-0.12.99, whatever
413 2016-01-07 22:33:48 <jtimon> wumpus: thoughts ?
414 2016-01-07 22:35:00 <Luke-Jr> branch-0.12 might be clearer
415 2016-01-07 22:35:57 <MarcoFalke> last-0.11.99, not last-0.12.99 ?
416 2016-01-07 22:37:04 <jtimon> MarcoFalke: no, now master is 0.13.99 until we branch 0.13 out of master
417 2016-01-07 22:38:20 <MarcoFalke> jtimon, https://github.com/bitcoin/bitcoin/commit/c12ff995f7d70aafb12f34887fb64aa7482bbc85
418 2016-01-07 22:40:52 <jtimon> MarcoFalke: oops, you're right. I've been naming my branches wrong for a while then (I hope that's not the reason they weren't merged :p)
419 2016-01-07 22:41:26 <jtimon> to me last-0.11.99 is clearer than branch-0.12, but as said, whatever
420 2016-01-07 22:41:58 <jtimon> all I want is something more memorable than 3cd836c1
421 2016-01-07 22:42:15 <MarcoFalke> Or just tag with "0.11.99"?
422 2016-01-07 22:42:48 <jtimon> yep, I like just 0.11.99
423 2016-01-07 22:43:19 <jtimon> or maybe v0.11.99
424 2016-01-07 22:43:32 <MarcoFalke> I have a tag locally. I can live without having it tagged in bitcoin/bitcoin ^^
425 2016-01-07 22:44:10 <jtimon> me too, and I suspect we're not the only 2
426 2016-01-07 22:44:27 <jtimon> of course this is not a big deal, just an idea
427 2016-01-07 22:50:03 <Yoghur114_2> hypothetical: SW is rolled out, and a script update is being rolled out on top of it - after activation, some miners are - for any reason - left behind and are mining using unupgraded nodes (like BIP66 - sort of), there is now a situation where I might spend upgraded-script transactions (anyone-can-spend to unupgraded nodes) into something that was valid previously, hope for the best it gets picked up by an old miner and gets accepted into, say, a
428 2016-01-07 22:50:04 <Yoghur114_2> chain 2-3 deep that'll be orphaned some time later, I might then spend those to merchants that haven't upgraded - essentially, I'm now spending money I don't have. Barring all practical reasons this might not happen, and ignoring the fact this chain will be orphaned. Would it be a reasonable solution for a wallet to /not/ accept transactions that have an anyone-can-spend tx they have no consensus frame for (like updated segwit transactions would) in
429 2016-01-07 22:50:06 <Yoghur114_2> all (or up to some depth) of the transaction's history to prevent that merchant from being defrauded?
430 2016-01-07 22:50:17 <Yoghur114_2> yeez wall of text, sorry
431 2016-01-07 22:51:54 <Luke-Jr> Yoghur114_2: current miners will NEVER pick up segwit transactions
432 2016-01-07 22:52:09 <Yoghur114_2> I mean, that would quite decisively solve any left-over risk of theft while updating, wouldn't it?
433 2016-01-07 22:52:20 <Yoghur114_2> luke-jr ah yes, but - the adversarial case, then
434 2016-01-07 22:52:26 <Luke-Jr> it's even theoretically possible that pre-segwit miners may continue to work on the new chain
435 2016-01-07 22:53:30 <Luke-Jr> Yoghur114_2: the adversarial case basically requires you to be a miner
436 2016-01-07 22:54:23 <Luke-Jr> anyhow, while we humans talk about it as "anyone-can-spend", actually detecting that condition is not trivial for software
437 2016-01-07 22:56:01 <jtimon> it's also confusing with the anyone can spend sighash
438 2016-01-07 22:56:18 <jtimon> I suggest finding some other term
439 2016-01-07 22:57:55 <Yoghur114_2> well, it'll simply be "I have no idea what anything with these versions might be, but whatever it is, it'll be valid to me" is it not? They can't derive any meaning from it, and will ignore the implication it might have - but allow it
440 2016-01-07 22:57:57 <NicolasDorier> actually myself I thought it referred to the sighash before reading the bip
441 2016-01-07 22:59:30 <Luke-Jr> "I have no idea what anything with these versions might be, but whatever it is, it'll be valid to me" does not exist in the current protocol; it is a new feature being introduced with segwit
442 2016-01-07 23:00:30 <Yoghur114_2> right - they're pretty easy to detect I would imagine?
443 2016-01-07 23:01:02 <Yoghur114_2> if nVersion > x then echo 'wat'
444 2016-01-07 23:01:39 <Luke-Jr> Yoghur114_2: yeah, except all pre-segwit software was released.. a long time ago
445 2016-01-07 23:01:48 <Luke-Jr> can't change the past
446 2016-01-07 23:04:14 <phantomcircuit> is there a meta list for the -dev and -discuss lists?
447 2016-01-07 23:04:25 <Luke-Jr> phantomcircuit: -discuss
448 2016-01-07 23:04:29 <phantomcircuit> ok
449 2016-01-07 23:05:54 <Yoghur114_2> Luke-Jr: I'm not sure why they're relevant?
450 2016-01-07 23:06:10 <Luke-Jr> …
451 2016-01-07 23:06:24 <Yoghur114_2> to the specific case in the hypothetical, I mean
452 2016-01-07 23:06:55 <Yoghur114_2> (ignoring that miners wouldn't mine updated segwits)
453 2016-01-07 23:07:23 <Luke-Jr> it's too late to implement that
454 2016-01-07 23:10:54 <jtimon> but we could implement those kind of warnings so that next time is not too late again
455 2016-01-07 23:13:13 <Yoghur114_2> oh I'm not suggesting to implement that still - was wondering whether that would effectively eliminate another edgiest of edge cases
456 2016-01-07 23:13:57 <Luke-Jr> potentially, but if you're not careful it might also eliminate fungibility
457 2016-01-07 23:14:38 <Luke-Jr> /actually/… I think we might have the highest degree of that possible, already
458 2016-01-07 23:14:46 <Luke-Jr> since nodes will currently reject segwit from their mempool
459 2016-01-07 23:14:59 <Luke-Jr> and without the parent txns, the descendents won't be accepted either
460 2016-01-07 23:15:06 <Luke-Jr> so it would never get to the wallet
461 2016-01-07 23:16:30 <Yoghur114_2> that only applies when unconfirmed, no?
462 2016-01-07 23:19:46 <Luke-Jr> yes, if you made it apply to confirmed transactions, you break fungibility
463 2016-01-07 23:27:48 <Yoghur114_2> but it'd be just a wallet saying "well, this here transaction I'm receiving has a fishy parent, I'm saying nope until you're another dozen or so blocks down" - which, because of segwit, is now something we can explicitly do - whereas previously the 'fishiness' of transactions was impossible to determine. It technically would break fungibility in the sense that a transaction is treated differently based on some arbitrary indicator - but that wouldn't
464 2016-01-07 23:27:50 <Yoghur114_2> last longer than some small amount of blocks, until a wallet is sufficiently sure it is not tracking an attacking chain (it might not know about), and it only applies to the window wherein a node hasn't yet upgraded
465 2016-01-07 23:29:16 <Yoghur114_2> in other words, it would only break fungibility in the same way that altcoin exchange thing... shapeshift? breaks fungibility by not accepting 0-conf nil-fee transactions, and does accept greenaddress txs - so not really at all