Transcript for #bitcoin-dev 2017/05/23

00:59 midnightmagic lol
02:36 ryan-c anyone know how to craft a transaction spending a non-standard redeemScript?
02:49 ryan-c argh
02:49 ryan-c why did my testnet daemon derp up the chain?
02:49 msbrogli I was looking at miner.cpp and it seems that the tx selection algorithm is not optimal, since it selects the ones with higher freerate. It seems to be an optimization problem equivalent to the knapsack 0/1 problem. Does it make sense? I will develop the algorithm. I’m just checking before coding.
02:50 ryan-c msbrogli: yes, it's the knapsack problem
02:51 msbrogli Do you know why it has not been implemented yet?
02:53 ryan-c msbrogli: I think the current algorithm is "good enough"
02:54 ryan-c someone wrote about it here https://freedom-to-tinker.com/2014/10/27/bitcoin-mining-is-np-hard/
02:54 ryan-c you might be able to get an extra 1% out of a block maybe
02:54 ryan-c probably not even that
02:54 ryan-c probably not even 0.01%
02:58 msbrogli ryan-c: I’ll take a read. I also found some discussions about it at Github. Thanks!!
02:59 ryan-c msbrogli: have fun
13:24 luke-jr kallewoof: https://github.com/bitcoin/bips/pull/538 please either do the file rename & README update, or allow me to push to your branch
14:01 ryan-c Hey, can anyone point me at an example of how to construct a transaction to spend a an output to a non-standard p2sh script?
14:03 ryan-c luke-jr: Hey, I don't suppose you can help me with this?
16:15 BlueMatt abpa: heh, suhas is not a fan
16:15 ryan-c luke-jr: can you give me some help with p2sh transactions?
16:15 abpa BlueMatt cest la vie
16:16 BlueMatt i think its more a question of how agressive you want to be...certainly suhas is right that there are better ways we can go about segwit activation (even under uasf), but most of them require waiting for the timeout first
16:16 luke-jr I disagree those ways are better
16:16 luke-jr it leaves too much uncertainty for Segwit
16:16 BlueMatt that a way which does not orphan any existing unmodified miners is not better?
16:16 abpa It's kind of a circular argument, it's aggressive because of lack of support which is lacking because of how aggressive it is
16:16 BlueMatt I think thats certainly better from a technical perspective
16:17 luke-jr there is no such thing as unmodified miners ;)
16:17 abpa Jihan clearly promises a chain split regardless
16:17 BlueMatt abpa: only kinda, i mean there is a difference between lack of support and whether miners will, by default, mine blocks which are invalid under the proposed fork
16:17 BlueMatt eg non-segwit miners can keep mining after segwit and will mine perfectly valid blocks
16:17 BlueMatt which is a super nice feature
16:17 abpa I just want some UASF, 148 or 149 or whatever
16:18 luke-jr BlueMatt: until someone mines one malicious block, then they all follow it
16:18 abpa Lightsword did specify that this is similar behavior to the previous soft forks that target on versioning
16:18 BlueMatt indeed, but if you have a simple majority of miners it is much safer for miners
16:18 abpa I do concede that a 149 style fork is "stickier" since you have the naive miners swinging to whichever side has the 50%+
16:19 luke-jr BlueMatt: not much safer, no.
16:19 BlueMatt to your point, luke-jr, about uncertainty, indeed, the reason I'm ok with the Lightsword proposal is because I do, personally, see the arguments about uncertainty in the ecosystem as an issue
16:19 BlueMatt but its a question of how critical an issue you actually think things are
16:19 luke-jr BIP 148's style is arguably safer since the non-enforcing miners get compelled to update sooner
16:20 BlueMatt i very strongly disagree with that sentiment
16:23 BlueMatt we have historically *never* taken a position that miners should be "compelled" to upgrade, if you want to compell miners, it should be by the market not wanting to pay them for their coins, not encouraging other miners to orphan them in ways that are super agressive...the Lightsword sits ok with me cause there is still a lock-in and reasonable threshold, plus the "upgrade" doesnt require segwit, only setting the version bit appropriately
16:23 BlueMatt but, indeed, even that is a bit agressive, and I can certainly understand sdaftuar's position on it
16:34 Lightsword BlueMatt, yeah I don’t really see it being fundamentally different from previous ISM forks
20:46 arubi ryan-c, got that tx eventually?
21:06 ryan-c arubi: yeah, i did
21:07 arubi ah nice :)
21:07 ryan-c arubi: I found some code from petertodd from python-bitcoinlib that i was able to modify to spend the output
21:07 arubi cool, can you tell what the script was?
21:08 ryan-c <pubkey> <four byte nonce> OP_DROP OP_CHECKSIG
21:09 arubi okay, so what's the nonce for?
21:10 ryan-c purely to make the hash different
21:10 ryan-c experimenting with ways to generate lots of valid p2sh addresses at high speed
21:10 ryan-c vanity addresses are one possible use (i know some people here hate them...)
21:11 arubi hehe yea :), so you're using one key 2^32 times then?
21:11 ryan-c cycling through nonces until i get one that gives me an interesting p2sh address
21:12 ryan-c don't have to generate a new key per address
21:12 arubi mhm, well that would really stand out as a spend on the chain if anything
21:13 ryan-c yes, it would
21:13 ryan-c a 1-of-2 would be less obvious
21:14 arubi yep, or some non activated op_csv \ cltv
21:14 arubi that's pretty much standard and only costs you one more byte for the op. you'd use DROP anyway
21:14 ryan-c that gives five bytes to twiddle at the beginning of the second sha256 block
21:15 ryan-c is there a "standard" form for csv/cltv?
21:15 ryan-c you could generate times in the past with cltv
21:15 arubi <pubkey> <4 byte value> <cltv\csv> <drop> <checksig> would work
21:15 arubi or just use some sequence that doesn't activate it
21:16 arubi or version 1 transactions for op_csv, that would deactivate it altogether
21:16 ryan-c yeah, i'm writing a tool which will just insert the nonce (probably support 1 to 8 bytes) into a template
21:17 ryan-c so whatever script would work
21:17 arubi well bignum is 5 bytes maximum, so csv\cltv wouldn't work with that value (not that it matters if they don't execute)
21:19 ryan-c the example cltv transaction i saw was <4 byte value> <cltv> <dup> <hash160> <pkh> <equalverify> <checksig>
21:19 ryan-c yeah, it depends what one is doing
21:19 arubi right so here it'd fail before everything starts if cltv isn't satisfied. I think using csv is better anyway
21:20 arubi still need to re-read the bips though, maybe some caveats I'm forgetting
21:20 ryan-c i think if one wants to be sneaky, 1-of-2 is the way to go, otherwise just inserting the nonce somewhere and dropping it is fine
21:21 ryan-c 1-of-2 also avoids needing a custom tool to spend
21:21 arubi right
21:21 arubi bleh I'm ignoring the fact that csv\cltv have to be satisfied
21:21 ryan-c since the bitcoin rpc api doesn't seem to be able to deal with signing a non-standard p2sh transaction
21:21 ryan-c cltv seems easier to satisfy because you can set the time in the past
21:22 arubi yea
21:22 ryan-c has to be above 500,000,000 and then below the current time, which is like 30 bits to play with
21:23 arubi but still, why use vanity addresses?
21:23 arubi or maybe it's not for daily use
21:23 ryan-c arubi: They're fun?
21:24 arubi ok, good enough :)
21:24 ryan-c arubi: I have one that is 1<all lowercase>
21:24 arubi yep, I saw that one
21:25 ryan-c have it on my keybase profile, and sometimes use it to make "hey dumbass, i have your private key" transactions
21:25 arubi sounds fun, oh you could write the first vanity generator for bech32, for segwit!
21:26 ryan-c i might
21:27 ryan-c I've mostly been working on some further research involving cracking different stuff brainflayer (i submitted a talk about this for bsideslv in july)
21:27 ryan-c The p2sh vanity generator will be a good thing to learn some GPU programming on.
21:28 arubi neat. I'm looking for that talk
21:28 ryan-c the funny thing about bech32 is it's actually pretty quick to grind out a bitcoin address that matches ^[1-9A-Z]+$ allowing for smaller QR codes
21:29 abpa ryan-c that is cool
21:29 ryan-c but i think the switch to using error correcting codes rather than a checksum is *fantastic*
21:34 arubi oh man it's late.. night!
21:34 ryan-c arubi: europe?
21:34 arubi ME
21:34 ryan-c ah