< jtimon>
btw, iirc libbitcoin implemented bip90 as an option despite the complains
< jtimon>
I don't think the option is very interesting (since the result will always be the same unless very bad things happen, just to further note is not bitcoin core specific)
< michagogo>
Hm, does anyone have any idea why my gitian build is crashing?
< MarcoFalke>
Just noting that the 0.16 gh branch is not "protecte" like the other branches...
< MarcoFalke>
s/protecte/protected/
< achow101>
Uhh, so it seems like sendtoaddress can sometimes make an invalid/non-standard transaction.. Or maybe my coin selection code somehow messes with that
< achow101>
I'm very confused now
< gmaxwell>
invalid in what way?!?!?!?!???!??!?!?!?
< achow101>
64: non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation)
< achow101>
that's the error I get when I try to sendrawtransaction with it
< achow101>
basically what I was doing was sendtoaddress, then gettransaction, then sendrawtransaction the hex
< achow101>
and then that error happened
< achow101>
so AFAICT that error means that the signature is being produced incorrectly
< arubi>
so there is a signature in the script \ witness at all? are you signing something malformed?
< achow101>
There's a signature
< achow101>
the transaction _looks_ right, besides the fact that I can't mentally verify signatures
< arubi>
signrawtransaction along with the utxo in json should give a more verbose error about what's wrong
< arubi>
unless it's really all it is and the signature is invalid for the tx.. that's pretty scary
< achow101>
hmm. It looks like there's a signature hash mis-calculation
< achow101>
the signer signed one sighash but a different sighash was calculated when verifying before the send
< achow101>
I've only observed this on segwit, so I think this may actually be a blocker for 0.16
< arubi>
can you tell which of the hashes is the correct one?
< arubi>
achow101, can you paste the payment to this tx please?
< achow101>
what do you mean "payment to"?
< achow101>
Like the input txs?
< kallewoof>
I'd like to see the raw tx hex as well
< arubi>
right, to know the amounts
< kallewoof>
oops it's there nvm
< arubi>
the raw hex for the spend is in the issue, but I wanna see what the sighash is supposed to be
< arubi>
oh it does show the amount for the failed one nValue=4.68120500 , probably stopped because it's the first one
< arubi>
ah no it's the output
< achow101>
there's a lot of inputs...
< achow101>
I can drop the wallet file instead and you can go find the transactions yourself
< arubi>
sounds good
< achow101>
updated the issue
< arubi>
cheers
< kallewoof>
newbie question but how would you dump the wallet info from that? :]
< arubi>
I'm getting ba89d6d01bdfd4b611757e38802c5a09255659ae7d2d42ae3f0729e7f261de1f as sighash for the first input..
< arubi>
(not 0.16)
< arubi>
kallewoof, you can 'gettransaction' for the txids in the inputs to the one posted
< arubi>
pretty much only need the amounts from there
< kallewoof>
Oh.. I tried listunspent but it was empty. Thanks
< kallewoof>
I'm getting Invalid or non-wallet transaction id. I'm just starting a regtest instance with -datadir set to one containing that wallet.dat file, though.
< achow101>
You have to use 0.16 or mater
< achow101>
*master
< achow101>
arubi: that's what the verifier got. it's just byteswapped
< kallewoof>
This is master.. (well, as of jan 24)
< arubi>
ah!
< achow101>
usual byteswap stuff
< achow101>
kallewoof: really? It should be in the wallet
< achow101>
use decoderawtransaction on the tx hex and then fetch the input tx with gettransaction
< arubi>
I'm running this on pre-0.16 on regtest too
< kallewoof>
dumpwallet gave me a ton of stuff, but yeah. I did decoderaw and tried to gettx the first input (cf0996c1b356bf7df7ef81d65c6741d5db6058826be47842ab45e18afd36dd03)
< arubi>
should work. sure you're using gettransaction and not getrawtransaction?
< achow101>
arubi: if you're using a version of master after september or som ething it should be fine
< kallewoof>
Yes, I'm using gettransaction.
< achow101>
strange
< arubi>
I'm using jl2012's latest bip114 client (vault branch)
< arubi>
ah, it's from september
< cfields>
achow101: regtest?
< achow101>
cfields: yes. from the test framework (which is what my simulator does)
< achow101>
s/does/uses
< cfields>
achow101: we'll need your chain data :)
< achow101>
oh, duh
< achow101>
cfields: updated in the issue
< kallewoof>
Doh. I put wallet.dat in datadir/ not datadir/regtest/wallets/. Works now.
< achow101>
oh shit. I fucked up my coin selection stuff
< achow101>
that's the problem, the amount is wrong
< arubi>
phew :)
< achow101>
I guess this is why I shouldn't suppress exceptions :/
< michagogo>
Dammit. The compiler just keeps segfaulting, somewhere else every time
< gmaxwell>
memtest86 time
< michagogo>
D:
< michagogo>
Hm, I wonder if shutting down the VM and starting it again might help
< michagogo>
gmaxwell: (on the physical machine, right? Or can running it in the VM also be relevant?)
< kallewoof>
michagogo: i get that if I don't bump the RAM of the VM. esp if i use -j with make.
< michagogo>
I thought about that
< michagogo>
Took it down from -j5 to -j3, and had htop open
< bitcoin-git>
[bitcoin] laanwj opened pull request #12308: contrib: Add support for out-of-tree builds in gen-manpages.sh (master...2018_01_genmanpages_outoftree) https://github.com/bitcoin/bitcoin/pull/12308
< michagogo>
Oh, good, it worked.
< michagogo>
Don’t know if it was rebooting the VM, updating vbox, rebooting the host, or some combination
< bitcoin-git>
[bitcoin] laanwj opened pull request #12309: doc: Explain how to update chainTxData in release process (master...2018_01_release_process_chaintxstats) https://github.com/bitcoin/bitcoin/pull/12309
< wumpus>
ah yes VMs, aren't they delightful, combining the flakyness of hardware with the labyrinthine complexity of software
< michagogo>
Uh, WTF? Build-windows.md has instructions that I’m pretty sure will completely hose any Xenial system
< michagogo>
Namely, adding the apt repo for a newer release
< wumpus>
unfortunately there is no way to cross-build to windows from xenial otherwise
< michagogo>
Maybe there’s a way to just get the new versions of the relevant packages, I don’t know
< wumpus>
the mingw-gcc in that ubuntu release is hosed. THere used to be a warning to simply not do that, but to some people that wasn't good enough...
< michagogo>
But those instructions will trash the system
< michagogo>
They tell you to apt-get upgrade. With the wrong repos.
< michagogo>
wumpus: yeah, I know about that issue
< wumpus>
maybe they'd rather break their system than simply admit something is not possible and use a different release
< michagogo>
Maybe
< michagogo>
But the problem is that we’re telling people to do that
< wumpus>
I mean it's windows users, they're doing this in a sandbox that can be nuked and re-instated with one button push
< michagogo>
With a little footnote saying “this might cause issues”
< wumpus>
also they're probably not doing anything else in these VMs than building bitcoin
< michagogo>
Rather than “this is guaranteed to completely break the system”
< wumpus>
anyhow, feel free to add proper warnings to the document, I've given up on that
< wumpus>
it's not that I didn't mention that in reviews but who listens to me, maybe they listen to you
< michagogo>
Is there a way to safely get just the newer compiler packages?
< michagogo>
Some ppa, backports, something like that?
< wumpus>
you could build your own toolchain, I'm partial to crosstool-ng myself as it comes with a nice menu configuration tool
< wumpus>
you need some patience but at least you can configure anything you'd ever wanted (and not wanted) to configure about the toolchain, and you're not bound to a certain version of binutils, gcc, libc, etc, that happens to come with your distro
< wumpus>
I use this for ARM boards all the time as ubuntu's default cross compilers only target a specific sw/hw combo, but i think it can do mingw-something as well.
< wumpus>
of course for a guide it's much easier to just say 'use ubunu 16.10 or higher', but I digress, that's what we already tried...
< wumpus>
at least we'll hopefully have 18.04 soon so there's a new LTS that can (hopefully) build working windows executables
< michagogo>
Yeah
< michagogo>
Btw, someone in #ubuntu pointed out that zesty is EOL...
< michagogo>
So even those instructions won’t work
< michagogo>
I wonder how much trouble it would be to get mingw backported
< anil_>
hello
< michagogo>
Hi.
< anil_1524>
What is the easiest way to install the Berkeley DB dependencies on Debian Stretch?
< wumpus>
contrib/install_db4.sh
< wumpus>
michagogo: just use 17.10 then...
< wumpus>
it will be EOL july 2018, but by that time you can upgrade to 18.04
< anil_1524>
wumpus: thanks
< wumpus>
I've heard of people here using the 18.04 pre-release dailies but that's really living on the edge
< bitcoin-git>
[bitcoin] practicalswift closed pull request #10975: [script] Return early if no valid opcodes found in CountWitnessSigOps(...) (master...return-early-in-CountWitnessSigOps) https://github.com/bitcoin/bitcoin/pull/10975
< provoostenator>
I'm one of those people living on the edge with 18.04 pre-release. I sometimes fall off the edge :-)
< provoostenator>
(in a VM, that I don't really need)
< wumpus>
well someone needs to do the testing :)
< provoostenator>
Oh and with production c-lightning :-)
< wumpus>
the danger of succesfully discouraging people from using pre-release software is that the released software will be less well-tested and thus increases risk for the rest.
< wumpus>
this is, FWIW, why I'm not super enthusiastic about #12300
< wumpus>
yes let's not get started about production c-lighting :)
< provoostenator>
That PR does seem a bit pedantic. Anyone who compiles from source should know what they're doing. But adding a flag isn't a show-stopper either.
< wumpus>
no, it's not, though having experience from having to type --with-incompatible-bdb 20 times a day (okay, overstating a bit) do we want another flag we always need :-)
< provoostenator>
What would be more useful for me is being able to have testnet=1 in bitcoin.conf and then launch with -mainnet, because I do make that mistake quite often on my dev account.
< wumpus>
I think the long-term idea is to have a -network=<bla> or -chain=<bla> instead of separate options for testnet, mainnet, regtest
< wumpus>
this resolves the case of conflicting options while specifying multiple
< provoostenator>
I also want to be able to configure them differently, I believe there's a PR for that, e.g. I don't care about pruning testnet.
< wumpus>
I mean if you specify -regtest -testnet -mainnet who is the code to know what you really want?
< provoostenator>
That should be an error. Generally commandline flags override options in a config file, right?
< wumpus>
it *is* an error
< wumpus>
(at least specifying -regtest and -testnet at the same time)
< provoostenator>
At least that's how -changetype behave now
< wumpus>
but with -chain=... you could use simple override and it would simply work without having to special case them
< provoostenator>
Yes, I agree -chain=testnet is more sensible than -testnet=1
< Sentineo>
+1 on that :) I remember I was confused the first time I saw it
< bitcoin-git>
bitcoin/master 7f968ae Wladimir J. van der Laan: doc: Explain how to update chainTxData in release process...
< bitcoin-git>
bitcoin/master 895fbd7 MarcoFalke: Merge #12309: doc: Explain how to update chainTxData in release process...
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #12309: doc: Explain how to update chainTxData in release process (master...2018_01_release_process_chaintxstats) https://github.com/bitcoin/bitcoin/pull/12309
< jamesob>
promag: but the fs namespace is used in that file?
< promag>
jamesob: it is, but it's an unnecessary change in your PR. I mean, there are tons of other "missing" includes I guess
< promag>
jamesob: if by any chance you have to amend, consider removing it
< jamesob>
promag: will do, thanks. If others have similar feelings I'm happy to - just hard to tell when to make small improvements. I figured since this is a fairly low-risk, small change that an addition like that couldn't hurt, but maybe I'm wrong about that.
< jamesob>
s/change/changeset
< promag>
jamesob: I know that feeling. Usually I do secondary changes "near" the primary changes. I avoid unrelated changes (even simple changes). Maybe submit them in other pulls..
< jamesob>
promag: just don't want to become the guy who opens PRs for #include changes (more than I already am ;)
< promag>
jamesob: right, just don't do it then :) unless you have to
< arubi>
seems that dumpwallet puts base58 addresses in the dump when the wallet is set to bech32 (getnewaddress returns bech32)
< DDDev>
Hi there, guys!
< DDDev>
Have you ever seen deleted transaction in the blockchain?
< DDDev>
For instance, you sent 10BTC and your transaction was unconfirmed for a long period of time. And after that the transaction became removed from the blockchain
< AndyS2>
It's not even on the blockchain if it is unconfirmed. It's just in the mempool to be potentially added. There's #bitcoin-dev for more general development questions, btw. This channel is more so for development of Bitcoin Core (an implementation of the protocol).
< DDDev>
Thank you, AndyS2
< provoostenator>
I just noticed this by chance: #12312
< gmaxwell>
If we want to reduce screw up risk we should make the github default branch a release branch; not boobytrap the prerelease software.
< gmaxwell>
for the original ask, a developer that doesn't want to mess up their own wallets, could be just as well addressed with a --disable-mainnet configure option that they could setup to normally use.
< gmaxwell>
achow101: so your belief is that for some input conditions the signer is producing an invalid signature?
< bitcoin-git>
[bitcoin] jnewbery opened pull request #12317: Document method for reviewers to verify chainTxData (master...verify_chainTxData) https://github.com/bitcoin/bitcoin/pull/12317
< cfields>
gmaxwell / jonasschnelli: I agree as well. If anything, I think that's kinda dangerous as downstreams can just quietly remove the ifdef, and users think they're shielded from mainnet
< cfields>
i can see the need for some kind of switch like that, but I'd rather do it in the appropriate place. ie If exposing the wallet to mainnet is scary, then add something there.