Transcript for #bitcoin-dev 2017/12/07

02:44 ponzibanker Anyone here familiar with when a validating node updates the mempool?
03:18 phantomcircuit ponzibanker, define updates
03:20 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.
03:23 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?
04:23 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
04:25 cncr04s windows?
04:25 cncr04s that won't work
04:25 cncr04s linux, sure
04:26 BGL i just had a site in front of me saying it does
04:26 BGL have you tried it on windows?
04:26 cncr04s i have
04:26 cncr04s its been a while though
04:26 cncr04s I just got a 2tb ssd
04:26 cncr04s dont gotta worry
04:48 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
04:53 cncr04s well
04:53 cncr04s try creating a partition for the blocks
04:53 cncr04s and mount it in the blocks folder
04:53 cncr04s instread of giving it a drive
04:53 cncr04s that may work
04:54 cncr04s probably will work
04:54 cncr04s since thats what I do with my linux daemons
05:01 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
05:06 cncr04s well, thats life =D
05:09 BGL lol
05:11 BGL does anyone else have any ideas that they know for sure will work?
05:14 luke-jr BGL: mount --bind /some/path /destination
05:15 luke-jr although a symlink should work there
05:16 BGL windows
05:16 luke-jr oh, lol
05:16 luke-jr glwt
05:16 luke-jr why use a backdoored OS?
05:16 BGL because it doesn't come with struts
05:55 mlz glwt?
05:55 mlz oh nvm
15:56 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)
16:00 deego In reality, my wallet doesn't seem to discover the transaction that gave x btc to key PUB1 :(. I did a full -rescan
16:02 deego Could a wallet/blocks/ get corrupted somehow to lose a particular transaction? is that even possible?
16:36 gevs hello people! from this thread:
16:36 gevs a answer mentions "run bitcoin core with -zapwallettxes"
16:36 gevs since i broadcast the transaction over the smartbit API - i guess i cant do that, right?
16:39 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.
16:39 gevs can I cancel my transaction this way ?
16:51 gevs ok never mind, i think the CPFP approach talks more to me :P more to learn haha double spend is buh
17:12 Sentineo gevs: electrum has an esy click option for cpfp
17:18 gevs that would indeed apply i think
17:19 Sentineo if you have a change back you can use it
17:19 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
17:19 gevs now i already coded the child pays for parent thingy in my little cli :D
17:20 gevs currently fighting because before i worked with P2SH for the multisig and now this transaction im creating uses P2PKH
17:20 gevs but thats just more stuff i'll learn on the way :)
17:20 Sentineo ah I remember you were talking with arubi about it here
17:20 Sentineo so still strugling?
17:20 gevs ill look into the electrum cpfp definitely - maybe a quick help
17:21 Sentineo I have learnt it today :)
17:21 Sentineo that electrum supports it
17:21 gevs nono - the usdt is sent back - but i defined a too small fee :(
17:21 gevs being too careful during tests... then for the real life thing i specified a too small fee :(
17:21 gevs so its limbo dancing now
17:21 gevs haha
17:21 Sentineo tried on testnet, easy to use, no hand crafting of TXes
17:21 Sentineo gevs: did you use RBF though
17:21 Sentineo ?
17:21 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
17:22 gevs no
17:22 gevs arubi mentioned that my transaction did not signal RBF
17:22 gevs is that what you mean?
17:22 ne0futur hi all, 210k unconfirmed transactions on , anyone have some explanation ?
17:24 Sentineo gevs: yep, ok than CPFP is the only option
17:24 Sentineo gevs: what fee did you use?
17:24 Sentineo if it is not that urgent I would perhaps wait
17:28 gevs it was kind of urgent x] i worked so hard to reproduce the copay multisig approach, etc xD
17:29 gevs and then now, its hurting on that last little step of confirmation haha
18:43 arubi ugh. what's my last message here please?
18:46 dansmith_btc arubi, there were none
18:46 arubi thanks dansmith_btc. well I was asking who's timewarping testnet :)
18:47 Sentineo is there an attack on it?
18:47 arubi not an attack, just using the 20 minute difficulty 1 rule to mine blocks hehe
18:48 arubi I was just about to do it, but I see someone else is already running, so was wondering
18:54 Sentineo ah yeah
18:55 Sentineo I tought bitcoind saves mempool between reboots
18:55 Sentineo but does not seem so
18:55 Sentineo I have 146 txes now
18:55 arubi there's a flag to make it not load mempool
18:55 arubi it's also in a file now, intuitively mempool.dat
18:56 Sentineo I want it to load it
18:56 Sentineo just it does not seem to
18:56 arubi maybe they got in a block in between?
18:56 Sentineo but am lagging a few blcosk
18:56 arubi oh, not sure
18:56 Sentineo the backlog was like few thousand txes
18:56 Sentineo now I see 146
18:57 Sentineo poor node stopped processing new blocks as it was handling RPC calls
18:57 arubi rip
18:58 arubi but also not sure that should happen :)
18:58 arubi if you can recreate it, it's worth opening an issue on github
19:01 Sentineo it happens a lot on this odroid
19:02 arubi are you using the release binaries?
19:02 Sentineo no compiled it myself
19:03 Sentineo with arm optimisation for libsecpp256k1
19:03 Sentineo it happens less now, that I built it with it
19:04 arubi oic
19:04 Sentineo the blockchain is on an usb stick
19:04 Sentineo to might be that as well
19:04 arubi oof
19:04 Sentineo do not know how to measure it
19:09 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?
19:22 arubi segwit, lightning, coinjoin, signature aggregation.. all things that can be done to make transactions smaller
19:23 arubi really it's only about using as much space as possible for inputs and outputs. the rest is just noise
19:23 arubi eventually there's going to be a limit
19:25 arubi we're not using signature aggregation yet, that's in the future. the three others are live, but underused
19:25 jheathco arubi: was that supposed to answer the question?
19:25 jheathco i'm a bitcoin hodler and supporter, so don't take my skepticism the wrong way
19:25 arubi never did, just not sure on what's to explain
19:26 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
19:26 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
19:27 Sentineo you can have a channel to your exchange as well
19:27 jheathco i see lightning helping with tx activity related to retail/etc. in the future
19:27 Sentineo what makes you think people would not choose it in case it is cheaper?
19:28 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
19:28 Sentineo it would me much cheaper for the exchange and they could gain fees
19:28 jheathco sentineo, because we urge users to keep their funds in their private wallets... not to open a channel
19:28 arubi a channel isn't for /all/ your funds
19:28 jheathco i know that... that's my point
19:29 adiabat jheathco: funds in a channel with an exchange is much better than funds on an exchange as they work today
19:29 jheathco the amount you'd want to trade you'd have to top up on the channel, or pull from the channel
19:29 adiabat if the exchange gets hacked and you have a channel with them, you lose nothing
19:29 arubi exactly, it's much better than sending bit by bit so you don't lose it all
19:29 jheathco adiabat: agreed, but funds on an exchange aren't affecting the tx backlog anyway... so i don't see the point
19:29 Sentineo you need an amount to open the channel, than it is very cheap
19:30 Sentineo jheathco: you have to get those funds there somehow
19:30 jheathco i'm not talking about safety or where to keep bitcoin (on exchange versus in channel), i'm talking about the backlog/mempool
19:30 arubi funds to and from exchanges are probably a huge part
19:30 Sentineo so it is effecting it
19:30 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
19:30 arubi jheathco, even with all improvements being used to their full extent, there will /still/ be backlog
19:31 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
19:31 adiabat I mean ... if you make the same # of transactions, then sure
19:31 adiabat the idea is that people who have all 100 on their computer
19:32 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
19:32 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
19:33 Sentineo jheathco: I am not sure you need to send 10 for the channel, you can send more later, or not?
19:33 jheathco sentineo: sure, but then you're posting another tx on-chain to top-up the channel
19:33 arubi huh? why open a channel for the bare minimum?
19:33 jheathco i just don't see how we alleviate mempool issues without scaling via blocksize increase
19:33 jheathco ....arubi: not suggesting that
19:33 arubi if you believe 10 is not enough, open for 50
19:34 arubi stop after 10 if it does end up being enough
19:34 jheathco arubi: responding to sentineo
19:34 arubi you're suggesting a channel should be funded as much as sending individual transactions
19:34 arubi that's not the point. if you're funding as much as you'd normally just send, you're inefficient
19:35 jheathco no, i'm not
19:35 Sentineo arubi: so should it be funded with more?
19:35 jheathco i'm comparing to current activity with an exchange
19:35 arubi yes, with an exchange I can use lightning to open a channel with 100 bitcoins, and only risk 0.00001 at each send
19:35 arubi and there would be 2 transactions on chain
19:36 jheathco you're talking about risk
19:36 jheathco i'm talking about mempool issues
19:36 jheathco i agree with you re: risk
19:36 arubi okay, rephrase the issue please
19:36 Sentineo but if it is sent via a channel, no mempool issue that is what arubi is saying
19:36 jheathco how does this help the mempool using lightning?
19:36 arubi seems like every counter point is met "but that's not 'mempool'"
19:37 Sentineo txes sent via lightning do not get to the mempool
19:37 Sentineo ignoring seting up the channel
19:37 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
19:37 arubi if you want to send once, you just send
19:37 jheathco option 1) obviously much safer re: risk, but both affect mempool equally
19:37 arubi what's the fix for the minimal case?
19:37 arubi use segwit
19:38 adiabat option 3) send 1 to the exchnage
19:38 adiabat because it's too dangerous to send all 10
19:38 adiabat which is what people do
19:38 Sentineo yep
19:38 jheathco *facepalm* ok, i guess i'm only making sense to myself
19:38 jheathco i've made it clear i'm not talking about risk/danger/safety
19:39 adiabat OK then sure, there's no point
19:39 jheathco i see the obvious benefits of lightning
19:39 jheathco i'm talking about fees/mempool issues
19:39 Sentineo well ok consider this
19:39 adiabat if you're going to do everything without worrying about risk, just have everything on coinbase...
19:39 jheathco apparently those aren't important?
19:39 Sentineo I have 5 exchange accounts
19:39 adiabat then can make transactions with everyone else on coinbase without touching the blockchain
19:40 Sentineo funding 5 vs opening one channel and using the fact that there might be channels between them
19:40 Sentineo this scenario would make less stress on mempool? (I think yes) but not sure
19:40 jheathco adiabat: ok? that's not what txs are likely happening now anyhow
19:40 adiabat it's very scalable and fast, but is trusted... the whole point of lightning was to try and prevent that from happening
19:40 jheathco sentineo: yes, that would help, but you think most users are trading on 5 exchanges?
19:40 adiabat people do internal coinbase transactions, as they did with gox, etc
19:41 jheathco let's look at the *current* typical use cases
19:41 jheathco adiabat: yes, and internal coinbase txs aren't hitting blockchain anyway
19:41 jheathco (at least i don't think they are?)
19:41 jheathco but regardless, there are likely very few
19:41 Sentineo jheathco: yes I think it is pretty common to have at least 2 exchanges
19:41 jheathco most of the tx activity right now is related to trading and to/from exchanges
19:41 adiabat right, so compared to everyone just having coins on an exchange, lightning doesn't help with scalability, it helps with security / trust
19:42 jheathco adiabat: agree 100%
19:42 Sentineo jheathco: did you make any measurements, using most of, bla bla as if you know ...
19:42 jheathco and i'm stoked on that
19:42 adiabat compared with every trade happening on-chain, it helps with scalability
19:42 jheathco but i have major concerns for not increasing blocksize
19:42 adiabat but... people don't do all trades on-chain already, because it's too expensive
19:42 adiabat I agree that 2MB is too small
19:42 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?
19:43 jheathco adiabat: also agreed
19:43 Sentineo it is 4MB
19:44 adiabat 4MB... kindof / sortof...
19:44 jheathco sentineo: it's < 2mb with the most optimistic calculations afaik
19:44 jheathco regardless, it needs to be higher
19:44 jheathco imho
19:44 adiabat funny thing is I thing signature aggregation will actually lower the weights of blocks
19:44 Sentineo I am afraid of the consequences it will cause
19:45 adiabat thing is, hard forks are... pretty tough
19:45 adiabat gotta convince everyone to run new code
19:45 jheathco i disagree, but if they are, we could do extension blocks
19:45 adiabat I think some kind of bulletproof extention block would be really cool
19:45 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
19:45 Sentineo the solution will perhaps lie in the combination of all
19:45 mlz hey antpool still mines empty blocks, why is that?
19:46 mlz if jihan is so concerned about blksize, why still mining empty blocks?
19:46 adiabat "core" isn't really a thing. people who work on it argue with each other all the time
19:46 jheathco mlz: there are reasons and it has nothing to do with him trying to increase the mempool
19:46 mlz oh really?
19:46 jheathco adiabat: i know... i'm just generalizing
19:47 adiabat sure if most / all of the developers had some extention block thing and agreed on it, I think most people would use it
19:47 adiabat That may happen, but probably not for a year or two
19:48 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
19:49 jheathco so i just hope it has enough time until we get to some serious scaling solution (assuming the community supports it)
19:49 esotericnonsense jheathco: that and people aren't muppets
19:49 adiabat it's not like alts have better ideas...
19:49 jheathco esotericnonsense: not sure what you mean by that
19:49 esotericnonsense moving to an alt means gaining a small, temporary increase in throughput
19:50 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
19:50 jheathco esotericnonsense: small and temporary? where do you get that?
19:50 esotericnonsense jheathco: so you use ltc instead of btc
19:50 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
19:50 esotericnonsense okay, so the block size on ltc is currently higher than btc's
19:50 jheathco actually, we're not supposed to talk about alts regardless so i should probably shift away from that
19:51 esotericnonsense that's it
19:51 esotericnonsense sorry, not the block size; the interval hence throughput.
19:51 jheathco i don't want to use alts, i want to use btc - i just want to see it scale
19:52 mlz btc CAN NOT scale on chain
19:52 mlz and if you make it scale on chain, it will becomes another paypal, so use the current Paypal now
19:52 jheathco uh... care to explain?
19:52 esotericnonsense increasing the block size is not scaling bitcoin
19:52 esotericnonsense as a matter of fact it's probably the opposite
19:52 jheathco ok
19:52 jheathco so i guess we can decrease blocksize
19:53 esotericnonsense a tiny portion of bitcoin 'owners' actually use bitcoin as it stands
19:53 jheathco and scale it more?
19:53 jheathco by that logic?
19:53 mlz jheathco, stop being a troll
19:53 esotericnonsense jheathco: very possibly, yes
19:53 jheathco mlz: so i'm a troll because i question your narrative?
19:54 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
19:54 jheathco this is one of the major problems with the community
19:54 mlz no, by you going around your "blocksize blahbla" narrative
19:54 jheathco mlz: then ignore me
19:54 esotericnonsense jheathco: it's mostly that there's a distinction between using bitcoin and 'owning' bitcoin, for lack of better terminology
19:54 esotericnonsense barely anyone actually takes part in the network as it stands
19:55 jheathco i agree
19:55 esotericnonsense increasing the block size substantially (sure, go and make it 2x or whatever, don't care) would make that worse
19:55 jheathco but we want to see that happen (which is one of the major hopes for lightning - retail payments, etc.)
19:55 jheathco i agree
19:55 jheathco i'm not arguing for 1gb blocks like some due
19:55 jheathco do*
19:55 esotericnonsense the point is that LN (or a system like it) is not a broadcast network
19:56 esotericnonsense with the current amount of computational power the average person has, that's the only way to do it
19:56 jheathco yes
19:56 jheathco which is great
19:56 jheathco agree
19:56 jheathco i think the issue is we've become so polarized... it's either tiny blocks with lightning, or massive blocks and no l2
19:57 jheathco why not safely increase block size and use l2?
19:57 esotericnonsense that is almost certainly going to happen
19:57 esotericnonsense it's just that right now it's pretty much a pure bikeshed issue
19:57 jheathco that's unfortunate, but i hope you're right that it will happen (sooner than later)
19:57 instagibbs jheathco, was already increased once, users arent even using the new space yet
19:58 esotericnonsense obviously this is my view, but tx fees on the bitcoin network being 'high' is basically irrelevant right now
19:58 jheathco instagibbs: they're using it whenever they can. that's very misleading for you to say
19:58 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
19:59 esotericnonsense so erring on the side of lower throughput / more bitcoin users/verifiers seems sensible to me given that
19:59 jheathco esotericnonsense: i agree, however a year or two ago i *was* buying some things with bitcoin
19:59 jheathco i wouldn't now, and i agree that those use cases should be moved to l2
19:59 esotericnonsense the past few years was like an accident
19:59 esotericnonsense or a dream world or something
19:59 esotericnonsense it's like thinking about a time when you could drive cars about in central london with no traffic
20:00 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
20:00 jheathco sure, but bitcoin worked *better* back then ;)
20:00 esotericnonsense right, it worked better with fewer people
20:00 jheathco it's like having horseback now and dreaming of a time when we used cars
20:00 esotericnonsense i don't think that's the case, it's purely congestion
20:00 esotericnonsense just like dreaming of a time when fewer people owned cars
20:00 jheathco yep
20:01 esotericnonsense 10-20 years ago in the UK there was a lot less traffic and it was better (for those that owned cars)
20:01 jheathco well, playing devils advocate... let's imagine the blocksize was set at 50kb back when satoshi set the limit
20:01 esotericnonsense but it only ever worked as an elitist thing
20:01 esotericnonsense and i'd argue it still does
20:01 jheathco do you think we'd be here now arguing to keep it at 50kb?
20:01 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
20:01 jheathco and that increasing it is not a way (one way) to scale bitcoin?
20:02 Sentineo you want to solve an exponential problem with linear fix
20:02 Sentineo does not sound right, block size alone is for sure not enough
20:02 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
20:02 esotericnonsense jheathco: i think that increasing the block size as a HF should come with other HF fixes
20:02 jheathco sentineo: nope, otherwise i'd be arguing against lightning
20:03 jheathco esotericnonsense: agree - so let's push for all of that
20:03 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
20:03 esotericnonsense i dunno. it's like i have a 20 year old civic and i'm buying a tesla next year
20:03 esotericnonsense and i'm arguing with the wife about whether to rice it and put spoilers on it and shit
20:03 esotericnonsense it's just, i don't care
20:04 mlz how did pushing 2X work out for you and garzik, jheathco?
20:04 jheathco mlz: why are you asking irrelevant questions that you already have an answer to, mlz?
20:04 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
20:04 esotericnonsense it's a necessary part of the evolution of the system if we want to protect the coin cap
20:04 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
20:04 mlz jheathco, it's irrelevant because you can't deny it's stupid to push for a HF
20:05 jheathco mlz, hopefully you scream at the core devs that were suggesting for hard forked block size increases then a year or so ago?
20:07 jheathco there will have to be hfs in the future if bitcoin is to survive, and there is nothing wrong with that
20:07 adiabat "There are levels of survival we are prepared to accept." :)
20:07 mlz jheathco, huh?
20:08 mlz jheathco, sure there might be necessary hf's in the future but i don't see you aim for that
20:08 jheathco ok, have to go work - enjoyed the chat
20:09 jheathco later all
21:53 MrBar this info outdated?
21:54 MrBar 100 byte hard limit on coinbase tx?
21:55 arubi it's not "coinbase tx"
21:55 arubi it's "coinbase"
21:56 arubi it's the data where an input script will usually be
21:56 arubi so, where currently there's block height
22:05 MrBar input script?
22:05 arubi what's the question exactly?
22:06 arubi there's a script present in each input in a transaction, usually has signatures and pubkeys in it
22:06 MrBar when i get getrawtransaction with coinbase tx id it 201 bytes
22:06 arubi well, "coinbase" is just a part of that transaction
22:07 arubi the term "coinbase tx" is confusing
22:07 MrBar How to build coinbase transaction
22:07 MrBar head from doc
22:07 arubi in what sense?
22:08 MrBar question exactly abut coinbase tx
22:10 MrBar if coinbase data does not overflow the 100 bytes what the rest of tx?
22:10 arubi what you'd usually find in a transaction outputs, version, locktime, amounts..
22:11 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
22:12 MrBar hm
22:13 MrBar coinbase tx = coinbase data + outputs
22:13 MrBar right?
22:14 arubi there's more to it that + outputs. it's a transaction
22:14 arubi s/that/than/
22:15 MrBar outputs+tx_witnesses+lock_time
22:15 MrBar ?
22:15 arubi what's the actual question?
22:17 MrBar now clear, tnx
22:25 MrBar sometimes show in coinbase tx "Unparsed address [0] 0 BTC" as second output, this is site code problem? incompatibles with protocol?