1 2017-04-30 05:27:10	0|bitcoin-git|[13bitcoin] 15jameshilliard opened pull request #10301: Check if sys/random.h is required for getentropy. (06master...06getentropy-rand) 02https://github.com/bitcoin/bitcoin/pull/10301
 2 2017-04-30 10:30:35	0|afk11|hey all. been looking at the MAST BIP and it got me wondering how jl2012 was able to do the hash-locked example. It's a good example for MAST (look what happens the DUP), and for parsing mutually exclusive execution pathways in general
 3 2017-04-30 10:31:42	0|afk11|anyways, I've come up with something that seems to allow one to produce the mutually exclusive branches for any script. Need to test it over more scripts 2bh, but it's coming along nicely
 4 2017-04-30 10:32:00	0|afk11|https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki#hashed-time-lock-contract
 5 2017-04-30 10:34:22	0|afk11|keeping in mind most bitcoin libraries only sign scripts that don't have any degrees of freedom with the pathway that's executed.. I'm starting out by iterating over script opcodes and making a tree out of possible execution pathways as they come
 6 2017-04-30 10:35:50	0|afk11|to do this, I start with a single node in the tree (the no logical ops case), and build up a vector of values of dependent ifs. for the above script, that's [true], [false, true], and [false, false] (same order jl2012 has them)
 7 2017-04-30 10:39:36	0|afk11|next, you need all the opcodes under that pathway.. I decided to do this separately to building the tree. Basically copy EvalScript, remove all opcodes but IF/ELSE/ENDIF/NOTIF, strip away some checks, and log all logical operations and opcodes where fExec==true. The mainStack is now only operated on by IF/ELSE/ENDIF/NOTIF, so you can pass in the vector of vchs representing the list above, ie, "\x01" for true, "" for false..
 8 2017-04-30 10:40:30	0|afk11|and that gets you a list of all opcodes in the script that you need to satisfy if you wished to sign it
 9 2017-04-30 10:42:04	0|afk11|I've only gotten as far as normal scripts, ie, bare or P2SH. MAST requires checking for side effects of earlier operations, and stripping away any where the predicate was failed.
10 2017-04-30 10:49:11	0|afk11|if this should be in #bitcoin-dev please someone let me know
11 2017-04-30 10:50:22	0|afk11|the general motivation behind all this is to allow signing of arbitrary scripts. you can only do that once you know if there are logical operations.. after that, looking at the opcodes just under that branch tells you what you need to satisfy in order to redeem using that branch
12 2017-04-30 10:53:16	0|afk11|with the branch specific opcodes, you can then try to break up the script into pieces the signer can understand, and may support: hashlocks, csv/cltv checks (signer should know the current time), signature operations
13 2017-04-30 10:59:45	0|afk11|I think using the [true], [false,true], [false, false] could be a good way of relating to another party to your script/payment channel which branch you are expecting them to sign. Wallets like Copay work by creating a proposed spend from a multisig address, and requesting signatures from others, and atm there isn't really a way to specify branches in a script agnostic way. Hardware wallets also may also face the same thing in the future
14 2017-04-30 11:04:33	0|afk11|anyway, I think if wallets come to deal with scripts with logical operators, the innermost Sign() function should really be checking that the user isn't accidentally working on the wrong branch, hence the need for to designate the branch in a way the software can verify against later.
15 2017-04-30 11:07:31	0|afk11|I don't want to use something like branch 1, 2, 3, because the allowed boolean values are specific to the script.
16 2017-04-30 11:26:04	0|bitcoin-git|[13bitcoin] 15spencerlievens opened pull request #10302: [Makefile] Alphabetically Reorder addrdb.cpp (06master...06patch-2) 02https://github.com/bitcoin/bitcoin/pull/10302
17 2017-04-30 11:34:27	0|afk11|oh, forgot to post a gist showing steps to try and sign that hashlock script: https://gist.github.com/afk11/cb276f78b7407773e76e81f6d5b62d4f
18 2017-04-30 18:04:58	0|NicolasDorier|is there a way in Bitcoin Core to get an unused address ? I am tempted to call getnewaddress everytimes, but doing so would create big gap in by BIP32 path, which would make rescanning fail
19 2017-04-30 18:22:52	0|sipa|bitcoin core doesn't support gaps or reconstruction from a seed at all
20 2017-04-30 18:22:54	0|sipa|(yet)
21 2017-04-30 18:36:28	0|SopaXorzTaker|dammit piqure
22 2017-04-30 18:37:14	0|SopaXorzTaker|banned me from #bitcoin for posting a malware link, explicitly marked like this and obsured: [https://]malware[.]coin.stealer
23 2017-04-30 18:39:28	0|NicolasDorier|sipa: I know, for now. jonasschnelli is working on it somewhere I saw recently. Anyway, do you know a way to get the latest unused address of the wallet ?
24 2017-04-30 18:39:42	0|NicolasDorier|or any unused address
25 2017-04-30 18:40:31	0|NicolasDorier|Another reason is that I provide a link to the user to send money to my address. And I don't want a user to generate a new address everytimes he hit F5 on my page
26 2017-04-30 18:40:39	0|NicolasDorier|other solutions to do it of course
27 2017-04-30 18:40:50	0|NicolasDorier|but if anything exist in core, would make life easier
28 2017-04-30 18:41:49	0|sipa|NicolasDorier: getnewaddress...
29 2017-04-30 18:43:21	0|sipa|NicolasDorier: or make your application cache a number of addresses ahead of time
30 2017-04-30 18:46:23	0|NicolasDorier|sipa: Imagine I want to show the QR code of an unused address of my wallet in the profile page of whatever social media service. If I use getnewaddress, then everytimes someone make a request to the QR code, a new address will bloat up my wallet, leading to DOS eventually.
31 2017-04-30 18:46:51	0|NicolasDorier|of course I can use the server generating the QR cache the latest created address and verify if not used
32 2017-04-30 18:47:03	0|sipa|NicolasDorier: yes, so cache addresses in your application, and remove them when used?
33 2017-04-30 18:47:41	0|sipa|there used to be a way in core get an unused address, which was only updated when a tx was seen to it
34 2017-04-30 18:47:57	0|sipa|but that's very hard to not make different RPC clients get in eachother's way
35 2017-04-30 18:48:05	0|NicolasDorier|ha ok I see
36 2017-04-30 18:48:31	0|NicolasDorier|well yes I will cache the address on the server side, and just make a request to bitcoin core to know if it was used before returning it to the server
37 2017-04-30 18:48:35	0|NicolasDorier|good enough
38 2017-04-30 18:55:40	0|afk11|*
39 2017-04-30 23:14:10	0|chatter29|hey guys