< bitcoin-git>
[bitcoin] luke-jr opened pull request #12246: Bugfix: Only run bitcoin-tx tests when bitcoin-tx is enabled (master...separate_utils) https://github.com/bitcoin/bitcoin/pull/12246
< instagibbs>
is there any particular reason the genesis block transaction isnt included in txindex?
< meshcollider>
instagibbs: same reason it's not spendable I guess
< instagibbs>
txindex isn't consensus, but I could see the reason being "because no one would ever bother trying to spend it"
< instagibbs>
just was surprised that joe schmoe can't use bitcoind to inspect it
< meshcollider>
Yeah I just mean in terms of code, there's no reason I can see why we shouldn't add it
< meshcollider>
It'd make sense to add it I think
< sipa>
instagibbs: well from a consensus point of view the genesis block isn't really a normal block
< sipa>
it's just there as a given starting point
< sipa>
it could be removed from bitcoind entirely, and just treat its hash in a prevblock as an indication "this is the first block"
< Sentineo>
one can not fetch the first coinbase tx from RPC then and show it the people - here is the january 3 message ... :)
< Sentineo>
which is kind of a question I get a lot - why doesn;t it work
< instagibbs>
sipa, ehhhhh it'd be just as easy to remove it from txindex in that case :)
< instagibbs>
anyways, not a big deal, just surprised me
< sipa>
instagibbs: my point is that it shouldn't be in the txindex, because for all intents and purposes, that transaction doesn't exist
< sipa>
it's just some arbitrary data the genesis block happens to be filled with
< sipa>
the system would work equally well if it wasn't even a valid transaction
< instagibbs>
disagree, but that's enough NACK to leave it as a simple observation than a PR
< sipa>
instagibbs: maybe there is a bit more historical context here
< sipa>
before 0.8, there was no chainstate - the whole utxo set was defined by the txindex, and the txindex was all there was
< sipa>
no version of bitcoin ever added the genesis block to the txindex, which is the reason why the genesis coinbase output is unspendable
< instagibbs>
ah, yes that is more motivated
< sipa>
in 0.8, the consensus relevance of the txindex was moved to the chainstate
< BW^->
sipa: ah, so those first 1 million BTC minted by Satoshi, are unspendable?
< sipa>
but as the genesis coinbase tx (intentionally or not) had never been part of the txindex, there isn't really a reason to change it
< sipa>
BW^-: no, the first 50
< sipa>
instagibbs: it's been brought up so many times on SE that i wonder if gettransaction should special case it and return some special error or so :)
< instagibbs>
hah
< instagibbs>
answer: yes
< BW^->
sipa: the first 50 blocks
< BW^->
?
< sipa>
BW^-: no, we're only talking about the genesis block, which has an "output" of 50 BTC - those 50 BTC are not spendable
< BW^->
ah.
< Sentineo>
ah I always wondered why it is unspendable :) ty sipa !
< Sentineo>
I beleive chainstate was created to make the utxo set more compact and maybe efficient (lookup wise)
< Sentineo>
is it a correct assumption sipa ?
< sipa>
yes
< sipa>
the txindex was 2 GB by the time the chainstate was 70 MB
< sipa>
now the chainstate is 2 GB, i don't want to know how large the txindex would have been :)
< Sentineo>
well my index folder with txindex=1 is 15G :)
< sipa>
yes, but the post-0.8 txindex is much smaller than the one in pre-0.8 times
< Sentineo>
my chainstate is 3.4G ... is it cause txindex is on?
< Sentineo>
ah ok, so it would have been even bigger
< sipa>
as it doesn't need to serve the function of UTXO set anymore
< sipa>
in particular, the pre-0.8 txindex had information about all spent inputs; now we only keep information per block or per tx
< jnewbery>
v0.16.0 contains a change to P2SH activation, so we activate based on height rather than block time (a similar change to BIP 90 buried deployment). I have a very short BIP written up to describe the change. Do people think it's worth publishing as a BIP?
< sdaftuar>
see also #11739 -- if we merge that then perhaps this is moot
< instagibbs>
i think BIPs are a good idea if we're changing consensus rules
< Chris_Stewart_5>
jnewbery: Do you think this will be re-usable for other soft forks or is p2sh unique in the regard the activation was done by block time
< MarcoFalke>
The motivation for the consensus change was to make (test) code look cleaner. Since we have 11739 upcoming, that temporary more clean code is no longer a valid motivation for a change on the consensus level, as it comes with documentation burden of e.g. creating a bip.
< jnewbery>
in some ways it's not a consensus change, since it's below the last checkpoint
< jnewbery>
Chris_Stewart_5: I can imagine we may want to bury the CSV deployment at some point
< jnewbery>
11739 would remove segwit bip9 activation
< Chris_Stewart_5>
jnewbery: I say publish it -- especially if it could apply to other soft forks
< MarcoFalke>
Chris_Stewart_5: Can you elaborate? If the BIP is published, it couldn't be applied to other soft forks
< MarcoFalke>
You can't really change BIPs retroactively
< Chris_Stewart_5>
MarcoFalke: I was thinking about it the way that BIP9 provides process for deploying soft forks -- not a *specific* soft fork
< Chris_Stewart_5>
I.e. you could use this process to bury CSV deployment alogn with p2sh if i understand what it does correctly...
< Chris_Stewart_5>
but perhaps this is too narrow.. idk
< MarcoFalke>
I see
< MarcoFalke>
If I am not mistaken, p2sh deployment is the only time based soft fork that "is left". So it wouldn't apply to others...
< Chris_Stewart_5>
either way, i think posting it to the dev mailing list at least isn't a bad
< Chris_Stewart_5>
bad idea
< MarcoFalke>
Agree, text itself looks fine to me, but I will stick to -0
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #12251: initwallet: Do not translate highly technical addresstype help (master...Mf1801-walletNoTranslateInitHelp) https://github.com/bitcoin/bitcoin/pull/12251
< bitcoin-git>
[bitcoin] ajtowns opened pull request #12252: Require all tests to follow naming convention (master...rename_tests_no_leeway) https://github.com/bitcoin/bitcoin/pull/12252
< jtimon>
sdaftuar: perhaps mention in your bip that this is similar to the way bip30 was activated ?
< cncr04s>
how do I setup LN on mainnet?
< cncr04s>
I run mining/pool/deposit services. I would like to try to test it out
< achow101>
cncr04s: not here, try asking in #lightning-dev
< cncr04s>
thanks
< jojeyh>
hey trying to setup private regtest chain locally. running the command 'bitcoind -regtest -daemon' outputs usual phrase 'Bitcoin server starting.." but 'ps aux' returns no process running it
< jojeyh>
nvm guess it was because i was also running testnet too, but this shouldn't be a problem right?
< jojeyh>
i shutdown testnet and regtest worked
< jojeyh>
nvm now i can run testnet and regtest at same time