< kallewoof>
achow101: the approach given in the doc I linked is outdated, then? I could write/update docs, but I'm honestly stumped on how to approach this. E.g. I am supposed to give a signer, but I don't want to shuffle private GPG keys around to let the VM sign using a key it doesn't hold (I am guessing wildly here).
< esotericnonsense>
kallewoof: there's a section in gitian-building.md that references copying out the assert files?
< esotericnonsense>
(missed most of the conversation, just guessing here)
< kallewoof>
esotericnonsense: I don't think I saw that. Will look, thanks!
< esotericnonsense>
:) right at the bottom
< kallewoof>
Ahh, yeah, I missed that completely. Thanks
< kallewoof>
Reading the OP_RETURNTRUE discussion on bitcoin-dev it struck me that if we bump segwit script version at some point, old nodes will all accept the tx without looking, and new nodes will use the new script to verify. A miner running old version could mine txs with invalid scripts and old nodes would accept this block while new nodes would not. This would become a hardfork, no?
< kallewoof>
Wait, no, it would become a softfork. *headscratch*
< kallewoof>
I'm confused about Johnson Lau's statement "If we use a softfork to transform OP_RETURNTRUE into OP_17 (pushing the number 17 to the stack), new nodes will collect the (pubkey, message) pair and try to aggregate with other pairs. This becomes a hardfork.
< kallewoof>
"
< kallewoof>
Old nodes all accept, new nodes do more. It should be a softfork, no?
< luke-jr>
kallewoof: he's talking about after some hypothetical signature aggregation scheme
< luke-jr>
I'm not convinced it's a real blocker
< luke-jr>
just an additional consideration that needs to be made when such aggregation is introduced
< Guest81071>
can i get any useful ideas to implement to develop bitcoin
< Guest81071>
how can i develop or contribute to bitcoin
< vicenteH>
I use addwitnessaddress command to generate a segwit address. To save/restore in cold storage that segwit address should I dump private key from original address, then import that private key, get the original address and execute addwitnessaddress again?
< Guest81071>
what is the scope of devoloping the applications using bit coins
< Guest81071>
what applications can be developed
< meshcollider>
Guest81071: try asking in #bitcoin - this chat is only for discussion on bitcoin core development not general development
< meshcollider>
vicenteH: yeah I believe so, at least until proper segwit support in wallets is added in 0.15.1
< gribble>
https://github.com/bitcoin/bitcoin/issues/11366 | [rpc] Fix pruneheight help description in getblockchaininfo by esotericnonsense · Pull Request #11366 · bitcoin/bitcoin · GitHub
< jnewbery>
promag : just waiting for Travis to complete. There was a bad automatic rebase before. If Travis passes, then I'd definitely appreciate some review at this stage
< bitcoin-git>
[bitcoin] esotericnonsense closed pull request #11366: [rpc] Fix pruneheight help description in getblockchaininfo (master...2017-09-getblockchaininfo-docs) https://github.com/bitcoin/bitcoin/pull/11366
< esotericnonsense>
(put the changes in #11367 as it's pretty small).
< esotericnonsense>
sorry about the repeated pushes, should be done now, missed your style adjustment on while {} promag.
< BlueMatt>
https://github.com/bitcoin/bitcoin/issues/11373 should just be closed with "Your filesystem permissions have been set to prevent bitcoind from accessing its datadir, which prevents it from starting" (unless someone wants to change it to a "we need a better error message for this bug" issue)
< promag>
jnewbery: do you think there should be a PR to replace start+stop with restart_node? or you see an incremental change instead?
< bitcoin-git>
bitcoin/master fdc3293 practicalswift: Document assumptions that are being made to avoid NULL pointer dereferences
< bitcoin-git>
bitcoin/master 551d7bf Wladimir J. van der Laan: Merge #11132: Document assumptions that are being made to avoid NULL pointer dereferences...
< bitcoin-git>
[bitcoin] laanwj closed pull request #11132: Document assumptions that are being made to avoid NULL pointer dereferences (master...document-non-nullptr-assumptions) https://github.com/bitcoin/bitcoin/pull/11132
< ThomasV>
is it true that core will let users reuse the same private key in p2pkh, p2wpkh and p2wpkh-in-p2sh ?
< ThomasV>
sipa: ^
< chainhead>
if they use addwitnessaddress
< jl2012>
if it is compressed key, and with addwitnessaddress
< sipa>
ThomasV: for now, yes, we have no choice
< ThomasV>
no choice??
< sipa>
that's how addwitnessafdress already works
< ThomasV>
sipa: if you release that, you will have to keep supporting that forever
< sipa>
ThomasV: addwitnessaddress has existed since 0.13.0
< ThomasV>
because users will expect to see their coins when they import an address
< ThomasV>
do you plan to do something about that?
< sipa>
in a future version we plan to redesign the logoc for determining which addresses are ours, and have split chain for each type of address
< sipa>
and perhaps deprecate importprivkey in favor of importmulti (which requires passing all relevant information)
< aashu>
join
< sipa>
i agree it's a bad situation that we accept payments to addresses we didn't create, but it's a too invasive change to make in a minor release
< sipa>
it's an issue that has existed for a long time too (for example, core also accepts payments to pay to pubkeys for corresponding keys of addresses that were created)
< ThomasV>
well, p2pk is a bit different, because you do not create a bitcoin address for it
< ghost43>
so then if a user somehow exports a private key from Core, and tries to import that in another software, what should that other software do with it? try to convert that to all types of outputs?
< ThomasV>
ghost43: that's what I want to avoid
< ThomasV>
that would encourage key reuse
< sipa>
internally, the ismine logic basically decides what is our based on the ability to sign... which is a mistake, but rewriting that code replacing it with something sane will take time
< sipa>
ThomasV: i understand
< sipa>
ghost43: i don't think you should associate any type of output with a key... a key is just a key and not an address
< sipa>
but that's not how things work now
< ThomasV>
sipa: a key is just a key, but the serialization of a key is not just a key
< ThomasV>
it has a byte that disambiguates compressed/uncompressed
< ThomasV>
and that's a good thing
< ThomasV>
we really need to extend that
< sipa>
i disagree
< goatpig>
maybe it's time to agree on a set of identifiers for common script types
< sipa>
if you want to import an address, give the address; if you want to spend from it, give its associated key
< sipa>
i think it's unmaintainable to keep implying the address from just the key
< goatpig>
not as a requirement, but just allow those wallets who want to to forward that information in a standardized fashion?
< sipa>
give the address + privkey?
< sipa>
importing addresses doesn't sound like something a normal user would do frequently
< goatpig>
no they usually import the privkey
< ghost43>
give the full scriptPubKey + the private key, haha
< goatpig>
expect the software they using it with to know which scripts to look for on chain
< goatpig>
cant tell if this is just pebkac and should be ignored, or if there is a need to cover this case
< goatpig>
but it exists alright
< sipa>
i expect the same issue does exist at least for importing hd chains, though
< goatpig>
now it does
< goatpig>
before, not necessarely
< ThomasV>
sipa: that's interesting. why dont you post that in the ML?
< goatpig>
if you stick to BIP44, p2pkh is basically implied
< sipa>
ghost43: right
< sipa>
ThomasV: i hate the ml
< ThomasV>
goatpig: please no bip44
< goatpig>
ThomasV: is that a voldermort moment?
< ThomasV>
sipa: if you hate it, why did you answer to my post?
< sipa>
i felt i had to
< ThomasV>
yeah, but you kept the real annsyer until now
< sipa>
hmm?
< sipa>
you're asking my opinion
< ThomasV>
I asked what core plans to do regarding key imports
< ThomasV>
goatpig: I guess you know what I think of bip44
< goatpig>
oh i do
< goatpig>
i agree with your position on the WIF thing
< goatpig>
extending it would help
< goatpig>
otherwise, id fall back on Lombrozo's BIP124 and flesh that out?
< ThomasV>
goatpig: bip124 is not really specified
< goatpig>
therefor it wont be as resistant to proposals
< ThomasV>
goatpig: I am interested in it too
< goatpig>
i mean the WIF is for single keys
< goatpig>
but at least if we can agree on some stuff for entire chains
< ThomasV>
well, if we had a decent bip124 we could use it for single keys too
< sipa>
ThomasV: thanks for bringing it up. thinking more about it, i think my main issue is that we should start thinking about addresses and keys as orthogonal things (there are some things you consider yours - addresses, and then some things you know how to sign for - keys)... especially with things like hardware wallets, multisig
< sipa>
however, that doesn't mean there can't be a format that encapsulates both
< sipa>
i'll respond on the list
< ThomasV>
well, what is the point of having a serialization format, if it is not to encapsulate ?
< sipa>
ThomasV: well there can be separate formats, i guess
< ThomasV>
sipa: electrum has orthogonal classes for wallets and keystores. a wallet is defined by the type of output script, regardless of how keys are stored
< sipa>
right, sounds great
< ThomasV>
so we can use hardware or software keystores in multisig wallets, with the same wallet class
< ThomasV>
but I believe that what we export and show to users should be encapsulated
< sipa>
right, but you also need a way to export/import a chain or address without revealing the key
< sipa>
for an address that's easy, as it's just an address
< sipa>
though i saw there was talk of including a birthtime too
< ThomasV>
a wallet cannot import an address unless it is a special wallet type
< sipa>
sure
< sipa>
but i'm sure some software will exist that can import arbitrary individual addresses
< goatpig>
and that's fine
< ThomasV>
electrum can do it. my point is that wallet class does not have a keystore
< ThomasV>
there is a wallet class that just means "a set of imported addresses"
< goatpig>
the issue would be importing a private key and failing to find all funds that key can sign for
< sipa>
goatpig: i think it's a terrible idea to treat every output you can sign for as your own
< ThomasV>
there also is a keystore class for imported private keys, but it has nothing to do with imported addresses, and it assumes p2pkh
< andytoshi>
goatpig: taken literally that leads to trivial attacks (e.g. you can sign for a 1-of-2 multisig with me, but that output isn't yours and if you have one you can't consider it as a final payment)
< sipa>
ThomasV: my point is that we should really think about importing something as either an address/chain (something to look for) or as private key (something to sign with) - there can be a convenience method to encode both simultaneously
< sipa>
and i'm not opposed to such a convenience, but i don't have many opinions on it
< goatpig>
sipa: andytoshi: the idea is not for me to support all of these possible script variations, it's to able to tell my user: "my software does not support all of tehse variations, do not use to import from this key"
< ThomasV>
sipa: current wallets allow to import private keys, and they assume p2pkh
< ThomasV>
it is difficult to undo that
< sipa>
ThomasV: we don't need to continue that practice
< sipa>
have a new private key format that does not have any implied address
< ThomasV>
sipa: stop supporting privkey imports in core, and see how users will react :D
< sipa>
ThomasV: i'm not saying we should stop supporting imports
< ThomasV>
sipa: ok, I read you
< sipa>
but the modern way of doing it is using importmulti, where you just give both the address and the private key
< sipa>
(and the import checks that that private indeed can sign for that address)
< sipa>
and if it's P2SH it also requires giving the relevant redeemscript
< goatpig>
sipa: that could turn into a GUI nightmare, just saying
< sipa>
goatpig: perhaps
< goatpig>
well between expecting that much info from the user
< goatpig>
or agreeing to a header byte that refer to a table telling you how to derive the script hash
< goatpig>
obviously i'd pick the easy way out
< sipa>
as said, i'm not opposed to a convenience method to encode all of it
< ThomasV>
sipa: what do you think of bip124?
< goatpig>
i believe that's what we're hinting towards
< sipa>
ThomasV: i haven't looked at it
< goatpig>
it's a bit lean atm
< ThomasV>
goatpig: all it needs is a way to extend script with variables
< sipa>
so for example an issue i see is CLTV/CSV
< sipa>
i expect people at some point will want a standard way of using these in scripts]
< sipa>
an "address import" for one of those will need to include the locktime/sequence requirement number, or you can't derive the scriptPubKey
< ThomasV>
right
< sipa>
an approach that just requires you to pass the full scriptPubKey you're looking for is an elegant, but not perfectly convenient, method
< sipa>
but as a 'raw' export/import function, i think that's totally acceptable
< goatpig>
for cltv you could imply the position on the address chain is the cltv member
< goatpig>
for csv idk if you can sneak around like that
< sipa>
yuck.
< goatpig>
aww
< sipa>
cltv can have a locktime in seconds
< goatpig>
i was thinking on the block count after confirmation variant only
< ThomasV>
sipa: you mean the full script, not its hash?
< goatpig>
sipa: you have to think of backups as well as imports in the case of cltv/csv
< sipa>
ThomasV: yes, that's what importmulti requires
< goatpig>
the least user inputed data, the better
< sipa>
goatpig: well at least everything expect the private keys is much less sensitive
< sipa>
but yes, you're right, that's an issue
< adiabat>
it may also make sense to standardize on an importable utxo format, with optional privatekey field
< adiabat>
I use this in my lightning software between wallet / lightning layer
< adiabat>
could enable imports without rescanning or anything
< ThomasV>
sipa: ok, so Iguess the issue is to find a good serialization for what importmulti needs
< sipa>
ThomasV: for a subset, at least...
< sipa>
unfortunately the checksum properties in bech32 degrade when there are more than 89 characters
< sipa>
ThomasV: did you see my comment on your only-v0-witness commit?
< goatpig>
use several lines, have a counter in each line
< ThomasV>
sipa: yes I saw it
< sipa>
goatpig: yuck :)
< goatpig>
so mean!
< ThomasV>
sipa: but soft forks are not so common, so I have time to think about it :)
< sipa>
ThomasV: depends on how fast your users upgrafe
< ThomasV>
yeah
< sipa>
we saw with p2sh that it took years before every wallet was able to send to it
< sipa>
i expect that for bip173 it will be less time, but i'd rather ot have that delay for every softfork
< ThomasV>
I understand
< ThomasV>
will do
< sipa>
thanks!
< ThomasV>
ok, dinner time
< sipa>
ok, lunch time
< gmaxwell>
adiabat: have you seen achow's psbt format? not what you're suggesting but its relevant. It could perhaps incorporate what you're thinking by gaining extra fields to carry around the private key for an input.
< adiabat>
gmaxwell: saw the post; looks interesting and not quite what I have, but something similar
< adiabat>
github link in that doesn't seem to work though
< adiabat>
(link from the mailing list post I mean)
< tknp>
i might be missing something simple but is there a single rpc call to display the btc value of the items in a vin array using 'getblock'
< sipa>
no
< sipa>
bitcoind doesn't have that information
< tknp>
ok thanks. i'll do some more reading. the value i'm after does look to be in the output of gettxout of the txid of the vin in question
< goatpig>
outpoint value?
< tknp>
oh sorry, i don't mean the monetary value of btc but the 'value' key that relates to the number of bitcoins paid for the output
< goatpig>
yeah, you want the value of the outpoint the txin is pointing at
< goatpig>
i dont think the RPC let's you request outpoints at all
< goatpig>
well i guess the proper term is resolving the outpoint
< tknp>
goatpid correct. was hoping to not have to make a secondary rpc call for each tx input with the proper vout value
< goatpig>
that resolution is expensive, you cant expect a call to get a tx would just go ahead and resolve the outpoints on the off chance the caller might want it
< tknp>
yup, was hoping that there was a convenience method cooked in with the understanding that it was expensive to call. like a hidden valid value for the format param that would do the resolving
< goatpig>
im just guessing here
< goatpig>
but i expect core has the dataset necessary to resolve arbitrary outpoints
< goatpig>
or maybe not
< goatpig>
that's just a guess on my part
< gmaxwell>
Bitcoind doesn't have the information.
< goatpig>
you need to resolve outpoints to verify incoming zero conf tx
< gmaxwell>
Providing it would require an additional quite expensive index, or a sequential scan of the blockchain.
< sipa>
it only has the information about unspent outputs
< gmaxwell>
goatpig: yes but he is asking about getblock.
< goatpig>
but you could do that by just maintaining the utxo set and checking outpoints in zc vs that
< sipa>
which is sufficient for validating new blocks
< goatpig>
well then he should use armory =D
< goatpig>
cause it has a supernode teehee
< gmaxwell>
and was unusably slow and will be again eventually. :P
< goatpig>
=( so mean
< gmaxwell>
haha
< goatpig>
man it;s hard to keep up, i wrote the first supernode in 2013, blockchain is like 7 times as large now
< gmaxwell>
Sorry. Just the point there is that it's not provided not because bitcoind is lazy or something, but because it has a real non-trivial cost.
< goatpig>
yes, just maintaining the dataset to resolve arbirtary tx hashes is expensive
< tknp>
understood and thanks. i'll deal with making separate requests through other means
< achow101>
gmaxwell: isn't txindex like that
< achow101>
an index that can be used to grab arbitrary outpoints
< sipa>
achow101: very inefficiently, yes
< gmaxwell>
does it still even work? :( I stopped using it on all my hosts because its such a slowdown.
< sipa>
(it read the entire block for each output you're looking up)
< achow101>
gmaxwell: I use it on my node, seems to work
< achow101>
but the index itself is 12 GB apparently
< achow101>
syncing a new node with txindex is probably a massive slowdown, but I have had it enabled for several years now so when I synced it wasn't that bad
< adiabat>
I run txindex on mainnet and testnet3, it doesn't slow it down too much
< adiabat>
then again I'm running on spinning disks so it's pretty slow no matter what :P
< Sentineo>
I run txindex on an odroid xu4
< Sentineo>
works fine too, usb stick has the blockchain
< Sentineo>
syncing is a pain in the b, but otherwise kt is fine
< bitcoin-git>
[bitcoin] tomasvdw opened pull request #11376: Ensure backupwallet fails when attempting to backup to source file (master...core) https://github.com/bitcoin/bitcoin/pull/11376