Transcript for #bitcoin-dev 2017/05/22

09:38 conman am I missing something about this alleged silbert agreement?
12:53 execute_ in a transaction's vout, how come the scriptpubkey has an array of addresses? Can there be more than 1 address?
17:09 arubi anybody knows what petertodd means here: ?
17:10 arubi or is it just a comment about the wtxid root being in the header itself?
17:12 arubi or is it a continuation from the previous tweet? twitter is hard :)
17:16 abpa It means you could asicboost and hide it
17:17 abpa Simple asicboost is granding the version number in the block header
17:17 arubi right, but that's overt
17:17 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
17:18 Diablo-D3 wtf is asicboost?
17:18 abpa arubi it makes it covert
17:18 arubi Diablo-D3, some way to re-use work and lower power consumption in asics
17:19 arubi abpa, what does?
17:19 abpa making the version bits into a nonce does
17:19 Diablo-D3 arubi: so its what I did in diablominer?
17:20 arubi right, I had trouble following the tweets timeline. thanks
17:20 arubi Diablo-D3, I don't know :), there's a pretty detailed paper that shows one way
17:20 Diablo-D3 I did pre-calc of the first few steps
17:21 Diablo-D3 saved about 12% of the time iirc
17:21 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
17:21 arubi here it's finding collisions of in the second sha256 block of the header
17:22 arubi the merkle root is in the header but 32 bits are in the second block
17:22 Diablo-D3 that seems to be more complex than what I did
17:22 arubi so if you find say 4 merkle roots that have the same 32 last bits, then you can re-use that second block
17:23 Diablo-D3 its trying to reduce work over further time by massaging the input
17:23 Diablo-D3 clever, but it can't be _that_ time saving
17:23 arubi about 20% power saving
17:23 Diablo-D3 20% power saving, or 20% work saving
17:23 Diablo-D3 they arent the same thing
17:23 arubi power
17:23 arubi same h/ps
17:23 Diablo-D3 yeah, that just tells me something became inefficient.
17:24 Diablo-D3 when I did round precalc on the cpu, power usage went up, but so did hps
17:24 arubi this asicboost thing is pretty big, are you just hearing about it now?
17:24 Diablo-D3 I don't really pay attention to mining anymore
17:24 arubi it's caused quite a shitstorm
17:25 arubi the covert use of it that is
17:25 Diablo-D3 but 20% power saving but not 20% work saving sounds like they fucked up
17:25 Diablo-D3 its an incomplete solution
17:25 Diablo-D3 due to the nature of asics, you can't just increase clock rate to compensate
17:25 arubi nobody's trying
17:25 arubi just add more asics :)
17:26 Diablo-D3 yeah, you can do that
17:26 Diablo-D3 but the way I view it
17:26 Diablo-D3 20% power saving, but not 20% increase in hashes means somebody is idle for 20%.
17:26 arubi well, you just don't do the work for the second block of the header
17:27 arubi it's also all done by software external to the asics
17:27 arubi finding the collisions that is
17:43 simul the reason you don't pay attention to mining any more is probably, indirectly, because of asicboost
17:45 arubi run bip148, let's fix this :)
19:10 Chris_Stewart_5 arubi: You aren't concerned about the risk of chain splits / minority chain for BIP148?
19:11 arubi not if I'm running bip148 Chris_Stewart_5
19:11 abpa The only think you have to fear is fear itself
19:11 Chris_Stewart_5 hah - well are you willing to be on the BIP148 chain indefinitely even if the economic majority is not?
19:12 arubi yep, at least it isn't broken by mining cartels
19:12 arubi it's time to face the truth here
19:12 Chris_Stewart_5 re: mining cartels. No arguments there
19:12 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 :-(
19:12 arubi it's the safest way for anyone who has money really
19:13 arubi there is 0 chance of reorg
19:13 arubi this is pure soft fork, like p2sh or whatever
19:13 Chris_Stewart_5 0 chance that the BIP148 chain gets reorg onto the non BIP148 chain you mean
19:13 arubi yes, like 0 chance of p2sh reverting
19:13 arubi (at the time even)
19:14 Chris_Stewart_5 I think I would need to see some more economic players (merchants, exchanges) supporting BIP148 before I support it
19:14 abpa They follow users
19:14 arubi right, that would be great if happened beforehand
19:15 Chris_Stewart_5 Some people keep talking about better ways to UASF than BIP148
19:15 arubi users have to run the nodes, this is a soft fork
19:15 arubi maybe, but that's too far offf
19:15 arubi off*
19:15 arubi we need to take advantage of segwit nodes already on the network
19:15 Chris_Stewart_5 Have you read BIP8/BIP149?
19:15 arubi bip149 once, so not so clear. but I get the idea
19:16 arubi I initially was against 148 and really for some flag day like bip149
19:16 Chris_Stewart_5 Yes, but don't segwit nodes need to be upgraded to support the activation of BIP148?
19:16 arubi but I changed my mind, 0.13.1+ nodes are too valuable
19:16 arubi no
19:16 arubi they wait for segwit until nov 15th
19:16 arubi and 148 activates on aug 1st
19:17 Chris_Stewart_5 Yes, but in the BIP9 activation cycle won't it fail because MASF doesn't have 95 %
19:17 Chris_Stewart_5 so those old 0.13.1 nodes won't realize segwit is active?
19:17 arubi yes, if 148 nodes aren't numerous
19:17 Chris_Stewart_5 so yeah, we need nodes to upgrade regardless :/
19:17 arubi no no
19:17 arubi 148 just has a set date to activate before bip9 runs out
19:18 arubi it's a stricter rule, a soft fork
19:18 arubi of course, if it's just 10 nodes, nobody cares and the chain goes on
19:18 arubi but if it's 30%, 50% of the nodes (we can do it..), then miners have to comply
19:19 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
19:19 arubi you don't
19:19 arubi just like any other soft fork pre- bip9
19:19 arubi back then it was obvious everyone would upgrade
19:20 arubi right now we see very fast adoption rate for new clients (I look at my own node's peers)
19:20 Chris_Stewart_5 ^ that isn't a reliable way to measure
19:20 arubi you never measured nodes
19:21 arubi bip9 measures hashrate, bip8 assumes adoption is fine over some year
19:21 arubi some time* (a year?)
19:22 arubi comon, it's clear we have significant active community, and that a lot do run core and upgrade
19:22 abpa Bitcoin has a social layer of consensus that is the answer to some problems
19:22 Chris_Stewart_5 Are you worried that this will be used in the future for less popular upgrades?
19:22 arubi people have to run the code for such things
19:23 arubi miners tried to pull extblocks without us noticing
19:23 arubi soft forks can always happen with miners, there's no way around it
19:23 abpa It's not a worry what other people want to do
19:23 abpa You can't stop people from going on their own forks and that is just a fact of life
19:23 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
19:24 abpa These are for soft forks
19:24 arubi I only looked at the soft fork aspect, didn't catch a hard fork reference in those
19:24 Chris_Stewart_5 I think it could be used for both. If it is a flag day and we have overwhelming consensus on it
19:24 Chris_Stewart_5 and I'm not sure if that is a good thing
19:25 abpa It's fine
19:25 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
19:25 arubi seems to be perfectly in spirit of bitcoin to me
19:25 arubi again, people would have to run the hard fork code
19:25 abpa Hard forks with flag days seem fine to me too
19:25 abpa You can't stop it anyway
19:26 arubi oh you mean if anybody else wants to fork?
19:26 Chris_Stewart_5 arubi: I think bitcoin needs to protect minority opinions, hard forks don't do this
19:26 Chris_Stewart_5 soft forks do
19:26 arubi I agree
19:26 abpa Soft forks should be favored, BIP 148 reinforces that idea
19:27 arubi yes, that's what I gathered from it too
19:27 Chris_Stewart_5 Food for thought any way -- i've been thinking about that a lot :/
19:27 arubi sure me too
19:27 arubi the more 2017 advances, the more it becomes the most eventful year in bitcoin yet :)
19:28 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
19:28 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
19:28 abpa BIP 148 has to be contentious before it is not contentious
19:29 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
19:29 arubi hopefully network effect takes in and bip148 gains more adoption. this is crucial.. hopefully it's merged in core soon
19:29 arubi yea, that post is correct, but we have new information now
19:29 abpa Sometimes you have to take the least bad of two bad options
19:30 abpa BIP9 was the safest rollout
19:30 Chris_Stewart_5 Hopefully we can get some major economic players to support BIP148. That would make me feel a lot better about it :-)
19:30 arubi some rich folk set up a gathering in twitter and are now deciding to hard fork bitcoin in september
19:30 arubi they have lots of signers, I'm sure you've seen barry's tweets etc
19:31 abpa There's also a soft fork component to it
19:31 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?
19:31 arubi it's incompatible with segwit if that's what you mean
19:31 arubi with bip141 that is
19:31 Chris_Stewart_5 exact same "agreement" i should say
19:31 arubi they will be signaling bit 2
19:31 arubi so 0.13.1+ nodes are dead anyway
19:32 arubi we really have no choice but to take the network..
19:32 abpa There's been lots of dumb agreements
19:32 arubi this is really doomsday miners soft forking some contentious change on top of us
19:33 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)
19:34 arubi this time it's really on a different scale
19:34 arubi at least imo
19:34 Chris_Stewart_5 arubi: abpa Check out sdaftuar 's post on the mailing list. It is pretty good IMO.
19:34 arubi link? if it's part of the gmax thread then I've read them all
19:34 abpa
19:35 Chris_Stewart_5 It is like 10 minute sold
19:35 arubi I was against bip148 even before that email, and really I had the same opinion
19:35 arubi ahh alright
19:35 arubi /humbled
19:35 Chris_Stewart_5 lol I just constantly spam refresh on the mailing list ;)
19:36 arubi I have to sign up sometime and just get it over with :)
19:36 abpa He's even against BIP 149
19:36 sdaftuar i am?
19:36 abpa > I'd recommend that we do so in a more careful way than BIP 148 or 149 currently suggest
19:37 sdaftuar i think bip 149 has plenty of time for improvements
19:37 sdaftuar my suggestions are not consensus critical, merely less disruptive
19:37 abpa I misunderstood then
19:38 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
19:38 Chris_Stewart_5 abpa: That appllies to every fork variation though. We want it to be safe even if people are *not* running it
19:38 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?
19:39 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.
19: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
19:39 arubi I'm worried about them activating segwit in a non bip9 manner
19:39 abpa Why target 148 specifically and not make statements about this new bit 4 segwit - 2mb HF scheme as well?
19:39 abpa That seems equally or more disruptive
19:39 sdaftuar bip 148 has a PR that i oppose!
19:40 abpa Yeah that was unfortunate
19:40 Chris_Stewart_5 abpa: The whole sw + 2MB thing sounds theoretical at best right now, BIP148 has concrete code
19:40 arubi sdaftuar, they might start enforcing segwit without the current bip9 bit or using some other one
19:40 abpa That risks a split but not much more than that
19:40 arubi that would mean that new software would have to be rolled out immediately anyway
19:40 abpa You can just avoid using that segwit
19:41 Chris_Stewart_5 also, arubi you need to get on the mailing list lol
19:41 arubi :)
19:41 sdaftuar arubi: i think we should all carefully evaluate when a proposal appears, for sure.
19:42 arubi it's almost out there by now.. we can't wait until the last moment
19:42 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
19:42 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.
19:43 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
19:43 arubi sdaftuar, it does have bigger problems than I assumed at least
19: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
19:43 arubi asicboost, antbleed, bitmain altogether
19:43 arubi this isn't healthy and will not be going into the future
19:44 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
19:44 arubi right, I am very for that too
19:44 Chris_Stewart_5 and obviously a large group of miners would be against it.
19:44 arubi but bip148 is a superset of that
19:45 arubi (at least if you include segwit transactions)
19:45 Chris_Stewart_5 arubi: Sort of. BIP148 doesn't fix covert ASICBOOST
19:45 Chris_Stewart_5 yea
19:45 arubi eventually, it would be a lot easier after the commitment is used almost by everyone
19:45 arubi except boosters that is
19:45 arubi currently only f2pool has wtxid commitment
19:46 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
19:46 Chris_Stewart_5 and fees are something like 30% of the block reward right now I think
19:47 arubi things like MAST that can carry huge scripts in the witness.. I can't believe miners don't consider those
19:47 Chris_Stewart_5 What? Doesn't MAST adhere to the 10,000 byte script size?
19:48 Chris_Stewart_5 Only the 'happy path' is revealed in MAST, so that has to be <= 10,000 bytes IIRC
19:48 arubi it does, but currently one script in p2sh is standard at 520 bytes
19:48 arubi the path itself can be huge
19:49 Chris_Stewart_5 I'm confused. Can't you just use P2SH(P2WSH()) and then place MAST in the witness?
19:49 arubi yes, but that witness can be a lot bigger than what a p2sh script in itself could be and still be standard
19:50 arubi either the path or the script itself (concatenated scripts)
19:50 arubi you could have a really big stack executing many concatenated scripts
19:50 Chris_Stewart_5 Does segwit enforce each witness stack item to be < 520 bytes?
19:51 arubi probably not
19:51 arubi oh each item!
19:51 arubi not sure
19:51 Chris_Stewart_5 I know in old scripts the max push size is 520
19:51 arubi hmm so maybe I'm confused here
19:52 arubi well no I can't be
19:52 arubi that's why you can't have like 20/20 multisig in p2sh right
19:52 arubi oh, well yes
19:52 Chris_Stewart_5 Yes, the keys would be to big
19:52 arubi that's the script being pushed :)
19:52 Chris_Stewart_5 33 * 20 > 520
19:53 arubi thanks for rubber duck etc. :)
19:54 arubi Chris_Stewart_5, just checked, it follows the same rules. max 10k bytes for script size and 520 for push
19:54 Chris_Stewart_5 Yeah, now that I was thinking about it, it would be a HF if it didn't I think
19:55 arubi yes, sounds like it now
22:52 abpa Seems like BlueMatt and Lightsword made a new proposal
22:54 Lightsword
22:56 abpa Looks smart, hope suhas likes
23:33 abpa luke-jr when can this get a bip #?