1 2017-12-07 02:44:17 <ponzibanker> Anyone here familiar with when a validating node updates the mempool?
  2 2017-12-07 03:18:57 <phantomcircuit> ponzibanker, define updates
  3 2017-12-07 03:20:34 <ponzibanker> phantomcircuit: I think I’m clear that the mempool is updated by a full node when it receives a block and validates it, the transactions within that block or removed from the mempool…if that is correct, my issue is what happens when there’s a fork in the chain.
  4 2017-12-07 03:23:09 <ponzibanker> phantomcircuit: So if the full node receives A-B-C with C being a valid block and removes the transactions from the mempool, what happens if the next block is A-B-D? That is, when does the full node validate the D block and then if it’s valid hang on to it until the blocks are reconciled? And if so, does the node try to remove the tx in D from the mempool as well?
  5 2017-12-07 04:23:13 <BGL> this is so frustrating, all i want to do is not have to re-download the entire blockchain again, i've moved the blockchain data off to a diff drive (imagine that) created a hard symbolic link for/to the blocks folder which seems to be working fine, but when i launch bitcoin-qt it's saying error initializing block database and if i want to rebuild, is this at all related to the chainstate folder? i really don't want to have t
  6 2017-12-07 04:25:30 <cncr04s> windows?
  7 2017-12-07 04:25:34 <cncr04s> that won't work
  8 2017-12-07 04:25:44 <cncr04s> linux, sure
  9 2017-12-07 04:26:05 <BGL> i just had a site in front of me saying it does
 10 2017-12-07 04:26:12 <BGL> have you tried it on windows?
 11 2017-12-07 04:26:16 <cncr04s> i have
 12 2017-12-07 04:26:21 <cncr04s> its been a while though
 13 2017-12-07 04:26:36 <cncr04s> I just got a 2tb ssd
 14 2017-12-07 04:26:45 <cncr04s> dont gotta worry
 15 2017-12-07 04:48:33 <BGL> i don't have $600 to spend on a 2tb SSD so i can store a blockchain on it, simply because i'd like to store my wallet on the ssd (which i have) and the blockchain elsewhere
 16 2017-12-07 04:53:03 <cncr04s> well
 17 2017-12-07 04:53:10 <cncr04s> try creating a partition for the blocks
 18 2017-12-07 04:53:17 <cncr04s> and mount it in the blocks folder
 19 2017-12-07 04:53:25 <cncr04s> instread of giving it a drive
 20 2017-12-07 04:53:28 <cncr04s> that may work
 21 2017-12-07 04:54:10 <cncr04s> probably will work
 22 2017-12-07 04:54:23 <cncr04s> since thats what I do with my linux daemons
 23 2017-12-07 05:01:35 <BGL> it took me an hour+ to copy the blockchain data to this other drive, in order to even try that, i'd have to erase to the drive & re-copy everything back again just to see if it workws
 24 2017-12-07 05:06:11 <cncr04s> well, thats life =D
 25 2017-12-07 05:09:55 <BGL> lol
 26 2017-12-07 05:11:32 <BGL> does anyone else have any ideas that they know for sure will work?
 27 2017-12-07 05:14:58 <luke-jr> BGL: mount --bind /some/path /destination
 28 2017-12-07 05:15:08 <luke-jr> although a symlink should work there
 29 2017-12-07 05:16:02 <BGL> windows
 30 2017-12-07 05:16:11 <luke-jr> oh, lol
 31 2017-12-07 05:16:13 <luke-jr> glwt
 32 2017-12-07 05:16:16 <luke-jr> why use a backdoored OS?
 33 2017-12-07 05:16:28 <BGL> because it doesn't come with struts
 34 2017-12-07 05:55:27 <mlz> glwt?
 35 2017-12-07 05:55:35 <mlz> oh nvm
 36 2017-12-07 15:56:01 <deego> Blockchain explorer shows x btc going to public address PUB1. I know the corresponding private key PRIV1. If I importprivkey PRIV1 - and rescan - in an unrelated wallet W, will my balance go up by precisely x?  Or could there be "missing inputs"?   (assuming that W doesn't already know PRIV1)
 37 2017-12-07 16:00:07 <deego> In reality, my wallet doesn't seem to discover the transaction that gave x btc to key PUB1 :(. I did a full -rescan
 38 2017-12-07 16:02:31 <deego> Could a wallet/blocks/ get corrupted somehow to lose a particular transaction? is that even possible?
 39 2017-12-07 16:36:15 <gevs> hello people! from this thread: https://bitcoin.stackexchange.com/questions/9046/why-is-my-transaction-not-getting-confirmed-and-what-can-i-do-about-it
 40 2017-12-07 16:36:30 <gevs> a answer mentions "run bitcoin core with -zapwallettxes"
 41 2017-12-07 16:36:56 <gevs> since i broadcast the transaction over the smartbit API - i guess i cant do that, right?
 42 2017-12-07 16:39:00 <gevs> >  The only resolutions are to confirm or invalidate (by double spending) the transaction. Double spending is not a danger in this situation because you are the sender, not the receiver.
 43 2017-12-07 16:39:14 <gevs> can I cancel my transaction this way ?
 44 2017-12-07 16:51:20 <gevs> ok never mind, i think the CPFP approach talks more to me :P more to learn haha double spend is buh
 45 2017-12-07 17:12:40 <Sentineo> gevs: electrum has an esy click option for cpfp
 46 2017-12-07 17:18:09 <gevs> that would indeed apply i think
 47 2017-12-07 17:19:30 <Sentineo> if you have a change back you can use it
 48 2017-12-07 17:19:31 <gevs> i did a pretty weird transaction taking out some USDT using a OP_RETURN but - the output i would use for the CPFP is from a omnicore wallet which doesnt need multisig
 49 2017-12-07 17:19:34 <gevs> now i already coded the child pays for parent thingy in my little cli :D
 50 2017-12-07 17:20:20 <gevs> currently fighting because before i worked with P2SH for the multisig and now this transaction im creating uses P2PKH
 51 2017-12-07 17:20:37 <gevs> but thats just more stuff i'll learn on the way :)
 52 2017-12-07 17:20:39 <Sentineo> ah I remember you were talking with arubi about it here
 53 2017-12-07 17:20:45 <Sentineo> so still strugling?
 54 2017-12-07 17:20:52 <gevs> ill look into the electrum cpfp definitely - maybe a quick help
 55 2017-12-07 17:21:13 <Sentineo> I have learnt it today :)
 56 2017-12-07 17:21:18 <Sentineo> that electrum supports it
 57 2017-12-07 17:21:23 <gevs> being too careful during tests... then for the real life thing i specified a too small fee :(
 58 2017-12-07 17:21:23 <gevs> nono - the usdt is sent back - but i defined a too small fee :(
 59 2017-12-07 17:21:24 <gevs> so its limbo dancing now
 60 2017-12-07 17:21:25 <gevs> haha
 61 2017-12-07 17:21:30 <Sentineo> tried on testnet, easy to use, no hand crafting of TXes
 62 2017-12-07 17:21:47 <Sentineo> gevs: did you use RBF though
 63 2017-12-07 17:21:48 <Sentineo> ?
 64 2017-12-07 17:21:57 <gevs> but the transaction is valid and omni also declares it as unconfirmed so im positive the USDT+CoPay will be out of the way once this transaction is confirmed
 65 2017-12-07 17:22:03 <gevs> no
 66 2017-12-07 17:22:13 <gevs> arubi mentioned that my transaction did not signal RBF
 67 2017-12-07 17:22:18 <gevs> is that what you mean?
 68 2017-12-07 17:22:21 <ne0futur> hi all, 210k unconfirmed transactions on https://blockchain.info/unconfirmed-transactions , anyone have some explanation ?
 69 2017-12-07 17:24:17 <Sentineo> gevs: yep, ok than CPFP is the only option
 70 2017-12-07 17:24:21 <Sentineo> gevs: what fee did you use?
 71 2017-12-07 17:24:31 <Sentineo> if it is not that urgent I would perhaps wait
 72 2017-12-07 17:28:22 <gevs> it was kind of urgent x] i worked so hard to reproduce the copay multisig approach, etc xD
 73 2017-12-07 17:29:03 <gevs> and then now, its hurting on that last little step of confirmation haha
 74 2017-12-07 18:43:47 <arubi> ugh.  what's my last message here please?
 75 2017-12-07 18:46:19 <dansmith_btc> arubi, there were none
 76 2017-12-07 18:46:46 <arubi> thanks dansmith_btc.  well I was asking who's timewarping testnet :)
 77 2017-12-07 18:47:03 <Sentineo> is there an attack on it?
 78 2017-12-07 18:47:42 <arubi> not an attack, just using the 20 minute difficulty 1 rule to mine blocks hehe
 79 2017-12-07 18:48:02 <arubi> I was just about to do it, but I see someone else is already running, so was wondering
 80 2017-12-07 18:54:51 <Sentineo> ah yeah
 81 2017-12-07 18:55:11 <Sentineo> I tought bitcoind saves mempool between reboots
 82 2017-12-07 18:55:16 <Sentineo> but does not seem so
 83 2017-12-07 18:55:26 <Sentineo> I have 146 txes now
 84 2017-12-07 18:55:45 <arubi> there's a flag to make it not load mempool
 85 2017-12-07 18:55:57 <arubi> it's also in a file now, intuitively mempool.dat
 86 2017-12-07 18:56:13 <Sentineo> I want it to load it
 87 2017-12-07 18:56:23 <Sentineo> just it does not seem to
 88 2017-12-07 18:56:38 <arubi> maybe they got in a block in between?
 89 2017-12-07 18:56:40 <Sentineo> but am lagging a few blcosk
 90 2017-12-07 18:56:53 <arubi> oh, not sure
 91 2017-12-07 18:56:56 <Sentineo> the backlog was like few thousand txes
 92 2017-12-07 18:56:58 <Sentineo> now I see 146
 93 2017-12-07 18:57:42 <Sentineo> poor node stopped processing new blocks as it was handling RPC calls
 94 2017-12-07 18:57:52 <arubi> rip
 95 2017-12-07 18:58:03 <arubi> but also not sure that should happen :)
 96 2017-12-07 18:58:18 <arubi> if you can recreate it, it's worth opening an issue on github
 97 2017-12-07 19:01:03 <Sentineo> it happens a lot on this odroid
 98 2017-12-07 19:02:26 <arubi> are you using the release binaries?
 99 2017-12-07 19:02:39 <Sentineo> no compiled it myself
100 2017-12-07 19:03:08 <Sentineo> with arm optimisation for libsecpp256k1
101 2017-12-07 19:03:21 <Sentineo> it happens less now, that I built it with it
102 2017-12-07 19:04:08 <arubi> oic
103 2017-12-07 19:04:39 <Sentineo> the blockchain is on an usb stick
104 2017-12-07 19:04:45 <Sentineo> to might be that as well
105 2017-12-07 19:04:50 <arubi> oof
106 2017-12-07 19:04:52 <Sentineo> do not know how to measure it
107 2017-12-07 19:09:11 <jheathco> the majority of txs currently on btc are likely to/from exchanges from private wallets, and other large p2p value transfers.  i see how lightning can help use cases related to retail and between exchanges, etc.. but i don't see how it will help alleviate the bulk of the current tx activity. mempool is sitting at close to 200mb and >200k txs.  can someone explain?
108 2017-12-07 19:22:50 <arubi> segwit, lightning, coinjoin, signature aggregation..  all things that can be done to make transactions smaller
109 2017-12-07 19:23:14 <arubi> really it's only about using as much space as possible for inputs and outputs.  the rest is just noise
110 2017-12-07 19:23:31 <arubi> eventually there's going to be a limit
111 2017-12-07 19:25:17 <arubi> we're not using signature aggregation yet, that's in the future.  the three others are live, but underused
112 2017-12-07 19:25:24 <jheathco> arubi: was that supposed to answer the question?
113 2017-12-07 19:25:43 <jheathco> i'm a bitcoin hodler and supporter, so don't take my skepticism the wrong way
114 2017-12-07 19:25:59 <arubi> never did, just not sure on what's to explain
115 2017-12-07 19:26:48 <arubi> there's lots of use, we see that sometimes.  technology to enable more in\outs is underused, so we're lagging a bit more that we could be
116 2017-12-07 19:26:51 <jheathco> the mempool/tx backlog is an obvious issue - people seem to be touting lightning as one of the potential solutions - i just don't see it based on what the likely tx use cases are as very little (if any) is being used for payments/services atm
117 2017-12-07 19:27:39 <Sentineo> you can have a channel to your exchange as well
118 2017-12-07 19:27:46 <jheathco> i see lightning helping with tx activity related to retail/etc. in the future
119 2017-12-07 19:27:50 <Sentineo> what makes you think people would not choose it in case it is cheaper?
120 2017-12-07 19:28:02 <arubi> there's safe way to enable unlimited capacity in bitcoin, so we're stuck with whatever we can use.  problem is, what we do have is heavily underused
121 2017-12-07 19:28:10 <Sentineo> it would me much cheaper for the exchange and they could gain fees
122 2017-12-07 19:28:27 <jheathco> sentineo, because we urge users to keep their funds in their private wallets... not to open a channel
123 2017-12-07 19:28:42 <arubi> a channel isn't for /all/ your funds
124 2017-12-07 19:28:51 <jheathco> i know that... that's my point
125 2017-12-07 19:29:00 <adiabat> jheathco: funds in a channel with an exchange is much better than funds on an exchange as they work today
126 2017-12-07 19:29:03 <jheathco> the amount you'd want to trade you'd have to top up on the channel, or pull from the channel
127 2017-12-07 19:29:14 <adiabat> if the exchange gets hacked and you have a channel with them, you lose nothing
128 2017-12-07 19:29:31 <arubi> exactly, it's much better than sending bit by bit so you don't lose it all
129 2017-12-07 19:29:41 <jheathco> adiabat: agreed, but funds on an exchange aren't affecting the tx backlog anyway... so i don't see the point
130 2017-12-07 19:29:49 <Sentineo> you need an amount to open the channel, than it is very cheap
131 2017-12-07 19:30:03 <Sentineo> jheathco: you have to get those funds there somehow
132 2017-12-07 19:30:08 <arubi> funds to and from exchanges are probably a huge part
133 2017-12-07 19:30:08 <jheathco> i'm not talking about safety or where to keep bitcoin (on exchange versus in channel), i'm talking about the backlog/mempool
134 2017-12-07 19:30:09 <Sentineo> so it is effecting it
135 2017-12-07 19:30:23 <adiabat> it might help in that people would be more comfortable leaving a channel open instead of sending coins to exchanges a few at a time
136 2017-12-07 19:30:52 <arubi> jheathco, even with all improvements being used to their full extent, there will /still/ be backlog
137 2017-12-07 19:31:08 <jheathco> ok say you have 100 btc... you want to trade actively trade 10 of it... you either put the 10 on an exchange or put the 10 into a lightning channel. obviously the latter is "safer", but both cases only affect mempool when pushing/pulling funds
138 2017-12-07 19:31:43 <adiabat> I mean ... if you make the same # of transactions, then sure
139 2017-12-07 19:31:54 <adiabat> the idea is that people who have all 100 on their computer
140 2017-12-07 19:32:20 <adiabat> and send 1 coin every time they want to sell, those people will switch to having a channel with 10 coins with the exchange
141 2017-12-07 19:32:51 <jheathco> i just think it's misleading then to act as if lightning is going to help considerably, even when adopted, with mempool/backlog.  if 80% of tx activity on-chain now was retail/payment based, i'd agree.... but it's not
142 2017-12-07 19:33:03 <Sentineo> jheathco: I am not sure you need to send 10 for the channel, you can send more later, or not?
143 2017-12-07 19:33:20 <jheathco> sentineo: sure, but then you're posting another tx on-chain to top-up the channel
144 2017-12-07 19:33:36 <arubi> huh? why open a channel for the bare minimum?
145 2017-12-07 19:33:46 <jheathco> i just don't see how we alleviate mempool issues without scaling via blocksize increase
146 2017-12-07 19:33:53 <jheathco> ....arubi: not suggesting that
147 2017-12-07 19:33:57 <arubi> if you believe 10 is not enough, open for 50
148 2017-12-07 19:34:07 <arubi> stop after 10 if it does end up being enough
149 2017-12-07 19:34:09 <jheathco> arubi: responding to sentineo
150 2017-12-07 19:34:29 <arubi> you're suggesting a channel should be funded as much as sending individual transactions
151 2017-12-07 19:34:50 <arubi> that's not the point.  if you're funding as much as you'd normally just send, you're inefficient
152 2017-12-07 19:35:12 <jheathco> no, i'm not
153 2017-12-07 19:35:20 <Sentineo> arubi: so should it be funded with more?
154 2017-12-07 19:35:23 <jheathco> i'm comparing to current activity with an exchange
155 2017-12-07 19:35:46 <arubi> yes, with an exchange I can use lightning to open a channel with 100 bitcoins, and only risk 0.00001 at each send
156 2017-12-07 19:35:55 <arubi> and there would be 2 transactions on chain
157 2017-12-07 19:36:05 <jheathco> you're talking about risk
158 2017-12-07 19:36:11 <jheathco> i'm talking about mempool issues
159 2017-12-07 19:36:14 <jheathco> i agree with you re: risk
160 2017-12-07 19:36:23 <arubi> okay, rephrase the issue please
161 2017-12-07 19:36:31 <Sentineo> but if it is sent via a channel, no mempool issue that is what arubi is saying
162 2017-12-07 19:36:32 <arubi> seems like every counter point is met "but that's not 'mempool'"
163 2017-12-07 19:36:32 <jheathco> how does this help the mempool using lightning?
164 2017-12-07 19:37:02 <Sentineo> txes sent via lightning do not get to the mempool
165 2017-12-07 19:37:10 <Sentineo> ignoring seting up the channel
166 2017-12-07 19:37:31 <jheathco> i thought i explained it clearly.  you have 100 btc, you want to trade or "play with" 10... option 1) open lightning channel for 10 btc, option 2) send 10 btc to exchange
167 2017-12-07 19:37:44 <arubi> if you want to send once, you just send
168 2017-12-07 19:37:50 <jheathco> option 1) obviously much safer re: risk, but both affect mempool equally
169 2017-12-07 19:37:54 <arubi> what's the fix for the minimal case?
170 2017-12-07 19:37:59 <arubi> use segwit
171 2017-12-07 19:38:00 <adiabat> option 3) send 1 to the exchnage
172 2017-12-07 19:38:07 <adiabat> because it's too dangerous to send all 10
173 2017-12-07 19:38:20 <adiabat> which is what people do
174 2017-12-07 19:38:29 <Sentineo> yep
175 2017-12-07 19:38:40 <jheathco> *facepalm* ok, i guess i'm only making sense to myself
176 2017-12-07 19:38:55 <jheathco> i've made it clear i'm not talking about risk/danger/safety
177 2017-12-07 19:39:03 <adiabat> OK then sure, there's no point
178 2017-12-07 19:39:10 <jheathco> i see the obvious benefits of lightning
179 2017-12-07 19:39:17 <jheathco> i'm talking about fees/mempool issues
180 2017-12-07 19:39:23 <Sentineo> well ok consider this
181 2017-12-07 19:39:26 <adiabat> if you're going to do everything without worrying about risk, just have everything on coinbase...
182 2017-12-07 19:39:28 <jheathco> apparently those aren't important?
183 2017-12-07 19:39:28 <Sentineo> I have 5 exchange accounts
184 2017-12-07 19:39:52 <adiabat> then can make transactions with everyone else on coinbase without touching the blockchain
185 2017-12-07 19:40:03 <Sentineo> funding 5 vs opening one channel and using the fact that there might be channels between them
186 2017-12-07 19:40:20 <Sentineo> this scenario would make less stress on mempool? (I think yes) but not sure
187 2017-12-07 19:40:25 <jheathco> adiabat: ok? that's not what txs are likely happening now anyhow
188 2017-12-07 19:40:27 <adiabat> it's very scalable and fast, but is trusted... the whole point of lightning was to try and prevent that from happening
189 2017-12-07 19:40:51 <jheathco> sentineo: yes, that would help, but you think most users are trading on 5 exchanges?
190 2017-12-07 19:40:57 <adiabat> people do internal coinbase transactions, as they did with gox, etc
191 2017-12-07 19:41:03 <jheathco> let's look at the *current* typical use cases
192 2017-12-07 19:41:23 <jheathco> adiabat: yes, and internal coinbase txs aren't hitting blockchain anyway
193 2017-12-07 19:41:39 <jheathco> (at least i don't think they are?)
194 2017-12-07 19:41:43 <jheathco> but regardless, there are likely very few
195 2017-12-07 19:41:46 <Sentineo> jheathco: yes I think it is pretty common to have at least 2  exchanges
196 2017-12-07 19:41:51 <jheathco> most of the tx activity right now is related to trading and to/from exchanges
197 2017-12-07 19:41:57 <adiabat> right, so compared to everyone just having coins on an exchange, lightning doesn't help with scalability, it helps with security / trust
198 2017-12-07 19:42:09 <jheathco> adiabat: agree 100%
199 2017-12-07 19:42:12 <Sentineo> jheathco: did you make any measurements, using most of, bla bla as if you know ...
200 2017-12-07 19:42:13 <jheathco> and i'm stoked on that
201 2017-12-07 19:42:17 <adiabat> compared with every trade happening on-chain, it helps with scalability
202 2017-12-07 19:42:22 <jheathco> but i have major concerns for not increasing blocksize
203 2017-12-07 19:42:30 <adiabat> but... people don't do all trades on-chain already, because it's too expensive
204 2017-12-07 19:42:54 <adiabat> I agree that 2MB is too small
205 2017-12-07 19:42:58 <jheathco> sentineo: no, so i realize i could be wrong... i'm using common sense.. who is accepting bitcoin for payment for goods/services now? and if they are, who in their right minds would be doing that with crazy fees?
206 2017-12-07 19:43:32 <jheathco> adiabat: also agreed
207 2017-12-07 19:43:57 <Sentineo> it is 4MB
208 2017-12-07 19:44:08 <adiabat> 4MB... kindof / sortof...
209 2017-12-07 19:44:17 <jheathco> sentineo: it's < 2mb with the most optimistic calculations afaik
210 2017-12-07 19:44:41 <jheathco> regardless, it needs to be higher
211 2017-12-07 19:44:46 <jheathco> imho
212 2017-12-07 19:44:48 <adiabat> funny thing is I thing signature aggregation will actually lower the weights of blocks
213 2017-12-07 19:44:58 <Sentineo> I am afraid of the consequences it will cause
214 2017-12-07 19:45:03 <adiabat> thing is, hard forks are... pretty tough
215 2017-12-07 19:45:15 <adiabat> gotta convince everyone to run new code
216 2017-12-07 19:45:22 <jheathco> i disagree, but if they are, we could do extension blocks
217 2017-12-07 19:45:42 <adiabat> I think some kind of bulletproof extention block would be really cool
218 2017-12-07 19:45:50 <jheathco> i think if core came out in support of increasing block size, it would be a breeze.... i just don't see that happening
219 2017-12-07 19:45:51 <Sentineo> the solution will perhaps lie in the combination of all
220 2017-12-07 19:45:57 <mlz> hey antpool still mines empty blocks, why is that?
221 2017-12-07 19:46:14 <mlz> if jihan is so concerned about blksize, why still mining empty blocks?
222 2017-12-07 19:46:26 <adiabat> "core" isn't really a thing.  people who work on it argue with each other all the time
223 2017-12-07 19:46:38 <jheathco> mlz: there are reasons and it has nothing to do with him trying to increase the mempool
224 2017-12-07 19:46:49 <mlz> oh really?
225 2017-12-07 19:46:52 <jheathco> adiabat: i know... i'm just generalizing
226 2017-12-07 19:47:20 <adiabat> sure if most / all of the developers had some extention block thing and agreed on it, I think most people would use it
227 2017-12-07 19:47:33 <adiabat> That may happen, but probably not for a year or two
228 2017-12-07 19:48:40 <jheathco> luckily bitcoin is riding on its brand equity (amongst other things) so the shift to alts hasn't been as swift as many feared
229 2017-12-07 19:49:03 <jheathco> so i just hope it has enough time until we get to some serious scaling solution (assuming the community supports it)
230 2017-12-07 19:49:10 <esotericnonsense> jheathco: that and people aren't muppets
231 2017-12-07 19:49:18 <adiabat> it's not like alts have better ideas...
232 2017-12-07 19:49:37 <jheathco> esotericnonsense: not sure what you mean by that
233 2017-12-07 19:49:50 <esotericnonsense> moving to an alt means gaining a small, temporary increase in throughput
234 2017-12-07 19:50:18 <jheathco> adiabat: agree... the idea is simply increasing block size ... it's not a "better" idea since it's already been the longest proposed solution
235 2017-12-07 19:50:37 <jheathco> esotericnonsense: small and temporary? where do you get that?
236 2017-12-07 19:50:48 <esotericnonsense> jheathco: so you use ltc instead of btc
237 2017-12-07 19:50:55 <mlz> if/when almost every user uses segwit, exchanges/services use segwit, that will help, then LN comes in in full force, that will help, AND Schnorr becomes a thing for bitcoin, that will help even more
238 2017-12-07 19:50:56 <esotericnonsense> okay, so the block size on ltc is currently higher than btc's
239 2017-12-07 19:50:58 <jheathco> actually, we're not supposed to talk about alts regardless so i should probably shift away from that
240 2017-12-07 19:51:03 <esotericnonsense> that's it
241 2017-12-07 19:51:18 <esotericnonsense> sorry, not the block size; the interval hence throughput.
242 2017-12-07 19:51:22 <jheathco> i don't want to use alts, i want to use btc -  i just want to see it scale
243 2017-12-07 19:52:02 <mlz> btc CAN NOT scale on chain
244 2017-12-07 19:52:31 <jheathco> uh... care to explain?
245 2017-12-07 19:52:31 <mlz> and if you make it scale on chain, it will becomes another paypal, so use the current Paypal now
246 2017-12-07 19:52:44 <esotericnonsense> increasing the block size is not scaling bitcoin
247 2017-12-07 19:52:49 <esotericnonsense> as a matter of fact it's probably the opposite
248 2017-12-07 19:52:52 <jheathco> ok
249 2017-12-07 19:52:58 <jheathco> so i guess we can decrease blocksize
250 2017-12-07 19:53:00 <esotericnonsense> a tiny portion of bitcoin 'owners' actually use bitcoin as it stands
251 2017-12-07 19:53:03 <jheathco> and scale it more?
252 2017-12-07 19:53:06 <jheathco> by that logic?
253 2017-12-07 19:53:13 <mlz> jheathco, stop being a troll
254 2017-12-07 19:53:16 <esotericnonsense> jheathco: very possibly, yes
255 2017-12-07 19:53:26 <jheathco> mlz: so i'm a troll because i question your narrative?
256 2017-12-07 19:54:04 <jheathco> jesus... i'm a bitcoin supporter and holder, and i can't question technical issues i see with it without being labeled a troll
257 2017-12-07 19:54:09 <jheathco> this is one of the major problems with the community
258 2017-12-07 19:54:12 <mlz> no, by you going around your "blocksize blahbla" narrative
259 2017-12-07 19:54:36 <esotericnonsense> jheathco: it's mostly that there's a distinction between using bitcoin and 'owning' bitcoin, for lack of better terminology
260 2017-12-07 19:54:36 <jheathco> mlz: then ignore me
261 2017-12-07 19:54:48 <esotericnonsense> barely anyone actually takes part in the network as it stands
262 2017-12-07 19:55:02 <jheathco> i agree
263 2017-12-07 19:55:15 <esotericnonsense> increasing the block size substantially (sure, go and make it 2x or whatever, don't care) would make that worse
264 2017-12-07 19:55:21 <jheathco> but we want to see that happen (which is one of the major hopes for lightning - retail payments, etc.)
265 2017-12-07 19:55:36 <jheathco> i agree
266 2017-12-07 19:55:43 <jheathco> i'm not arguing for 1gb blocks like some due
267 2017-12-07 19:55:44 <jheathco> do*
268 2017-12-07 19:55:54 <esotericnonsense> the point is that LN (or a system like it) is not a broadcast network
269 2017-12-07 19:56:09 <esotericnonsense> with the current amount of computational power the average person has, that's the only way to do it
270 2017-12-07 19:56:10 <jheathco> yes
271 2017-12-07 19:56:11 <jheathco> which is great
272 2017-12-07 19:56:17 <jheathco> agree
273 2017-12-07 19:56:54 <jheathco> i think the issue is we've become so polarized... it's either tiny blocks with lightning, or massive blocks and no l2
274 2017-12-07 19:57:07 <jheathco> why not safely increase block size and use l2?
275 2017-12-07 19:57:17 <esotericnonsense> that is almost certainly going to happen
276 2017-12-07 19:57:28 <esotericnonsense> it's just that right now it's pretty much a pure bikeshed issue
277 2017-12-07 19:57:43 <jheathco> that's unfortunate, but i hope you're right that it will happen (sooner than later)
278 2017-12-07 19:57:50 <instagibbs> jheathco, was already increased once, users arent even using the new space yet
279 2017-12-07 19:58:02 <esotericnonsense> obviously this is my view, but tx fees on the bitcoin network being 'high' is basically irrelevant right now
280 2017-12-07 19:58:15 <jheathco> instagibbs: they're using it whenever they can. that's very misleading for you to say
281 2017-12-07 19:58:32 <esotericnonsense> whether they are $4 or $1 you're still not buying low value items with it, the window of 'reasonable things to spend it on' doesn't change much
282 2017-12-07 19:59:12 <esotericnonsense> so erring on the side of lower throughput / more bitcoin users/verifiers seems sensible to me given that
283 2017-12-07 19:59:13 <jheathco> esotericnonsense: i agree, however a year or two ago i *was* buying some things with bitcoin
284 2017-12-07 19:59:24 <jheathco> i wouldn't now, and i agree that those use cases should be moved to l2
285 2017-12-07 19:59:34 <esotericnonsense> the past few years was like an accident
286 2017-12-07 19:59:41 <esotericnonsense> or a dream world or something
287 2017-12-07 19:59:50 <esotericnonsense> it's like thinking about a time when you could drive cars about in central london with no traffic
288 2017-12-07 20:00:08 <esotericnonsense> i don't even know if that did exist, but if it did, it's obvious that it couldn't last unless you just didn't think about it
289 2017-12-07 20:00:13 <jheathco> sure, but bitcoin worked *better* back then ;)
290 2017-12-07 20:00:22 <esotericnonsense> right, it worked better with fewer people
291 2017-12-07 20:00:28 <jheathco> it's like having horseback now and dreaming of a time when we used cars
292 2017-12-07 20:00:44 <esotericnonsense> i don't think that's the case, it's purely congestion
293 2017-12-07 20:00:51 <esotericnonsense> just like dreaming of a time when fewer people owned cars
294 2017-12-07 20:00:59 <jheathco> yep
295 2017-12-07 20:01:11 <esotericnonsense> 10-20 years ago in the UK there was a lot less traffic and it was better (for those that owned cars)
296 2017-12-07 20:01:29 <jheathco> well, playing devils advocate... let's imagine the blocksize was set at 50kb back when satoshi set the limit
297 2017-12-07 20:01:31 <esotericnonsense> but it only ever worked as an elitist thing
298 2017-12-07 20:01:33 <esotericnonsense> and i'd argue it still does
299 2017-12-07 20:01:37 <jheathco> do you think we'd be here now arguing to keep it at 50kb?
300 2017-12-07 20:01:45 <instagibbs> the year will be 20XX and someone on IRC will be arguing for a small constant factor like it's the death of the system
301 2017-12-07 20:01:48 <jheathco> and that increasing it is not a way (one way) to scale bitcoin?
302 2017-12-07 20:02:21 <Sentineo> you want to solve an exponential problem with linear fix
303 2017-12-07 20:02:30 <Sentineo> does not sound right, block size alone is for sure not enough
304 2017-12-07 20:02:34 <mlz> some people just can't get the fact that "increasing the blocksize will not scale bitcoin" it's too difficult for them to get it
305 2017-12-07 20:02:36 <esotericnonsense> jheathco: i think that increasing the block size as a HF should come with other HF fixes
306 2017-12-07 20:02:37 <jheathco> sentineo: nope, otherwise i'd be arguing against lightning
307 2017-12-07 20:03:03 <jheathco> esotericnonsense: agree - so let's push for all of that
308 2017-12-07 20:03:14 <esotericnonsense> and I also think it's kind of silly because to do it now will just require another one later and i don't think it's necessary now
309 2017-12-07 20:03:39 <esotericnonsense> i dunno. it's like i have a 20 year old civic and i'm buying a tesla next year
310 2017-12-07 20:03:53 <esotericnonsense> and i'm arguing with the wife about whether to rice it and put spoilers on it and shit
311 2017-12-07 20:03:55 <esotericnonsense> it's just, i don't care
312 2017-12-07 20:04:02 <mlz> how did pushing 2X work out for you and garzik, jheathco?
313 2017-12-07 20:04:27 <jheathco> mlz: why are you asking irrelevant questions that you already have an answer to, mlz?
314 2017-12-07 20:04:32 <esotericnonsense> it's a non issue for me personally, i don't think it's broken, i think we need to deal with blocks being full
315 2017-12-07 20:04:47 <esotericnonsense> it's a necessary part of the evolution of the system if we want to protect the coin cap
316 2017-12-07 20:04:49 <jheathco> and by the way, i own a supplement business - i have NOTHING to gain from bitcoin other than my hopes for where the technology goes
317 2017-12-07 20:04:58 <mlz> jheathco, it's irrelevant because you can't deny it's stupid to push for a HF
318 2017-12-07 20:05:23 <jheathco> mlz, hopefully you scream at the core devs that were suggesting for hard forked block size increases then a year or so ago?
319 2017-12-07 20:07:04 <jheathco> there will have to be hfs in the future if bitcoin is to survive, and there is nothing wrong with that
320 2017-12-07 20:07:40 <adiabat> "There are levels of survival we are prepared to accept." :)
321 2017-12-07 20:07:45 <mlz> jheathco, huh?
322 2017-12-07 20:08:32 <mlz> jheathco, sure there might be necessary hf's in the future but i don't see you aim for that
323 2017-12-07 20:08:41 <jheathco> ok, have to go work - enjoyed the chat
324 2017-12-07 20:09:26 <jheathco> later all
325 2017-12-07 21:53:45 <MrBar> this info outdated? https://en.bitcoin.it/wiki/Getblocktemplate
326 2017-12-07 21:54:13 <MrBar> 100 byte hard limit on coinbase tx?
327 2017-12-07 21:55:33 <arubi> it's not "coinbase tx"
328 2017-12-07 21:55:35 <arubi> it's "coinbase"
329 2017-12-07 21:56:19 <arubi> it's the data where an input script will usually be
330 2017-12-07 21:56:30 <arubi> so, where currently there's block height
331 2017-12-07 22:05:09 <MrBar> input script?
332 2017-12-07 22:05:33 <arubi> what's the question exactly?
333 2017-12-07 22:06:14 <arubi> there's a script present in each input in a transaction, usually has signatures and pubkeys in it
334 2017-12-07 22:06:24 <MrBar> when i get getrawtransaction with coinbase tx id it 201 bytes
335 2017-12-07 22:06:47 <arubi> well, "coinbase" is just a part of that transaction
336 2017-12-07 22:07:01 <arubi> the term "coinbase tx" is confusing
337 2017-12-07 22:07:28 <MrBar> How to build coinbase transaction
338 2017-12-07 22:07:36 <MrBar> head from doc
339 2017-12-07 22:07:41 <arubi> in what sense?
340 2017-12-07 22:08:09 <MrBar> question exactly abut coinbase tx
341 2017-12-07 22:10:06 <MrBar> if coinbase data does not overflow the 100 bytes what the rest of tx?
342 2017-12-07 22:10:54 <arubi> what you'd usually find in a transaction outputs, version, locktime, amounts..
343 2017-12-07 22:11:53 <arubi> the input encoding is the same, but the json shows up differently for these type of transactions so it seems like there's something special to it.  there's not.  just some specific "previous" txid and index
344 2017-12-07 22:12:55 <MrBar> hm
345 2017-12-07 22:13:25 <MrBar> coinbase tx = coinbase data + outputs
346 2017-12-07 22:13:32 <MrBar> right?
347 2017-12-07 22:14:02 <arubi> there's more to it that + outputs.  it's a transaction
348 2017-12-07 22:14:38 <arubi> s/that/than/
349 2017-12-07 22:15:16 <MrBar> outputs+tx_witnesses+lock_time
350 2017-12-07 22:15:21 <MrBar> ?
351 2017-12-07 22:15:57 <arubi> what's the actual question?
352 2017-12-07 22:17:04 <MrBar> now clear, tnx
353 2017-12-07 22:25:01 <MrBar> blockexplorer.com sometimes show in coinbase tx  "Unparsed address [0] 0 BTC" as second output, this is site code problem? incompatibles with protocol?