1 2017-09-05 06:24:15 <waxwing> i think if anything this place is way underused; you can't ask general dev. or tech. questions in core-dev, and you can in #bitcoin, but that place is often a madhouse.
  2 2017-09-05 06:24:39 <waxwing> people do still ask things here, but not that much.
  3 2017-09-05 11:59:10 <cad> Does bitcoin miners check transaction's senders balance?
  4 2017-09-05 11:59:34 <cad> before accepting it and including it in a block
  5 2017-09-05 12:01:48 <acagman> mustafa
  6 2017-09-05 12:02:24 <cad> efendim ahmet abi
  7 2017-09-05 12:02:31 <acagman> nasilsin yahu ?
  8 2017-09-05 12:03:02 <ozlemT> selam
  9 2017-09-05 12:03:05 <acagman> oo ozlem hosgeldin ya
 10 2017-09-05 12:03:17 <ozlemT> hosbuldum ahmet abi
 11 2017-09-05 12:04:02 <acagman> ooo ilker sende gelmisin
 12 2017-09-05 12:04:22 <ilkmccr> acagman: saygilar abi
 13 2017-09-05 12:23:25 <Emcy> cad yes but not int he way you probably think
 14 2017-09-05 12:23:30 <Emcy> also there are no 'balances'
 15 2017-09-05 12:48:18 <cad> Emcy: I know that there are no 'balances'. What I meant was does the miner runs detailed checks on the transactions before including them in a block and if it didn't (e.g. an evil miner), will the network mitigate such case? If yes how?
 16 2017-09-05 13:24:06 <dviola> hi
 17 2017-09-05 13:24:11 <dviola> I just saw this in my debug.log, any ideas what it means? 2017-09-05 13:19:06 ProcessMessages(version, 113 bytes) FAILED peer=14
 18 2017-09-05 13:26:57 <dviola> is it something critical?
 19 2017-09-05 13:33:16 <dviola> it's syncing fine but I saw this in a few lines in the debug.log
 20 2017-09-05 13:34:28 <Emcy> just a duff peer
 21 2017-09-05 13:35:01 <Emcy> cad miners are incentivised to check what they include in a block is valid
 22 2017-09-05 13:35:42 <Emcy> if its not, the rest of the network will orphan the block when the miner releases it if it has an invalid tx and that will cost mr miner like 60,000usd
 23 2017-09-05 13:36:31 <dviola> I see, thanks
 24 2017-09-05 13:36:34 <Emcy> i think at one point some miners were doing validationless mining while trying to chose down the orphan rate, but thats not so common anymore
 25 2017-09-05 13:36:36 <dviola> is it safe to ignore?
 26 2017-09-05 13:37:44 <dviola> I guess it is
 27 2017-09-05 13:38:07 <cad> Emcy: thx
 28 2017-09-05 13:38:13 <acagman> saol gardas..
 29 2017-09-05 13:39:50 <Emcy> i think antpool accidentally made an invalid mis-ordered block one while totally not doing asicboost kek
 30 2017-09-05 13:41:42 <Emcy> dviola bitcoin will just ban peers that keep sending nonsense
 31 2017-09-05 13:42:13 <dviola> Emcy: good, so this was that basically?
 32 2017-09-05 13:43:02 <Emcy> look at the banscore
 33 2017-09-05 13:44:11 <ozlemT> #namecoin-dev
 34 2017-09-05 13:44:19 <dviola> Emcy: how?
 35 2017-09-05 13:44:47 <dviola> I'm using bitcoind
 36 2017-09-05 13:55:55 <dviola> oh, I see now
 37 2017-09-05 13:55:59 <dviola> just started qt
 38 2017-09-05 13:58:38 <molz> dviola, "bitcoin-cli listbanned"
 39 2017-09-05 13:59:08 <dviola> oh, thanks
 40 2017-09-05 14:02:07 <dviola> I get an empty []
 41 2017-09-05 14:02:16 <dviola> maybe because I restarted bitcoind?
 42 2017-09-05 14:03:16 <molz> does your log say your node banned some IP?
 43 2017-09-05 14:05:29 <dviola> no
 44 2017-09-05 14:09:05 <dviola> I see 'FAILED' as in: 2017-09-05 13:19:06 ProcessMessages(version, 113 bytes) FAILED peer=14 with a few peers
 45 2017-09-05 14:09:09 <dviola> but no bans
 46 2017-09-05 15:21:59 <dviola> so if this peer is sending me crap and I see a FAILED, why I don't see it as banned?
 47 2017-09-05 15:26:54 <dviola> or are there some cases where core will not ban them?
 48 2017-09-05 15:33:23 <molz> dviola, do you see anything that says "ERRORS" after that line?
 49 2017-09-05 15:33:48 <dviola> molz: no
 50 2017-09-05 15:35:37 <molz> dviola, and your node is not stuck? it's still downloading blocks, correct?
 51 2017-09-05 15:35:44 <dviola> correct
 52 2017-09-05 15:35:47 <dviola> it's not stuck
 53 2017-09-05 15:36:07 <dviola> I think it will finish syncing tomorrow
 54 2017-09-05 15:36:43 <molz> ok, i wouldn't worry about it, probably something not important
 55 2017-09-05 15:37:18 <dviola> ok, thanks
 56 2017-09-05 16:48:30 <boltzar> I am using bitcoind json rpc api to send bitcoin to multiple bitcoin addresses. I am using sendrawtransaction. When i have 24 unconfirmed payments sent from my account, i can't send anymore because i get this error : 64: too-long-mempool-chain . I have increased the maxmempool to 1500 but it still doesn't fix it.	Any ideas on how to fix it ? I want to be able to create for example 300
 57 2017-09-05 16:48:30 <boltzar> unconfirmed transactions and not to receive that error.
 58 2017-09-05 16:48:37 <boltzar> Hey!
 59 2017-09-05 16:50:23 <ossifrage> boltzar, are all your transactions from the same address?
 60 2017-09-05 16:50:43 <boltzar> yes.
 61 2017-09-05 16:51:31 <ossifrage> So they are a single chain of unconfirmed transactions? Having a limit for that sounds like a sane thing to do
 62 2017-09-05 16:53:39 <ossifrage> You would be much better off having multiple outputs in fewer transactions then a long chain like that
 63 2017-09-05 16:54:17 <boltzar> ossifrage i can't have multiple outputs because my business is not like that...
 64 2017-09-05 16:54:31 <boltzar> orders come for example at 1-2-5-10 minutes apart from each other
 65 2017-09-05 16:55:39 <ossifrage> Well, you can either pay larger fees, or you can check if the transactions are getting backed up and do a CPFP transaction
 66 2017-09-05 16:56:19 <boltzar> CPFP ? sorry, i don't know what that is...
 67 2017-09-05 16:57:39 <ossifrage> child pays for parent... at the end of your chain of transactions, before you hit the bitcoind limit, just do a transaction with a larger fee to cover whatever part of the chain hasn't made it into a block
 68 2017-09-05 16:58:14 <ossifrage> Or you could just recompile bitcoind with a larger chain transaction limit, but you will have to find someone else to tell you if that is a really bad idea
 69 2017-09-05 17:00:30 <boltzar> i have tried now something. after i got "64: too-long-mempool-chain" i made a transaction with a higher fee, and i still couldn't make the payment
 70 2017-09-05 17:01:01 <ossifrage> boltzar, you would have to do that before the limit kicks in
 71 2017-09-05 17:01:42 <boltzar> if i do that before the limit kicks it, do i need to wait for that transaction to get confirmed also ?
 72 2017-09-05 17:01:48 <boltzar> because i can't wait.
 73 2017-09-05 17:02:12 <ossifrage> That long chain of (I'd assume low fee) transactions isn't overly appealing to the miners, they are much more likely to pick other smaller transactions then your long chain
 74 2017-09-05 17:02:40 <boltzar> when somebody pays me, my api has to send instant the bitcoin and as we know there are some days when you can wait for hours to get confirmations
 75 2017-09-05 17:02:50 <boltzar> well i use segwit at the moment
 76 2017-09-05 17:03:54 <ossifrage> First thing you can do is split your coins over multiple addresses, that will help this specific problem, I'm not sure it is wise to bump the long chain limit
 77 2017-09-05 17:04:22 <boltzar> can you tell me the reason for this ? why it's not wise ?
 78 2017-09-05 17:05:25 <ossifrage> Because you are decreasing your chances of getting in a block. All those transactions have to go into blocks in the right order because they are a dependency chain
 79 2017-09-05 17:07:04 <boltzar> before i made my own json api i used the one from block.io . I had times when i had 200 unconfirmed transactions . They eventually all got confirmed, a bit late, but they got confirmed. I want to make like that...It's not a problem if they get confirmed a bit late...
 80 2017-09-05 17:07:56 <ossifrage> Are you sure they all came from the same address chain?
 81 2017-09-05 17:08:10 <boltzar> Yes.
 82 2017-09-05 17:08:24 <ossifrage> It looks like there are command line options to control this for bitcoind
 83 2017-09-05 17:09:05 <boltzar> that's what i'm trying to find out..
 84 2017-09-05 17:09:07 <ossifrage> I think the thing you want to change is "-limitancestorcount", the default is 25
 85 2017-09-05 17:09:39 <arubi> that's only local policy.  changing that won't make other nodes relay that long chain
 86 2017-09-05 17:10:51 <boltzar> i think this also ?
 87 2017-09-05 17:10:52 <boltzar> walletrejectlongchains
 88 2017-09-05 17:11:55 <ossifrage> arubi has a good point, you might be shooting yourself in the foot making that change (I'm assuming it is some sort of anti-spam protection)
 89 2017-09-05 17:13:05 <boltzar> what do you mean by this ?
 90 2017-09-05 17:13:18 <arubi> that and if you get to a point in time where you have a long chain which isn't confirmed, you're better off just putting all those outputs in a single transaction..
 91 2017-09-05 17:14:02 <boltzar> It happens very rare to have 200 unconfirmed transactions
 92 2017-09-05 17:14:06 <ossifrage> arubi, his point is that the transactions are happening over time, not batched
 93 2017-09-05 17:14:34 <boltzar> yes, exactly
 94 2017-09-05 17:15:00 <boltzar> and i have to instantly send the bitcoins to the clients
 95 2017-09-05 17:15:01 <arubi> yea I understand, bitcoin isn't very good for long chains of transactions, plus it takes about 10 minutes between blocks
 96 2017-09-05 17:15:11 <ossifrage> boltzar, the first thing to do is to slowly bump your fee as the unconfirmed chain gets larger and potentially use multiple addresses
 97 2017-09-05 17:15:32 <arubi> yep, just prepare many outputs that you can use
 98 2017-09-05 17:15:46 <arubi> take one big input, send it to 1000 addresses of yours
 99 2017-09-05 17:16:15 <boltzar> do you guys have any tip for me how to calculate the fee ?
100 2017-09-05 17:16:16 <arubi> every time you need to pay, grab one of the 1000 that are already confirmed.  eventually you can just consolidate small outputs at the lowest level
101 2017-09-05 17:16:31 <ossifrage> But if they other nodes aren't going to forward long chains of unconfirmed transactions, then it doesn't help you to make the transaction right away if your customers aren't going to see it
102 2017-09-05 17:16:36 <boltzar> i have searched everywhere but to be honest didn't find anything i can use
103 2017-09-05 17:16:49 <boltzar> they all give me very big fees.
104 2017-09-05 17:17:07 <arubi> you can just wait for v0.15.0 . it'll have proper fee estimator
105 2017-09-05 17:17:29 <arubi> or use rc3 which is out now.  I've been running rc1 for a while and it worked well.  updating to rc3 now
106 2017-09-05 17:17:37 <ossifrage> no need to wait... the 0.15.0 fee estimator is better, but it still overpays fee wise
107 2017-09-05 17:17:56 <boltzar> for example i use segwit now and my fees are 0.3 $
108 2017-09-05 17:18:35 <arubi> not sure what the fees are now.  I just always underpay and wait :)
109 2017-09-05 17:18:49 <arubi> got a 1 satoshi/byte tx confirmed over the weekend.  all is fine
110 2017-09-05 17:18:54 <boltzar> sorry for asking arubi, i'm not a pro at this ... what is rc3 ?
111 2017-09-05 17:19:03 <arubi> release candidate 3
112 2017-09-05 17:19:08 <boltzar> Fee per byte	27.903 sat/B
113 2017-09-05 17:19:15 <boltzar> this is what i have now
114 2017-09-05 17:19:18 <arubi> doesn't sound so bad
115 2017-09-05 17:19:24 <ossifrage> My last 1 sat/byte transaction took over 20 days to confirm due to the recent mempool constipation
116 2017-09-05 17:19:37 <boltzar> :))
117 2017-09-05 17:19:51 <boltzar> one more questions if you can figure it out
118 2017-09-05 17:19:56 <boltzar> i never understood this
119 2017-09-05 17:19:59 <arubi> yea 1/b is pretty extreme, but fun to do once in a while if you're sending to yourself anyway hehe
120 2017-09-05 17:20:01 <boltzar> check this tx out : 6938726463d5a3ab25de805538ad591043258d814544317512cfe0046a6c33c7
121 2017-09-05 17:20:12 <boltzar> on blockchain.info it doesn't show
122 2017-09-05 17:20:16 <boltzar> on chain.so it appears
123 2017-09-05 17:20:33 <boltzar> on blockr.io it doesn't appear
124 2017-09-05 17:20:52 <ossifrage> boltzar, that is fee is pretty high, should be able to go much lower only have to wait a few blocks (right now) https://jochen-hoenicke.de/queue/#2h
125 2017-09-05 17:20:56 <boltzar> i had this issue for a long long time with some of my transactions. what's the problem ?
126 2017-09-05 17:21:13 <arubi> probably because they're one of the very long chain..?
127 2017-09-05 17:21:31 <boltzar> i understand. so that's the issue.
128 2017-09-05 17:21:56 <arubi> right, block explorers might be running with the same default rules at 25 max
129 2017-09-05 17:22:12 <boltzar> for example if i have 5 segwit addresses in my wallet
130 2017-09-05 17:22:36 <boltzar> when i use createraw..sign...send... does it take randomly from one of those addreses ?
131 2017-09-05 17:22:56 <arubi> no, it uses the one from the input
132 2017-09-05 17:22:59 <boltzar> blockchain.info i know for sure it has 25 max. :) i used the api from them and the same issue i had with their api also
133 2017-09-05 17:23:02 <ossifrage> That looks like ~23 unconfirmed transactions on that address, right at the 25 txn limit
134 2017-09-05 17:23:28 <boltzar> ossifrage i had 25 unconfirmed, 2 got confirmed.
135 2017-09-05 17:23:33 <boltzar> i was just making tests
136 2017-09-05 17:23:37 <boltzar> to figure this out
137 2017-09-05 17:24:22 <ossifrage> boltzar, FYI, if I was writing a spam detector those transactions would be labeled as spam
138 2017-09-05 17:25:09 <ossifrage> same input, same outputs, many transactions all created at the same time == spam
139 2017-09-05 17:25:21 <boltzar> to be honest i'm kind of crazy ... i use the same address just to keep track of my balance easy.. i have my bitcoin address on watch on the blockchain api on my phone
140 2017-09-05 17:25:55 <arubi> that's not very good for your customers
141 2017-09-05 17:26:05 <boltzar> yes, but that was just for test.
142 2017-09-05 17:26:38 <ossifrage> Once those clear out, try your test again with more realistic timing and output addresses
143 2017-09-05 17:26:40 <arubi> but if one customer gets a transaction from you, they can then track your address too and learn about your business
144 2017-09-05 17:27:51 <boltzar> i understand that risk. another issue was segwit...to move my change to different segwit wallets...it's kind of difficult for me
145 2017-09-05 17:28:07 <boltzar> sendtoaddress moves the funds around, but not to segwit addreses
146 2017-09-05 17:28:43 <arubi> sendtoaddress can send to p2sh addresses
147 2017-09-05 17:29:20 <arubi> and that's most of what people use now as segwit addresses, so really not sure why it couldn't send for you
148 2017-09-05 17:29:24 <boltzar> i mean for example i have 1 bitcoin. 0.5 goes to the customer + fee and 0.5 has to return to me. that return address is not segwit
149 2017-09-05 17:29:34 <arubi> ohh
150 2017-09-05 17:29:37 <arubi> yea, that's right.
151 2017-09-05 17:29:43 <boltzar> and next time i send...i send from non-segwit
152 2017-09-05 17:29:59 <arubi> why aren't you using fundrawtransaction?
153 2017-09-05 17:30:02 <boltzar> so to move funds around with createraw...difficult for my brain.
154 2017-09-05 17:30:05 <arubi> or are you?
155 2017-09-05 17:30:16 <boltzar> no. create, sign, send
156 2017-09-05 17:30:31 <arubi> alright, so if you place fundraw between send and sign, you can set a change address
157 2017-09-05 17:30:35 <boltzar> don't know what's the difference. to be honest i have 1 week since i'm playing with bitcoind
158 2017-09-05 17:30:58 <arubi> you place the output from createraw into fundraw, then the output from fundraw into signraw
159 2017-09-05 17:31:03 <boltzar> you can set a change address on sendraw also
160 2017-09-05 17:31:14 <arubi> sendraw? no
161 2017-09-05 17:31:25 <arubi> sendraw just sends signed and complete transactions
162 2017-09-05 17:31:41 <boltzar> on createraw i have to put the change address
163 2017-09-05 17:31:46 <arubi> better not
164 2017-09-05 17:31:53 <boltzar> then sign and send
165 2017-09-05 17:32:06 <arubi> better let fundraw deal with it.  it will also select an input, then you put that into signraw, then sendraw
166 2017-09-05 17:32:29 <boltzar> fundraw selects it's own change address ?
167 2017-09-05 17:32:32 <boltzar> i don't have to define it ?
168 2017-09-05 17:32:36 <arubi> yes
169 2017-09-05 17:32:47 <boltzar> but it won't select a segwit address :)
170 2017-09-05 17:32:57 <boltzar> same thing like on sendtoaddress
171 2017-09-05 17:33:14 <arubi> it won't but you can set one
172 2017-09-05 17:33:30 <arubi> if you set one in createraw, your signraw won't know that it's a change address and just add a new one
173 2017-09-05 17:33:41 <arubi> so the only way to specify one yourself right now, is using fundraw
174 2017-09-05 17:34:40 <boltzar> i have to try this
175 2017-09-05 17:34:56 <boltzar> it sounds good. if it would add a new segwit address, it would be perfect
176 2017-09-05 17:35:38 <arubi> sure.  just one thing, the wallet can't restore these addresses in case you need to restore from backup.  you need to add them all back manually yourself, so not sure if you should use it with lots of money right now
177 2017-09-05 17:36:17 <arubi> I mean, it's not that these are completely lost in case the wallet is lost.  they can always be restored, but it's a manual process now
178 2017-09-05 17:36:17 <boltzar> will make some tests with 10-20 $ on it :)
179 2017-09-05 17:36:22 <arubi> nice :)
180 2017-09-05 17:36:37 <arubi> (you can also use testnet)
181 2017-09-05 17:37:16 <boltzar> you're awesome dude. i've been with my head into this api for a week. it's just awesome, but difficult.
182 2017-09-05 17:37:46 <arubi> cheers man, it's great knowing people are having fun with bitcoin stuff
183 2017-09-05 17:37:49 <boltzar> so , related to the fee. how much do you recommend for me to use ? like i said, i use 0.3 $ = 0.0000692
184 2017-09-05 17:38:01 <boltzar> what's your suggestion ?
185 2017-09-05 17:38:23 <arubi> you can use https://jochen-hoenicke.de/queue/#2h for looking at what other people are paying
186 2017-09-05 17:38:37 <ossifrage> boltzar, the right fee always depends on the current state of the network, using a fixed value is just wasting money
187 2017-09-05 17:38:47 <arubi> so just set to whatever lowest color is getting cleared :)
188 2017-09-05 17:41:02 <boltzar> i'm dumb as f*ck
189 2017-09-05 17:41:10 <boltzar> don't know how to read this graph
190 2017-09-05 17:41:38 <arubi> it's got the legend on the left, bars are at 1mb intervals
191 2017-09-05 17:42:09 <arubi> at each block, a bunch of transactions get into a block, you can see the graph drop when that happens
192 2017-09-05 17:42:41 <arubi> usually higher paying txs get into a block first, then as more clears over time, lower fees do
193 2017-09-05 17:43:12 <arubi> but right now you can see that two or even one block will clear the current peak, so a smart miner will just include all transactions in that peak
194 2017-09-05 17:43:42 <arubi> which means a high fee paying one has the same chance to get into the next block as a low fee paying one
195 2017-09-05 17:44:17 <arubi> er, the website is https://core.jochen-hoenicke.de/queue/#24h
196 2017-09-05 17:44:32 <arubi> (change the view to 2 hours, not 24 hours)
197 2017-09-05 17:45:31 <boltzar> at the pending transactions for example there is 600+ : 0.024 btc
198 2017-09-05 17:45:36 <boltzar> 0.024 / 600 ?
199 2017-09-05 17:45:48 <arubi> 600 is what?
200 2017-09-05 17:45:59 <boltzar> sat/b
201 2017-09-05 17:47:16 <arubi> wait, you paid 0.024 btc for a 600 byte transaction?
202 2017-09-05 17:47:41 <boltzar> no no. i was reading the graph
203 2017-09-05 17:48:14 <arubi> ohh, yea, someone is paying very expensive fees and losing a ton of money
204 2017-09-05 17:49:07 <arubi> it means they're paying 4000 satoshi / byte
205 2017-09-05 17:49:39 <boltzar> to understand better, for a 248 (bytes) what's a good transaction fee ?
206 2017-09-05 17:50:04 <boltzar> 5 satoshi / byte ?
207 2017-09-05 17:50:09 <arubi> right now it is
208 2017-09-05 17:50:14 <boltzar> 10 ?
209 2017-09-05 17:50:15 <arubi> it doesn't matter how big the tx is
210 2017-09-05 17:50:21 <arubi> you're paying by the byte
211 2017-09-05 17:50:53 <arubi> boltzar, how much does it cost to ship 1 2x2x2 box?
212 2017-09-05 17:51:20 <arubi> you pay per weight, the size nearly doesn't matter
213 2017-09-05 17:51:37 <boltzar> Weight	662
214 2017-09-05 17:53:28 <arubi> so the setting in core is "pay this much BTC per kilobyte" right
215 2017-09-05 17:53:44 <boltzar> yes
216 2017-09-05 17:53:48 <arubi> 1 bitcoin is 100,000,000 satoshis.  it's asking you how many satoshis per 1000 kilobytes
217 2017-09-05 17:54:11 <arubi> so basically the setting is (5 * 1000 / 100000000)
218 2017-09-05 17:54:17 <arubi> ;;calc 5 * 1000 / 100000000
219 2017-09-05 17:54:18 <gribble> 5e-05
220 2017-09-05 17:55:20 <boltzar> 0.005 / kb right ?
221 2017-09-05 17:55:36 <arubi> 0.00005000
222 2017-09-05 17:55:38 <boltzar> sorry
223 2017-09-05 17:55:39 <boltzar> yeah
224 2017-09-05 17:56:37 <boltzar> 0.00003 aprox for that 662 bytes transaction
225 2017-09-05 17:56:50 <boltzar> ?
226 2017-09-05 17:57:15 <arubi> yea, just over that
227 2017-09-05 17:57:46 <arubi> 0.00003310 specifically.  fundrawt has a 'feeRate' field you can set at funding time if the preferred fee changes
228 2017-09-05 17:58:04 <boltzar> yeah, unfortunetly i have to calculate that in php
229 2017-09-05 17:58:20 <boltzar> i have to make it auto
230 2017-09-05 17:58:22 <arubi> well no, because you put 0.00005000 in there, not the end result :)
231 2017-09-05 17:58:35 <arubi> it'll include 0.00003310 when you send a 662 byte tx
232 2017-09-05 17:58:41 <arubi> and whatever else if it's a different size
233 2017-09-05 17:59:10 <boltzar> i mean for each transaction, i have to calculate it in php. because when i create the raw transaction, i put the amount to send the fee and the return amount.
234 2017-09-05 17:59:30 <arubi> but you don't if you use fundraw, that the point
235 2017-09-05 17:59:31 <boltzar> if i put that fee, it will work only on sendtoaddress ...
236 2017-09-05 17:59:33 <arubi> you don't have to*
237 2017-09-05 17:59:39 <arubi> bitcoind will take care of that for you
238 2017-09-05 17:59:47 <boltzar> i see
239 2017-09-05 17:59:55 <boltzar> interesting
240 2017-09-05 18:00:09 <boltzar> i have to lookup this function asap
241 2017-09-05 18:00:42 <arubi> takes a simple json with whatever you want to set.  probably changeAddress and feeRate
242 2017-09-05 18:00:57 <arubi> (and the hex from createraw)
243 2017-09-05 18:01:17 <arubi> the hex from createraw should not contain an input of yours already, or a change address.  just the output to the customer
244 2017-09-05 18:01:42 <arubi> fundraw will choose inputs to cover the output, set the fee and the change, and then you get a complete unsigned transaction that you can pass to signraw
245 2017-09-05 18:02:25 <boltzar> very nice. i will empty the wallet and try this function
246 2017-09-05 18:02:36 <arubi> cheers.  I'm off for a while.  good luck
247 2017-09-05 18:02:38 <boltzar> limitancestorcount i have to put into bitcoin.conf ?
248 2017-09-05 18:02:47 <arubi> nah, don't set it at all
249 2017-09-05 18:02:58 <arubi> other nodes don't have it set, so it's not like it's going to help you
250 2017-09-05 18:03:01 <boltzar> i want to set it , because i will have problems with my orders...
251 2017-09-05 18:03:11 <arubi> you'll still have the same problems
252 2017-09-05 18:03:24 <arubi> setting it won't change the end result of long chains not being relayed
253 2017-09-05 18:03:36 <boltzar> how come when i used block.io i sent 200-300 payments
254 2017-09-05 18:03:42 <boltzar> all unconfirmed ?
255 2017-09-05 18:03:54 <arubi> that's because they can't relay these to a miner for you
256 2017-09-05 18:04:00 <arubi> the network largely ignores them
257 2017-09-05 18:04:05 <arubi> because of that same policy
258 2017-09-05 18:04:16 <boltzar> the payment went thru...
259 2017-09-05 18:04:31 <arubi> when it's a 23 long chain, sure
260 2017-09-05 18:05:06 <boltzar> really, it's not BS.
261 2017-09-05 18:05:12 <boltzar> i've used them 1 year
262 2017-09-05 18:05:24 <arubi> anyway, gotta go.  you can set that in your bitcoin.conf no problem.  but it might just cause your software to pay and pay without end
263 2017-09-05 18:06:07 <ossifrage> It is possible that the end of the chain does not show up in other nodes until the head of the chain ends up in blocks (so it will work eventually)
264 2017-09-05 18:06:35 <boltzar> arubi, thanks a lot !
265 2017-09-05 18:06:58 <boltzar> ossifrage yes you are right. not all the transactions showed up on the blockchain, untill they got confirmed
266 2017-09-05 18:07:12 <boltzar> they showed up only on chain.so , but just there
267 2017-09-05 18:07:36 <ossifrage> So block.io might just crank up those limits and let the network sort it out...
268 2017-09-05 18:08:09 <ossifrage> But it won't give your users the feedback they expect if the transactions are getting filtered by nodes
269 2017-09-05 18:09:10 <boltzar> i know, it was frustrating, but i just want to find out what's the solution. last week i didn't even know that the output of bitcoin has a return address for the rest of the funds :))
270 2017-09-05 18:09:24 <boltzar> i'm new at this subject
271 2017-09-05 18:10:09 <boltzar> untill now i've used bitcoin api's build by other websites and i'm tired of those issues and i want to create my own. that's why i want to know what's the best solution.
272 2017-09-05 18:11:08 <boltzar> i will try with fundraw to see if it still uses segwit on the return address and if yes, i will fund 20-30 addresses so i won't have problems with the long chain
273 2017-09-05 18:18:14 <boltzar> anyway. thanks a lot ossifrage and arubi. you guys are awesome
274 2017-09-05 18:18:33 <arubi> o/
275 2017-09-05 19:57:37 <JackH> Can we get an RPC to see data usage in Bitcoin? Would it make sense?
276 2017-09-05 19:59:31 <arubi> might be that one of the debug options tracks it?
277 2017-09-05 19:59:59 <arubi> I'm not sure, I never checked.
278 2017-09-05 20:00:51 <JackH> I checked the RPC calls, nothing for tracking data usage
279 2017-09-05 20:02:03 <JackH> I think it can become useful for certain nodes to keep track of data usage. I just did 91GB in 3 days
280 2017-09-05 20:02:49 <arubi> so -debug=<category> doesn't show it for category 'net' ?
281 2017-09-05 20:03:52 <JackH> huh?
282 2017-09-05 20:04:14 <arubi> bitcoind's debug flag, might track network usage
283 2017-09-05 20:04:24 <arubi> I mean, I'm asking if you tried it, because I didn't
284 2017-09-05 20:05:01 <arubi> output should appear in debug.log
285 2017-09-05 20:05:11 <JackH> I never tried this to be honest
286 2017-09-05 20:05:30 <arubi> I'm gonna try
287 2017-09-05 20:06:17 <arubi> well it does tell me whatever the bytes for each message sent \ received
288 2017-09-05 20:06:22 <arubi> so I guess it does just that ;)
289 2017-09-05 20:06:39 <JackH> wait so how does it store this?
290 2017-09-05 20:06:43 <JackH> whats the output?
291 2017-09-05 20:06:47 <arubi> in debug.log
292 2017-09-05 20:06:54 <arubi> 2017-09-05 20:06:16 initial getheaders (483711) to peer=6 (startheight:483712)
293 2017-09-05 20:06:55 <arubi> 2017-09-05 20:06:16 sending getheaders (997 bytes) peer=6
294 2017-09-05 20:07:03 <arubi> pretty sweet
295 2017-09-05 20:07:50 <JackH> but the output of 10GB will be impossible to keep track of like this
296 2017-09-05 20:08:04 <arubi> max message is that many right
297 2017-09-05 20:08:15 <arubi> and really there aren't messages bigger than one block
298 2017-09-05 20:08:22 <arubi> so, 4mb max
299 2017-09-05 20:08:51 <arubi> you can't keep track of gigabytes without tracking bytes
300 2017-09-05 20:08:57 <arubi> you just accumulate :)
301 2017-09-05 20:09:38 <JackH> there must be something in the GUI then that counts all the bytes and draws the graph and also keeps track of the data per session
302 2017-09-05 20:10:59 <arubi> sounds pretty useful really.  I made some output for myself of connected peers and the amount of data sent \ received from me to them
303 2017-09-05 20:11:41 <JackH> do you read from the debug then?
304 2017-09-05 20:11:50 <JackH> or how do you grab the data?
305 2017-09-05 20:12:04 <arubi> no, just rpc calls and prettyprinting in bash
306 2017-09-05 20:12:33 <JackH> ahh
307 2017-09-05 20:12:43 <arubi> https://gist.github.com/fivepiece/07fdaa7bce38ffa0c77bdb5c40a69a25
308 2017-09-05 20:13:02 <arubi> I run that with `watch -d -n15 ./peerinf.sh`
309 2017-09-05 20:13:22 <arubi> it's somewhat buggy when nodes have spaces in their useragent :\
310 2017-09-05 20:13:48 <JackH> ah well that can be cut out
311 2017-09-05 20:13:57 <JackH> doesnt matter (for me) who downloads what
312 2017-09-05 20:14:05 <JackH> as long as I have overview of total consumption
313 2017-09-05 20:14:25 <arubi> getpeerinfo has all the details, but data disappears when a peer disconnects
314 2017-09-05 20:14:37 <arubi> it's just for real time stats
315 2017-09-05 20:15:40 <arubi> /dinner
316 2017-09-05 20:21:38 <tloriato_> Hello. I was wondering about HD wallets creation. I would like to generate deterministics public addresses linked to a specific BIP39 24 word list, but without having to expose the words. I came across a specific implementation that can use BIP39 to generate BIP32 addresses (bitcoinjs lib) and it does that using the BIP39 seed and not the words. Is the seed a "disposable" information?
317 2017-09-05 20:22:04 <tloriato_> Disposable in the sense that if a hacker manages to grab that information it would not be harmful in any way?
318 2017-09-05 20:22:23 <tloriato_> (monetarily speaking)
319 2017-09-05 20:39:24 <tloriato_> Ok... I that it's actually quite important, in the sense that I was able to derivate the BIP32 Root Key from the BIP39 Seed and then get the private keys became trivial. Does anyone knows how I could achive what I'm aiming?
320 2017-09-05 20:51:24 <arubi> tloriato_, it sounds like you didn't read bip32 or bip39 at all?  there's info in bip32 specifically about public derivation paths
321 2017-09-05 20:53:36 <tloriato_> arubi , I read it but I was looking for an implementation of the described process in the "Public parent key → public child key"
322 2017-09-05 20:54:08 <tloriato_> I believe that would cover my use? Being able to generate new deterministics public address on a server without having to keep any sensible data on it?
323 2017-09-05 21:01:24 <arubi> yea but, the process is right there in bip32, and there are links to implementations at the bottom
324 2017-09-05 21:12:40 <tloriato_> yes, you are right. i'm currently looking into the JS implementation to see if I can pinpoint where he implemented the desired Public parent key → public child key process
325 2017-09-05 21:12:52 <tloriato_> but have been unlucky
326 2017-09-05 21:14:35 <arubi> look for parts where it does hmac-sha512
327 2017-09-05 21:15:05 <arubi> one of them will be public child key derivation
328 2017-09-05 21:17:31 <tloriato_> thank you arubi
329 2017-09-05 21:17:36 <tloriato_> i think that i found it https://github.com/sarchar/brainwallet.github.com/blob/bip32/js/bip32.js#L229
330 2017-09-05 21:18:17 <arubi> yea that's it
331 2017-09-05 21:18:22 <tloriato_> so it's possible to do what i'm looking for, right? generate a public address from another "master" pub address (linked to a bip39 passphrare)?
332 2017-09-05 21:18:29 <tloriato_> just to be clear, sorry
333 2017-09-05 21:19:00 <arubi> it is, but you have to remember to never export a private key from that path
334 2017-09-05 21:19:07 <tloriato_> (without knowing sensible information, so i can keep them off computers)
335 2017-09-05 21:19:14 <tloriato_> uhm...
336 2017-09-05 21:19:30 <arubi> you can give someone a master public key, and they can generate addresses from it
337 2017-09-05 21:19:48 <arubi> but if you also give them one single private key from one of these addresses, then they can get all other keys
338 2017-09-05 21:20:00 <tloriato_> oh, i see!
339 2017-09-05 21:20:10 <tloriato_> that's incredible and exactly what i've been looking for
340 2017-09-05 21:20:36 <tloriato_> i'll see if i can find it in the bitcoinjs lib to use easily, otherwise i'll implement it there
341 2017-09-05 21:20:38 <tloriato_> thank you!
342 2017-09-05 21:20:45 <arubi> yw
343 2017-09-05 21:53:41 <jimpo> Is it known or is there a leading theory why Satoshi used double SHA256?
344 2017-09-05 23:03:32 <Emcy> in case of a marginal sha256 break maybe?
345 2017-09-05 23:03:40 <Emcy> like what happened with sha1
346 2017-09-05 23:04:09 <Emcy> you know like how DES got weakened significantly and everyone said screw it DES but 3 times
347 2017-09-05 23:57:21 <esotericnonsense> double sha protects against length extension
348 2017-09-05 23:57:52 <esotericnonsense> i'm not aware of anything in bitcoin that needs that particular property though