1 2015-06-29 00:02:15 <Luke-Jr> well, we don't ban for checkpoint violations
  2 2015-06-29 00:02:25 <Luke-Jr> eh, or do we :|
  3 2015-06-29 00:02:27 <sdaftuar> sure we do...  or at least old versions do
  4 2015-06-29 02:35:17 <warren> Can someone see if my --clearsign GPG signed message on bitcoin-dev list verifies?
  5 2015-06-29 02:38:11 <mr_burdell> my client says "Signed with unknown key (Key ID: B1179EB7347DC10D)"
  6 2015-06-29 02:38:25 <mr_burdell> i haven't imported your key though... so that's expected
  7 2015-06-29 02:42:14 <jps> warren: yep, verifies for me
  8 2015-06-29 02:42:40 <warren> ok thanks
  9 2015-06-29 02:46:33 <warren> Turned off the e-mail address munging where it did s/@/ at / as that was pretty useless as a spam protection anyway.
 10 2015-06-29 02:53:10 <Luke-Jr> warren: it manually verifies fine, but my mail client doesn't autodetect/verify on its own
 11 2015-06-29 03:35:39 <leakypat> phantomcircuit: any chance you could set a high fee policy on your testnet mining?
 12 2015-06-29 05:28:06 <warren> leakypat: why?
 13 2015-06-29 05:29:38 <leakypat> warren I am testing out RBF transactions
 14 2015-06-29 05:33:09 <petertodd> p2pool succesfully upgraded to bip66: https://blockchain.info/block-index/911887/000000000000000015233f7f94e5f065851a89a123d362848e5e098194ab07f1
 15 2015-06-29 05:40:48 <Luke-Jr> petertodd: you should know better -.-
 16 2015-06-29 05:41:11 <petertodd> Luke-Jr: one sec, lemme finish up my "relay-nothing-at-all" pull-req...
 17 2015-06-29 05:42:12 <petertodd> Luke-Jr: quite seriously, we need a decentralized tx relay network or small miners are at a huge disadvantage, yet we also need that network to have an anti-spam mechanism. The only alternative I can come up with to the current system is hashcash.
 18 2015-06-29 05:42:40 <Luke-Jr> tx fees are hashcash by proxy
 19 2015-06-29 05:43:16 <petertodd> Luke-Jr: yes, but only if txs are mined... which implies co-ordination of mempool policy to some degree
 20 2015-06-29 05:43:45 <Luke-Jr> hm
 21 2015-06-29 05:43:46 <petertodd> Luke-Jr: if we had a on-disk mempool it might be reasonable to just save txs for every output regardless of what rules they meet, but that's a shitton of txs
 22 2015-06-29 05:44:00 <petertodd> Luke-Jr: gigabytes worth is in principle possible
 23 2015-06-29 06:01:34 <Luke-Jr> petertodd: you may want to review BIP 1
 24 2015-06-29 06:02:05 <Luke-Jr> particularly, BIP Types and format
 25 2015-06-29 06:15:14 <CodeShark> anyone working on a normalized or unsigned sighash soft fork right now?
 26 2015-06-29 06:15:47 <CodeShark> I mean, I know sipa's been working on segregated witness...but is anyone doing something similar with plans for deployment on mainnet?
 27 2015-06-29 06:16:46 <petertodd> CodeShark: been thinking about it, but no code
 28 2015-06-29 06:17:23 <CodeShark> I think it's an important step and am willing to give it a go
 29 2015-06-29 06:17:30 <gmaxwell> those things do not provide the value of what SW provides; many of those proposals hardly work at all. (e.g. can only go one transaction deep; pretty much busted)
 30 2015-06-29 06:17:47 <petertodd> CodeShark: did you see my "what OP_CODESEPARATOR should have been" notes?
 31 2015-06-29 06:17:50 <gmaxwell> SW is the correct solution, but it's unclear how to do anything remotely compariable in a soft fork.
 32 2015-06-29 06:18:07 <CodeShark> petertodd: I'm pretty sure I remember seeing something to the effect but I'll reread it
 33 2015-06-29 06:18:28 <wumpus> CodeShark: https://github.com/laanwj/bitcoin/tree/2015_06_softforkinfo
 34 2015-06-29 06:18:42 <CodeShark> ah, is that the soft fork stat thing?
 35 2015-06-29 06:19:03 <CodeShark> thanks, wumpus
 36 2015-06-29 06:19:05 <wumpus> CodeShark: just adds the softfork status to getblockchaininfo, nothing special, but as you asked
 37 2015-06-29 06:19:11 <gmaxwell> OTOH, SW is a pretty darn trivial hard-fork. The patch is tiny.
 38 2015-06-29 06:19:13 <gmaxwell> :(
 39 2015-06-29 06:20:35 <CodeShark> I'd like a more general solution as well, gmaxwell...but consensus is a bitch :p
 40 2015-06-29 06:20:52 <wumpus> especially now
 41 2015-06-29 06:20:54 <gmaxwell> I mean, less complete solutions are non-solutions.
 42 2015-06-29 06:20:56 <petertodd> gmaxwell: what's so hard about SW in a soft-fork? just don't sign prevouts with normal CHECKSIG, and add some (ugly) crap to update them in the mempool code, then commit to a separate set of SW prevouts
 43 2015-06-29 06:22:09 <petertodd> wumpus: is that a pull-req anywhere?
 44 2015-06-29 06:23:00 <gmaxwell> petertodd: that almost doublex typical tx sizes (two sets of outputs), doubles utxo sizes (two sets of lookup keys). needs complex code to change the commitments, and and non-SW checksiged transaction in a chain breaks the updatability. :(
 45 2015-06-29 06:23:35 <petertodd> gmaxwell: so basically... it's 100% doable in a practical sense, as we're not going to be able to change all wallet SW overnight anyway
 46 2015-06-29 06:23:42 <wumpus> petertodd: never PRed it, no - would have been useful, but BIP62 is the last softfork using this mechanism and we're almost there, so it's a bit too late
 47 2015-06-29 06:23:59 <petertodd> wumpus: don't assume never, BIP65 :)
 48 2015-06-29 06:24:01 <gmaxwell> petertodd: maybe, but those overheads are pretty obnoxious.
 49 2015-06-29 06:25:33 <petertodd> gmaxwell: half the implementation would be a natural outcome of a txo commitment scheme
 50 2015-06-29 06:26:46 <Luke-Jr> (SW doesn't solve malleability in all use cases, though.)
 51 2015-06-29 06:26:50 <gmaxwell> Even just the always having to carry around two different lookup keys for every txin/txout is quite costly.
 52 2015-06-29 06:27:02 <gmaxwell> Luke-Jr: nothing does, because malleability is an intentional feature!
 53 2015-06-29 06:27:34 <Luke-Jr> gmaxwell: using H(sPK) as the input does :p
 54 2015-06-29 06:27:47 <gmaxwell> and other advantages you gain from SW, e.g. being able to fetch txn without the signatures; wouldn't be gained by that approach.
 55 2015-06-29 06:28:08 <Luke-Jr> sure, maybe we should do both
 56 2015-06-29 06:28:14 <CodeShark> from a design perspective, I really like separating contract definitions from authorization (signatures)
 57 2015-06-29 06:28:55 <CodeShark> being able to chain contracts together without the authorization to execute is a fundamental building block for layered protocols
 58 2015-06-29 06:28:59 <gmaxwell> Luke-Jr: and then gives you a nice set of replay vulnerabilities in return, not exactly general.
 59 2015-06-29 06:29:22 <gmaxwell> CodeShark: yes, the SW is clearly the correct construction for several reasons.
 60 2015-06-29 06:29:34 <Luke-Jr> gmaxwell: not for supported use; and if it's locked to a new opcode, it's harmless
 61 2015-06-29 06:30:03 <gmaxwell> Luke-Jr: sure, likewise most applications where thats a concern are address by (R)CLTV.
 62 2015-06-29 06:30:26 <gmaxwell> many ways to skin a cat.
 63 2015-06-29 06:32:44 <Luke-Jr> none quite as elegant as H(sPK) inputs :<
 64 2015-06-29 06:34:08 <gmaxwell> Luke-Jr: even H(spk) inputs still need txin updating; because doubling the utxo set size to carry two keys just to avoid revision in mempool support would be kinda nuts.
 65 2015-06-29 06:34:57 <Luke-Jr> not if we're doing a hardfork for SW anyway <.<
 66 2015-06-29 06:35:56 <gmaxwell> it's kinda nuts because the extreme overhead of it.
 67 2015-06-29 06:41:27 <wumpus> cfields: let me know when you have time so we can dot the last i's for rc3
 68 2015-06-29 06:41:41 <gmaxwell> I don't remember the numbers exactly but I think it was that 1/3rd of the bytes in the utxo set are txids, not including lookup overhead (which is probably similar to the key sizes in total).  (one third due to the average number of utxos per txid).
 69 2015-06-29 06:42:05 <CodeShark> the most general approach to SW is to support input fields and treat it as a script satisfaction problem
 70 2015-06-29 06:42:37 <CodeShark> an "input tape" as it were
 71 2015-06-29 06:44:13 <CodeShark> this is essentially what segregated witness is...but it could be expressed in an even more general context
 72 2015-06-29 06:45:02 <gmaxwell> I think it's already very general. It's all the satisfaction data, and the only place it gets committed to is seperately in blocks.
 73 2015-06-29 06:46:43 <CodeShark> I think in practice it's the same thing - just making a comment regarding nomenclature
 74 2015-06-29 06:50:04 <gmaxwell> idioct of reddit will never stop impressing me, here I am with a negative vote score for correcting someone who claims that transactions contain a source IP address: https://www.reddit.com/r/Bitcoin/comments/3bh1v9/a_transactions_approval_committee_can_easily_be/csm52yc?context=1
 75 2015-06-29 06:52:00 <CodeShark> lol - I don't know what impresses me more...that someone would write that, or that gmaxwell is able to read all this and respond to it AND do stuff that's actually relevant in this space at the same time!
 76 2015-06-29 06:52:28 <gmaxwell> I get forwarded a lot of links.
 77 2015-06-29 06:52:53 <wumpus> after decoding the fifth level of hidden meaning of a transaction with satoshi's magical golden key, you get to the record that contains the source IP, as well as DNA traces of the sender
 78 2015-06-29 06:53:36 <wumpus> everyone knows that, right?
 79 2015-06-29 06:54:44 <CodeShark> I never got my golden key...think it got lost in the mail somewhere
 80 2015-06-29 07:00:58 <leakypat> Classic reddit
 81 2015-06-29 07:01:20 <CodeShark> too much nonsense on reddit
 82 2015-06-29 07:02:00 <CodeShark> once in a while there's an enlightened thread...but you have to pick through a bunch of garbage to find it
 83 2015-06-29 07:02:25 <CodeShark> same with bitcointalk
 84 2015-06-29 07:02:26 <leakypat> Bitcoin onboarding via reddit and bc.info
 85 2015-06-29 07:03:22 <wumpus> CodeShark: if you get me a seat on thie "transactions approval committe" then I'll send you mine
 86 2015-06-29 07:03:53 <CodeShark> wumpus: be careful what you wish for...
 87 2015-06-29 07:03:56 <gmaxwell> https://medium.com/@Stunna/breaking-the-house-63f1021a3e6d
 88 2015-06-29 07:06:16 <gmaxwell> wumpus: hah, every document, circulating endlessly from desk to desk, must eventually find the right one;  I never before realized it but I think Lem must have been describing bitcoin.
 89 2015-06-29 07:07:13 <wumpus> gmaxwell: waa, that's a very good fit indeed
 90 2015-06-29 07:08:06 <phantomcircuit> gmaxwell, that's pretty bad
 91 2015-06-29 07:08:36 <gmaxwell> phantomcircuit: the novel or the reddit post?
 92 2015-06-29 07:08:46 <phantomcircuit> primedice thing
 93 2015-06-29 07:08:53 <gmaxwell> oh! ha. yea.
 94 2015-06-29 07:09:04 <gmaxwell> they don't really give any information about how they created a race condition there.
 95 2015-06-29 07:09:30 <gmaxwell> I'm going to guess that their RNG was seeded by the time and they managed to get two http processes forked in the same second.
 96 2015-06-29 07:26:30 <CodeShark> so anyway, what's going to happen regarding SW deployment on mainnet?
 97 2015-06-29 07:27:05 <CodeShark> or is there something we can do in the meantime that's less of a consensus headache that still allows chaining contracts?
 98 2015-06-29 07:27:17 <CodeShark> a new sighash
 99 2015-06-29 07:29:40 <CodeShark> this is somewhat separate from the broadcast p2p network
100 2015-06-29 07:33:23 <gmaxwell> CLTV covers most of the applications, though not all.
101 2015-06-29 07:47:50 <CodeShark> I think CLTV is extremely clever...but at some level still feel like overusing it is a bit hackish
102 2015-06-29 07:48:55 <phantomcircuit> CodeShark, if you think that's a bit of a hack dont look at the mining incentives :P
103 2015-06-29 07:49:27 <CodeShark> well, it does have its place
104 2015-06-29 07:49:39 <CodeShark> it does solve a problem - so I applaud it for that :p
105 2015-06-29 07:50:58 <CodeShark> but yeah...the mining stuff is very tricky to manage
106 2015-06-29 07:51:43 <CodeShark> it does lend itself to causing locktime issues
107 2015-06-29 07:51:47 <CodeShark> intentionally :p
108 2015-06-29 07:51:54 <wumpus> CodeShark petertodd extended softfork info a bit and filed a PR https://github.com/bitcoin/bitcoin/pull/6353
109 2015-06-29 07:52:29 <CodeShark> nice, looking at it now, wumpus
110 2015-06-29 07:52:59 <CodeShark> I did test your branch...let me try this one
111 2015-06-29 07:53:20 <wumpus> this one is a bit more complete, it adds the counts as well, as well as documentation
112 2015-06-29 07:55:21 <CodeShark> weren't we going to be transitioning to a new soft fork status flag something or other?
113 2015-06-29 07:56:04 <wumpus> yes, that was my point for not filing it before, but there is lots of interest in it
114 2015-06-29 07:56:48 <wumpus> when there is a new softfork status thing, the code can be updated to report on that
115 2015-06-29 08:06:29 <CodeShark> I think it's important to make this sort of thing widely available
116 2015-06-29 08:08:41 <phantomcircuit> CodeShark, unfortunately the code for the new soft fork mechanism isn't written
117 2015-06-29 08:10:07 <CodeShark> it didn't sound super complicated
118 2015-06-29 08:10:30 <CodeShark> what's the spec called again?
119 2015-06-29 08:13:17 <phantomcircuit> coderwill, https://gist.github.com/sipa/bf69659f43e763540550
120 2015-06-29 08:13:18 <phantomcircuit> CodeShark, https://gist.github.com/sipa/bf69659f43e763540550
121 2015-06-29 08:13:50 <CodeShark> ah yes...version bits...thank you :)
122 2015-06-29 08:14:20 <CodeShark> your autocomplete goofed, phantomcircuit ? :)
123 2015-06-29 08:14:36 <phantomcircuit> yeah
124 2015-06-29 11:40:51 <hearn> is it intentional that there doesn't seem to be any logging in the rpc code?
125 2015-06-29 11:41:27 <hearn> other than in the rpc server itself i mean
126 2015-06-29 11:41:45 <CodeShark> the wallet stuff in particular is scary :)
127 2015-06-29 11:42:11 <CodeShark> I suppose you can parse debug.log :)
128 2015-06-29 11:42:12 <wumpus> hearn: there's no implicit or explicit rule not to, at least
129 2015-06-29 11:42:20 <wumpus> CodeShark: what are you talking about?
130 2015-06-29 11:42:35 <CodeShark> are you talking about a log of RPC calls?
131 2015-06-29 11:43:19 <CodeShark> as in to enable audits?
132 2015-06-29 11:43:23 <wumpus> you can make it log RPC calls (debug=rpc), I don't think that's what hearn is talking about, though, there's hardly any logging *inside* RPC method implementation
133 2015-06-29 11:43:44 <hearn> right
134 2015-06-29 11:43:49 <hearn> that's what i was meaning. was a bit surprised, that's all
135 2015-06-29 11:43:51 <hearn> ok, good
136 2015-06-29 11:45:32 <wumpus> CodeShark: a wallet audit log wouldn't be that bad an idea, no - although the wallet itself is supposed to be a log of everything that happens to the balance, so may as well add more metadata to the transactions there
137 2015-06-29 11:46:48 <CodeShark> you know how I feel about the Core wallet :)
138 2015-06-29 11:47:38 <CodeShark> nvm... :p
139 2015-06-29 11:48:16 <wumpus> well at least it is robust, as far as I know there have been no critical errors in it resulting in coin loss or theft
140 2015-06-29 11:48:19 <paveljanik> and what are you doing about your feeling?
141 2015-06-29 11:48:32 <CodeShark> lol
142 2015-06-29 11:48:45 <CodeShark> shall I lie down?
143 2015-06-29 11:48:58 <moa> roll over
144 2015-06-29 11:50:00 <hearn> wumpus: do you know where the code to disconnect a banned peer is? i can't seem to find it
145 2015-06-29 11:50:11 <hearn> wumpus: i see code that drops a newly connecting peer if it is banned
146 2015-06-29 11:50:39 <wumpus> hearn: probably something like peer->fDisconnect=true; ?
147 2015-06-29 11:51:11 <hearn> ah i see, it's hiding in SendMessages. i hate it when i find something after searching for a while and just asking someone a few seconds before ... sorry about that
148 2015-06-29 11:51:43 <hearn> i would have expected calling CNode::Ban to actually cause the disconnect, but it doesn't
149 2015-06-29 12:05:12 <CodeShark> you're right, though, wumpus - it works within its design
150 2015-06-29 12:06:17 <CodeShark> nvm, though, I get it...this has nothing to do with what was being discussed :p
151 2015-06-29 12:23:17 <hearn> wumpus: what are the threading rules for CNode public members? i see some CNode specific locks for some parts of the state but not all of it
152 2015-06-29 12:38:53 <hearn> hmm, does anyone else know?
153 2015-06-29 12:39:02 <hearn> it'd be useful if there was a doc explaining which locks protect what
154 2015-06-29 12:54:37 <wumpus> hearn: it's not quite documented, which sucks, cfields is working on rewriting that code though
155 2015-06-29 12:55:19 <wumpus> e.g. some of the CNode state is not protected by locks and can only be accessed by a single thread
156 2015-06-29 13:07:08 <ren0v0> my -qt has frozen whilst sending a payment
157 2015-06-29 13:07:19 <ren0v0> ok its back, nvm
158 2015-06-29 13:12:27 <jonasschnelli> [13:51:43]  <hearn>
159 2015-06-29 13:12:49 <jonasschnelli> hearn: the ban code will call  peer->fDisconnect=true; after it was added to the ban map.
160 2015-06-29 13:12:57 <hearn> yes
161 2015-06-29 13:12:59 <hearn> i saw that
162 2015-06-29 13:13:05 <hearn> i presume that requires cs_main
163 2015-06-29 13:13:10 <hearn> or at least cs_recvMsgs
164 2015-06-29 13:13:22 <jonasschnelli> peer->fDisconnect=true; does not require a lock.
165 2015-06-29 13:13:41 <jonasschnelli> It will disconnect during the next node/msg interaction.
166 2015-06-29 13:14:41 <jonasschnelli> hearn: we had locking issues / race condition while calling CloseSocketDisconnect() directly (this is not thread safe in any way)
167 2015-06-29 13:15:24 <hearn> well, technically any data that is accessed from multiple threads is meant to be locked by something
168 2015-06-29 13:15:28 <hearn> but sure, ok, i'll go with that for now
169 2015-06-29 13:16:06 <dhill> hearn
170 2015-06-29 13:17:15 <dhill> well now i forgot
171 2015-06-29 13:17:24 <dhill> oh
172 2015-06-29 13:17:30 <hearn> dhill!
173 2015-06-29 13:17:59 <dhill> hearn: if bloom filtering were disabled, would it be proper to send the SPV client a normal Block, or still a MerkleBlock with all tx's "matched"
174 2015-06-29 13:18:38 <hearn> a normal block should work, in the case of bitcoinj. however that's not the only SPV implementation and others may expect properly filtered blocks. it is not an optional feature of the protocol.
175 2015-06-29 13:19:09 <hearn> also i suspect in cases where a remote node didn't provide the expected responses there may be bugs. it isn't unit tested.
176 2015-06-29 13:20:48 <wumpus> send the whole block would "work" but I'm not sure that makes SPV clients happy as they try to reduce bandwidth. Even disconnecting may be better.
177 2015-06-29 13:21:17 <btcdrak> been reading the logs, what is "SW"?
178 2015-06-29 13:21:22 <Diablo-D3> southwest
179 2015-06-29 13:21:23 <Diablo-D3> software
180 2015-06-29 13:21:39 <Diablo-D3> social warrior
181 2015-06-29 13:21:50 <dhill> wumpus:  yes.  I guess a node could match on if they want to be relayed inv's in the version
182 2015-06-29 13:21:51 <Diablo-D3> sweden
183 2015-06-29 13:22:05 <Diablo-D3> Smith & Wesson
184 2015-06-29 13:22:08 <Diablo-D3> southwest airlines
185 2015-06-29 13:22:22 <leakypat> Silent witness
186 2015-06-29 13:22:47 <Diablo-D3> Strike Witches
187 2015-06-29 13:22:55 <jonasschnelli> Is there a better channel to peer a SPV client with your personal controlled full node than P2P 8333? Something that is tunneled/sshed?
188 2015-06-29 13:23:01 <Diablo-D3> Star Wars
189 2015-06-29 13:23:37 <hearn> jonasschnelli: with bitcoinj you can use a tor hidden service
190 2015-06-29 13:23:48 <hearn> jonasschnelli: if you want better than that, you must tunnel with ssh and set it up manually at the moment.
191 2015-06-29 13:23:50 <wumpus> Diablo-D3: if you don't know, please just shut up
192 2015-06-29 13:24:11 <Diablo-D3> wumpus: bah.
193 2015-06-29 13:24:18 <hearn> jonasschnelli: see this example: https://github.com/bitcoinj/bitcoinj/commit/9f8501a7bfdca97f774db380c12dad3d6a1c0d2f
194 2015-06-29 13:27:19 <jonasschnelli> hearn: What about running a full node, having a script behind apache that serves cached/aggregated data to your "SPV" (no longer) client? The apache CGI script would interact over RPC/ZMQ.
195 2015-06-29 13:27:21 <wumpus> jonasschnelli: right, tunnel the P2P protocol over e.g. ssh or stunnel, combined with whitelisting
196 2015-06-29 13:27:37 <hearn> jonasschnelli: i don't understand what you're asking for. why would you need apache?
197 2015-06-29 13:28:06 <jonasschnelli> It just feels bloated to use SPV with a tunneled/sshed smartphone<->fullnode connection.
198 2015-06-29 13:28:21 <jonasschnelli> mod_bitcoind_wallet for apache would be nice. :)
199 2015-06-29 13:28:48 <wumpus> you could make that point for ssh (I don't know) - but stunnel is not bloated at all, it just wraps the connection in a TLS connection
200 2015-06-29 13:29:05 <jonasschnelli> hearn: apache would be required have a secure entry point. Or how would you expose your full node to a dyn-ip enviromnent?
201 2015-06-29 13:29:31 <hearn> SSL?
202 2015-06-29 13:29:39 <hearn> it's not something i've ever had a need for
203 2015-06-29 13:29:51 <jonasschnelli> wumpus: the tunnel itself is not bloated. Right. But you don't need to crawl through headers and find wtx's if your trusted full node could do that job for you.
204 2015-06-29 13:30:26 <wumpus> jonasschnelli: you're describing something like electrum's protocol?
205 2015-06-29 13:30:41 <jonasschnelli> wumpus: Indeed. It goes into this direction...
206 2015-06-29 13:31:16 <wumpus> jonasschnelli: https://electrum.orain.org/wiki/Stratum_protocol_specification
207 2015-06-29 13:32:25 <wumpus> it also uses TLS by default, so there's not need to do your own tunneling
208 2015-06-29 13:32:39 <hearn> the only upgrade it'd give you is better understanding of whether an unconfirmed transaction is valid. instead of monitoring network propagation you'd trust your own node instead.
209 2015-06-29 13:32:58 <hearn> and of course hope that your node is in sync with what the rest of the network is running :)
210 2015-06-29 13:32:58 <jonasschnelli> wumpus: right. Running your one full node with your own stratum service if probably the best way to serve your "SPV" client.
211 2015-06-29 13:34:11 <jonasschnelli> hearn: Yes. You would heavily rely on your full node. But if your use SPV, you rely/trust the connected nodes.
212 2015-06-29 13:34:12 <wumpus> jonasschnelli: yes. There are some payment companies using that, too, they have a few private electrum servers and use those internally.
213 2015-06-29 13:35:38 <hearn> jonasschnelli: you trust that you're genuinely connected to multiple non-sybils of each other, which is the same security model as Tor, essentially, plus that your internet connection isn't totally hijacked.
214 2015-06-29 13:35:44 <hearn> jonasschnelli: and only until you have confirmations.
215 2015-06-29 13:36:03 <hearn> jonasschnelli: in practice upgrades to trusted-peer-mode aren't the top things users demand from SPV wallet makers.
216 2015-06-29 13:36:11 <hearn> so, take that into account when deciding what to work on :)
217 2015-06-29 13:37:32 <wumpus> SPV still kind of sucks for privacy
218 2015-06-29 13:37:43 <jonasschnelli> hearn: Right. I just go to and from with what could be a good approach for SPV/fullnode interaction.
219 2015-06-29 13:37:54 <wumpus> (at least, when used with a non-trusted node)
220 2015-06-29 13:38:01 <hearn> wumpus: i pointed this out on reddit the other day, but you can run an SPV wallet that downloads every transaction
221 2015-06-29 13:38:07 <hearn> it will just be slow and bandwidth heavy
222 2015-06-29 13:38:07 <leakypat> btcdrak: actually I think it's segregated witnesses not silent witnesses (that is probably a movie:)
223 2015-06-29 13:38:30 <wumpus> hearn: of course you can, but in that case you could just as well run a full node with pruning
224 2015-06-29 13:38:37 <hearn> wumpus: existing SPV wallets expose no such option to the user, but if someone wanted to make a PowerUser Wallet™ then such a setting could exist
225 2015-06-29 13:38:48 <jonasschnelli> I just think if you could manage to run a full node (maybe a pruned/trottled at home) you might trust this node more than serval nodes in SPV mode.
226 2015-06-29 13:38:50 <wumpus> as you're downloading all the data anyway, why not verify it and be useful (TM)
227 2015-06-29 13:39:06 <hearn> wumpus: well, unless your internet is quite slow and your computer is very fast, it's still faster to download+scan+throw_away than to maintain the UTXO set and check the scripts
228 2015-06-29 13:39:22 <hearn> wumpus: also, the user may have other requirements from their wallet. for example all SPV wallets i know of support exchange rates integration. Core does not.
229 2015-06-29 13:39:26 <wumpus> hearn: I guess so, but it's a bit of abuse of resources
230 2015-06-29 13:39:27 <hearn> that's a must-have for most users
231 2015-06-29 13:39:53 <hearn> why would it be abuse? people run non-listening full nodes all the time.
232 2015-06-29 13:40:48 <hearn> jonasschnelli: how many people do you know that have always-on desktop machines at home? maybe it's just the age group i hang out with, but i did not see this for many years now. everyone uses laptops.
233 2015-06-29 13:40:50 <hearn> jonasschnelli: myself included.
234 2015-06-29 13:41:04 <hearn> jonasschnelli: so optimising for the "user who has an always on computer at home" is probably optimising for a small and shrinking market
235 2015-06-29 13:41:35 <jonasschnelli> hearn: Agreed. But how many people in your circle are able to run a full node / have a vserver somewhere?
236 2015-06-29 13:41:49 <hearn> a few. mostly ex-colleagues :)
237 2015-06-29 13:41:58 <hearn> but not many indeed.
238 2015-06-29 13:42:32 <jonasschnelli> You could buy a RiP, install bitcoind, sync a full node in pruned more, throttled relay, install in your homes network. Serve your bitcoin thinclients with it.
239 2015-06-29 13:42:42 <hearn> which is why existing wallets don't spend much time on the trusted node feature. andreas' wallet has it, but mostly because it's easy to implement rather than because it's a must-have feature.
240 2015-06-29 13:43:11 <wumpus> as said, most people that want  a trusted node setup use electrum with their own private server
241 2015-06-29 13:43:39 <hearn> yes, you could. and how will you convince people to spend the money and time it'd take to do that? simply hand-waving "more security" won't get you far: users are quite used to being hawked security upgrades they don't understand and will often pass on them if they can't see the benefit.
242 2015-06-29 13:44:07 <wumpus> that's not the point, though
243 2015-06-29 13:44:08 <hearn> or even if they can ,but just feel lazy (e.g. see the fate of two-factor auth)
244 2015-06-29 13:45:13 <jonasschnelli> hearn: But at least you have to offer people a way of using bitcoin in a save and private way.
245 2015-06-29 13:45:15 <wumpus> "convincing users" doesn't come into it, scratch your own itch, if you can use something there are almost always other people that want to use it
246 2015-06-29 13:46:33 <hearn> jonasschnelli: up to you. pick what kind of wallet you want to make, really. e.g. if you prioritise that above loading exchange rates, then you're pretty clearly targeting a power user market that doesn't care about convenience but does care about relatively obscure protocol details.
247 2015-06-29 13:46:44 <hearn> which is fine, but don't expect much adoption
248 2015-06-29 13:47:23 <wumpus> also this book isn't written yet, one shock may be enough to make people suddenly realize how important that extra privacy is, and how their flimsy SPV wallet have been broadcasting what outputs they are interested in to everyone all the time
249 2015-06-29 13:47:38 <jonasschnelli> hearn: My goal is to create a full node wallet with the convenience of a current SPV wallet. Which is impossible but still the thing that drives me.
250 2015-06-29 13:48:22 <leakypat> jonasschnelli: my SPV wallet takes 18 minutes to sync from scratch
251 2015-06-29 13:48:39 <leakypat> Not far off Bitcoin core :)
252 2015-06-29 13:48:52 <hearn> leakypat: from scratch meaning .... ?
253 2015-06-29 13:48:56 <hearn> leakypat: the genesis block?
254 2015-06-29 13:49:48 <leakypat> hearn no, I assume they package some of the data with the app
255 2015-06-29 13:49:59 <leakypat> I'm referring to breadwallet
256 2015-06-29 13:50:00 <hearn> which wallet?
257 2015-06-29 13:50:36 <wumpus> also the mobile SPV wallet for your 100 millibit change segment is pretty much catered to, what is lacking are robust, high-privacy and security wallets for power users
258 2015-06-29 13:50:38 <leakypat> I did a test the other day, downloaded it from the App Store and timed it with my stopwatch
259 2015-06-29 13:50:48 <hearn> breadwallet uses checkpoints, same as bcj
260 2015-06-29 13:50:53 <jonasschnelli> wumpus: +1!
261 2015-06-29 13:51:13 <hearn> so you are not comparing apples and oranges there
262 2015-06-29 13:51:26 <jonasschnelli> Buying a coffee or pizza with BTC: spv. But everything that goes beyond that, i would have a really bad feeling if i would recommend a SPV wallet...
263 2015-06-29 13:51:34 <hearn> especially as you are comparing a vastly more powerful laptop or desktop against an iphone!
264 2015-06-29 13:51:34 <wumpus> armory tried to do this but was not entirely succesful
265 2015-06-29 13:51:37 <wumpus> jonasschnelli: +1
266 2015-06-29 13:52:13 <leakypat> Hearn: Still, 18 minutes vs instant setup on a centralized node based mobile wallet
267 2015-06-29 13:52:30 <leakypat> Not exactly great UX
268 2015-06-29 13:52:34 <hearn> leakypat: you shouldn't see an 18 minute sync time unless you replay your wallet from a seed backup, i would guess
269 2015-06-29 13:52:49 <hearn> leakypat: certainly Bitcoin Wallet for Android syncs a fresh install more or less immediately. it doesn't bother showing progress even
270 2015-06-29 13:53:06 <leakypat> Is that because it is sending out transaction data?
271 2015-06-29 13:53:17 <hearn> leakypat: replaying a wallet from scratch is painful. the fix is to never have to do that.  wallet backups should be more than  just a seed
272 2015-06-29 13:53:18 <leakypat> Requests
273 2015-06-29 13:53:22 <hearn> leakypat: no
274 2015-06-29 13:53:35 <hearn> leakypat: it just knows that for a fresh install, you have no transactions, so all it needs to do is fetch the headers from the last checkpoint to the chain tip
275 2015-06-29 13:53:44 <hearn> leakypat: and that's fast. you get 5000 at a time, they are 80 byte structures
276 2015-06-29 13:54:05 <leakypat> That explains it
277 2015-06-29 13:54:15 <leakypat> Breadwallet never removed your seed
278 2015-06-29 13:54:23 <leakypat> Unless you reset your phone
279 2015-06-29 13:54:47 <jonasschnelli> leakypat = Aaron Voisine?
280 2015-06-29 13:54:53 <leakypat> No
281 2015-06-29 13:54:56 <jonasschnelli> Okay.
282 2015-06-29 13:55:05 <leakypat> When I said my wallet , I meant the one on my phone
283 2015-06-29 13:55:11 <jonasschnelli> clear.
284 2015-06-29 13:56:00 <hearn> jonasschnelli: i have to go in a sec, battery is running low. but i am not totally sure what your goal is, still. last time we talked you wanted to make an SPV wallet that was a part of the reference implementation, because you felt having such a wallet come from Bitcoin Core was important.
285 2015-06-29 13:56:19 <jonasschnelli> hearn: im not sure either. :)
286 2015-06-29 13:56:21 <hearn> jonasschnelli: now you're saying you want a fully verifying wallet with the convenience of SPV, which is not currently possible.
287 2015-06-29 13:56:31 <hearn> jonasschnelli: and then you said you wouldn't recommend SPV for anything beyond buying pizza
288 2015-06-29 13:56:36 <hearn> so .... yeah :) clarify your goals first, i think :)
289 2015-06-29 13:56:58 <hearn> if all you care about is upgrading security then it'd be easier to work on the trusted node feature of existing SPV implementations
290 2015-06-29 13:57:16 <hearn> easier as in, less code to write
291 2015-06-29 13:58:36 <hearn> anyway, bbl
292 2015-06-29 13:59:36 <jonasschnelli> hearn needs a bouncer... :)
293 2015-06-29 14:08:49 <leakypat> So segregated witness means separation of the signatures and the tx data so that the tx ids are hashes of the tx data only?
294 2015-06-29 14:09:43 <leakypat> So where are the signatures stored? (Currently tagged on to the input script)
295 2015-06-29 14:14:23 <helo> i think they are still part of the transaction, just not used to define the ID
296 2015-06-29 14:15:22 <leakypat> helo so they would have to be stripped out before hashing to get the id, I see
297 2015-06-29 14:15:40 <leakypat> But in the block would be same as before
298 2015-06-29 14:15:56 <helo> similar, at least, yeah
299 2015-06-29 15:21:25 <gavinandresen> Where are we at with a decision on using c++11 features in new code?
300 2015-06-29 15:24:37 <wumpus> I'm afraid that discussion kind of went to the background with all the recent drama, but this is the issue about it: https://github.com/bitcoin/bitcoin/issues/6211
301 2015-06-29 15:33:01 <phantomcircuit> hearn, the cost of syncing a wallet is really based on the fp rate selected
302 2015-06-29 15:33:15 <phantomcircuit> if you have a trusted node you can just use fp~=0
303 2015-06-29 15:33:40 <phantomcircuit> and actually i believe most of the spv clients in practice run with fp rates close to zero
304 2015-06-29 15:35:01 <phantomcircuit> leakypat, that's exactly what segregated witness means, the signatures can be more or less free floating as long as they're in the block and clearly indicate which goes with which transaction input
305 2015-06-29 15:35:48 <phantomcircuit> helo, stripping them out before hashing is probably the easiest way to implement it, but certainly they could actually be separate structures
306 2015-06-29 15:38:39 <phantomcircuit> wumpus, are we actually compiling with --std=c++11 ?
307 2015-06-29 15:41:23 <wumpus> phantomcircuit: no
308 2015-06-29 15:43:41 <phantomcircuit> looks like gcc support for c++11 is listed as experimental at least upto 4.8
309 2015-06-29 15:43:45 <phantomcircuit> and probably upto 5.1
310 2015-06-29 15:43:48 <gavinandresen> ok, for now I'll use LOCK instead of std::atomic<> ....
311 2015-06-29 15:43:58 <warren> Distros shipping gcc-5 are shipping both ABI's, but building to the old ABI by default I think.
312 2015-06-29 15:45:04 <phantomcircuit> std::atomic isn't available until gcc 4.9 iirc
313 2015-06-29 15:45:28 <phantomcircuit> no that's just thread local storage
314 2015-06-29 15:45:46 <phantomcircuit> either way yeah it's all listed as experimental
315 2015-06-29 15:46:14 <gavinandresen> https://gcc.gnu.org/projects/cxx0x.html  says gcc 4.4
316 2015-06-29 15:47:05 <phantomcircuit> yes i corrected myself
317 2015-06-29 15:47:07 <phantomcircuit> <phantomcircuit> no that's just thread local storage
318 2015-06-29 15:49:08 <jonasschnelli> Is there a reason for the separation of CWalletTx and CMerkleTx?
319 2015-06-29 15:50:20 <phantomcircuit> jonasschnelli, filtered blocks? that would be my guess
320 2015-06-29 15:51:45 <jonasschnelli> There is no independent use of CMerkleTx (no non-inherited to CWalletTX use). And i don't see a use case to use CMerkleTx outside of the CWalletTx scope.
321 2015-06-29 15:53:41 <jonasschnelli> It somehow a uncommon design. CWallet manages CWalletTx's. But every CWalletTx has a pointer to CWallet where. CWalletTx also directly LOCKs cs_main. Uses mapBlockIndex, etc.
322 2015-06-29 15:54:13 <phantomcircuit> jonasschnelli, it's messy
323 2015-06-29 15:54:22 <jonasschnelli> While re-creating a full node wallet i try to make clean interfaces.
324 2015-06-29 15:54:41 <phantomcircuit> the wallet code all assumes that it has a current and self consistent view of the chain state info
325 2015-06-29 15:54:50 <phantomcircuit> which means it needs to lock world basically
326 2015-06-29 15:55:55 <phantomcircuit> note: do not try to open bitcoin-qt with a wallet containing 1m+ transactions
327 2015-06-29 15:56:06 <jonasschnelli> phantomcircuit: that's fine IMO. But it should go over a clean interface. I added now corewallet/coreinterface which is a first step to factor out communication between the full node and the wallet.
328 2015-06-29 15:56:37 <jonasschnelli> phantomcircuit: i tried with 300k+. But right. Won't work on QT level.
329 2015-06-29 15:56:41 <jonasschnelli> But it's a trivial issue.
330 2015-06-29 15:56:57 <phantomcircuit> nobody really has that many unless shenanigans
331 2015-06-29 15:56:58 <jonasschnelli> The transaction QTableView must do lazy loading
332 2015-06-29 15:57:03 <jonasschnelli> :)
333 2015-06-29 15:57:17 <phantomcircuit> oh
334 2015-06-29 15:57:40 <phantomcircuit> the rpc getblocktemplate stuff wont build a block that's 1000000 bytes even if you hack nBlockMaxSize to be 1000000
335 2015-06-29 15:58:02 <phantomcircuit> doe to an off by 1 in the comparison
336 2015-06-29 15:58:10 <phantomcircuit> not sure if anybody cares though
337 2015-06-29 18:20:23 <warren> Any Chinese speakers here now?  I need a bitcoin-related dev draft reviewed.
338 2015-06-29 18:34:34 <cfields> wumpus: doing the descriptor changes now.
339 2015-06-29 19:50:35 <jonasschnelli> :)
340 2015-06-29 19:50:43 <jonasschnelli> (oops, wrong window)
341 2015-06-29 20:24:44 <cfields> michagogo: around?