1 2016-03-24 01:45:54 <Luke-Jr> jonasschnelli: PR & BIP number requests should not be made until AFTER the draft has been discussed on the ML
 2 2016-03-24 02:05:54 <morcos> pharley: it shouldn't require the mempool being empty.
 3 2016-03-24 06:35:11 <jonasschnelli> Luke-Jr: Yes. I'm sorry. btcdrak already pointed that out to me. Should I close the PR for now until there is an agreement on the ML?
 4 2016-03-24 06:46:53 <Luke-Jr> jonasschnelli: it doesn't need agreement, just discussion. just re-ping me on the PR when you've had time to consider the discussions and decided to take it further to assignment. (or close it if for some reason you decide not to)
 5 2016-03-24 06:47:13 <jonasschnelli> Okay. Thanks.
 6 2016-03-24 06:47:41 <Luke-Jr> it's not a big deal really, I just point it out because otherwise people will repeat it and/or think there's a double standard
 7 2016-03-24 07:43:47 <Luke-Jr> in anticipation of jonasschnelli's BIPs, I'm thinking of reserving 16x for p2p presentation layer stuff
 8 2016-03-24 11:16:36 <wumpus> sounds good to me
 9 2016-03-24 12:53:02 <Chris_Stewart_5> Are script verify flags (https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.h#L30) used to enforce soft forks?
10 2016-03-24 13:19:32 <Chris_Stewart_5> also, where are script verify flags set for node operators? Can they be configured inside of bitcoin.conf or is the only configurable by what version you chose
11 2016-03-24 13:21:58 <jonasschnelli> Chris_Stewart_5: this is policy. There is no configuration option available. But node operators can alter the code/compile and run their own node software.
12 2016-03-24 13:22:20 <jonasschnelli> The whole standard-ness is policy and not consensus.
13 2016-03-24 13:23:26 <Chris_Stewart_5> jonasschnelli: Not sure if I understood your answer, these flags vary per bitcoin core release, correct?
14 2016-03-24 13:23:55 <jonasschnelli> Chris_Stewart_5: It can (depending on what policy we recommend / implement in core).
15 2016-03-24 13:24:07 <Chris_Stewart_5> is there a file where I can see what flags are set in which bitcoin core release? I haven't been able to find it. I can see where they are evaluated in interpreter.cpp but not where they are set
16 2016-03-24 13:24:11 <jonasschnelli> But there are serval miners that use cores codebase and change the policy.
17 2016-03-24 13:24:35 <Chris_Stewart_5> jonasschnelli: I understand what you are sayin. Core strongly advises this policy but anyone is free to deviate from that policy.
18 2016-03-24 13:24:42 <jonasschnelli> you might need to check policy.h (and the places where this code part was before).
19 2016-03-24 13:25:34 <jonasschnelli> "Standard script verification flags that standard transactions will comply with. However scripts violating these flags may still be present in valid blocks and we must accept those blocks."
20 2016-03-24 13:26:20 <Chris_Stewart_5> Just got done reading that, isn't that contradicting the purpose of these flags?
21 2016-03-24 13:26:58 <Chris_Stewart_5> Because, from what I can tell in interpreter.cpp, if these flags are violated the script fails and an error is returned
22 2016-03-24 13:29:06 <jonasschnelli> Chris_Stewart_5: they might fail for AcceptToMempool, but they should not fail when verifying a new block.
23 2016-03-24 13:29:39 <jonasschnelli> IsStandardTx() should only be called for accepting to the mempool.
24 2016-03-24 13:29:45 <jonasschnelli> *from
25 2016-03-24 13:31:17 <Chris_Stewart_5> So basically if a miner tries to include a non-standard tx that passes interpreter.cpp disregarding script verify flags nodes must also accept it as a valid tx?
26 2016-03-24 13:33:45 <instagibbs> isStandard only effects local node policy/relay
27 2016-03-24 13:33:50 <instagibbs> affects*
28 2016-03-24 13:38:17 <Chris_Stewart_5> so are all script verify flags nulled out when checking a block of txs then?
29 2016-03-24 13:39:08 <Chris_Stewart_5> I'm getting confused of the relation of IsStandardTx() being called and script verify flag checks being in interpreter.cpp.
30 2016-03-24 13:39:34 <Chris_Stewart_5> Seems like IsStandardTx is irrelevant to checking blocks of txs according to jonasschnelli
31 2016-03-24 13:41:29 <wumpus> yes, IsStandardTx is irrelevant to blocks
32 2016-03-24 13:42:10 <wumpus> 'standardness' rules are rules on enforced on top of the consensus by miners and relay nodes
33 2016-03-24 13:42:32 <Chris_Stewart_5> wumpus: Are script verify flags totally disregarded when evaluating tx in blocks?
34 2016-03-24 13:42:37 <wumpus> they have no obligation to do so, and some miners will in fact accept non-standard transactions
35 2016-03-24 13:43:26 <wumpus> Chris_Stewart_5: well, no, some script verify flags are used when evaluating tx in blocks, but not all
36 2016-03-24 13:43:49 <Chris_Stewart_5> wumpus: Can you point to the line in bitcoin core that determines what flags are mandatory for block verification?
37 2016-03-24 13:44:05 <wumpus> a softfork can add script verify flags that are mandatory for consensus
38 2016-03-24 13:45:10 <Chris_Stewart_5> This is really interesting - also confusing :-).
39 2016-03-24 13:47:19 <Chris_Stewart_5> wumpus: Wouldn't that imply that older versions of nodes NOT running the mandatory script verify flags would fall out of consensus?
40 2016-03-24 13:47:38 <wumpus> that logic is in ConnectBlock in main.cpp
41 2016-03-24 13:49:12 <instagibbs> Chris_Stewart_5, older version will accept blocks with more lenient rules, sure. This is drifting into #bitcoin territory if you wanna chat more about it :)
42 2016-03-24 13:53:15 <Chris_Stewart_5> I'll try to keep it on topic. Can't help myself from asking broader questions sometimes :-)
43 2016-03-24 13:55:47 <instagibbs> your question seems essentially what a hardfork/softfork is, no worries
44 2016-03-24 19:12:44 <TomMc> May not be such a dev question, but why is testnet pouring through blocks? A week ago I'd wait at least an hour for 10 confs
45 2016-03-24 19:22:21 <Luke-Jr> TomMc: someone is mining it?
46 2016-03-24 19:24:06 <johnwhitton> Hi all I have a question about GetBlock Template (specifically creating the merkle root)
47 2016-03-24 19:24:19 <TomMc> Just surprised at the rate I suppose
48 2016-03-24 19:24:42 <johnwhitton> I’ve been reading over https://en.bitcoin.it/wiki/Getblocktemplate and https://chrispacia.wordpress.com/2013/09/02/bitcoin-mining-explained-like-youre-five-part-2-mechanics/
49 2016-03-24 19:27:08 <johnwhitton> So if I understand it correctly you get a block template and then you can append a coinbase transaction and then you
50 2016-03-24 19:27:11 <johnwhitton> “Collect your coinbase transaction (modified or not) at the front of the "transactions" list provided by the server. Apply a double-SHA256 hash to each transaction in the list.”
51 2016-03-24 19:27:21 <johnwhitton> I suppose I have two question
52 2016-03-24 19:27:33 <johnwhitton> The first is regarding the transaction list
53 2016-03-24 19:29:39 <johnwhitton> How do the transactions get pulled into the block, my assumption is that there are a number of unconfirmed transactions out there and that some of these based on priority are pulled in and used to create the merkle tree
54 2016-03-24 19:29:43 <johnwhitton> Is that correct?
55 2016-03-24 19:30:10 <johnwhitton> Or to take a step back, is this the right channel to be asking this question?
56 2016-03-24 19:30:12 <Luke-Jr> The generation transaction needs to be prepended
57 2016-03-24 19:30:35 <Luke-Jr> sure, here is fine
58 2016-03-24 19:31:15 <Luke-Jr> unconfirmed transactions get flooded across the p2p network
59 2016-03-24 19:31:28 <Luke-Jr> bitcoind saves those and builds the transaction list based on them
60 2016-03-24 19:33:24 <johnwhitton> So bitcoind creates a transaction list at some point in time and the miner then, gets the block template and then gets the transaction list from bitcoind, creates their merkle tree, hashes it and then submits it as a Proof of Work?
61 2016-03-24 19:33:49 <Luke-Jr> the block template includes the transaction list
62 2016-03-24 19:33:55 <johnwhitton> ahhh
63 2016-03-24 19:34:23 <Luke-Jr> the proof-of-work is across the block header, which includes the merkle tree root
64 2016-03-24 19:35:04 <johnwhitton> so if I get a block template at 12:00 and someone else gets a block template at say 12:05 is the block template different (i.e. does it contain different transactions)?
65 2016-03-24 19:40:47 <johnwhitton> So now specifically on the transactions included in the block template I’m thinking that a) bitcoind running on a node makes a list of transactions which it passes in the block template
66 2016-03-24 19:41:15 <johnwhitton> b) each node at each time would potentially include different transaction in the block template
67 2016-03-24 19:42:15 <johnwhitton> c) when a block is confirmed it would be published and then bitcoind would have to update it’s transaction list removing those confirmed transactions?
68 2016-03-24 19:43:30 <johnwhitton> I suppose I’m trying to understand whether everyone starts with the same set of transaction in the block template and when a block is solved everyone just gets a new set or whether it’s more granular
69 2016-03-24 19:44:32 <johnwhitton> And people start with different sets of transactions and when a block is solved they, update their transaction list accordinly and start trying to solve the next block
70 2016-03-24 19:45:12 <johnwhitton> Is there any other documentation for this other than what I’ve list or some source code I could look at to see how the transaction list is created?
71 2016-03-24 20:03:17 <TD-Linux> johnwhitton, everything you said sounds correct. each node has its own mempool.
72 2016-03-24 20:05:06 <johnwhitton> So then each node does start with it’s list of transactions and then when a block is solved it will stop working on it’s current attempt update it’s txn list and start again
73 2016-03-24 20:05:34 <johnwhitton> Thanks :Luke-Jr and :TD-Linux
74 2016-03-24 20:06:26 <Luke-Jr> johnwhitton: note libblkmaker implements GBT from the client end
75 2016-03-24 20:13:13 <johnwhitton> Luke-Jr: So here https://github.com/bitcoin/libblkmaker
76 2016-03-24 20:13:41 <Luke-Jr> yes
77 2016-03-24 20:14:24 <johnwhitton> Luke-Jr: Thanks :)
78 2016-03-24 20:15:56 <Luke-Jr> np
79 2016-03-24 22:35:44 <PRab> I'm reading through https://github.com/jonasschnelli/bips/blob/2016/03/auth_enc/bip-undef-0.mediawiki and its not clear to me. Are all peers required to be in the authorized-peers db to send authenticated messages, or would that just be to have access to the additional services?