< jtimon> sdaftuar: oh, I had missed https://github.com/bitcoin/bitcoin/pull/11739 till today, good one
< 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
< bitcoin-git> [bitcoin] karibik opened pull request #12247: ZSnarks tech integration (master...HODLCoin0.11.3) https://github.com/bitcoin/bitcoin/pull/12247
< bitcoin-git> [bitcoin] fanquake closed pull request #12247: ZSnarks tech integration (master...HODLCoin0.11.3) https://github.com/bitcoin/bitcoin/pull/12247
< 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
< sipa> (the latter when txindex is enabled)
< Sentineo> ic
< promag> sipa: btw
< promag> if the creation fails or whatever then que key is returned to the pool
< promag> but LearnRelatedScripts will add other addresses to the wallet. Or am I wrong?
< sipa> LearnRelatedScripts never has any effect
< sipa> except for downgrading
< bitcoin-git> [bitcoin] ryanofsky opened pull request #12250: Make CKey::Load references const (master...pr/keyload) https://github.com/bitcoin/bitcoin/pull/12250
< 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
< gribble> https://github.com/bitcoin/bitcoin/issues/11739 | Enforce SCRIPT_VERIFY_P2SH and SCRIPT_VERIFY_WITNESS from genesis by sdaftuar · Pull Request #11739 · bitcoin/bitcoin · GitHub
< 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
< jojeyh> don't know what i did wrong