1 2016-01-08 01:49:05 <Guest57980> could u knuckledheads stop censoring gavin on the dev list
  2 2016-01-08 01:49:10 <Guest57980> its annoying to try to read
  3 2016-01-08 01:49:13 <Guest57980> thanks a shitheap
  4 2016-01-08 02:31:36 <rusty> BlueMatt: am setting your mod bit, am CC'ing those on the thread + all mods.
  5 2016-01-08 02:31:48 <BlueMatt> rusty: I expected that :)
  6 2016-01-08 02:32:02 <BlueMatt> rusty: still, I stand by my comment
  7 2016-01-08 02:32:48 <BlueMatt> sorry, but anyone saying we should deliberately weaken the crypto used to protect people's bitcoin, when they're clearly informed of their actions, is completely unacceptable
  8 2016-01-08 02:33:38 <rusty> BlueMatt: doesnt' p2sh have exactly this problem today though?
  9 2016-01-08 02:34:16 <BlueMatt> rusty: I didnt say it didnt, but when people stand up and say "hmm...this is broken, lets fix this" the response should not be "hold on a second there...."
 10 2016-01-08 02:37:07 <rusty> BlueMatt: (1) if you want to make personal attacks, however justified you think it is, choose somewhere else than the ml I have to moderate.  (2) you should apply extra sensitivity when criticising someone's idea; I'm pretty sure Gavin personally relates to P2SH design decisions.
 11 2016-01-08 02:37:57 <BlueMatt> rusty: I actually didnt see any personal attacks here? Sure, strong language, but in cases like these I'd call that expected
 12 2016-01-08 02:38:44 <BlueMatt> rusty: as for gavin associating with his own design, I'm not sure that's really the case here...for P2SH he just copied the existing address length, which is a reasonable design decision. However, since then people have thought about it more and realized this was maybe not a good idea
 13 2016-01-08 02:39:19 <BlueMatt> I'm not sure anyone is criticizing gavin for the decisions on p2sh, and since I'm not aware of significant criticism about it at the time, doing so would be unfair
 14 2016-01-08 02:39:38 <rusty> Sure, but then you accuse him of "You may feel comfortable weakening crypto", which was across the line.
 15 2016-01-08 02:40:40 <BlueMatt> in this case I disagree...if I cant yell at people when they're trying to push for bad crypto, in the face of people telling them to stop, I dont know when I can
 16 2016-01-08 02:40:59 <moa> but maybe he is comfortable weakening crypto (in this instance) as part of the design decision?
 17 2016-01-08 02:41:34 <BlueMatt> moa: sure, and in cases like that, I think a response of "WTF?" is appropriate
 18 2016-01-08 02:41:51 <BlueMatt> a simple reminder of the value of bitcoin outstanding...
 19 2016-01-08 02:42:45 <rusty> BlueMatt: let's keep it simple: don't yell at people on the ml.  For any reason.  Full stop.
 20 2016-01-08 02:44:52 <BlueMatt> rusty: while I agree, generally, there are cases where it is called for
 21 2016-01-08 02:45:20 <rusty> BlueMatt: I welcome your input to the January 21st review of moderation.
 22 2016-01-08 02:54:01 <Anduck> isn't using sha256d quite bad because there are... lots of asics doing just that already?
 23 2016-01-08 02:55:32 <phantomcircuit> Anduck, bitcoin miners have brute forced 83 bits of the keyspace
 24 2016-01-08 02:55:46 <Anduck> so 2^80 should be "easy"
 25 2016-01-08 02:55:50 <phantomcircuit> Anduck, which would be bad news with a 160 bit hash function
 26 2016-01-08 02:56:56 <rusty> Hmm, how fast can you generate keypairs?  In my ignorance, it seems like you can inc pubkey and add G to privkey?
 27 2016-01-08 02:57:01 <phantomcircuit> the risk is actually less about brute forcing and more that the security of the underlying hash function is reduced
 28 2016-01-08 02:57:18 <phantomcircuit> rusty, that's correct, it's not secure but who cares for brute forcing
 29 2016-01-08 02:57:47 <rusty> phantomcircuit: well, if you start at a random point, it means you only have to store a table of pubkeys....
 30 2016-01-08 02:58:03 <BlueMatt> rusty: yes, you can just inc the pubkey when brute forcing
 31 2016-01-08 02:59:22 <phantomcircuit> Anduck, im not so much worried about someone building asic farms to brute force than i am the security of the hash function being reduce enough that i can do it on aws in a month
 32 2016-01-08 03:00:48 <rusty> BlueMatt: um, I think inc the priv and do a 32-byte add on the pubkey?
 33 2016-01-08 03:01:17 <rusty> pieter would probably be able to estimate how fast an optimized version would run...
 34 2016-01-08 03:01:54 <BlueMatt> rusty: there should be optimized versions lying around already
 35 2016-01-08 03:02:01 <BlueMatt> its what people doing custom-address things use :)
 36 2016-01-08 03:02:02 <phantomcircuit> rusty, yes that's what you do
 37 2016-01-08 03:02:21 <phantomcircuit> BlueMatt, iirc not publicly but not super hard to fig up from libsecp256k1
 38 2016-01-08 03:02:23 <BlueMatt> the readily-available ones are not that great, but I know at least gmaxwell has implemented a much faster version
 39 2016-01-08 03:02:39 <Anduck> phantomcircuit: how is ripemd-160 better than sha256?
 40 2016-01-08 03:02:56 <BlueMatt> Anduck: its a question of headroom
 41 2016-01-08 03:03:08 <BlueMatt> at 80 bits, your headroom is very, very low
 42 2016-01-08 03:03:18 <BlueMatt> when hash functions are broken, generally it comes in fits and spurts
 43 2016-01-08 03:03:45 <Anduck> so it's better to use different functions because of that?
 44 2016-01-08 03:03:45 <BlueMatt> which would normally give you time to upgrade to something else (ie often a few years to upgrade, which is what we'd need in bitcoin)
 45 2016-01-08 03:04:04 <BlueMatt> but if you dont have any headroom, you're fucked very suddenly with no warning
 46 2016-01-08 03:04:35 <phantomcircuit> Anduck, ripemd160 is not better than sha256 in anyway, it is however different which provides some amount of protection when doing ripemd160(sha256(d))
 47 2016-01-08 03:04:38 <BlueMatt> ie an attack which drops security from 80 bits to 60 means attacks are practical...one that drops you from 128 to 100...not so much
 48 2016-01-08 03:05:34 <BlueMatt> and at 100 bits we can start migrating...by the time there are better attacks, people have had a year or two to migrate to something better
 49 2016-01-08 03:09:48 <Anduck> alright
 50 2016-01-08 03:16:56 <Anduck> well, i think saying gavin is pushing for backdoored crypto is exaggerating as bitcoin already uses sha256d (though for not that important purpose as coin ownership things?)
 51 2016-01-08 03:18:33 <BlueMatt> Anduck: hmm? gavin is pushing for ripemd160(sha256()), not sha256-d
 52 2016-01-08 03:19:14 <BlueMatt> Anduck: while its true that construct is being used for p2sh/p2pkh, the point was that, when people explained why that was actually a bad idea and we should start migrating to fix it sooner rather than later, gavin refused to listen
 53 2016-01-08 03:20:04 <BlueMatt> hence my comment...sorry, but backdooring bitcoin is unacceptable and insisting you're not when people are clearly explaining why is unacceptable
 54 2016-01-08 03:20:05 <Anduck> ah, yup meant that way around
 55 2016-01-08 03:20:09 <BlueMatt> (and should be yelled at)
 56 2016-01-08 03:24:02 <Anduck> wouldn't the best option be to use something stronger than ripemd-160 but not sha256? or would it be an overkill
 57 2016-01-08 03:24:09 <Anduck> using sha256 everywhere doesn't sound too good either
 58 2016-01-08 03:25:22 <BlueMatt> Anduck: not sure there is anything that cryptographers would agree even slightly was more recommended than sha256 right now :/
 59 2016-01-08 03:26:17 <BlueMatt> if there were then I'd totally agree
 60 2016-01-08 03:26:43 <BlueMatt> djb seems to like sha3 these days, but it is still a bit "new" in crypto years
 61 2016-01-08 03:34:59 <Chris_Stewart_5> BlueMatt: How long does it usually take for a new crypto algo to be production ready for something like Bitcoin
 62 2016-01-08 03:38:45 <Anduck> BlueMatt: well, i think it's harsh to call it backdooring as lots of bitcoin already relies on that ripemd160(sha256)
 63 2016-01-08 03:39:38 <Anduck> if ripemd160 is indeed backdoored, too much is already relying on it so...
 64 2016-01-08 03:39:58 <rusty> BlueMatt: there's a good argument that v0 should simply be RIPEMD(SHA256(WP)).  (1) It's good enough today, (2) it's smaller than the current proposal for normal scripts, and (3) it's easy to fix to a simple SHA256(WP) later.
 65 2016-01-08 03:41:16 <rusty> It's also the only place I can think to cut the SW proposal (if you make it SHA256(WP) and no inline scripts today, you apparently lose most size gains)
 66 2016-01-08 03:42:46 <BlueMatt> Chris_Stewart_5: I can answer how long it takes me to be comfortable with something, but you should listen to cryptographers, not me...
 67 2016-01-08 03:43:01 <morcos> BlueMatt: phantomcircuit: I'd prfer to save my energy for other bitcoin arguments, but just so i understand
 68 2016-01-08 03:43:05 <BlueMatt> Anduck: I never claimed either ripemd160 or sha256 was backdoored
 69 2016-01-08 03:43:24 <rusty> Chris_Stewart_5: a couple of weeks, usually.  (Assuming "something like Bitcoin" == "altcoins" :)
 70 2016-01-08 03:43:30 <morcos> ripemd160 and sha256 would have to have attacks in order to reduce the collision resistance below 2^80 right?
 71 2016-01-08 03:44:01 <morcos> would both have to i mean
 72 2016-01-08 03:44:35 <BlueMatt> rusty: if we know that the old stuff is broken, why would we design an upgrade that is broken in the same way?
 73 2016-01-08 03:45:07 <rusty> BlueMatt: we're arguing over whether it is broken, and on what pace we should replace it, and how.
 74 2016-01-08 03:45:33 <BlueMatt> rusty: hmm? I think most people think that the use of a 160-bit hash function for p2sh was a bad idea
 75 2016-01-08 03:45:43 <rusty> BlueMatt: first I've heard of it.
 76 2016-01-08 03:45:53 <rusty> BlueMatt: though I asked the question.
 77 2016-01-08 03:46:43 <BlueMatt> rusty: fair enough, we need to do a better job writing down what we know as a community :)
 78 2016-01-08 03:46:55 <Anduck> morcos: if i get it right, either. near to 2^80 is already bad
 79 2016-01-08 03:47:24 <BlueMatt> morcos: when talking about hash functions, you can calculate a collision in n/2 work
 80 2016-01-08 03:47:41 <BlueMatt> so if you use a 160-bit hash you get 80 bits of collision resistance difficulty
 81 2016-01-08 03:48:13 <rusty> BlueMatt: if the answer is "we should worry about this in 20 years", then it's reasonable to implement it in 10-15 years....
 82 2016-01-08 03:49:38 <Anduck> the overhead which comes with extra bits may not be worth it as of today. there are already "bitcoins biggest problems" in capacity
 83 2016-01-08 03:51:16 <BlueMatt> rusty: the answer is "we should worry about this at some point that may be tomorrow or in 20 years"
 84 2016-01-08 03:51:19 <BlueMatt> but we cant tell when
 85 2016-01-08 03:51:34 <BlueMatt> and when it does happen, its very possible it goes from today to "HOLY SHIT, HAIR ON FIRE" overnight
 86 2016-01-08 03:51:48 <BlueMatt> vs with something with more overhead the chance that we have no time to react is much, much, much lower
 87 2016-01-08 03:52:30 <BlueMatt> Anduck: I'll take less scalibility if it means a few billion dollars are secure any day...not if the concerns is unwarranted, but here it is
 88 2016-01-08 03:52:36 <rusty> BlueMatt: I disagree, we should hair-on-fire when either hash gets weakened.  Until then Moore's law is our main enemy.
 89 2016-01-08 03:53:22 <rusty> It may be that SHA3(script) is a better answer, for example.
 90 2016-01-08 03:53:36 <Anduck> maybe there should be plans about upgrading all the crypto from current weaker cryptos, when the time is right. but currently as bitcoin already relies on 160bit ripemd it shouldn't be too bad to use it for segwit too?
 91 2016-01-08 03:54:16 <BlueMatt> rusty: hmm? if we go from "all these things we're building on top of are secure" to "wow, lightning is broken" overnight, I think thats a big problem
 92 2016-01-08 03:54:26 <BlueMatt> if a hash gets weakened, we have time to react
 93 2016-01-08 03:54:31 <rusty> BlueMatt: not if only one hash is weakend.
 94 2016-01-08 03:54:39 <BlueMatt> no, that is not the case
 95 2016-01-08 03:54:57 <BlueMatt> if ripemd160 were weakened in a year, and we are using it, we have to tell everyone to stop using lightning overnight
 96 2016-01-08 03:55:07 <BlueMatt> that is really not something we should be setting ourselves up for
 97 2016-01-08 03:55:12 <rusty> BlueMatt: really?  Why?
 98 2016-01-08 03:55:32 <BlueMatt> if we're using sha256 and it gets weakened, we have time to react, because generally hash functions dont go from fine to broken overnight
 99 2016-01-08 03:55:39 <BlueMatt> they go from fine to slightly-reduced overnight
100 2016-01-08 03:55:48 <BlueMatt> but slightly-reduced from 80 bits is "oh, fuck, ok stop using this"
101 2016-01-08 03:56:02 <BlueMatt> slightly-reduced from 128 bits is "oh, fuck, lets start rolling out a fix asap"
102 2016-01-08 03:56:04 <rusty> BlueMatt: even if RIPEMD is completely broken, you still have to break SHA256 to get a collision.
103 2016-01-08 03:56:10 <BlueMatt> no
104 2016-01-08 03:56:16 <morcos> rusty: exactly what i thought
105 2016-01-08 03:56:22 <BlueMatt> not necessarily
106 2016-01-08 03:56:26 <BlueMatt> depends on how its broken
107 2016-01-08 03:56:31 <BlueMatt> could be the case, but might not be
108 2016-01-08 03:56:42 <Anduck> how about that both sha256 & ripemd+sha256 are enabled and user can choose which one to use?
109 2016-01-08 03:56:58 <BlueMatt> Anduck: hilariously, thats the way segwit is being proposed
110 2016-01-08 03:57:11 <BlueMatt> Anduck: (because its nice to have backwards compatibility with p2sh)
111 2016-01-08 03:57:31 <morcos> BlueMatt: not so.  to use the 160bit hahses you need to also have a scriptsig
112 2016-01-08 03:57:34 <rusty> BlueMatt: I think you're wrong.
113 2016-01-08 03:59:10 <morcos> rusty: but to be fair i'm not sure i understand gavins side of the argument either
114 2016-01-08 03:59:28 <morcos> what is the security risk of using sha256
115 2016-01-08 03:59:47 <morcos> its going to be a different construction than p2sh anyway
116 2016-01-08 03:59:53 <rusty> morcos: ah, if you simplify SW by removing the version 0 option (inline scripts) apparently you shred the space benefits.
117 2016-01-08 03:59:55 <Anduck> solely using sha256 you don't have the protection from using different cryptos
118 2016-01-08 03:59:57 <morcos> so still plenty of opportunity to have user error
119 2016-01-08 04:00:07 <morcos> yes i understand the space benefits
120 2016-01-08 04:00:47 <rusty> morcos: having both an inline script and indirect commitment is kinda icky.
121 2016-01-08 04:01:26 <morcos> you mean having a v0 and a v1, or having a embed in p2sh or not option
122 2016-01-08 04:01:30 <morcos> there are 4 ways of doing witness
123 2016-01-08 04:02:10 <morcos> embed in p2sh is obviously strictly less efficient space wise, but is a familiar address that old software can pay to
124 2016-01-08 04:03:09 <morcos> v0 vs v1 bare witness scripts is not that much complication, but i don't think v0 actually saves you much space over v1
125 2016-01-08 04:03:59 <morcos> a p2pkh in v0 is less virtual bytes than p2pk in v1 but i'm not sure its huge...  let me check
126 2016-01-08 04:08:56 <Anduck> actually, i think having options for the algos would be great. if (or when) things start to break, no update is needed as the safe option already exists
127 2016-01-08 04:09:39 <Anduck> nobody knows how hard it may be to update anything in the future
128 2016-01-08 04:10:23 <morcos> rusty: i'm sure i messed up the math, but looks like what takes 107 virtual bytes now drops to 61 with v1 and 54 with v0
129 2016-01-08 04:10:48 <morcos> pay to public key in the first two cases, pay to public key hash in the last
130 2016-01-08 04:14:11 <morcos> oh so gavinandresen wants to get rid of v0 so we don't have 2 ways of doing it?
131 2016-01-08 04:14:34 <morcos> thats a completely different argument that has little to do with space savings in my mind
132 2016-01-08 04:15:37 <rusty> morcos: see his latest post.
133 2016-01-08 04:16:26 <morcos> rusty: yes he's combining two arguments
134 2016-01-08 04:16:48 <morcos> he wants to only have one kind of witness script AND he wants that to be a different hash function
135 2016-01-08 04:17:16 <morcos> if he wants to get rid of inline witness scripts, he might not have as much opposition
136 2016-01-08 04:17:35 <rusty> morcos: I think that's because of previous off-list discussions (which is why I hate that crap).  Pieter told me that without inline scripts the space savings are a wash, IIRC.
137 2016-01-08 04:17:52 <morcos> you maybe misunderstood
138 2016-01-08 04:18:24 <morcos> I think Pieter was probably saying that the additional space savings you get from having the option to do inline scripts are a wash
139 2016-01-08 04:18:28 <morcos> you don't really need them
140 2016-01-08 04:19:02 <morcos> in fact i implemented a test for them and he was saying he didn't anticipate people using them much, and i said well they are a bit smaller
141 2016-01-08 04:19:26 <rusty> morcos: maybe...
142 2016-01-08 04:48:21 <rusty> gijensen: hmm, so, with walletbroadcast=0, I get the hilarious result that bitcoind doesn't seem to know about the tx at all!
143 2016-01-08 04:48:46 <rusty> $ bitcoin-cli sendtoaddress 2Mt9gYTH6Bb8JWPjJqAWTj7hVydPsdShZbQ 0.00100000
144 2016-01-08 04:48:46 <rusty> ec363356ff9a3cec92140881d6699e6fdcc83d2d65a00dd7d45b237d3ce49518
145 2016-01-08 04:48:47 <rusty> $ bitcoin-cli getrawtransaction ec363356ff9a3cec92140881d6699e6fdcc83d2d65a00dd7d45b237d3ce49518
146 2016-01-08 04:48:47 <rusty> error code: -5
147 2016-01-08 04:48:47 <rusty> error message:
148 2016-01-08 04:48:47 <rusty> No information available about transaction
149 2016-01-08 04:50:36 <phantomcircuit> rusty, yeah you never put it into the mempool
150 2016-01-08 04:50:42 <phantomcircuit> which is how it gets into the wallet
151 2016-01-08 04:50:51 <rusty> phantomcircuit: then, how do I get it? :)
152 2016-01-08 04:51:00 <phantomcircuit> gettransaction
153 2016-01-08 04:51:09 <phantomcircuit> but i dont know if that returns the raw transaction or not
154 2016-01-08 04:51:21 <phantomcircuit> fix getrawtransaction to check wallet transactions?
155 2016-01-08 04:51:24 <rusty> phantomcircuit: ah!  Yes it's in the "hex" field....
156 2016-01-08 04:51:38 <rusty> phantomcircuit: I'm so used to using getrawtransaction....
157 2016-01-08 04:51:56 <phantomcircuit> it's annoying that they're not the same
158 2016-01-08 06:19:51 <bitcoin-dev448> Hey can anyone provide pointer to understanding the flow between boost signals and SendMessages(). Like how thread invokes function in main.cpp?
159 2016-01-08 09:06:24 <fredrin> I'm running bitcoind on segwit test net with gen=1, what more can I do to help out testing?
160 2016-01-08 09:09:30 <jl2012> Luke-Jr: Since bitcoin/bips is a fork, there is no issues page for it. Is it possible to fix it?
161 2016-01-08 15:41:18 <xabbix> When I see this message in my debug.log 2016-01-08 15:40:12 AcceptToMemoryPool: peer=16784 /Bitcoin XT:0.11.0D/ : accepted b2277cb0546727f6d20399674cd15ceb638ac9ba59d4b519c194b38c9ad4ddd0 (poolsz 71815), does it mean that my mempool has 71815 txs right now?
162 2016-01-08 15:46:28 <jonasschnelli> xabbix: yes.
163 2016-01-08 15:46:48 <jonasschnelli> You might want to upgrade to the current master of core. It has a mempool memory limit.
164 2016-01-08 15:47:28 <jonasschnelli> you can also call your node (bitcoin-cli) with getmempoolinfo to get some more info
165 2016-01-08 15:47:46 <jonasschnelli> If you have a recent version of core (not sure about XT), you might see the "usage" (in bytes)
166 2016-01-08 15:48:45 <xabbix> jonasschnelli: Why is my mempool so large? Even though new blocks are found it seems to have very little effect on my mempool size
167 2016-01-08 15:49:10 <xabbix> jonasschnelli: btw I'm running bitcoin-core, not XT.
168 2016-01-08 15:49:33 <jonasschnelli> Ah right. the XT is from the remote peer. sry.
169 2016-01-08 15:49:48 <jonasschnelli> You mempool is large because there are so many transactions i guess?
170 2016-01-08 15:50:13 <xabbix> shouldn't the mempool zero down when a new block is found? (let's assume all txs are valid etc..)
171 2016-01-08 15:50:27 <jonasschnelli> hmm... i have only limites nodes running... 300MB fully filled up with ~10k transaction.
172 2016-01-08 15:50:53 <xabbix> So why are you on 10k? according to https://tradeblock.com/bitcoin/ there are ~1300txs in the mempool
173 2016-01-08 15:51:04 <sipa> xabbix: every node has their own mempool
174 2016-01-08 15:51:13 <jonasschnelli> xabbix: only if miners can mine all tx,.. if miners don't put them into blocks, then they stay in the mempool,... another reason could be, that blocks are full and that there are more tx then blocks.
175 2016-01-08 15:51:23 <sipa> xabbix: and its own rules abimout what to accept into it
176 2016-01-08 15:52:00 <xabbix> sipa, generally and theoretically, once a block is found should all txs that were in the block be removed from the mempool?
177 2016-01-08 15:52:11 <sipa> xabbix: no way
178 2016-01-08 15:52:23 <xabbix> Oh, ok I didn't know that
179 2016-01-08 15:52:51 <sipa> if people produce more transactions than fit in a block, that can't be
180 2016-01-08 15:53:11 <xabbix> no, i meant, all blocks that were accepted to the block should be removed from the mempool
181 2016-01-08 15:53:15 <xabbix> not ALL txs that are in the mempool
182 2016-01-08 15:53:29 <sipa> yes, this is the case
183 2016-01-08 15:54:00 <xabbix> ok so my node just accumulates all these non valid txs or whatever and doesn't clean it up I guess. Maybe I should upgrade
184 2016-01-08 15:56:00 <jonasschnelli> xabbix: if you can compile core, compile the 0.12 branch,...
185 2016-01-08 15:58:23 <xabbix> jonasschnelli: Yes I can, thanks for all the help!
186 2016-01-08 16:08:04 <Luke-Jr> jl2012: what kind of issues could there be? I think it may simply be disabled
187 2016-01-08 16:09:42 <jonasschnelli> Yes. The issue tracker for the bitcoin/bips is disabled.
188 2016-01-08 16:10:01 <jonasschnelli> And i agree with @Luke-Jr: no need for issues there?
189 2016-01-08 16:10:12 <jonasschnelli> s/?/.
190 2016-01-08 16:10:30 <jl2012> it's ok
191 2016-01-08 16:10:45 <jl2012> just want to discuss some general policy of BIP
192 2016-01-08 16:12:07 <Luke-Jr> that's something for -dev ML
193 2016-01-08 16:13:12 <jl2012> for standard type BIP, I think it should come with an implementation (even a partial one) in order get a number. Or the authors should at least demonstrate their ability to do that
194 2016-01-08 16:13:19 <jonasschnelli> while looking at github.com/bitcoin, is https://github.com/bitcoin/bitcoin.github.com still required?
195 2016-01-08 16:13:47 <jl2012> It's so easy to write up a BIP, to say 3MB in 2016, 6MB in 2017, etc
196 2016-01-08 16:19:12 <jcorgan> "rough consensus and working code"
197 2016-01-08 16:26:08 <NicolasDorier> I agree needing a mergeable code for having BIP number is a good "proof of work" so to say. It would also prevent vague BIPs. It would also oblige to break down a big BIP into several one, which is good for understanding.
198 2016-01-08 16:26:45 <NicolasDorier> and make debate easier on specific parts rather than on the whole.
199 2016-01-08 16:27:13 <jl2012> I like the term PoW
200 2016-01-08 16:27:42 <jl2012> may not be immediately mergeable, but at least some reasonable PoW
201 2016-01-08 16:32:01 <NicolasDorier> I don't think "rough consensus" for assigning a bip number is not necessary. Someone will not waste time working on a code which he thinks don't have chance of being accepted. The "proof of code" is a good anti spam.
202 2016-01-08 16:32:15 <NicolasDorier> I don't think**** is necessary. I mean
203 2016-01-08 16:32:58 <Luke-Jr> jl2012: well, the ability to write a proper specification IMO implies ability to implement
204 2016-01-08 16:34:19 <jl2012> Luke-Jr: sounds like circular reasoning
205 2016-01-08 16:34:28 <Luke-Jr> …
206 2016-01-08 16:34:46 <jcorgan> working code is indeed a good PoW (I like that concept). Rough consensus means a lot of people think its a good idea worth hasing out as a BIP, which could still ultimately be rejected
207 2016-01-08 16:35:39 <jcorgan> i could have working code that removes the 21M cap, for a trivial example
208 2016-01-08 16:36:27 <jl2012> I think we could be flexible, depends on the nature of the BIP. If it is a trivial one like block size increase, PoW should be the minimum requirement
209 2016-01-08 16:36:35 <Luke-Jr> as it stands, I would assign a BIP number to jcorgan if he wrote an actual BIP proposing that and discussed it on the ML; it might even be a good BIP to have, as an example that being a BIP does not mean it is accepted
210 2016-01-08 16:36:42 <NicolasDorier> Making code mandatory is also a nice way to reject proposals who are simple to understand, but not easily to implement and vice versa.
211 2016-01-08 16:36:50 <NicolasDorier> jcorgan => yes did not thought about that  :p
212 2016-01-08 16:40:25 <jcorgan> Luke-Jr: i think that policy would invite a trivial BIP DoS
213 2016-01-08 16:41:20 <jcorgan> you can discuss proposed-bips at length without assigning a number; when it is clear there is at least some consensus it would be a desirable thing, then a number could be assigned
214 2016-01-08 16:41:20 <jl2012> jcorgan: BIP is run by human, not software....
215 2016-01-08 16:42:18 <Luke-Jr> there has never been any such agreement necessary for BIP assignments. so anything like that would be a change
216 2016-01-08 16:42:24 <jcorgan> and when said human pushed back on the trivial BIPs, then reddit will be full of whiners complaining they wrote code and couldn't get a bip number
217 2016-01-08 16:43:06 <jcorgan> the mandatory code (for non-informational bips) requirement would be a change too
218 2016-01-08 16:44:36 <NicolasDorier> true for whiners, still need rough consensus indeed. The mandatory code at least prevent "christmas list" BIPs by uninformed redditor. :p
219 2016-01-08 16:44:44 <jcorgan> yep
220 2016-01-08 16:48:36 <jcorgan> not sure how we converge on a policy for this, but code + positive ML response seems a reasonable way to go
221 2016-01-08 16:53:41 <Luke-Jr> jcorgan: this new policy requires a BIP. how will you write code implementing it? :P
222 2016-01-08 16:55:58 <jcorgan> i know you're being facetious--but bip0001 describes standards track, informational, and process bips; this policy change would apply to standards track only
223 2016-01-08 16:56:13 <jcorgan> and the change would be to bip0001, which is a process bip :)
224 2016-01-08 16:56:37 <Luke-Jr> :p
225 2016-01-08 17:05:56 <btcdrak> BIP DoS haha
226 2016-01-08 17:06:30 <btcdrak> I think it's important for people to get confortable with using bip-alias-shorttitle
227 2016-01-08 17:07:20 <btcdrak> that's what gmaxwell was trying to encourage. so the BIP is numbered and the file is named like bip-btcdrak-myproposal
228 2016-01-08 17:08:06 <btcdrak> it also allows people to write competing BIPs on the same topic.
229 2016-01-08 17:09:12 <btcdrak> +1 no the PoW idea.
230 2016-01-08 17:09:24 <btcdrak> /no/on/
231 2016-01-08 17:23:15 <Luke-Jr> jcorgan: correction: changing 21mil probably falls under breaking with Bitcoin philosophy
232 2016-01-08 17:24:40 <btcdrak> Luke-Jr: technically, since it's a forbidden change, it cant be called a BIP, because it's not a bitcoin improvement proposal.
233 2016-01-08 18:05:55 <Luke-Jr> ok, all outstanding BIPs have been assigned I think
234 2016-01-08 18:13:19 <Luke-Jr> gavinandresen: please decide on https://github.com/bitcoin/bips/pull/251 and https://github.com/bitcoin/bips/pull/259 ; thanks
235 2016-01-08 18:33:35 <btcdrak> Luke-Jr: my inbox blew up with all the BIPs notifications :-P
236 2016-01-08 18:35:11 <maaku> Luke-Jr: suggestion: move bitcoin/bips (fork of petertodd's repo) to bitcoin/bips-old, and push a new, non-fork repo to bitcoin/bips
237 2016-01-08 18:36:50 <sipa> or, move bips to bips-old, and ask petertodd to move the repo over to bitcoin
238 2016-01-08 18:37:40 <Luke-Jr> I don't see a problem with the repo?
239 2016-01-08 18:38:49 <maaku> otherwise github will forever think bitcoin/bips is a fork of petertodd's repo, and e.g. #123 references ping back to his issue tracker
240 2016-01-08 18:38:56 <maaku> (and you won't have an issue tracker)
241 2016-01-08 18:39:16 <maaku> but maybe support at github can fix this in a non-disruptive manner
242 2016-01-08 18:39:23 <Luke-Jr> the issue tracker is explicitly disabled.. not related to that
243 2016-01-08 18:39:32 <maaku> ah
244 2016-01-08 18:39:54 <sipa> maaku: yes, you can move a repo to another org
245 2016-01-08 18:39:59 <sipa> that is the correct solution
246 2016-01-08 18:40:24 <sipa> it updates the forked-from pointers in other repos too
247 2016-01-08 18:40:27 <sipa> afaik
248 2016-01-08 18:40:38 <maaku> right ok, tht would be best
249 2016-01-08 18:40:51 <maaku> to make bitcoin/bips the "master" repo instead of petertodd
250 2016-01-08 18:44:41 <jl2012> thanks Luke-Jr.
251 2016-01-08 18:44:58 <jl2012> 141 has a special meaning in Cantonese....
252 2016-01-08 18:45:20 <jl2012> not asking you to change it, though...
253 2016-01-08 18:49:30 <Luke-Jr> O.o?
254 2016-01-08 18:54:18 <Luke-Jr> bleh, the original bips is actually genjix/bips ..
255 2016-01-08 19:03:15 <btcdrak> maaku I think you can ask Github to break the association.
256 2016-01-08 19:04:03 <maaku> jl2012: kinda hard to avoid numbers with special meanings in various chinese dialects ;)
257 2016-01-08 19:04:05 <btcdrak> maaku: so it's no longer shown as a fork. but in any case, pushing a repo will setup redirects automatically
258 2016-01-08 19:04:20 <Luke-Jr> #github says to email support to break the association; but it'd be nice to setup redirects
259 2016-01-08 19:04:42 <Luke-Jr> the problem with that is, we're forked from petertodd who forked from genjix
260 2016-01-08 19:04:44 <btcdrak> Luke-Jr: it sets up redirectis automatically when you push the repo
261 2016-01-08 19:04:57 <Luke-Jr> so is it Amir we need to move from?
262 2016-01-08 19:05:37 <btcdrak> Luke-Jr: no in the case of bitcoin/bips just ask #github to break the fork association, and it's done.
263 2016-01-08 19:05:45 <jl2012> maaku: that's true, but BIP141 was first publicly announced in Hong Kong, so it's more relevant
264 2016-01-08 19:07:11 <Luke-Jr> btcdrak: if we just break it, you can no longer submit pull requests..
265 2016-01-08 19:07:20 <btcdrak> Luke-Jr: I think assigning the BIP numbers is better done in a comment to let the bip author then make the necessary renaming and updates
266 2016-01-08 19:07:46 <btcdrak> Luke-Jr: well ask them, they can probably set it up
267 2016-01-08 19:07:50 <Luke-Jr> btcdrak: that would encourage rebasing/amending, and I don't see the benefit?
268 2016-01-08 19:08:09 <btcdrak> Luke-Jr: doesnt encourage rebasing, it can just be another commit.
269 2016-01-08 19:08:39 <Luke-Jr> how is that any better than me just adding the commit myself and merging? :p
270 2016-01-08 19:08:50 <btcdrak> Luke-Jr: it's more work since now everyone has to open a new PR just to rename the file, update the number and add to the index.
271 2016-01-08 19:09:12 <btcdrak> heh :)
272 2016-01-08 19:09:19 <btcdrak> Luke-Jr: see your PM please
273 2016-01-08 19:09:26 <Luke-Jr> btcdrak: what? no?
274 2016-01-08 19:11:20 <Luke-Jr> btcdrak: why would a new PR need to be opened?
275 2016-01-08 19:11:41 <btcdrak> well if you are happy to make the changes yourself then ok :)
276 2016-01-08 19:12:58 <Luke-Jr> seems the least wasted time overall if I just do it
277 2016-01-08 19:17:50 <Chris_Stewart_5> If i see a '0' leading a p2sh script sig does that evaluate to OP_0?
278 2016-01-08 19:18:07 <Chris_Stewart_5> for example
279 2016-01-08 19:18:11 <Chris_Stewart_5> "asm" : "0 3045022100884c8a4776f4aa2a70f25f6bc0071929ade0ff4987844347e051e018c267aae402201fcec5dd052e7b01198bb57e1b58696c38ccd9d0b408c55047cac89b47287b4101 3045022100b064d492712a080b726ecf37de2957b783fa411edae33bd13005e62d6a45d02302201b82b632df54cf1204758c2b5a3599f1f9a80da3d508951695bfcf8d2c2cce0f01
280 2016-01-08 19:18:12 <Chris_Stewart_5> 522102632178d046673c9729d828cfee388e121f497707f810c131e0d3fc0fe0bd66d62103a0951ec7d3a9da9de171617026442fcd30f34d66100fab539853b43f508787d452ae"
281 2016-01-08 19:18:21 <sipa> yes
282 2016-01-08 19:18:26 <sipa> not evaluate
283 2016-01-08 19:18:41 <sipa> it's just human representation of a script
284 2016-01-08 19:20:24 <Chris_Stewart_5> sipa: not sure what you mean by that. In this context i'm trying to parse that script sig into script operations/constants. If it is just for human representation can it be ignored?
285 2016-01-08 19:21:37 <sipa> a script is a byte array
286 2016-01-08 19:22:02 <sipa> what you are seeing under "asm" is a human representation of a script, not the script itself
287 2016-01-08 19:22:15 <sipa> in this human representation " 0 " means OP_0
288 2016-01-08 19:22:27 <Chris_Stewart_5> ahhh ok
289 2016-01-08 19:23:01 <Chris_Stewart_5> thank you :-). What does the acronym 'asm' stand for any way? I just always assume assembly but that doesn't make much sense in this context
290 2016-01-08 19:23:57 <sipa> assembly
291 2016-01-08 19:24:53 <sipa> as opposed to machine language (script byte array), this is an instruction-per-instruction translation of it to human readable mnemonics (opcodes)
292 2016-01-08 19:25:38 <Chris_Stewart_5> Ok that makes sense. Thanks for the explanation
293 2016-01-08 21:01:40 <jl2012> just reading BIP125 RBF. Does it mean BIP68 tx must be RBF?
294 2016-01-08 22:45:23 <arubi> can anyone source a live segnet node?  I can't find a connection for days now.. would really like to participate
295 2016-01-08 22:46:06 <Luke-Jr> FWIW, GitHub says there shouldn'
296 2016-01-08 22:46:17 <Luke-Jr> FWIW, GitHub says there shouldn't be any issues with the bips repo and PR references