1 2015-11-24 05:07:22 <btcdrak> gmaxwell: I think it would be a good idea to merge #245. Regardless of whether the spec is perfected or not, the PR does represent the current implementation and is less confusing for people who might read the wrong version.
2 2015-11-24 08:04:31 <jonasschnelli> CodeShark: Example: for the hardware wallet Im working on, i could use a function where I can pass a script template with pubkeys and keypath (for the one that are controlled by the HWW).
3 2015-11-24 08:05:29 <CodeShark> you can insert literal keys into a template (the pubkeys are not templated)
4 2015-11-24 08:05:42 <jonasschnelli> Example: i have a 2of3 ms input. I'd like to my ms signature. So i need to build the redeem script. The HWW does not derive pubkeys from the other participants, ... so having a pubkey (33bytes comp.) instead of a keypath could make sense?
5 2015-11-24 08:05:54 <jonasschnelli> okay.
6 2015-11-24 08:06:45 <jonasschnelli> CodeShark: and your bip does not cover how to pass around partial signed transactions? (IMO this is another things that should have a bip).
7 2015-11-24 08:06:59 <CodeShark> right, I decided to limit the scope of this BIP
8 2015-11-24 08:07:09 <CodeShark> there are a few other problems that also need solving for a complete system
9 2015-11-24 08:07:26 <jonasschnelli> Assumption: i have a partical signed inputs (multisig), ... what standard would be there to pass on the signatures to the next signer.
10 2015-11-24 08:07:49 <CodeShark> right - and given what sipa's been working on, that might change
11 2015-11-24 08:07:55 <jonasschnelli> I need to take a look in how bitcoin-cores rawtransaction handles that.
12 2015-11-24 08:08:06 <jonasschnelli> CodeShark: what is he working on?
13 2015-11-24 08:08:33 <CodeShark> for my stuff I've been using empty placeholders for signatures...but I think gmaxwell and sipa have come up with something better
14 2015-11-24 08:08:42 <CodeShark> with segregated witness
15 2015-11-24 08:09:16 <CodeShark> sipa wants to use an input vector containing arbitrary data
16 2015-11-24 08:10:05 <CodeShark> so that would effectively treat input fields separately from the redeemscript
17 2015-11-24 08:10:07 <jonasschnelli> Indeed. A vector/map with arbitrary data would be nice.
18 2015-11-24 08:11:26 <CodeShark> SW has a significant impact in the way signatures are passed around
19 2015-11-24 08:12:14 <CodeShark> in my stuff, I've also been using an internal "normalized hash" where I use empty placeholders for all signatures and hash the unsigned transaction
20 2015-11-24 08:12:34 <CodeShark> with SW, this issue goes away
21 2015-11-24 08:14:18 <jonasschnelli> CodeShark: SW?
22 2015-11-24 08:14:42 <CodeShark> segregated witness, although I've been considering calling it "green monkey" since to most people the name is about as descriptive and it lends itself to cooler branding and logos :p
23 2015-11-24 08:16:21 <CodeShark> you're familiar with the concept, yes?
24 2015-11-24 08:16:25 <aj> CodeShark: "confidential informant" would almost work :)
25 2015-11-24 08:16:36 <CodeShark> almost :)
26 2015-11-24 08:16:47 <btcdrak> snitch
27 2015-11-24 08:18:57 <jonasschnelli> CodeShark: I think that the stuff that sipa has implemented for Alpha? https://github.com/ElementsProject/elements/commit/663e9bd32965008a43a08d1d26ea09cbb14e83aa?
28 2015-11-24 08:19:15 <CodeShark> yes, sorta - except Luke-Jr figured out how to make it a soft fork in bitcoin
29 2015-11-24 08:19:34 <CodeShark> so now it actually looks viable :)
30 2015-11-24 08:19:36 <aj> btcdrak: with the quidditch p2p message allowing you to catch the snitch?
31 2015-11-24 08:20:17 <CodeShark> so chances are the actual implementation will differ markedly from what sipa did in elements alpha
32 2015-11-24 08:21:02 <aj> CodeShark, jonasschnelli: https://github.com/sipa/bitcoin/commits/segwit is the soft forked segwit code i think?
33 2015-11-24 08:21:03 <gmaxwell> aj: no, you subponea the witness. :P darn you people and your neologisms.
34 2015-11-24 08:21:08 <btcdrak> aj: yes, but we have to be careful of House Slytherin, they might plan an attack.
35 2015-11-24 08:21:38 <aj> btcdrak: can we call miners Hash Eaters then?
36 2015-11-24 08:21:45 <CodeShark> aj: yes
37 2015-11-24 08:22:02 <btcdrak> CodeShark: has it been legalised in all states yet?
38 2015-11-24 08:22:11 <CodeShark> we will make it legal :)
39 2015-11-24 08:29:44 <btcdrak> CodeShak: does that require a soft fork or a hard fork?
40 2015-11-24 08:33:34 <CodeShark> making it legal? :)
41 2015-11-24 08:33:35 <CodeShark> lol
42 2015-11-24 08:33:54 <CodeShark> hard forks are easy - it's merging that's a bitch
43 2015-11-24 08:34:43 <CodeShark> divide and conquer :)
44 2015-11-24 08:36:06 <CodeShark> there's also slushforks ;)
45 2015-11-24 08:36:18 <CodeShark> where SPV clients can't tell which chain is legit
46 2015-11-24 10:39:18 <btcdrak> For anyone not subscribed to the bitcoin-dev ML, I posted "Alternative name for CHECKSEQUENCEVERIFY (BIP112)" http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011801.html
47 2015-11-24 10:45:42 <aj> btcdrak: woo, bikeshed thread!
48 2015-11-24 10:46:36 <btcdrak> heh.
49 2015-11-24 10:47:49 <aj> btcdrak: i like delay vs timeout personally; so OP_CHECK_DELAY_VERIFY i guess...
50 2015-11-24 10:48:26 <moa> bounties for winning Op_CODE names could be a great distraction from that 'other' bike shed topic though
51 2015-11-24 10:48:32 <btcdrak> aj: anything non generic will do for me
52 2015-11-24 10:49:17 <aj> btcdrak: do you think mempool-only bip68 has met all the objections now? guess it's deferred to 0.12.1 though...
53 2015-11-24 10:50:30 <btcdrak> aj: the softfork was always going to be deferred till post 0.12 but the mempool policy can and should be merged now-ish.
54 2015-11-24 10:53:28 <btcdrak> aj: i do believe the specification is settled. amusingly petertodd read the old spec found some issued and reinvented the new spec which was agreed in October... so i think that may be a good sign.
55 2015-11-24 10:53:53 <aj> btcdrak: yeah, saw that; does seem +ve
56 2015-11-24 10:57:49 <sipa> btcdrak: OP_RELATIVE_HODL ?
57 2015-11-24 10:58:12 <btcdrak> sipa: yay!
58 2015-11-24 11:16:55 <moa> OP_RLTVHODL
59 2015-11-24 11:23:34 <CodeShark> OP_NOP3_PSYCHE_FOOLED_YA
60 2015-11-24 12:19:59 <btcdrak> OP_ALLYOURCOINSBELONGTOME
61 2015-11-24 12:48:44 <wachub> Hi.. has anyone looked into a decentralized bitcoin/fiat currency exchange, with peer to peer participants , and a trust system backing it....
62 2015-11-24 12:51:00 <phantomcircuit> wachub, #bitcoin
63 2015-11-24 15:09:46 <jtimon> cfields_: please tell me up to which commit https://github.com/bitcoin/bitcoin/pull/7091 makes sense to you (this is related to what we talked about the other day)
64 2015-11-24 15:13:01 <jtimon> CodeShark: I remember you saying that libconsensus doesn't exist yet. It's incomplete but it does exist: #7091 makes it much more clear
65 2015-11-24 15:19:26 <nickler> Did someone already publish code to benchmark blocks that take a long time to validate (f.e. due many checkopsigs, c.f. "A transaction that takes at least 3 minutes to validate")?
66 2015-11-24 16:44:11 <gavinandresen> nickler: run with -debug=bench and you'll get timing info in debug.log.
67 2015-11-24 16:57:56 <nickler> gavinandresen: So in regtest mode I would create a 955kb tx that executes many checksigs, then mine it with 'generate' and record the -bench ConnectBlock duration.
68 2015-11-24 16:58:58 <gavinandresen> nickler: yup, that would work. You could save the blockchain and use invalidateblock/reconsiderblock to re-run the benchmark....
69 2015-11-24 16:59:46 <sipa> yeah, though that wouldn't flush the signature cache (if the signature validation is something you want to include in the benchmark)
70 2015-11-24 17:00:15 <gavinandresen> nickler: git HEAD also has a src/benchmark/ framework that I wrote, but a some of the code you want to benchmark relies on global state so writing benchmarks isn't as easy as it should be.
71 2015-11-24 17:02:22 <gavinandresen> Yes, depending if you do or don't want the signature cache to be warm you'd need to either sendrawtransaction all the transactions first (if you want them in the cache) or invalidateblock, shutdown, restart, then reconsiderblock. I think....
72 2015-11-24 17:03:59 <nickler> so the signature cache is not saved to disk?
73 2015-11-24 17:04:17 <sipa> nickler: no, it's in memory only, and uses random eviction
74 2015-11-24 17:04:48 <sipa> nickler: also, the signature cache is only a replacement for actual ECDSA verification; sighash computation is not cached
75 2015-11-24 17:05:35 <nickler> I want to research the worst-case so I'll try the invalidate and restart method
76 2015-11-24 17:05:54 <sipa> nickler: i can write a very simple patch for you to invalidate the sigcache if you need it
77 2015-11-24 17:06:32 <gavinandresen> ... can also run with a very small signature cache, right?
78 2015-11-24 17:06:53 <sipa> gavinandresen: true!
79 2015-11-24 17:06:54 <nickler> sipa: I'd prefer not to modify bitcoind
80 2015-11-24 17:07:15 <sipa> gavinandresen: though that may negatively impact performance in other areas too
81 2015-11-24 17:07:34 <phantomcircuit> nickler, many OP_CHECKSIG ops is not worst case actually
82 2015-11-24 17:07:44 <sipa> nickler: by adding a separate RPC to wipe the sigcache?
83 2015-11-24 17:07:56 <nickler> sipa: by restarting?
84 2015-11-24 17:08:09 <gavinandresen> phantomcircuit: what IS the worst case?
85 2015-11-24 17:08:32 <nickler> phantomcircuit: OP_CHECKMULTISIG 1/20 ?
86 2015-11-24 17:08:48 <phantomcircuit> gavinandresen, the one with the CVE
87 2015-11-24 17:09:03 <phantomcircuit> by a huge margin
88 2015-11-24 17:09:10 <phantomcircuit> CVE-2013-2292
89 2015-11-24 17:10:36 <gavinandresen> phantomcircuit: that IS many OP_CHECKSIGs....
90 2015-11-24 17:10:49 <nickler> "bitcoind and Bitcoin-Qt 0.8.0 and earlier allow remote attackers to cause a denial of service (electricity consumption) by mining a block to create a nonstandard Bitcoin transaction containing multiple OP_CHECKSIG script opcodes."
91 2015-11-24 17:12:24 <phantomcircuit> gavinandresen, yeah if you use multisig you can get more hashing into a single tx
92 2015-11-24 17:12:54 <gavinandresen> Speaking of CVE-2013-2292... the thread on bitcoin-dev talking about mitigating validation cost went nowhere. Does nobody have an opinion, are people keeping their opinions quiet so they have something to say in Hong Kong?
93 2015-11-24 17:17:09 <nickler> If you mean the 'validation-cost metric' thread, I am currently working with maaku and instagibbs on the talk. If anyone has a suggestion we would definitely like to hear it.
94 2015-11-24 17:18:12 <phantomcircuit> nickler, he's not
95 2015-11-24 17:18:28 <phantomcircuit> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009494.html
96 2015-11-24 17:18:58 <gavinandresen> No, I'm talking about the thread started by maaku that I replied to.
97 2015-11-24 17:19:34 <instagibbs> there were two threads, I think.
98 2015-11-24 17:20:25 <gavinandresen> This thread: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011662.html
99 2015-11-24 17:22:52 <gavinandresen> .... crickets ....
100 2015-11-24 17:23:58 <sipa> gavinandresen: sorry, i'm no longer on the mailinglist
101 2015-11-24 17:28:55 <gavinandresen> nickler : my current thinking is the benefits of having separate caps on UTXO growth, CPU, and bandwidth outweigh the problems, but if you have a single cost metric scheme that makes sense my mind could easily be changed.
102 2015-11-24 17:29:17 <gavinandresen> nickler: "it is hard, so lets do nothing" is NOT a good answer, in my opinion.
103 2015-11-24 17:30:11 <gavinandresen> e.g. see https://github.com/bitcoin/bitcoin/pull/7081 for Yet Another Band-Aid patch ....
104 2015-11-24 17:31:20 <kanzure> gavinandresen: there's definitely one or two talks about better ways to calculate the cost of validation, probably includes mitigation mentions (bug maaku)
105 2015-11-24 17:32:39 <instagibbs> I doubt there is one metric to Rule Them All, unfortunately.
106 2015-11-24 17:32:53 <sipa> i don't think there can be one
107 2015-11-24 17:33:54 <sipa> as the relative costs of I/O bandwidth, signature validation, hashing, ... will change over time and across hardware platforms
108 2015-11-24 17:34:01 <jl2012> different technology grows in different rate, so it doesn't make sense to have one metric
109 2015-11-24 17:34:04 <gavinandresen> My full thoughts were in reply to maaku: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011663.html
110 2015-11-24 17:34:27 <sipa> but i don't think it's hard to create a metric that encourages good behaviour over bad behaviour
111 2015-11-24 17:34:37 <instagibbs> jl2012, the GROWTH of the cap clearly won't be consistent, no
112 2015-11-24 17:35:22 <instagibbs> I'd treat any sort of growth thing as separate. We will probably be way off one way or another even in the one dimensional bandwidth case
113 2015-11-24 17:36:49 <gavinandresen> We're talking caps, so we can be off by a factor of two or three for a while and nothing horrible will happen.
114 2015-11-24 17:39:04 <instagibbs> Bounding worst-case behavior is the goal, so as long as that cap isn't too far off, yeah.
115 2015-11-24 17:39:13 <gavinandresen> yup
116 2015-11-24 17:40:41 <gavinandresen> I'd like to find a way to rationally discuss how to pick a reasonable cap-- I've proposed "pick some arbitrary, commonly-available, recent hardware and then benchmark" -- but I've got to go right now, and those conversations always seem to lead to bad places for some reason I can't fathom.....
117 2015-11-24 17:47:03 <kanzure> "OP_CHECKWILDCARDSIGVERIFY or "Wildcard Inputs"" http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011805.html
118 2015-11-24 23:13:30 <Lightsword> PR#7087 is an option that miners should run to disconnect SPV clients right?
119 2015-11-24 23:38:11 <phantomcircuit> Lightsword, yes
120 2015-11-24 23:38:47 <phantomcircuit> the entire bloom filter thing is a disaster
121 2015-11-24 23:39:03 <Lightsword> yeah
122 2015-11-24 23:39:04 <phantomcircuit> they are useful for a bunch of the mru set stuff though :)
123 2015-11-24 23:39:39 <Lightsword> mru set?
124 2015-11-24 23:44:28 <phantomcircuit> Lightsword, most recently used
125 2015-11-24 23:44:51 <phantomcircuit> Lightsword, things like "have i recently rejected this transaction from the mempool? yes -> great i wont request it again"
126 2015-11-24 23:45:13 <Lightsword> ah
127 2015-11-24 23:46:21 <Lightsword> phantomcircuit, is there a planned replacement for bloom filters for SPV wallets?
128 2015-11-24 23:47:01 <phantomcircuit> Lightsword, a replacement was suggested by op_mul which is strictly superior but nobody has actually implemented it yet
129 2015-11-24 23:47:26 <phantomcircuit> i dont think it would be too hard, but it requires storing a bunch more data
130 2015-11-24 23:47:34 <phantomcircuit> (although maybe not that much more data)
131 2015-11-24 23:47:59 <Lightsword> any writeup on it?