1 2015-01-28 00:10:27 <denisx> phantomcircuit: you are the one building bitcoin on freebsd?
2 2015-01-28 00:11:19 <phantomcircuit> no it's the guy who left
3 2015-01-28 00:11:51 <phantomcircuit> i stopped running freebsd after someone accidentally removed the LD_PRELOAD filter for setuid binaries
4 2015-01-28 00:11:58 <phantomcircuit> and nobody noticed for years
5 2015-01-28 00:14:41 <phantomcircuit> Luke-Jr, i just noticed that i was running ./qt/bitcoin-qt and it was using a datadir other than ~/.bitcoin
6 2015-01-28 00:14:52 <phantomcircuit> and $HOME is properly configured
7 2015-01-28 00:18:53 <phantomcircuit> oh
8 2015-01-28 00:18:56 <phantomcircuit> ~/.config/Bitcoin/Bitcoin-Qt.conf
9 2015-01-28 00:19:03 <phantomcircuit> is that new?
10 2015-01-28 00:19:43 <akstunt600> nah
11 2015-01-28 00:19:46 <akstunt600> always been there
12 2015-01-28 00:21:00 <phantomcircuit> huh 2013
13 2015-01-28 02:21:21 <phantomcircuit> hmm
14 2015-01-28 02:21:36 <phantomcircuit> possibly shouldn't be processing network messges during reindex or ibd
15 2015-01-28 02:21:47 <phantomcircuit> the inv messages cause some lock contention
16 2015-01-28 02:21:50 <phantomcircuit> on cs_main
17 2015-01-28 06:16:03 <earlz> Can invalid scripts be mined? For instance if you just put `op_pop << op_verify` as a vout script, woudl that eb accepted?
18 2015-01-28 06:16:20 <earlz> ie, stack under/over flows
19 2015-01-28 06:19:16 <kadoban> earlz: You mean could a mined block be valid containing invalid scripts? No.
20 2015-01-28 06:22:58 <earlz> Well, I know a vout with op_return is technically "invalid", but it's accepted into a block
21 2015-01-28 06:25:21 <gmaxwell> earlz: you might get more help in #bitcoin this is a really basic question and you could probably enjoy a couple hours of talk around the basis to help firm up your expectations on this front.
22 2015-01-28 06:26:30 <earlz> Well, my expectations don't match what I'm seeing in the code.. errors happen, but appear to just make a vout unspendable.. whereas my expectation I guess was that it wouldn't be accepted
23 2015-01-28 06:27:21 <gmaxwell> earlz: a txout in a transaction is pretty much just a bunch of bytes, its a public key, (with only small exception) the system doesn't care whats in it at all.
24 2015-01-28 06:27:37 <gmaxwell> scripts are executed when a signature is verified.
25 2015-01-28 06:28:53 <earlz> I mean for raw transactions/custom scripts, not the standard p2sh/p2pkh
26 2015-01-28 06:29:32 <gmaxwell> uhh
27 2015-01-28 06:29:43 <earlz> So other than is-standard scripts.. and I guess checks for signature verification counts, a txout script is never really looked at until it's spent?
28 2015-01-28 06:29:55 <earlz> er, is-standard checks
29 2015-01-28 06:30:05 <gmaxwell> why would it be? it's just a public key.
30 2015-01-28 06:30:07 <justanotheruser> gmaxwell: yeah, I was wondering about that too. OP_RETURN returns an error and so does OP_CAT, but on the wiki they are treated differently. Should the wiki be changed so OP_RETURN is "disabled"?
31 2015-01-28 06:30:25 <justanotheruser> I mean, OP_RETURN returns a different error... but only because it is called OP_RETURN
32 2015-01-28 06:31:09 <earlz> My understanding is you could technically make an `op_cat` vout.. but it'd be seen as invalid/unspendable at least until op_cat is enabled
33 2015-01-28 06:32:42 <gmaxwell> justanotheruser: they're not actually the same in behavior.
34 2015-01-28 06:32:50 <gmaxwell> earlz: it cannot be 'enabled'
35 2015-01-28 06:33:00 <Luke-Jr> justanotheruser: no, if there's a "disabled" opcode within an OP_IF that is NOT followed, it fails still
36 2015-01-28 06:33:19 <Luke-Jr> earlz: OP_CAT basically does not exist
37 2015-01-28 06:33:25 <gmaxwell> it not any more OP_SOLVE_GOLDBACH_CONJECTURE
38 2015-01-28 06:33:54 <gmaxwell> s/it not any more/not any more than than/
39 2015-01-28 06:34:13 <justanotheruser> right..
40 2015-01-28 06:34:37 <gmaxwell> justanotheruser: an OP_RETURN hidden inside an if is just ducky AFAIR, not so for the outright invalid opcodes.
41 2015-01-28 06:35:11 <earlz> Well, if you take the byte assigned to the op_cat opcode, and put it into a vout, and mined it into a block, would it be accepted?
42 2015-01-28 06:35:34 <earlz> nevermind that it'd be unspendable
43 2015-01-28 06:35:43 <gmaxwell> earlz: ugh why is this hard for you to understand. Please take the questions to #bitcoin.
44 2015-01-28 06:36:05 <gmaxwell> It's just a sequence of bytes at that point (ignoring the broken sigops counting stuff). They don't have any meaning.
45 2015-01-28 06:37:19 <earlz> Ok, so that would be accepted into a block, but not spendable then, right /
46 2015-01-28 06:37:30 <justanotheruser> ah fExec || (OP_IF <= opcode && opcode <= OP_ENDIF)
47 2015-01-28 06:37:42 <earlz> oh wtf
48 2015-01-28 06:37:59 <earlz> that's why my searches weren't yielding anything heh
49 2015-01-28 06:40:57 <poutine> some disabled opcodes are valid in an unfollowed conditional
50 2015-01-28 06:41:33 <justanotheruser> poutine: sounds like they wouldn't be disabled then
51 2015-01-28 06:42:34 <poutine> I guess I should say more that there's some reserved opcodes that do not make a transaction invalid if they exist in an unfollowed conditional
52 2015-01-28 06:42:51 <wumpus> well the interpreter never encounters them
53 2015-01-28 06:42:56 <justanotheruser> also, this matches the list of disabled opcodes on the wiki exactly https://github.com/bitcoin/bitcoin/blob/b01a435c34f0669affece2b3d90f92c347588d69/src/script/interpreter.cpp#L279
54 2015-01-28 06:43:11 <poutine> wumpus, well, some do, regardless of where they exist in the tx
55 2015-01-28 06:43:14 <wumpus> your CPU program can also have invalid instructions in parts of the code that are never executed
56 2015-01-28 06:43:26 <poutine> OP_VERIF does not act as OP_VER does
57 2015-01-28 06:43:33 <wumpus> poutine: true
58 2015-01-28 06:50:16 <wumpus> (the logical conclusion being that non-folowed conditionals are a waste of block chain space, and indeed it'd be enough to store just a proof of the followed path, but in the case of the current system that'd of course invalidate the signature hash)
59 2015-01-28 07:16:11 <qetchx> can i question on bitcoin network?
60 2015-01-28 07:27:31 <aburan28> are there any plans/anyone working on making the wire protocol encrypted?
61 2015-01-28 07:28:04 <Luke-Jr> nope, no benefit to doing so
62 2015-01-28 07:29:06 <aburan28> why is that? i
63 2015-01-28 07:30:09 <Luke-Jr> because if your ISP is anti-bitcoin, you've already lost.
64 2015-01-28 07:30:19 <Luke-Jr> also because you're sending and receiving public data
65 2015-01-28 07:30:23 <Luke-Jr> so there's nothing to hide
66 2015-01-28 07:33:04 <aburan28> but it has already been proven that associating txs with ip addresses is trivial and i would argue that hiding the originating ip where large amounts of bitcoins reside is essential
67 2015-01-28 07:33:27 <aburan28> ISPs are letting the govt tapping in directly
68 2015-01-28 07:33:43 <aburan28> i understand that the blockchain is public
69 2015-01-28 07:34:10 <Luke-Jr> encryption won't help that
70 2015-01-28 07:35:39 <aburan28> by encryption i mean in a onion routing manner which would "decay" each layer of encryption over n nodes and thus providing some anonymity
71 2015-01-28 07:36:17 <Luke-Jr> no, your ISP will just become all layers
72 2015-01-28 07:37:27 <aburan28> if a certificate chain model is used mitm attacks could be used but i am talking about a transport layer encryption based on something like CurveCP/CurveZMQ
73 2015-01-28 07:37:47 <wumpus> you know you can already use bitcoin over tor, don't you?
74 2015-01-28 07:39:24 <aburan28> yes and i know that research indicates that is not a good option http://arxiv.org/abs/1410.6079
75 2015-01-28 07:39:28 <wumpus> there is no advantage to implementing a onion routing protocol ourselves, e.g. lots of ways to screw it up, and as it would only contain bitcoin traffic it'd also be less deniable
76 2015-01-28 07:40:02 <wumpus> no, that research doesn't say it is not a good option, it just says that you need to protect against different attacks
77 2015-01-28 07:40:13 <wumpus> which would be the same for any custom onion protocol
78 2015-01-28 07:41:01 <wumpus> there is no silver bullet here, just different compromises with different possible attacks and defenses
79 2015-01-28 07:42:03 <wumpus> (e.g. if you're afraid of your node being isolated, you could listen to different sources sending you new block headers, including a sattelite link)
80 2015-01-28 07:44:52 <wumpus> it all depends on the resources of the attacker, e.g. just using tor works fine to be private from random thieves and snoopers, but a large organization may mount a sybil attack that undermines the assumption that you're connecting to different peers at all
81 2015-01-28 07:51:55 <Luke-Jr> not to mention that even without an IP address, bitcoins can be traced easily
82 2015-01-28 09:22:23 <adlai> can reindexing be stopped partway, and continued later?
83 2015-01-28 09:27:48 <Luke-Jr> yes
84 2015-01-28 09:27:59 <Luke-Jr> ⦠IIRC
85 2015-01-28 09:30:15 <adlai> how? :)
86 2015-01-28 09:31:07 <adlai> there's the trivial SIGSTOP + SIGCONT, but that seems crude, and there's a nonzero chance that i'll have to reboot in between
87 2015-01-28 09:32:52 <Luke-Jr> not sure on the continuing later bit âº
88 2015-01-28 09:32:59 <Luke-Jr> I guess I just let mine sync from network later..
89 2015-01-28 10:56:32 <wumpus> just stop the node, and restart it later?
90 2015-01-28 10:56:48 <wumpus> or is there any reason you need it to keep running?
91 2015-01-28 10:58:15 <wumpus> reindex will automatically continue, I don't think there is even a way to break it off before it scanned through all the block files
92 2015-01-28 13:39:29 <mappum> what is the ETA for the release of bitcoin core 0.10?
93 2015-01-28 13:43:15 <gmaxwell> mappum: it's being held up by BIP66 (and more general review and fixes)
94 2015-01-28 13:46:47 <adlai> Luke-Jr, wumpus, yep. simpler than i expected; it's running again.
95 2015-01-28 15:10:39 <kanzure> "There are also very interesting and useful transactions which can never, ever be made malleability-safe."
96 2015-01-28 15:10:46 <kanzure> maaku_: quickhint please?
97 2015-01-28 15:23:19 <gmaxwell> kanzure: like the lighthouse assurance contract transactions, for example.
98 2015-01-28 15:24:39 <kanzure> alright
99 2015-01-28 15:25:05 <gmaxwell> kanzure: any case you'd use a sighash other than sighash all is inherently malleable.
100 2015-01-28 17:06:48 <cfields> sipa: at what point does SCRIPT_VERIFY_DERSIG move to MANDATORY_SCRIPT_VERIFY_FLAGS ?
101 2015-01-28 17:12:12 <cfields> by the looks, if i'm running 0.10 after the dersig rules have become active, a new invalid dersig won't trigger a DoS ban. Is that intentional?
102 2015-01-28 17:14:43 <wumpus> I think at the point that a new release happens after the switch
103 2015-01-28 17:16:36 <sipa> cfields: strictenc is already in mandatory, no?
104 2015-01-28 17:17:15 <cfields> no
105 2015-01-28 17:17:41 <sipa> i need to look at that code, but i think it easipy can be
106 2015-01-28 17:17:48 <sipa> right now, already
107 2015-01-28 17:17:58 <sipa> there are 0 non-der transactions happening
108 2015-01-28 17:43:05 <wumpus> ah yes, I thought it was mandatory as well, I wasn't able to get a non-dersig transaction into the mempool
109 2015-01-28 17:43:09 <wumpus> even on regtest
110 2015-01-28 17:45:02 <wumpus> and the error was mandatory-script-verify-flag-failed
111 2015-01-28 18:30:11 <sipa> wumpus: sure it wasn't 'non-mandatory' ?
112 2015-01-28 18:34:37 <morcos> if he was testing after the super-majority was passed, he'd get a mandatory-..-failed right?
113 2015-01-28 18:35:19 <sipa> no
114 2015-01-28 18:35:35 <sipa> the rules used for individual transaction validation and block validation are different
115 2015-01-28 18:35:48 <sipa> the only difference between mandatory and non-mandatory is a dos ban or not
116 2015-01-28 18:36:01 <sipa> for block validation, it's determined by consensus rules
117 2015-01-28 18:36:24 <sipa> but we may want to make DERSIG a mandatory flag after the softfork
118 2015-01-28 18:36:33 <gmaxwell> We never want to dosban on something that is just isstandard; but once the lock in happens we could elevate that to dosban, either right away automatically or just in the next release.
119 2015-01-28 18:36:59 <gmaxwell> An argument against doing it automatically is that it will immediately partition varrious pieces of derpy software that sends invalid txn.
120 2015-01-28 18:41:43 <morcos> yeah what i was saying didn't make sense anyway...
121 2015-01-28 18:45:22 <morcos> but so i'm clear on what you're saying, the consensus rules build up on flags happens to be the same as MANDATORY_SCRIPT = SCRIPT_VERIFY_P2SH, but we shouldn't think of MANDATORY_SCRIPT as defining consensus
122 2015-01-28 18:48:27 <wumpus> yes, it's non-mandatory-script-verify-flag, strange, I remember it differently
123 2015-01-28 19:41:09 <sdaftuar_> sipa: regarding 5703 -- the worker thread in CCheckQueue::Loop notifies the master before incrementing nIdle and waiting on the next condition
124 2015-01-28 19:41:42 <sdaftuar_> so ConnectBlock could finish, and move on to the next block, and create a new control before nIdle gets incremented by the CCheckQueue thread
125 2015-01-28 19:42:15 <sipa> oooh
126 2015-01-28 19:42:16 <sipa> interesting
127 2015-01-28 19:42:29 <sdaftuar_> at least, that's what I was able to demonstrate by sticking a usleep(500000) in CCheckQueue::Loop() before nIdle++
128 2015-01-28 19:43:37 <sdaftuar_> i have a fix where I just created an IsIdle function in CCheckQueue that acquires the lock first and then does the checks, and changed CCheckQueueControl to use that function instead
129 2015-01-28 19:43:41 <sdaftuar_> does that sound right to you?
130 2015-01-28 19:44:16 <sipa> sounds good