1 2017-05-23 00:59:02 <midnightmagic> lol
2 2017-05-23 02:36:51 <ryan-c> anyone know how to craft a transaction spending a non-standard redeemScript?
3 2017-05-23 02:49:03 <ryan-c> argh
4 2017-05-23 02:49:17 <ryan-c> why did my testnet daemon derp up the chain?
5 2017-05-23 02:49:24 <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.
6 2017-05-23 02:50:30 <ryan-c> msbrogli: yes, it's the knapsack problem
7 2017-05-23 02:51:06 <msbrogli> Do you know why it has not been implemented yet?
8 2017-05-23 02:53:37 <ryan-c> msbrogli: I think the current algorithm is "good enough"
9 2017-05-23 02:54:06 <ryan-c> someone wrote about it here https://freedom-to-tinker.com/2014/10/27/bitcoin-mining-is-np-hard/
10 2017-05-23 02:54:39 <ryan-c> you might be able to get an extra 1% out of a block maybe
11 2017-05-23 02:54:44 <ryan-c> probably not even that
12 2017-05-23 02:54:54 <ryan-c> probably not even 0.01%
13 2017-05-23 02:58:18 <msbrogli> ryan-c: Iââ¬â¢ll take a read. I also found some discussions about it at Github. Thanks!!
14 2017-05-23 02:59:58 <ryan-c> msbrogli: have fun
15 2017-05-23 13:24:29 <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
16 2017-05-23 14:01:15 <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?
17 2017-05-23 14:03:58 <ryan-c> luke-jr: Hey, I don't suppose you can help me with this?
18 2017-05-23 16:15:22 <BlueMatt> abpa: heh, suhas is not a fan
19 2017-05-23 16:15:26 <ryan-c> luke-jr: can you give me some help with p2sh transactions?
20 2017-05-23 16:15:31 <abpa> BlueMatt cest la vie
21 2017-05-23 16:16:00 <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
22 2017-05-23 16:16:23 <luke-jr> I disagree those ways are better
23 2017-05-23 16:16:36 <luke-jr> it leaves too much uncertainty for Segwit
24 2017-05-23 16:16:41 <BlueMatt> that a way which does not orphan any existing unmodified miners is not better?
25 2017-05-23 16:16:47 <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
26 2017-05-23 16:16:49 <BlueMatt> I think thats certainly better from a technical perspective
27 2017-05-23 16:17:00 <luke-jr> there is no such thing as unmodified miners ;)
28 2017-05-23 16:17:16 <abpa> Jihan clearly promises a chain split regardless
29 2017-05-23 16:17:16 <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
30 2017-05-23 16:17:29 <BlueMatt> eg non-segwit miners can keep mining after segwit and will mine perfectly valid blocks
31 2017-05-23 16:17:36 <BlueMatt> which is a super nice feature
32 2017-05-23 16:17:39 <abpa> I just want some UASF, 148 or 149 or whatever
33 2017-05-23 16:18:07 <luke-jr> BlueMatt: until someone mines one malicious block, then they all follow it
34 2017-05-23 16:18:14 <abpa> Lightsword did specify that this is similar behavior to the previous soft forks that target on versioning
35 2017-05-23 16:18:45 <BlueMatt> indeed, but if you have a simple majority of miners it is much safer for miners
36 2017-05-23 16:18:57 <abpa> I do concede that a 149 style fork is "stickier" since you have the naive miners swinging to whichever side has the 50%+
37 2017-05-23 16:19:05 <luke-jr> BlueMatt: not much safer, no.
38 2017-05-23 16:19:28 <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
39 2017-05-23 16:19:40 <BlueMatt> but its a question of how critical an issue you actually think things are
40 2017-05-23 16:19:50 <luke-jr> BIP 148's style is arguably safer since the non-enforcing miners get compelled to update sooner
41 2017-05-23 16:20:24 <BlueMatt> i very strongly disagree with that sentiment
42 2017-05-23 16:23:02 <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
43 2017-05-23 16:23:30 <BlueMatt> but, indeed, even that is a bit agressive, and I can certainly understand sdaftuar's position on it
44 2017-05-23 16:34:27 <Lightsword> BlueMatt, yeah I donââ¬â¢t really see it being fundamentally different from previous ISM forks
45 2017-05-23 20:46:29 <arubi> ryan-c, got that tx eventually?
46 2017-05-23 21:06:49 <ryan-c> arubi: yeah, i did
47 2017-05-23 21:07:11 <arubi> ah nice :)
48 2017-05-23 21:07:20 <ryan-c> arubi: I found some code from petertodd from python-bitcoinlib that i was able to modify to spend the output
49 2017-05-23 21:07:41 <arubi> cool, can you tell what the script was?
50 2017-05-23 21:08:33 <ryan-c> <pubkey> <four byte nonce> OP_DROP OP_CHECKSIG
51 2017-05-23 21:09:56 <arubi> okay, so what's the nonce for?
52 2017-05-23 21:10:10 <ryan-c> purely to make the hash different
53 2017-05-23 21:10:34 <ryan-c> experimenting with ways to generate lots of valid p2sh addresses at high speed
54 2017-05-23 21:10:59 <ryan-c> vanity addresses are one possible use (i know some people here hate them...)
55 2017-05-23 21:11:29 <arubi> hehe yea :), so you're using one key 2^32 times then?
56 2017-05-23 21:11:56 <ryan-c> cycling through nonces until i get one that gives me an interesting p2sh address
57 2017-05-23 21:12:20 <ryan-c> don't have to generate a new key per address
58 2017-05-23 21:12:57 <arubi> mhm, well that would really stand out as a spend on the chain if anything
59 2017-05-23 21:13:04 <ryan-c> yes, it would
60 2017-05-23 21:13:17 <ryan-c> a 1-of-2 would be less obvious
61 2017-05-23 21:14:02 <arubi> yep, or some non activated op_csv \ cltv
62 2017-05-23 21:14:23 <arubi> that's pretty much standard and only costs you one more byte for the op. you'd use DROP anyway
63 2017-05-23 21:14:44 <ryan-c> that gives five bytes to twiddle at the beginning of the second sha256 block
64 2017-05-23 21:15:19 <ryan-c> is there a "standard" form for csv/cltv?
65 2017-05-23 21:15:42 <ryan-c> you could generate times in the past with cltv
66 2017-05-23 21:15:46 <arubi> <pubkey> <4 byte value> <cltv\csv> <drop> <checksig> would work
67 2017-05-23 21:15:58 <arubi> or just use some sequence that doesn't activate it
68 2017-05-23 21:16:14 <arubi> or version 1 transactions for op_csv, that would deactivate it altogether
69 2017-05-23 21:16:46 <ryan-c> yeah, i'm writing a tool which will just insert the nonce (probably support 1 to 8 bytes) into a template
70 2017-05-23 21:17:01 <ryan-c> so whatever script would work
71 2017-05-23 21:17:37 <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)
72 2017-05-23 21:19:08 <ryan-c> the example cltv transaction i saw was <4 byte value> <cltv> <dup> <hash160> <pkh> <equalverify> <checksig>
73 2017-05-23 21:19:47 <ryan-c> yeah, it depends what one is doing
74 2017-05-23 21:19:57 <arubi> right so here it'd fail before everything starts if cltv isn't satisfied. I think using csv is better anyway
75 2017-05-23 21:20:24 <arubi> still need to re-read the bips though, maybe some caveats I'm forgetting
76 2017-05-23 21:20:45 <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
77 2017-05-23 21:21:03 <ryan-c> 1-of-2 also avoids needing a custom tool to spend
78 2017-05-23 21:21:08 <arubi> right
79 2017-05-23 21:21:23 <arubi> bleh I'm ignoring the fact that csv\cltv have to be satisfied
80 2017-05-23 21:21:23 <ryan-c> since the bitcoin rpc api doesn't seem to be able to deal with signing a non-standard p2sh transaction
81 2017-05-23 21:21:50 <ryan-c> cltv seems easier to satisfy because you can set the time in the past
82 2017-05-23 21:22:01 <arubi> yea
83 2017-05-23 21:22:38 <ryan-c> has to be above 500,000,000 and then below the current time, which is like 30 bits to play with
84 2017-05-23 21:23:30 <arubi> but still, why use vanity addresses?
85 2017-05-23 21:23:54 <arubi> or maybe it's not for daily use
86 2017-05-23 21:23:57 <ryan-c> arubi: They're fun?
87 2017-05-23 21:24:06 <arubi> ok, good enough :)
88 2017-05-23 21:24:13 <ryan-c> arubi: I have one that is 1<all lowercase>
89 2017-05-23 21:24:21 <arubi> yep, I saw that one
90 2017-05-23 21:25:11 <ryan-c> have it on my keybase profile, and sometimes use it to make "hey dumbass, i have your private key" transactions
91 2017-05-23 21:25:52 <arubi> sounds fun, oh you could write the first vanity generator for bech32, for segwit!
92 2017-05-23 21:26:04 <ryan-c> i might
93 2017-05-23 21:27:09 <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)
94 2017-05-23 21:27:43 <ryan-c> The p2sh vanity generator will be a good thing to learn some GPU programming on.
95 2017-05-23 21:28:22 <arubi> neat. I'm looking for that talk
96 2017-05-23 21:28:58 <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
97 2017-05-23 21:29:28 <abpa> ryan-c that is cool
98 2017-05-23 21:29:35 <ryan-c> but i think the switch to using error correcting codes rather than a checksum is *fantastic*
99 2017-05-23 21:34:24 <arubi> oh man it's late.. night!
100 2017-05-23 21:34:41 <ryan-c> arubi: europe?
101 2017-05-23 21:34:50 <arubi> ME
102 2017-05-23 21:34:55 <ryan-c> ah