1 2015-07-30 06:06:03 <jonasschnelli> StephenM347 (is gone, but for the records): bitcoins RPC server speaks JSON RPC 1.0 + support for batching from the 2.0 standard.
  2 2015-07-30 06:23:50 <drazisil> Could I be directed to an explanation and/or code that explains how a miner knows the tx fees and collects them? Please :)
  3 2015-07-30 06:24:46 <Luke-Jr> drazisil: uh, I'm not clear on what you mean there. the fee is the difference between output sum and input sum
  4 2015-07-30 06:26:12 <drazisil> Is that really the only way to know? The miner subtracts vin from vout from each tx and sums into the coinbase? I figured there was more to it I just couldn't find.
  5 2015-07-30 06:26:54 <Luke-Jr> that's it
  6 2015-07-30 06:27:11 <Luke-Jr> Bitcoin Core caches the information in the memory pool, but .. doesn't actually use it when mining XD
  7 2015-07-30 06:36:53 <drazisil> thank you for the help Luke, I was completely overthinking it.
  8 2015-07-30 06:37:38 <Luke-Jr> np
  9 2015-07-30 06:58:02 <drazisil> What would be the bast way to get what peer my node recieves each block from? Is that info logged anywhere, or would I have to make a proxy for it?
 10 2015-07-30 07:03:51 <jonasschnelli> drazisil: you'd like to know which peer did server you which block?
 11 2015-07-30 07:04:03 <jonasschnelli> (during initial sync or during "normal" operation?)
 12 2015-07-30 07:04:34 <jonasschnelli> what do you like to achieve?
 13 2015-07-30 07:05:09 <drazisil> jonasschnelli: normal. The use case was to see which peers were most reliable in relaying blocks in a timely fashion
 14 2015-07-30 07:06:17 <jonasschnelli> drazisil: if you enable -debug=net you would get a log msg like this: "received block %s peer=%d\n"
 15 2015-07-30 07:06:48 <drazisil> jonasschnelli: ah, that would be perfect, thanks. :)
 16 2015-07-30 07:07:06 <jonasschnelli> if you do like to add some custom (database) logging for later analysis, add something here: https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L4374
 17 2015-07-30 07:08:10 <drazisil> also very helpful.
 18 2015-07-30 10:23:02 <jonasschnelli> is there now the plan to avoid on-line ifs/elses without brackets?
 19 2015-07-30 10:26:19 <jtimon> jonasschnelli: not that I'm aware of, the current clang-format rules allow them
 20 2015-07-30 10:27:46 <jtimon> we have many functions of the form: if (x) return false; if (y) return false; if (z) return false; return true; and brakets don't add anything there
 21 2015-07-30 10:28:15 <jtimon> but you can propose changes to the clang-format file
 22 2015-07-30 10:29:20 <jonasschnelli> found: https://github.com/jonasschnelli/bitcoin/commit/5c6a28cb0bcb0e28315e2ee9937e25980bdb213f#commitcomment-12348557
 23 2015-07-30 10:29:53 <jonasschnelli> jtimon: Yes. I started to like the one-liner-ifs ... (in past i didn't liked them)
 24 2015-07-30 10:31:28 <jtimon> jonasschnelli: I tend to like anything that looks more like python...but anyway, we haven't even applied the current style project-wide yet
 25 2015-07-30 10:32:14 <jtimon> last time, when deciding the rules, a criterion used was to see how many changes would require to apply the style project-wise
 26 2015-07-30 10:33:12 <jtimon> for example "CObject& o" produced a smaller diff than "CObject &o"
 27 2015-07-30 10:34:06 <jonasschnelli> Okay. Makes sense.
 28 2015-07-30 10:34:34 <jonasschnelli> Or is the comment on the same line (https://github.com/jonasschnelli/bitcoin/commit/5c6a28cb0bcb0e28315e2ee9937e25980bdb213f#commitcomment-12348557) an issue?
 29 2015-07-30 10:34:40 <jtimon> without objective criteria like that, it is to easy to start an endless style subjective discussion
 30 2015-07-30 10:36:28 <jonasschnelli> Agreed.
 31 2015-07-30 10:36:42 <jtimon> "
 32 2015-07-30 10:36:42 <jtimon> jonasschnelli: not sure, the best way to find out is running clang-format, last time I used it (probably not the best way to use it, since you only want to apply the style in the lines you have touched already) was with: "clang-format-3.5 -style=file script/interpreter.cpp > aux; cat aux > script/interpreter.cpp; rm aux
 33 2015-07-30 10:37:45 <jtimon> try it in main, for example, and you should be able to get an overall idea of the current style rules
 34 2015-07-30 10:40:17 <jtimon> it would be nice to have some automatic way to do that only on your staged changes or something
 35 2015-07-30 10:42:10 <jonasschnelli> there's probably a gif oneliner.. :)
 36 2015-07-30 10:42:15 <jonasschnelli> s/gif/git
 37 2015-07-30 10:42:26 <jtimon> oneliner?
 38 2015-07-30 10:42:51 <jonasschnelli> one line of shell stuff
 39 2015-07-30 10:43:19 <jtimon> oh, got it. well, if you find it, please let me know
 40 2015-07-30 10:43:34 <jonasschnelli> somethig like this: git diff --cached --name-only --diff-filter=ACMRT | grep "\.[cmh]$" | xargs -n1 clang-format -style=file -output-replacements-xml | grep "<replacement " >/dev/null
 41 2015-07-30 10:43:46 <jonasschnelli> (not usefull in our case)
 42 2015-07-30 10:44:17 <jonasschnelli> from another project, "oneliner" is maybe a swiss-english-word .. :)
 43 2015-07-30 10:49:58 <jtimon> well, it would be nice to have a script in contrib or something
 44 2015-07-30 10:51:25 <jonasschnelli> Indeed
 45 2015-07-30 11:40:28 <jonasschnelli> Anyone from bitpay / bip45 authors here?
 46 2015-07-30 11:41:23 <jonasschnelli> i don't understand the reason why bip45 (hd multisig wallets) should have a bip32chain with a cosigner_index.
 47 2015-07-30 11:44:08 <jonasschnelli> What's the advantage over each multisig participant having a standard bip44 chain (like m / 44' / 0' / 100' / 0 / X) where each ms address has the same X (index) for each participant
 48 2015-07-30 11:51:27 <jonasschnelli> nm. I see the advantages now...
 49 2015-07-30 12:21:31 <joedoe-> it's always good to see the advantates
 50 2015-07-30 12:44:17 <jonasschnelli> hah.. indeed
 51 2015-07-30 12:45:19 <jonasschnelli> for the records: with bip45 you can avoid address "collisions"/reusing if two ms participants creates addresses.
 52 2015-07-30 12:45:27 <jonasschnelli> (^ main benefit IMO)
 53 2015-07-30 13:36:26 <zip_> Any devs up for a quick question?
 54 2015-07-30 13:41:23 <jonasschnelli> shoot
 55 2015-07-30 13:43:18 <zip_> Up to now, the soft blocksize limit seems to have held up fine to miners simply defaulting to the hard 1MB limit. Why can't this hold true in the future?
 56 2015-07-30 13:43:42 <zip_> I.E. Raising max blocksize and have miners still implement their soft maxes accordingly as they've always done?
 57 2015-07-30 13:43:49 <jonasschnelli> zip_: please don't bother use with blocksize. Thanks.
 58 2015-07-30 13:44:17 <zip_> Sorry... didn't mean to disturb. Seemed quite enough in here to try shooting a question. That's all
 59 2015-07-30 13:44:21 <zip_> *quiet
 60 2015-07-30 13:44:43 <jonasschnelli> zip_: Yeah. Sorry. for the harsh reaction..
 61 2015-07-30 13:45:13 <jonasschnelli> But there are serval placed where the discussion about the blocksize just exceed any normal level
 62 2015-07-30 13:45:26 <zip_> I agree
 63 2015-07-30 13:45:49 <zip_> I've noticed things have been getting quite heated on the maillist
 64 2015-07-30 13:45:53 <jonasschnelli> I think your questions better off in #bitcoin
 65 2015-07-30 13:45:59 <zip_> ok
 66 2015-07-30 13:46:01 <zip_> thanks again
 67 2015-07-30 13:46:22 <jonasschnelli> sdaftuar: now running #6148 ...
 68 2015-07-30 13:47:18 <sdaftuar> jonasschnelli: thanks! please let me know if you spot any issues
 69 2015-07-30 13:48:04 <jonasschnelli> sdaftuar: am i right that tx relaying was always on for pruned nodes? now it just also relay blocks?
 70 2015-07-30 13:48:10 <sdaftuar> yes that's right
 71 2015-07-30 13:48:42 <jonasschnelli> okay... so i keep it running a while (24h),... while also checking the "net" category logs if there are any getblocks i assume?
 72 2015-07-30 13:50:40 <sdaftuar> yes, sure -- also you could start up say an 0.9 node and connect it to the pruning node (since that uses getblocks -- if your peers are only 0.10 or later you'll never see any)
 73 2015-07-30 14:06:51 <jonasschnelli> sdaftuar: 2015-07-30 14:05:49 sending: block (816471 bytes) peer=33     <--- looks good
 74 2015-07-30 16:42:21 <akstunt600> big fan of this super duper mempool limiter
 75 2015-07-30 16:42:55 <akstunt600> Floating relay fee sounds reasonable.
 76 2015-07-30 18:31:13 <Luke-Jr> hm, it just occurred to me jgarzik's miner-voting thing could be construed as an implicit "dynamic miner soft-fork"
 77 2015-07-30 18:44:30 <Anduck> http://0bin.net/paste/XGBsHlAmEv092Nod#oMC8+LlfszYluL77enyAJ3gPSth6-Mx+ZAJU250UXOi
 78 2015-07-30 18:44:46 <Anduck> is this silly or could it be worthwhile?
 79 2015-07-30 18:50:08 <phantomcircuit> Anduck, that's pointless
 80 2015-07-30 18:50:16 <phantomcircuit> Anduck, the miners can still do whatever they want
 81 2015-07-30 18:51:01 <Anduck> when the nodes are not accepting it?
 82 2015-07-30 18:51:23 <Luke-Jr> phantomcircuit is unexpectedly polite; the 0bin is absurd :P
 83 2015-07-30 18:51:30 <Anduck> or when they're at least resisting it
 84 2015-07-30 18:51:41 <jcorgan> nodes can already not "accept" whatever they like
 85 2015-07-30 18:52:39 <Anduck> why?
 86 2015-07-30 18:52:46 <Apocalyptic> <Luke-Jr> phantomcircuit is unexpectedly polite; the 0bin is absurd :P << +1
 87 2015-07-30 18:53:11 <Luke-Jr> 1. treating consensus rules as policy = no consensus
 88 2015-07-30 18:53:12 <jcorgan> node operators are free to impose any sort of policy they want on what they will relay
 89 2015-07-30 18:53:18 <Anduck> it would break consensus about the tip of the blockchain but resisting nodes would need to follow the others to keep using it
 90 2015-07-30 18:53:34 <Luke-Jr> 2. using local mempool in  consensus rules = no consensus
 91 2015-07-30 18:54:12 <Luke-Jr> 3. using previous block sizes to determine limit = miners just censor or stuff blocks to control it
 92 2015-07-30 18:54:15 <Anduck> so concencus couldn't be achieved by taking the most common policies following chain?
 93 2015-07-30 18:54:28 <Luke-Jr> 4. SPV miners don't necessarily make too-small blocks, nor are too-small blocks a problem
 94 2015-07-30 18:54:30 <phantomcircuit> Anduck, it's a waste of time; shunning a block isn't going to make it go away
 95 2015-07-30 18:54:42 <Luke-Jr> 5. time does not improve consensus in this situation
 96 2015-07-30 18:54:44 <phantomcircuit> you would just be delaying your view of the world by a few hours
 97 2015-07-30 18:54:59 <Luke-Jr> 6. stale ("orphan") blocks are inherently bad for consensus
 98 2015-07-30 18:55:12 <jcorgan> Anduck: there is a difference between what is valid (fixed consensus rules) and what a node chooses to relay, which is basically called "standard"
 99 2015-07-30 18:55:36 <Anduck> right, right, i am just wondering could it all be made dynamic, based on nodes policies.
100 2015-07-30 18:55:37 <jcorgan> your use of the term "accept" is ambiguous in this regard
101 2015-07-30 18:56:29 <jcorgan> if you are proposing to make consensus-rules per node, that is not a consensus
102 2015-07-30 18:56:59 <jcorgan> each participant in bitcoin would have to negotiate consensus rules with whomever they wanted to transact with
103 2015-07-30 18:57:13 <jcorgan> to ensure that the other party had compatibile consensus rules
104 2015-07-30 18:58:01 <Anduck> hmm.. why would they need to negotiate? if a node starts to push something you don't want, he can block it, right?
105 2015-07-30 18:58:02 <jcorgan> "oh, you're TX got included in a block my node doesn't recogizne? sorry, try again"
106 2015-07-30 18:58:15 <jcorgan> damn my spelling today
107 2015-07-30 18:58:50 <Anduck> well, the nodes would need to drop their resistance when their initial position ends being against the consensus
108 2015-07-30 18:59:34 <Apocalyptic> Anduck, what do you know about consensus systems, how long have you studied them ?
109 2015-07-30 19:00:30 <jcorgan> btw, this might be better over in -wizards, but meh
110 2015-07-30 19:00:53 <Anduck> ._. what do you expect me to answer? i've studied some bitcoin.. right? know... something, right? and if this is not the appropriate channel for this kind of discussions.. well, let me know
111 2015-07-30 19:02:15 <Anduck> slightly ot but it has reached github for sure
112 2015-07-30 19:02:30 <Anduck> this channel, not so much
113 2015-07-30 19:03:34 <Anduck> so... if the nodes would have very different policies (or consensus rules), it would be a mess in the beginning at least
114 2015-07-30 19:03:47 <Anduck> why couldn't the consensus be reached eventually?
115 2015-07-30 19:04:50 <Luke-Jr> Anduck: because my node would (eg) *never* accept your blockchain with DP spam
116 2015-07-30 19:04:57 <Luke-Jr> no matter how long it got
117 2015-07-30 19:05:05 <jcorgan> consensus rules have to be objectively verifiable after the fact, all the way back to the genesis block
118 2015-07-30 19:05:39 <Anduck> luke: if the others would, you would need to drop your resistance or you wouldn't be part of the bitcoin anymore
119 2015-07-30 19:05:51 <Luke-Jr> Anduck: but not all others would
120 2015-07-30 19:06:31 <jcorgan> you're basically proposing a hard fork every block
121 2015-07-30 19:06:53 <Anduck> Luke-Jr: if the majority would, as in everyone would strectch enough to gain the common consensus path
122 2015-07-30 19:07:40 <Anduck> jcorgan: well, there could still be the strict consensus rules which just can't be changed (or well, 99.9999% of the nodes will not change it, like the amount of bitcoins etc)
123 2015-07-30 19:08:27 <Anduck> things like block size and what transactions are grouped in it could be determined by policy, right? i may be missing something big here, starting to feel like so =D
124 2015-07-30 19:10:16 <Anduck> there are obviously downsides (consensus couldn't be reached as well as today) but also good things like the flexibility of the network
125 2015-07-30 19:11:43 <jcorgan> miners, by the act of extending the chain, only decide the order of transactions that meet a pre-defined set of consensus rules.  if those rules aren't global, then the meaning of "best chain tip" becomes fragmented, and the coin essentially would fork into a set of altcoins, each with their own community of users that agrees that particular tip is best
126 2015-07-30 19:16:34 <Anduck> yes. but in the end these altcoins would drop and the minority communities with their own tips would drop it. this could even be in the consensus rules
127 2015-07-30 19:16:52 <Luke-Jr> /me facepalms.
128 2015-07-30 19:16:54 <Anduck> would it be bad to have a constant "fight" over the tip
129 2015-07-30 19:17:22 <Anduck> well, is there a #bitcoin-dev-noobs probably...?
130 2015-07-30 19:17:50 <Anduck> :)
131 2015-07-30 19:18:08 <jcorgan> actually, no reason not to have this conversation in #bitcoin or maybe -wizards, but i don't think there is much more to say
132 2015-07-30 19:20:30 <Anduck> ok. well, gotta think deeper into these things. thanks all for feedback
133 2015-07-30 19:23:33 <jcorgan> no worries, it's not always intuitive, and i welcome honestly motivated discussions
134 2015-07-30 20:09:08 <morcos> i've been doing some thinking about policy restricting the number of related unconfirmed txs.  in the vein of #6403, and wondered if any one has thoughts on the criteria we should be aiming for.
135 2015-07-30 20:10:52 <morcos> there are a couple of useful metrics: the entire package of descendant transactions (# and total tx size or maybe even links followed or depth or breadth) - this is probably the biggest concern for being able to intentionally clog a mempool that is capped in size
136 2015-07-30 20:11:19 <morcos> entire package of ancestor transactions - useful for being able to reasonably calculate CPFP for mining
137 2015-07-30 20:11:33 <morcos> unfortunately both of these might be prohibtively expensive to calculate
138 2015-07-30 20:12:43 <morcos> sipa mentioned a concept of partition, which is all transactions which are related to each other.  the partitions are determined by the transitive closure of the mempool.  i believe this will probably be far cheaper to calculate, but it doesn't have any useful results on its own.
139 2015-07-30 20:13:01 <morcos> you can't use it to sort the mempool for more effective eviction or for CPFP
140 2015-07-30 20:13:24 <morcos> but it would serve as an upper bound on the ability to create clogging chains
141 2015-07-30 20:14:24 <morcos> however it also means you may not be able to place a tx which has very few unconfirmed dependencies solely because of sibling or other relative tx's that aren't relevant to you but already exist in the mempool
142 2015-07-30 20:15:10 <morcos> also how much of a performance hit are we willing to take to keep track of this information
143 2015-07-30 21:03:19 <phantomcircuit> morcos, CPFP is ultimately nothing more than a hack which is largely unnecessary if replace-by-fee was common
144 2015-07-30 21:05:27 <Luke-Jr> phantomcircuit: eh, not really
145 2015-07-30 21:05:32 <Luke-Jr> phantomcircuit: you need it when you're the recipient
146 2015-07-30 21:06:27 <phantomcircuit> Luke-Jr, only if you're trying to spend unconfirmed outputs
147 2015-07-30 21:06:37 <phantomcircuit> and why are you trying to do that?
148 2015-07-30 21:08:27 <Luke-Jr> phantomcircuit: no, you missed the point: the /goal/ of spending the UTXOs, is to *cause* them to be confirmed
149 2015-07-30 21:09:10 <Luke-Jr> phantomcircuit: if Joe pays Bob without a fee, and Bob wants it confirmed faster, Bob then spends it with a fee
150 2015-07-30 21:09:19 <morcos> phantomcircuit: also regardless of whether its a feature the users will use, its the rational algorithm to use for mining
151 2015-07-30 21:09:26 <phantomcircuit> Luke-Jr, no i did understand that, but i dont see how failing to pay a fee should be the recipients problem
152 2015-07-30 21:09:41 <phantomcircuit> that's just going to lead to nobody paying a fee and expecting the recipient to CPFP it
153 2015-07-30 21:10:02 <Luke-Jr> phantomcircuit: that's why the payment protocol supports the recipient surrendering a fee upfront
154 2015-07-30 21:10:22 <Luke-Jr> so CPFP is only needed when the fee needs bumping
155 2015-07-30 23:36:21 <go1111111> is the following post appropriate/worthwhile for a thread on the bitcoin-dev mailing list? http://pastebin.com/HSzLEDqi . It seems that block size discussion is on topic, but I also know that new people posting on the dev list about block size have generated lots of unwanted posts lately.
156 2015-07-30 23:55:52 <halitosis> This is the tail of my vanilla 0.11   ~/.bitcoin/debug.log  just before it crashed: http://privatepaste.com/download/86bcc1e682
157 2015-07-30 23:55:58 <halitosis> Notice the incomplete line
158 2015-07-30 23:56:27 <halitosis> The machine has a huge amount of memory and disk, so it's not that. Any way I can get more information tracking down a crash?