1 2016-03-09 00:10:51 <Luke-Jr> wallet42: bitcoind never downloads orphan blocks anymore. if you mean stale blocks, it keeps all that it has ever used forever (unless pruning maybe?)
  2 2016-03-09 00:11:38 <wallet42> got it, i was wondereing since all blocks are stores in blk*.dat files
  3 2016-03-09 00:12:12 <wallet42> while they are limited to 128MiB
  4 2016-03-09 00:12:28 <wallet42> and not guaranteed to be in order since headers fist
  5 2016-03-09 00:12:43 <wallet42> and since there are stale blocks etc..
  6 2016-03-09 00:12:50 <wallet42> and once they are "full" they just dont get touched anymore
  7 2016-03-09 00:13:14 <wallet42> so there is no "stale block" garbage collection code
  8 2016-03-09 00:44:36 <rusty> btcdrak: see last mail re:bip9.
  9 2016-03-09 02:42:40 <mappum> does Bitcoin Core have some sort of rate limiting for getdata requests? if so, where can i find it?
 10 2016-03-09 08:01:01 <CryptoSiD> I have weird issue with v12, when someone send me bitcoin, i wont see hem, and when i send bitcoin, the tx wont be visible to any blockchain till i use a pushtx service like blockchain.info/pushtx
 11 2016-03-09 08:01:17 <CryptoSiD> trying to find the problem, can it be the pruning? i use prune=550
 12 2016-03-09 08:02:10 <jonasschnelli> CryptoSiD: how do you send them? GUI? RPC?
 13 2016-03-09 08:02:18 <CryptoSiD> GUI
 14 2016-03-09 08:02:26 <jonasschnelli> What does the transaction list says? Can you see your transaction there?
 15 2016-03-09 08:02:30 <CryptoSiD> worked fine with v9, v10 and v11
 16 2016-03-09 08:02:36 <CryptoSiD> i can see it yes
 17 2016-03-09 08:02:39 <CryptoSiD> but no one else can
 18 2016-03-09 08:02:51 <jonasschnelli> But you can't find the transaction on a blockexplorer?
 19 2016-03-09 08:03:20 <CryptoSiD> nope, its invisible to every blockexplorer, till i use blockchain.info/pushtx, or any other pushtx service/website
 20 2016-03-09 08:03:58 <CryptoSiD> never saw that with v9, v10, v11, but as soon as i updated to v12 i started using prune=550
 21 2016-03-09 08:04:16 <jonasschnelli> Should not be related to prune...
 22 2016-03-09 08:04:23 <jonasschnelli> Do you use CoinControl and extremely low fees?
 23 2016-03-09 08:05:02 <CryptoSiD> i use coincontrol but i use right fees, like my last tx had 0.00038 fees
 24 2016-03-09 08:05:16 <CryptoSiD> and its been invisible for 2 hours, till i use blockchain.info/pushtx
 25 2016-03-09 08:05:39 <jonasschnelli> So... you create the tx with core,... then copy the rawtx and push/broadcast it over blockchain.info?
 26 2016-03-09 08:05:47 <CryptoSiD> and now, i just received 0.015 bitcoin, the tx is unconfirmed, but im supose to see it anyway in my wallet
 27 2016-03-09 08:05:49 <CryptoSiD> exactly
 28 2016-03-09 08:06:15 <CryptoSiD> even with 0 confirm i always been able to see the tx in my wallet, but not since v12/prune
 29 2016-03-09 08:06:35 <CryptoSiD> so the problem seems to go both way, send/receive
 30 2016-03-09 08:06:44 <jonasschnelli> Yes. you should see it. Can you check in the debug window to how many peers you are connected to,... what is your current height?
 31 2016-03-09 08:07:06 <CryptoSiD> 401838
 32 2016-03-09 08:07:08 <CryptoSiD> 12 peers
 33 2016-03-09 08:07:23 <jonasschnelli> hmm... and you use walletbroadcast=0?
 34 2016-03-09 08:07:45 <CryptoSiD> nope, only prune=550 in my conf
 35 2016-03-09 08:07:46 <CryptoSiD> thats all
 36 2016-03-09 08:08:23 <jonasschnelli> hmm.... could be a IsMine() issue... do you use WatchOnly addresses?
 37 2016-03-09 08:08:33 <CryptoSiD> nope, i dont even know how:P
 38 2016-03-09 08:09:17 <CryptoSiD> all my addresses have been created trough file/receiving address, +new button
 39 2016-03-09 08:09:55 <CryptoSiD> current number of transaction 0, memory usage 0.00
 40 2016-03-09 08:10:02 <CryptoSiD> normal?
 41 2016-03-09 08:10:25 <CryptoSiD> anyway i should see that TX in my wallet and i don'T
 42 2016-03-09 08:10:26 <CryptoSiD> https://blockchain.info/tx/ab04d85d186c7af9778906196932ff9cb6a1608ccab1622e9842c79aa3c9a74c
 43 2016-03-09 08:10:26 <jonasschnelli> No... this is the reason why you don't recive transaction.
 44 2016-03-09 08:10:30 <CryptoSiD> the 0.015 is mine
 45 2016-03-09 08:10:44 <CryptoSiD> whats causing this?
 46 2016-03-09 08:10:57 <jonasschnelli> Hmm... did you try a Bitcoin-Qt restart?
 47 2016-03-09 08:11:06 <jonasschnelli> (kinda lame, i know)
 48 2016-03-09 08:11:08 <CryptoSiD> yep, multiple time
 49 2016-03-09 08:11:16 <jonasschnelli> okay... strange...
 50 2016-03-09 08:11:21 <jonasschnelli> Can you look in the debug.log?
 51 2016-03-09 08:11:23 <CryptoSiD> i restated windows also (like my isp would ask) (just kidding)
 52 2016-03-09 08:11:31 <CryptoSiD> sure, i can even upload it if you want to see it
 53 2016-03-09 08:11:43 <jonasschnelli> Yes. Would help... pastebin it somewhere
 54 2016-03-09 08:11:52 <CryptoSiD> but after looking at it, i cant find anything strange, im not that skilled tho
 55 2016-03-09 08:11:54 <CryptoSiD> sec
 56 2016-03-09 08:12:07 <jonasschnelli> If there is nothing suspicious,.. we might need to restart with -debug=net
 57 2016-03-09 08:14:20 <CryptoSiD> http://paste.ubuntu.com/15333525/ , cant use pastebin, exceed 512kb
 58 2016-03-09 08:14:41 <CryptoSiD> brrr, look like i crashed paste.ubuntu.com!?
 59 2016-03-09 08:14:44 <CryptoSiD> cant load the page lol
 60 2016-03-09 08:15:32 <jonasschnelli> I got something...
 61 2016-03-09 08:15:48 <CryptoSiD> kewl thanks
 62 2016-03-09 08:16:05 <CryptoSiD> i even resynced from 0, 2 time, still with prune=550 tho
 63 2016-03-09 08:18:39 <jonasschnelli> hmm.... strange..
 64 2016-03-09 08:18:49 <CryptoSiD> what?
 65 2016-03-09 08:19:14 <jonasschnelli> So. You getting new blocks but no transactions?!
 66 2016-03-09 08:19:20 <CryptoSiD> right
 67 2016-03-09 08:19:51 <jonasschnelli> Can you stop bitcoin-qt, move away the debug log (or delete it),.. and restart Bitcoin-Qt from console with -debug=mempool,net?
 68 2016-03-09 08:20:04 <jonasschnelli> This could really be a bug in the prune implementation
 69 2016-03-09 08:20:30 <CryptoSiD> doing this sec
 70 2016-03-09 08:20:37 <jonasschnelli> So, appreciate if you are willing to debug/track down this issue.
 71 2016-03-09 08:20:50 <CryptoSiD> I sure am:)
 72 2016-03-09 08:21:12 <jonasschnelli> Once you restarted with -debug=mempool,net  ... let it run for 1-2 mins... then upload the debug.log again (should be much smaller now).
 73 2016-03-09 08:22:06 <CryptoSiD> 2016-03-09 08:21:47 LoadBlockIndexDB: transaction index disabled
 74 2016-03-09 08:22:08 <CryptoSiD> is this normal?
 75 2016-03-09 08:22:31 <jonasschnelli> yes.
 76 2016-03-09 08:22:43 <jonasschnelli> transaction index is a "AddOn"... which is off by default.
 77 2016-03-09 08:22:51 <jonasschnelli> And incompatible with -prune
 78 2016-03-09 08:23:27 <CryptoSiD> ok, running it with -debug=mempool.net now
 79 2016-03-09 08:23:37 <CryptoSiD> will upload debug.log (brand new one) in 2 mins
 80 2016-03-09 08:24:12 <jonasschnelli> Wait...
 81 2016-03-09 08:24:24 <jonasschnelli> mempool.net should be mempool,net
 82 2016-03-09 08:24:32 <jonasschnelli> coma
 83 2016-03-09 08:24:41 <CryptoSiD> I lied, i have this in my conf
 84 2016-03-09 08:24:42 <CryptoSiD> blocksonly=1
 85 2016-03-09 08:24:42 <CryptoSiD> dbcache=3000
 86 2016-03-09 08:24:42 <CryptoSiD> prune=550
 87 2016-03-09 08:24:50 <CryptoSiD> my bad sorry
 88 2016-03-09 08:24:54 <CryptoSiD> any of those wrong?
 89 2016-03-09 08:24:54 <jonasschnelli> hah. Why blocksonly=1? :)
 90 2016-03-09 08:25:12 <jonasschnelli> Thats probably the reason.
 91 2016-03-09 08:25:13 <CryptoSiD> well someone told me to use that, apparently it sync faster, dont even know what it does:D
 92 2016-03-09 08:25:40 <jonasschnelli> it will make you only sync blocks...
 93 2016-03-09 08:25:56 <jonasschnelli> remove the blocksonly and restart..
 94 2016-03-09 08:25:56 <jonasschnelli> that should solve the issue
 95 2016-03-09 08:26:22 <jonasschnelli> Maybe someone told you to use checkblocks=1 ... which results in faster startup,... but won't detect db corruptions.
 96 2016-03-09 08:26:43 <jonasschnelli> (I used that sometimes, when I do multiple restarts)
 97 2016-03-09 08:27:06 <CryptoSiD> nope, even without that i still dont see the tx
 98 2016-03-09 08:27:19 <CryptoSiD> so will use -debug=mempool,net
 99 2016-03-09 08:27:49 <CryptoSiD> i really only have prune=550 in my conf now
100 2016-03-09 08:28:17 <jonasschnelli> -debug=mempool,net can be remove... its for debugging only
101 2016-03-09 08:28:26 <CryptoSiD> yeah i know, im not that noob:P
102 2016-03-09 08:28:29 <jonasschnelli> It will make your debug.log really big. So don't use it in production
103 2016-03-09 08:28:53 <CryptoSiD> now i see current number of tx and memory used tho, its not 0 anymore
104 2016-03-09 08:28:56 <jonasschnelli> dbcache =3000 is good... if you have enought memory
105 2016-03-09 08:29:36 <jonasschnelli> Now you should be able to receive transactions again.
106 2016-03-09 08:30:03 <CryptoSiD> well i still dont see the 0.015 after restarting without blocksonly=1
107 2016-03-09 08:30:55 <jonasschnelli> Is it confirmed, that transaction?
108 2016-03-09 08:31:27 <jonasschnelli> Maybe it takes a couple of seconds/minutes until you get this transaction from the peers (if its still unconfirmed)
109 2016-03-09 08:32:07 <CryptoSiD> yeah. will withdraw some more from an exchange to see
110 2016-03-09 08:34:29 <jonasschnelli> phantomcircuit have couple of minutes for me regarding: https://github.com/bitcoin/bitcoin/pull/5686#issuecomment-103354054?
111 2016-03-09 08:34:51 <phantomcircuit> jonasschnelli, sure
112 2016-03-09 08:35:07 <jonasschnelli> I'm implementing a save append only format in pure C.
113 2016-03-09 08:35:37 <jonasschnelli> What would be the benefit of a counter and a unique magic per frame record
114 2016-03-09 08:35:52 <jonasschnelli> To detect frame in case of a corruption?
115 2016-03-09 08:35:56 <jonasschnelli> frame*s*
116 2016-03-09 08:36:45 <phantomcircuit> jonasschnelli, the counter is to detect missing records
117 2016-03-09 08:37:13 <phantomcircuit> the unique magic is to make it possible to set the length to 0xffffffetc and then scan for the end of record
118 2016-03-09 08:37:19 <phantomcircuit> which makes streaming possible
119 2016-03-09 08:38:01 <jonasschnelli> Hmm... missing records should be detected by the continuous sha256 checksum ...
120 2016-03-09 08:39:00 <jonasschnelli> And I'm using key/value only records (bodys)... so it's always "varlen|key-body|varlen|value-body"... should work for streaming? Not?
121 2016-03-09 08:39:18 <phantomcircuit> jonasschnelli, the checksum is for the one record not a continuous checksum
122 2016-03-09 08:39:30 <phantomcircuit> which makes squashing the records into one really long journal easier
123 2016-03-09 08:39:42 <phantomcircuit> literally just cat * > huge_journal
124 2016-03-09 08:40:23 <jonasschnelli> hmm... sipa's approach was to use a continuous checksum,.. which makes sense IMO for a append only stogare...
125 2016-03-09 08:40:40 <jonasschnelli> A hash by frame should be not necessary?
126 2016-03-09 08:41:33 <jonasschnelli> phantomcircuit: If you want to reduce the filesize (remove overwritten records), someone could do a "compact" write,.. which would re-map the memory to disk by creating new checksums.
127 2016-03-09 08:41:54 <phantomcircuit> jonasschnelli, if you're doing a continuous checksum then the counter and per record checksum are un-necessary
128 2016-03-09 08:42:42 <jonasschnelli> phantomcircuit: okay. I see. Maybe a magic per record could still make sense to salvage records in case of a file corruption?
129 2016-03-09 08:42:57 <CryptoSiD> nope, still not seeing TX i receive, running with bitcoin-qt.exe -debug=mempool,net
130 2016-03-09 08:42:59 <CryptoSiD> is this fine?
131 2016-03-09 08:43:04 <CryptoSiD> im already running it with that
132 2016-03-09 08:43:17 <jonasschnelli> CryptoSiD: can you post the debug.log somewhere?
133 2016-03-09 08:43:24 <phantomcircuit> jonasschnelli, i was basically going for the most paranoid record framing possible there
134 2016-03-09 08:43:34 <jonasschnelli> CryptoSiD: Does the debug window lists the amount of transactions in the mempool?
135 2016-03-09 08:43:52 <jonasschnelli> phantomcircuit: Yes. I think this is a good idea for a wallet/key stogare
136 2016-03-09 08:44:02 <phantomcircuit> it's designed to detect basically every kind of corruption that can occur while *maybe* being able to recover something
137 2016-03-09 08:44:13 <CryptoSiD> wait, i cant find the tx from the exchange anywhere so
138 2016-03-09 08:44:17 <CryptoSiD> maybe i spoke too fast
139 2016-03-09 08:44:38 <phantomcircuit> CryptoSiD, iirc it's -debug=mempool -debug=net
140 2016-03-09 08:44:53 <phantomcircuit> i think -debug=mempool,net will filter on 'mempool,net' literally
141 2016-03-09 08:44:58 <CryptoSiD> ok i got it:)
142 2016-03-09 08:45:04 <CryptoSiD> removing blocksonly=1 worked
143 2016-03-09 08:45:04 <phantomcircuit> (note, i could be wrong but the thing i said 100% works)
144 2016-03-09 08:45:11 <phantomcircuit> ah
145 2016-03-09 08:45:13 <phantomcircuit> lol
146 2016-03-09 08:45:14 <phantomcircuit> yeah
147 2016-03-09 08:45:51 <jonasschnelli> phantomcircuit: thanks for the feedback!
148 2016-03-09 08:46:25 <CryptoSiD> i guess ill see the 0.015 once it have 1 confirm, cause i had blocksonly=1 when the TX happened its still not appearing in my transaction list
149 2016-03-09 08:46:30 <CryptoSiD> thanks jonasschnelli
150 2016-03-09 08:47:20 <moa> CryptoSiD: blocksonly=1 means your node will node receiev or send transactions, only blocks
151 2016-03-09 08:47:44 <CryptoSiD> kk, good to know, should have read about it before using this
152 2016-03-09 08:48:08 <jonasschnelli> CryptoSiD: happy it works now... :)
153 2016-03-09 08:55:06 <CryptoSiD> thanks for help, totaly me bad on that one
154 2016-03-09 08:56:23 <CryptoSiD> my*
155 2016-03-09 08:56:35 <jonasschnelli> np... happy it's not a bug in wallet&pruning
156 2016-03-09 13:11:21 <ali1234> the release notes for 0.12.0 say "#5288 4452205 Added -whiteconnections=<n> option (Josh Lehan)"
157 2016-03-09 13:11:32 <ali1234> this option was added, but it was later removed before release
158 2016-03-09 17:37:22 <Tasoshi> hi, is the bitcoin-dev mailing list meant to be cross-implementation?
159 2016-03-09 17:42:15 <Luke-Jr> Tasoshi: yes
160 2016-03-09 17:42:49 <Tasoshi> would it then be appropriate to have on the moderating list contributors from other implementations?
161 2016-03-09 17:43:01 <Tasoshi> or clients
162 2016-03-09 17:44:15 <Lauda> Anyone up for a question in regards to libsecp256k1 and the problem of validation time (at 2 MB block size limit)? I just can't remember the answer.
163 2016-03-09 17:44:36 <Lauda> Not sure whether this channel is the right one.
164 2016-03-09 17:45:22 <Luke-Jr> Tasoshi: probably. most of the moderators aren't Core devs FWIW
165 2016-03-09 17:45:37 <Luke-Jr> (in fact, I'm not sure if any are..)
166 2016-03-09 17:46:31 <Tasoshi> to avoid any potential bias in moderation however, would it not be more appropriate to have prominent contributors to other implementations on the mailing list, such as andrew stone for example or jonathan toomim if of course they up for it
167 2016-03-09 17:46:56 <Tasoshi> btw I am misusing implementation - I mean client or and implementation
168 2016-03-09 17:47:56 <Tasoshi> otherwise the bitcoin-dev mailing list may seem somewhat biased and a "bitcoin-core" list which may make cross-cooperation difficult
169 2016-03-09 17:52:29 <Luke-Jr> Tasoshi: Toomim certainly seems like not appropriate for being a moderator, but maybe Stone  (I don't know him well)
170 2016-03-09 17:52:50 <Luke-Jr> Tasoshi: the head mod is Jeff Garzik, who works on Classic
171 2016-03-09 17:53:18 <Tasoshi> he is extremely busy however. Andrew Stone is the lead dev of bitcoin unlimited
172 2016-03-09 17:53:31 <Tasoshi> why is Jonathan toomim not appropriate?
173 2016-03-09 17:55:08 <Luke-Jr> Tasoshi: he basically thinks he is superior to everyone else and that everyone must obey him, and he isn't even competent. major ego problems.
174 2016-03-09 17:55:25 <Tasoshi> that sounds highly opinionated
175 2016-03-09 17:55:42 <Tasoshi> and of course not your opinion or say
176 2016-03-09 17:56:06 <Tasoshi> the point is whether bitcoin-dev mailing list is cross-client and if so then the moderators should be from many clients
177 2016-03-09 17:57:54 <Luke-Jr> Tasoshi: or rather, what clients they contribute to is not a basis for discrimination
178 2016-03-09 17:58:20 <Tasoshi> it is, if one looks at if from a discrimination perspective
179 2016-03-09 17:58:43 <Luke-Jr> considering the lead mod is a Classic dev, and none of the mods are Core devs, despite Core being the only really significant implementation, I think there's a clear lack of bias in favour of Core
180 2016-03-09 17:58:46 <Tasoshi> if there is to be no bias, then contributors to other clients should have a moderating say
181 2016-03-09 17:59:26 <Tasoshi> I disagree, the mailing list, if not in actuality, is perceived to be highly biased
182 2016-03-09 17:59:36 <Luke-Jr> Tasoshi: such perception has no basis in reality
183 2016-03-09 17:59:40 <Luke-Jr> no basis at all
184 2016-03-09 17:59:50 <Tasoshi> plus, no one precludes a core dev being included in the moderation pannel
185 2016-03-09 18:00:00 <Tasoshi> that's your opinion :)
186 2016-03-09 18:00:23 <Luke-Jr> just because you don't like the facts doesn't mean they become opinions.
187 2016-03-09 18:00:37 <Tasoshi> what I am trying to establish is a working relationship based on perceived fairness if bitcoin-dev mailing list is to be truly cross client
188 2016-03-09 18:01:36 <Tasoshi> in any reasonable view, for the mailing list to be truly cross client, it needs to have on the moderating panel contributors to different clients, that means core, classic, unlimited and xt
189 2016-03-09 18:02:05 <Tasoshi> if not jonathan from classic, then tom hardin I think his name is, "tomz"
190 2016-03-09 18:03:04 <btcdrak> The bitcoin-dev mailing list is for Bitcoin protocol discussion.
191 2016-03-09 18:03:11 <Luke-Jr> Tasoshi: moderation isn't a competition
192 2016-03-09 18:03:16 <Tasoshi> doesn't really matter, as long as they're not extremely busy and practically unable to moderate
193 2016-03-09 18:03:19 <Tasoshi> I agree
194 2016-03-09 18:03:26 <Tasoshi> but moderation can be very biased
195 2016-03-09 18:03:35 <Luke-Jr> generally not
196 2016-03-09 18:03:42 <Tasoshi> that's your opinion
197 2016-03-09 18:03:48 <dgenr8> tomz is tom zander
198 2016-03-09 18:03:51 <Luke-Jr> frankly, if we ever got to the point where bias mattered, the moderators are going too far
199 2016-03-09 18:03:54 <Tasoshi> thank you
200 2016-03-09 18:04:04 <Tasoshi> some say they are Luke-jr
201 2016-03-09 18:04:14 <Tasoshi> now maybe they wrong, it doesn't really matter
202 2016-03-09 18:04:20 <Luke-Jr> it does matter
203 2016-03-09 18:04:25 <Tasoshi> as I said I am trying to establish a working relationship
204 2016-03-09 18:04:38 <Luke-Jr> people making up utter rubbish FUD should simply be ignored
205 2016-03-09 18:04:51 <Tasoshi> and by any reasonable analysis, if the mailing list is to be cross client, then it needs on the moderating list contributors from different clients
206 2016-03-09 18:04:58 <Luke-Jr> which it has
207 2016-03-09 18:05:11 <Tasoshi> it has no one from bitcoin unlimited
208 2016-03-09 18:05:13 <Tasoshi> or xt
209 2016-03-09 18:05:17 <Tasoshi> or btcd
210 2016-03-09 18:05:18 <Luke-Jr> so?
211 2016-03-09 18:05:22 <Luke-Jr> it has people from different clients
212 2016-03-09 18:05:39 <Tasoshi> Luke, I am not here to argue
213 2016-03-09 18:05:49 <Tasoshi> as I said, I am here to propose a working relationship
214 2016-03-09 18:06:00 <Tasoshi> if you do not with to be co-operative that is fine
215 2016-03-09 18:06:04 <Luke-Jr> …
216 2016-03-09 18:06:17 <Luke-Jr> the only ones not being co-operative, are the ones spreading FUD and/or not participating
217 2016-03-09 18:06:36 <Tasoshi> but, if the mailing list is to be cross client in any reasonable analysis it needs to have on the moderating list contributors to different clients so that the moderator's actions are not biased
218 2016-03-09 18:06:49 <Tasoshi> we need, in my view, to distill the political aspects from just code
219 2016-03-09 18:06:51 <Luke-Jr> Andrew Stone recently began to reach out, and I encouraged more cooperation.
220 2016-03-09 18:07:07 <Tasoshi> sure, on political aspects there is disagreement, but on many aspects we need to co-operate
221 2016-03-09 18:07:09 <Luke-Jr> Tasoshi: we already have that
222 2016-03-09 18:07:21 <Tasoshi> and we need to establish a basis on how that co-operation is to be carried out
223 2016-03-09 18:07:47 <Tasoshi> for any such co-operation there must be not only bias, but not even the possibility of bias, there must be checks and balances
224 2016-03-09 18:08:03 <Tasoshi> which is set by contributors to different clients being on the moderating pannel
225 2016-03-09 18:08:07 <Chris_Stewart_5> when verifying sigs for a p2sh/multisig input sigs are always assumed to be in order right?
226 2016-03-09 18:09:08 <Tasoshi> Luke-Jr, developers from other clients can not co-operate on a mailing list that may act as a podium
227 2016-03-09 18:09:19 <Tasoshi> if you wish to co-operate you have to set up checks and balances
228 2016-03-09 18:09:32 <Luke-Jr> Tasoshi: take your politics somewhere else. the ML is not where they belong.
229 2016-03-09 18:09:33 <Tasoshi> the ball is on you really
230 2016-03-09 18:09:39 <Tasoshi> but it is
231 2016-03-09 18:09:51 <Tasoshi> the moderators of the mailing list can be highly biased towards a client
232 2016-03-09 18:10:13 <Tasoshi> that is why you need moderators who are not super busy from different clients to balance any potential bias
233 2016-03-09 18:10:39 <Luke-Jr> everyone *is* super busy, which is why the majority of the moderators don't work on *any* client
234 2016-03-09 18:10:59 <Tasoshi> are you rejecting my proposal?
235 2016-03-09 18:11:34 <Tasoshi> not that you have any say of course, being just one guy
236 2016-03-09 18:11:44 <Luke-Jr> Tasoshi: I am rejecting your continued wasting of my time here. goodbye.
237 2016-03-09 18:12:06 <Tasoshi> then don't claim the mailing list is cross client
238 2016-03-09 18:12:20 <Luke-Jr> it is, so I will continue to claim so
239 2016-03-09 18:12:21 <Tasoshi> or that the bip process is cross client
240 2016-03-09 18:12:22 <moli> Tasoshi: go away
241 2016-03-09 18:12:26 <Luke-Jr> it also is
242 2016-03-09 18:12:34 <Tasoshi> that's your opinion
243 2016-03-09 18:12:40 <Luke-Jr> no, it is the fact
244 2016-03-09 18:12:47 <moli> Tasoshi: you've been wasting core devs' time too much, go away
245 2016-03-09 18:12:50 <Tasoshi> you have no monopoly on facts
246 2016-03-09 18:13:02 <Luke-Jr> I don't. You could have facts too if you didn't so vehemently reject them.
247 2016-03-09 18:13:15 <Tasoshi> unless you can give me some certain mathematical equation to prove it then it is simply your opinion
248 2016-03-09 18:13:35 <moli> as if you can understand maths?
249 2016-03-09 18:15:15 <Tasoshi> good to know bitcoin core devs have no desire whatever to co-operate however
250 2016-03-09 18:15:27 <Tasoshi> that was necessary information
251 2016-03-09 18:16:01 <Luke-Jr> Tasoshi: you reveal your utter dishonesty when you go forward spreading such absolute lies like that
252 2016-03-09 18:16:18 <jonasschnelli> guys,.. this type of conversation does not belong here. Its a tech/dev channel.
253 2016-03-09 18:16:29 <Tasoshi> so is the mailing list
254 2016-03-09 18:16:38 <Tasoshi> how cross clients co-operate is pretty tech
255 2016-03-09 18:16:53 <Tasoshi> but I'd be interested to hear other opinions than Luke's
256 2016-03-09 18:17:16 <jonasschnelli> Sure.. but show some "language" and "respect" guys.
257 2016-03-09 18:17:40 <Chris_Stewart_5> also does anyone have an example of a pay-to-pubkey output on testnet3?