1 2017-05-22 09:38:09 <conman> am I missing something about this alleged silbert agreement? https://bitcointalk.org/index.php?topic=1928093.0
  2 2017-05-22 12:53:41 <execute_> in a transaction's vout, how come the scriptpubkey has an array of addresses? Can there be more than 1 address?
  3 2017-05-22 17:09:47 <arubi> anybody knows what petertodd means here: https://mobile.twitter.com/petertoddbtc/status/866512081591447552 ?
  4 2017-05-22 17:10:35 <arubi> or is it just a comment about the wtxid root being in the header itself?
  5 2017-05-22 17:12:31 <arubi> or is it a continuation from the previous tweet?  twitter is hard :)
  6 2017-05-22 17:16:40 <abpa> It means you could asicboost and hide it
  7 2017-05-22 17:17:03 <abpa> Simple asicboost is granding the version number in the block header
  8 2017-05-22 17:17:12 <arubi> right, but that's overt
  9 2017-05-22 17:17:51 <arubi> yes I pretty much know how asicboost works.  just thought that this tweet had something to do with the segwit+hf thing suggested by SDL
 10 2017-05-22 17:18:18 <Diablo-D3> wtf is asicboost?
 11 2017-05-22 17:18:31 <abpa> arubi it makes it covert
 12 2017-05-22 17:18:57 <arubi> Diablo-D3, some way to re-use work and lower power consumption in asics
 13 2017-05-22 17:19:01 <arubi> abpa, what does?
 14 2017-05-22 17:19:16 <abpa> making the version bits into a nonce does
 15 2017-05-22 17:19:58 <Diablo-D3> arubi: so its what I did in diablominer?
 16 2017-05-22 17:20:08 <arubi> right, I had trouble following the tweets timeline.  thanks
 17 2017-05-22 17:20:28 <arubi> Diablo-D3, I don't know :),  there's a pretty detailed paper that shows one way
 18 2017-05-22 17:20:48 <Diablo-D3> I did pre-calc of the first few steps
 19 2017-05-22 17:21:00 <Diablo-D3> saved about 12% of the time iirc
 20 2017-05-22 17:21:06 <arubi> and there's another way to do it covertly by using some bits from the coinbase and some re-ordering of the transactions in the block
 21 2017-05-22 17:21:41 <arubi> here it's finding collisions of in the second sha256 block of the header
 22 2017-05-22 17:22:30 <arubi> the merkle root is in the header but 32 bits are in the second block
 23 2017-05-22 17:22:48 <Diablo-D3> that seems to be more complex than what I did
 24 2017-05-22 17:22:55 <arubi> so if you find say 4 merkle roots that have the same 32 last bits, then you can re-use that second block
 25 2017-05-22 17:23:04 <Diablo-D3> its trying to reduce work over further time by massaging the input
 26 2017-05-22 17:23:13 <Diablo-D3> clever, but it can't be _that_ time saving
 27 2017-05-22 17:23:21 <arubi> about 20% power saving
 28 2017-05-22 17:23:30 <Diablo-D3> 20% power saving, or 20% work saving
 29 2017-05-22 17:23:33 <Diablo-D3> they arent the same thing
 30 2017-05-22 17:23:35 <arubi> power
 31 2017-05-22 17:23:39 <arubi> same h/ps
 32 2017-05-22 17:23:48 <Diablo-D3> yeah, that just tells me something became inefficient.
 33 2017-05-22 17:24:08 <Diablo-D3> when I did round precalc on the cpu, power usage went up, but so did hps
 34 2017-05-22 17:24:31 <arubi> this asicboost thing is pretty big, are you just hearing about it now?
 35 2017-05-22 17:24:42 <Diablo-D3> I don't really pay attention to mining anymore
 36 2017-05-22 17:24:57 <arubi> it's caused quite a shitstorm
 37 2017-05-22 17:25:03 <arubi> the covert use of it that is
 38 2017-05-22 17:25:10 <Diablo-D3> but 20% power saving but not 20% work saving sounds like they fucked up
 39 2017-05-22 17:25:13 <Diablo-D3> its an incomplete solution
 40 2017-05-22 17:25:37 <Diablo-D3> due to the nature of asics, you can't just increase clock rate to compensate
 41 2017-05-22 17:25:47 <arubi> nobody's trying
 42 2017-05-22 17:25:54 <arubi> just add more asics :)
 43 2017-05-22 17:26:00 <Diablo-D3> yeah, you can do that
 44 2017-05-22 17:26:05 <Diablo-D3> but the way I view it
 45 2017-05-22 17:26:18 <Diablo-D3> 20% power saving, but not 20% increase in hashes means somebody is idle for 20%.
 46 2017-05-22 17:26:48 <arubi> well, you just don't do the work for the second block of the header
 47 2017-05-22 17:27:21 <arubi> it's also all done by software external to the asics
 48 2017-05-22 17:27:39 <arubi> finding the collisions that is
 49 2017-05-22 17:43:06 <simul> the reason you don't pay attention to mining any more is probably, indirectly, because of asicboost
 50 2017-05-22 17:45:24 <arubi> run bip148, let's fix this :)
 51 2017-05-22 19:10:55 <Chris_Stewart_5> arubi: You aren't concerned about the risk of chain splits / minority chain for BIP148?
 52 2017-05-22 19:11:21 <arubi> not if I'm running bip148 Chris_Stewart_5
 53 2017-05-22 19:11:41 <abpa> The only think you have to fear is fear itself
 54 2017-05-22 19:11:43 <Chris_Stewart_5> hah - well are you willing to be on the BIP148 chain indefinitely even if the economic majority is not?
 55 2017-05-22 19:12:01 <arubi> yep, at least it isn't broken by mining cartels
 56 2017-05-22 19:12:07 <arubi> it's time to face the truth here
 57 2017-05-22 19:12:19 <Chris_Stewart_5> re: mining cartels. No arguments there
 58 2017-05-22 19:12:43 <Chris_Stewart_5> I really want segwit to activate, but i don't think i've been convinced that BIP148 is a safe way to do it :-(
 59 2017-05-22 19:12:59 <arubi> it's the safest way for anyone who has money really
 60 2017-05-22 19:13:03 <arubi> there is 0 chance of reorg
 61 2017-05-22 19:13:19 <arubi> this is pure soft fork, like p2sh or whatever
 62 2017-05-22 19:13:26 <Chris_Stewart_5> 0 chance that the BIP148 chain gets reorg onto the non BIP148 chain you mean
 63 2017-05-22 19:13:38 <arubi> yes, like 0 chance of p2sh reverting
 64 2017-05-22 19:13:42 <arubi> (at the time even)
 65 2017-05-22 19:14:25 <Chris_Stewart_5> I think I would need to see some more economic players (merchants, exchanges) supporting BIP148 before I support it
 66 2017-05-22 19:14:49 <abpa> They follow users
 67 2017-05-22 19:14:54 <arubi> right, that would be great if happened beforehand
 68 2017-05-22 19:15:03 <Chris_Stewart_5> Some people keep talking about better ways to UASF than BIP148
 69 2017-05-22 19:15:09 <arubi> users have to run the nodes, this is a soft fork
 70 2017-05-22 19:15:16 <arubi> maybe, but that's too far offf
 71 2017-05-22 19:15:20 <arubi> off*
 72 2017-05-22 19:15:28 <arubi> we need to take advantage of segwit nodes already on the network
 73 2017-05-22 19:15:30 <Chris_Stewart_5> Have you read BIP8/BIP149?
 74 2017-05-22 19:15:48 <arubi> bip149 once, so not so clear.  but I get the idea
 75 2017-05-22 19:16:07 <arubi> I initially was against 148 and really for some flag day like bip149
 76 2017-05-22 19:16:18 <Chris_Stewart_5> Yes, but don't segwit nodes need to be upgraded to support the activation of BIP148?
 77 2017-05-22 19:16:24 <arubi> but I changed my mind, 0.13.1+ nodes are too valuable
 78 2017-05-22 19:16:32 <arubi> no
 79 2017-05-22 19:16:42 <arubi> they wait for segwit until nov 15th
 80 2017-05-22 19:16:49 <arubi> and 148 activates on aug 1st
 81 2017-05-22 19:17:06 <Chris_Stewart_5> Yes, but in the BIP9 activation cycle won't it fail because MASF doesn't have 95 %
 82 2017-05-22 19:17:22 <Chris_Stewart_5> so those old 0.13.1 nodes won't realize segwit is active?
 83 2017-05-22 19:17:23 <arubi> yes, if 148 nodes aren't numerous
 84 2017-05-22 19:17:37 <Chris_Stewart_5> so yeah, we need nodes to upgrade regardless :/
 85 2017-05-22 19:17:42 <arubi> no no
 86 2017-05-22 19:17:55 <arubi> 148 just has a set date to activate before bip9 runs out
 87 2017-05-22 19:18:05 <arubi> it's a stricter rule, a soft fork
 88 2017-05-22 19:18:20 <arubi> of course, if it's just 10 nodes, nobody cares and the chain goes on
 89 2017-05-22 19:18:36 <arubi> but if it's 30%, 50% of the nodes (we can do it..), then miners have to comply
 90 2017-05-22 19:19:02 <Chris_Stewart_5> it bothers me that BIP148 is very easy to sybil attack as well. How do you quantify how many *economic* nodes there are actually being used -- not just nodes spun up on EC2
 91 2017-05-22 19:19:11 <arubi> you don't
 92 2017-05-22 19:19:18 <arubi> just like any other soft fork pre- bip9
 93 2017-05-22 19:19:43 <arubi> back then it was obvious everyone would upgrade
 94 2017-05-22 19:20:01 <arubi> right now we see very fast adoption rate for new clients (I look at my own node's peers)
 95 2017-05-22 19:20:38 <Chris_Stewart_5> ^ that isn't a reliable way to measure
 96 2017-05-22 19:20:49 <arubi> you never measured nodes
 97 2017-05-22 19:21:15 <arubi> bip9 measures hashrate, bip8 assumes adoption is fine over some year
 98 2017-05-22 19:21:23 <arubi> some time* (a year?)
 99 2017-05-22 19:22:01 <arubi> comon, it's clear we have significant active community, and that a lot do run core and upgrade
100 2017-05-22 19:22:17 <abpa> Bitcoin has a social layer of consensus that is the answer to some problems
101 2017-05-22 19:22:28 <Chris_Stewart_5> Are you worried that this will be used in the future for less popular upgrades?
102 2017-05-22 19:22:45 <arubi> people have to run the code for such things
103 2017-05-22 19:23:01 <arubi> miners tried to pull extblocks without us noticing
104 2017-05-22 19:23:18 <arubi> soft forks can always happen with miners, there's no way around it
105 2017-05-22 19:23:20 <abpa> It's not a worry what other people want to do
106 2017-05-22 19:23:41 <abpa> You can't stop people from going on their own forks and that is just a fact of life
107 2017-05-22 19:23:55 <Chris_Stewart_5> also, BIP148/BIP8 streamlines the deployment of a hard fork doesn't it? I think your argument applies to soft forks/hard forks
108 2017-05-22 19:24:08 <abpa> These are for soft forks
109 2017-05-22 19:24:27 <arubi> I only looked at the soft fork aspect, didn't catch a hard fork reference in those
110 2017-05-22 19:24:33 <Chris_Stewart_5> I think it could be used for both. If it is a flag day and we have overwhelming consensus on it
111 2017-05-22 19:24:50 <Chris_Stewart_5> and I'm not sure if that is a good thing
112 2017-05-22 19:25:02 <abpa> It's fine
113 2017-05-22 19:25:20 <arubi> seems to be perfectly in spirit of bitcoin to me
114 2017-05-22 19:25:20 <Chris_Stewart_5> I like soft forks because it restricts the set of existing rules, but I think flag days could be used for hard forks as well which can be dangerous
115 2017-05-22 19:25:43 <arubi> again, people would have to run the hard fork code
116 2017-05-22 19:25:45 <abpa> Hard forks with flag days seem fine to me too
117 2017-05-22 19:25:53 <abpa> You can't stop it anyway
118 2017-05-22 19:26:07 <arubi> oh you mean if anybody else wants to fork?
119 2017-05-22 19:26:13 <Chris_Stewart_5> arubi: I think bitcoin needs to protect minority opinions, hard forks don't do this
120 2017-05-22 19:26:18 <Chris_Stewart_5> soft forks do
121 2017-05-22 19:26:22 <arubi> I agree
122 2017-05-22 19:26:46 <abpa> Soft forks should be favored, BIP 148 reinforces that idea
123 2017-05-22 19:27:00 <arubi> yes, that's what I gathered from it too
124 2017-05-22 19:27:20 <Chris_Stewart_5> Food for thought any way -- i've been thinking about that a lot :/
125 2017-05-22 19:27:31 <arubi> sure me too
126 2017-05-22 19:27:46 <arubi> the more 2017 advances, the more it becomes the most eventful year in bitcoin yet :)
127 2017-05-22 19:28:06 <abpa> It's a similar chicken and the egg problem to bitcoin: how can we have currency that is volatile? it has to be volatile before it is not volatile
128 2017-05-22 19:28:09 <Chris_Stewart_5> bitcoin is never boring -- i think we are due for an exchange to lose like 10MM in bitcoin any day now :P
129 2017-05-22 19:28:24 <abpa> BIP 148 has to be contentious before it is not contentious
130 2017-05-22 19:29:18 <Chris_Stewart_5> I think gmax had a good passage in a dev mailing list post about how the reputation of the system as conservative/rock solid is more important than contemporary changes
131 2017-05-22 19:29:20 <arubi> hopefully network effect takes in and bip148 gains more adoption.  this is crucial.. hopefully it's merged in core soon
132 2017-05-22 19:29:52 <arubi> yea, that post is correct, but we have new information now
133 2017-05-22 19:29:55 <abpa> Sometimes you have to take the least bad of two bad options
134 2017-05-22 19:30:16 <abpa> BIP9 was the safest rollout
135 2017-05-22 19:30:18 <Chris_Stewart_5> Hopefully we can get some major economic players to support BIP148. That would make me feel a lot better about it :-)
136 2017-05-22 19:30:22 <arubi> some rich folk set up a gathering in twitter and are now deciding to hard fork bitcoin in september
137 2017-05-22 19:30:53 <arubi> they have lots of signers, I'm sure you've seen barry's tweets etc
138 2017-05-22 19:31:07 <abpa> There's also a soft fork component to it
139 2017-05-22 19:31:24 <Chris_Stewart_5> I think we have successfully looped around to the beginning of the scaling debate -- didn't we have the exact same agreement like 2 years ago?
140 2017-05-22 19:31:25 <arubi> it's incompatible with segwit if that's what you mean
141 2017-05-22 19:31:28 <arubi> with bip141 that is
142 2017-05-22 19:31:31 <Chris_Stewart_5> exact same "agreement" i should say
143 2017-05-22 19:31:35 <arubi> they will be signaling bit 2
144 2017-05-22 19:31:59 <arubi> so 0.13.1+ nodes are dead anyway
145 2017-05-22 19:32:19 <arubi> we really have no choice but to take the network..
146 2017-05-22 19:32:40 <abpa> There's been lots of dumb agreements
147 2017-05-22 19:32:40 <arubi> this is really doomsday miners soft forking some contentious change on top of us
148 2017-05-22 19:33:41 <abpa> XT agreement (all the miners signed it) and BIP 101 (lots of blocks signal it) and the classic agreement (all the miners signed it) and then BU (lots blocks signal it)
149 2017-05-22 19:34:10 <arubi> this time it's really on a different scale
150 2017-05-22 19:34:13 <arubi> at least imo
151 2017-05-22 19:34:27 <Chris_Stewart_5> arubi: abpa Check out sdaftuar 's post on the mailing list. It is pretty good IMO.
152 2017-05-22 19:34:47 <arubi> link?  if it's part of the gmax thread then I've read them all
153 2017-05-22 19:34:58 <abpa> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014377.html
154 2017-05-22 19:35:06 <Chris_Stewart_5> It is like 10 minute sold
155 2017-05-22 19:35:09 <arubi> I was against bip148 even before that email, and really I had the same opinion
156 2017-05-22 19:35:16 <arubi> ahh alright
157 2017-05-22 19:35:20 <arubi> /humbled
158 2017-05-22 19:35:31 <Chris_Stewart_5> lol I just constantly spam refresh on the mailing list ;)
159 2017-05-22 19:36:14 <arubi> I have to sign up sometime and just get it over with :)
160 2017-05-22 19:36:21 <abpa> He's even against BIP 149
161 2017-05-22 19:36:35 <sdaftuar> i am?
162 2017-05-22 19:36:54 <abpa> > I'd recommend that we do so in a more careful way than BIP 148 or 149 currently suggest
163 2017-05-22 19:37:06 <sdaftuar> i think bip 149 has plenty of time for improvements
164 2017-05-22 19:37:14 <sdaftuar> my suggestions are not consensus critical, merely less disruptive
165 2017-05-22 19:37:41 <abpa> I misunderstood then
166 2017-05-22 19:38:18 <abpa> BIP 148 is a catch 22 - it would be perfectly safe if everyone ran it and then it is risky if no one runs it so if people avoid running it because it is risky they are self-defeating
167 2017-05-22 19:38:39 <Chris_Stewart_5> abpa: That appllies to every fork variation though. We want it to be safe even if people are *not* running it
168 2017-05-22 19:38:43 <arubi> sdaftuar, don't you think there's an element of urgency here now that we found out what miner's and co. have been discussing?
169 2017-05-22 19:39:16 <sdaftuar> no, i really don't.  i think segwit is great technology.  but i think we shoulnd't rush consensus changes in order to achieve it.
170 2017-05-22 19:39:39 <sdaftuar> in my view, in the long run it matters more whether we can maintain consensus than whether segwit activates this year or in 5 years
171 2017-05-22 19:39:40 <arubi> I'm worried about them activating segwit in a non bip9 manner
172 2017-05-22 19:39:42 <abpa> Why target 148 specifically and not make statements about this new bit 4 segwit - 2mb HF scheme as well?
173 2017-05-22 19:39:53 <abpa> That seems equally or more disruptive
174 2017-05-22 19:39:56 <sdaftuar> bip 148 has a PR that i oppose!
175 2017-05-22 19:40:20 <abpa> Yeah that was unfortunate
176 2017-05-22 19:40:27 <Chris_Stewart_5> abpa: The whole sw + 2MB thing sounds theoretical at best right now, BIP148 has concrete code
177 2017-05-22 19:40:37 <arubi> sdaftuar, they might start enforcing segwit without the current bip9 bit or using some other one
178 2017-05-22 19:40:52 <abpa> That risks a split but not much more than that
179 2017-05-22 19:40:58 <arubi> that would mean that new software would have to be rolled out immediately anyway
180 2017-05-22 19:40:59 <abpa> You can just avoid using that segwit
181 2017-05-22 19:41:00 <Chris_Stewart_5> also, arubi you need to get on the mailing list lol
182 2017-05-22 19:41:08 <arubi> :)
183 2017-05-22 19:41:36 <sdaftuar> arubi: i think we should all carefully evaluate when a proposal appears, for sure.
184 2017-05-22 19:42:01 <arubi> it's almost out there by now.. we can't wait until the last moment
185 2017-05-22 19:42:44 <abpa> Maybe we can see further discussion of BIP 149/BIP 8 strategies so we can have more thinking about how they can solve the problem
186 2017-05-22 19:42:44 <sdaftuar> arubi: part of the reason for my email was to fight the sense that some people seem to have that there will be some impending doom if we don't act quickly.
187 2017-05-22 19:43:15 <sdaftuar> arubi: if people believe that consensus can really change at the drop of a hat, i think bitcoin has bigger problems than any of us have previously thought
188 2017-05-22 19:43:37 <arubi> sdaftuar, it does have bigger problems than I assumed at least
189 2017-05-22 19:43:43 <abpa> It seems like people are looking to BIP 8 and BIP 149 as the solution but those are kind of unknown quantities because they haven't received a lot of feedback
190 2017-05-22 19:43:48 <arubi> asicboost, antbleed, bitmain altogether
191 2017-05-22 19:43:58 <arubi> this isn't healthy and will not be going into the future
192 2017-05-22 19:44:25 <Chris_Stewart_5> I actually think it would be interesting to deploy a fix for covert (invisible) ASICBOOST via UASF first. I think that is something the entire community could get behind
193 2017-05-22 19:44:40 <arubi> right, I am very for that too
194 2017-05-22 19:44:41 <Chris_Stewart_5> and obviously a large group of miners would be against it.
195 2017-05-22 19:44:47 <arubi> but bip148 is a superset of that
196 2017-05-22 19:45:03 <arubi> (at least if you include segwit transactions)
197 2017-05-22 19:45:04 <Chris_Stewart_5> arubi: Sort of. BIP148 doesn't fix covert ASICBOOST
198 2017-05-22 19:45:08 <Chris_Stewart_5> yea
199 2017-05-22 19:45:36 <arubi> eventually, it would be a lot easier after the commitment is used almost by everyone
200 2017-05-22 19:45:40 <arubi> except boosters that is
201 2017-05-22 19:45:59 <arubi> currently only f2pool has wtxid commitment
202 2017-05-22 19:46:08 <Chris_Stewart_5> Yeah, bluematt made made an argument that they will eventually be forced to implement it because they will lose out on segwit fees
203 2017-05-22 19:46:27 <Chris_Stewart_5> and fees are something like 30% of the block reward right now I think
204 2017-05-22 19:47:03 <arubi> things like MAST that can carry huge scripts in the witness..  I can't believe miners don't consider those
205 2017-05-22 19:47:33 <Chris_Stewart_5> What? Doesn't MAST adhere to the 10,000 byte script size?
206 2017-05-22 19:48:06 <Chris_Stewart_5> Only the 'happy path' is revealed in MAST, so that has to be <= 10,000 bytes IIRC
207 2017-05-22 19:48:22 <arubi> it does, but currently one script in p2sh is standard at 520 bytes
208 2017-05-22 19:48:42 <arubi> the path itself can be huge
209 2017-05-22 19:49:15 <Chris_Stewart_5> I'm confused. Can't you just use P2SH(P2WSH()) and then place MAST in the witness?
210 2017-05-22 19:49:56 <arubi> yes, but that witness can be a lot bigger than what a p2sh script in itself could be and still be standard
211 2017-05-22 19:50:20 <arubi> either the path or the script itself (concatenated scripts)
212 2017-05-22 19:50:44 <arubi> you could have a really big stack executing many concatenated scripts
213 2017-05-22 19:50:46 <Chris_Stewart_5> Does segwit enforce each witness stack item to be < 520 bytes?
214 2017-05-22 19:51:18 <arubi> probably not
215 2017-05-22 19:51:31 <arubi> oh each item!
216 2017-05-22 19:51:34 <arubi> not sure
217 2017-05-22 19:51:46 <Chris_Stewart_5> I know in old scripts the max push size is 520
218 2017-05-22 19:51:57 <arubi> hmm so maybe I'm confused here
219 2017-05-22 19:52:15 <arubi> well no I can't be
220 2017-05-22 19:52:32 <arubi> that's why you can't have like 20/20 multisig in p2sh right
221 2017-05-22 19:52:41 <arubi> oh, well yes
222 2017-05-22 19:52:44 <Chris_Stewart_5> Yes, the keys would be to big
223 2017-05-22 19:52:47 <arubi> that's the script being pushed :)
224 2017-05-22 19:52:58 <Chris_Stewart_5> 33 * 20 > 520
225 2017-05-22 19:53:00 <arubi> thanks for rubber duck etc. :)
226 2017-05-22 19:54:29 <arubi> Chris_Stewart_5, just checked, it follows the same rules.  max 10k bytes for script size and 520 for push
227 2017-05-22 19:54:50 <Chris_Stewart_5> Yeah, now that I was thinking about it, it would be a HF if it didn't I think
228 2017-05-22 19:55:25 <arubi> yes, sounds like it now
229 2017-05-22 22:52:51 <abpa> Seems like BlueMatt and Lightsword made a new proposal
230 2017-05-22 22:54:01 <Lightsword> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014380.html
231 2017-05-22 22:56:46 <abpa> Looks smart, hope suhas likes
232 2017-05-22 23:33:06 <abpa> luke-jr when can this get a bip #?