< vasild>
running with the same seed on the same corpus does not reproduce for some reason :/
< vasild>
is there a way to retrieve ./crash-0671aac15e619e99522e2119487eaa9cc97e5a34 from the CI machine?
< vasild>
when the fuzzer fails locally it prints the file name and also its contents in base64, but the CI log does not contain the base64 dump of the file, any idea why?
< bitcoin-git>
bitcoin/master 0a9129c Jon Atack: test: assert on the value of getblockchaininfo#time
< bitcoin-git>
bitcoin/master 78c3610 Jon Atack: test: assert on mediantime in getblockheader and getblockchaininfo
< bitcoin-git>
bitcoin/master d548dc7 Jon Atack: test: replace magic values by constants in rpc_blockchain.py
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #22520: test: improve rpc_blockchain.py tests and assert on time and mediantime (master...getblockchaininfo-time-tests) https://github.com/bitcoin/bitcoin/pull/22520
< bitcoin-git>
[bitcoin] jonatack opened pull request #22589: net, doc: update I2P hardcoded seeds and docs for 22.0 (master...i2p-seeds-and-doc-updates) https://github.com/bitcoin/bitcoin/pull/22589
< bitcoin-git>
bitcoin/master 84c8747 Sebastian Falbesoner: test: remove unneeded initialization code in feature_rbf.py
< bitcoin-git>
bitcoin/master a3f6397 Sebastian Falbesoner: test: feature_rbf.py: make MiniWallet instance available for all sub-tests...
< bitcoin-git>
bitcoin/master aa02c64 Sebastian Falbesoner: test: use MiniWallet for simple doublespend test in feature_rbf.py
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #22330: test: use MiniWallet for simple doublespend sub-test in feature_rbf.py (master...202106-test-feature_rbf_use_miniwallet_for_doublespend) https://github.com/bitcoin/bitcoin/pull/22330
< bitcoin-git>
[bitcoin] tylerchambers opened pull request #22590: Don't overwrite settings.json if it exists but can't be read. (master...fix-22571) https://github.com/bitcoin/bitcoin/pull/22590
< bitcoin-git>
[bitcoin] tylerchambers opened pull request #22591: Util: error if settings.json exists, but is unreadable. (master...fix-22571) https://github.com/bitcoin/bitcoin/pull/22591
< michaelfolkson>
Wallets in ecosystem would need to be able to send to P2TR (which hopefully they will)
< achow101>
no, 22364 just needs activation
< sipa>
no, that just enables the wallet to construct p2tr addresses
< sipa>
it won't create them unless asked to
< achow101>
22364 give the option for users to make p2tr addresses, but do not give them out by default
< sipa>
right now, you need to manually import a tr() descriptor before you can construct p2tr addresses
< S3RK>
I have a related question. What's the path to add tr descriptor to an exisitng wallet?
< sipa>
with 22364, such a tr() descriptor will be created by default
< achow101>
with 22364 should also need an option in the GUI which I think can be taken from 22260
< achow101>
S3RK: currently the only way is to use importdescriptors
< michaelfolkson>
Ohh ok. I thought that was making the default descriptor a Taproot descriptor. That is just allowing you to make a Taproot descriptor, gotcha
< achow101>
but I think we should add something (maybe to upgradewallet) that can generate a tr descriptor for the wallet
< S3RK>
achow101: yes, I was thinking the same
< S3RK>
manually constructing tr based on your existing master key is a bit tedious
< sipa>
michaelfolkson: there is no "default descriptor"
< sipa>
michaelfolkson: there is a default descriptor per address type
< sipa>
right now, no default bech32m descriptor is created, so no bech32m addresses can be requested
< sipa>
with 22364, a default bech32m descriptor will be created
< sipa>
(but there will also still be default bech32 and legacy descriptors)
< michaelfolkson>
Ok thanks
< michaelfolkson>
Then a question on Miniscript (that we discussed at the last wallet meeting)
< S3RK>
achow101: do you have any toughts on how a new command might work? we don't want a command just for the taproot, do we?
< michaelfolkson>
But I'll wait for above to finish
< achow101>
S3RK: I'm thinking maybe a new RPC for generating descriptors in general
< S3RK>
what's the input for it would look like?
< achow101>
generatedescriptor bech32m
< achow101>
?
< S3RK>
michaelfolkson: sorry for hijacking your quesitons
< prayank>
getnewdescriptor -tr ?
< michaelfolkson>
No it is fine, I'm not only one here :)
< achow101>
I think the argument would be the address type, and the descriptor generated depends on whatever the default for the address type we choose
< achow101>
this would change with future descriptors though
< achow101>
there's also some issues with sharing the same master private key as other descriptors (or rather lack of)
< sipa>
achow101: how would it know what key to use?
< S3RK>
good question
< achow101>
sipa: generate a new one?
< S3RK>
meh..
< S3RK>
now when I create new wallet don't I have one master key for all descriptors?
< sipa>
achow101: i'm mostly asking because i wonder if it could be extended later to help with a multisig workflow
< achow101>
S3RK: yes
< S3RK>
it's really nice to have one master key I think. I'd like to keep that
< achow101>
sipa: how would that work?
< sipa>
achow101: i don't really know...
< achow101>
S3RK: after a wallet is created, there isn't really a concept of "the wallet's master private key"
< achow101>
especially if people import things afterwards
< S3RK>
yeah, I understand. But I that was the promise of HD
< achow101>
the promise of descriptors is also that it doesn't matter
< achow101>
since the key is in the descriptor
< gene>
hi
< S3RK>
I kind of agree, but harder to backup and interropability is worse
< achow101>
S3RK: there could be a second argument that gives the address type to take the master privkey from
< sipa>
S3RK: well you need to backup either the wallet file, or the descriptors individually
< sipa>
just having the key is not enough in any case
< achow101>
e.g. "generatedescriptor bech32m bech32" would mean "make a descriptor that makes bech32m addresses using the master key from the current active external bech32 descriptor"
< sipa>
but with a different derivation path?
< achow101>
yes
< sipa>
how would it figure out what path to use?
< S3RK>
sipa: yes and there is also limited amount of derivations paths. I can just generate descriptors for all of them
< sipa>
S3RK: i really dislike that notion :)
< sipa>
especially if multisig becomes more common, with individual signers participating possibly in multiple multisigs, you can't just assume you can iterate over all possible derivation paths
< achow101>
sipa: I think it would just use the default derivation path. for tr that's in BIP 86
< S3RK>
yes, multisig makes everything more complicated
< sipa>
achow101: right, fair; perhaps it could check if that some other descriptor already uses that default derivation path
< achow101>
if we wanted to be more specific about which descriptor to take things from, we do have a descriptor id thing
< achow101>
but we might want to formalize descriptor ids before using them
< gene>
does the concept of domain separation apply to descriptors?
< S3RK>
gene: what do you mean by domain separation?
< gene>
having a specific prefix for derivation paths specific to the use-case
< achow101>
gene: the point of descriptors is that we can move away from doing that because the derivation paths are explicit in the descriptor
< S3RK>
there is a notion of an "account" in the derivation path. not sure if that's what you want
< gene>
not account, more like all tr addrs use m/45' where all normal use m/44'
< prayank>
Do we have any transaction on Testnet that has P2TR outputs? If someone tried and has transaction id, please share. I want to check few things in my node, different explorers.
< achow101>
sipa: we could also make the derivation path be overridden by the user
< michaelfolkson>
prayank: We do, I'll find you a link
< achow101>
gene: that exists already, see BIPs 44/49/84/86
< gene>
achow101: thanks +1
< S3RK>
sipa achow101: thanks for you ideas. we don't have to solve it now. Let's think about it and check back later
< achow101>
right, we still have time
< achow101>
michaelfolkson: you had somehing else?
< michaelfolkson>
Right on Miniscript...
< michaelfolkson>
I know nothing ever is final, final but is Miniscript considered "final" now. Time for a BIP etc?
< michaelfolkson>
There are still small changes being made every now and again
< michaelfolkson>
It seems gnarly getting these libraries into Core (Minisketch, Miniscript etc) when Core can change, the PR can change and the external library can change
< michaelfolkson>
Presumably the libsecp approach of keeping it as an external library rather than a subset of it being merged into Core isn't viable
< achow101>
looking briefly at rust-miniscript, it seems like changes aren't really being made to miniscript itself but rather to the specific implementation
< michaelfolkson>
And this would be final like Miniscript version 1, obviously Miniscript would change with Taproot etc
< sipa>
i don't tyink the current spec will change anymore
< achow101>
I think the same can be said of sipa's c++ miniscript implementation
< sipa>
but the c++ miniscript repo isn"t even up to date with that spec i think
< sipa>
of course more extensions can be added
< michaelfolkson>
There are a few issues and open PRs on sipa's C++ implementation
< michaelfolkson>
(I think... from memory)
< achow101>
sipa: is your website still the up to date spec?
< sipa>
there has been some.more activity recently, so i think we'll be able to make.progress there soonish
< sipa>
achow101: i don't remember
< sipa>
too swapped out...
< sipa>
(afk)
< prayank>
michaelfolkson: Thanks :) you can share here. I will check in logs if my IRC app disconnects.
< michaelfolkson>
James' Python implementation has been sitting there for a similar time so it would nice to get a "
< michaelfolkson>
"final" BIP spec
< achow101>
I can ask sanket or andytoshi if either of them would like to write a BIP
< michaelfolkson>
Happy to help (and not be named as a co-author on the BIP)
< michaelfolkson>
If needed
< achow101>
(I expect the only person who is actually fully up to date on all of the particulars is sanket)
< michaelfolkson>
Ok cool, that was my question having glanced over the open Miniscript PR earlier
< achow101>
anything else to discuss?
< S3RK>
I have one more small question
< michaelfolkson>
And ideally not 10 BIPs for Miniscript :)
< * michaelfolkson>
ducks
< S3RK>
how do we decide whether make listing private descriptors a separate RPC? #21500
< achow101>
I'll probably prototype some possible upgrade methods on monday
< gene>
thanks :3
< prayank>
gene: option to disable RPCs sounds interesting. Although I doubt many people would agree to add it.
< gene>
why?
< S3RK>
achow101: you mean adding tr descriptor to exsting wallet?
< achow101>
S3RK: yeah
< S3RK>
achow101: ping me if when you have something to share
< achow101>
sure
< gene>
my general impression of bitcoin devs is a high respect and concern for security. adding a feature that increases the ability of users to secure themselves seems like it fits
< achow101>
gene: I think there have been some ideas around multiple RPC users and permissions for those users
< michaelfolkson>
prayank: Just interested in testnet, not mainnet or signet? 0xB10C is the guru here
< achow101>
It would probably be better to do something related to that rather than disabling RPCs.
< achow101>
but generally our protection against unauthorized exports of wallet privkeys is to enable wallet encryption
< gene>
the separation of users is a good idea, too. accounts (user credentials) can be hacked, though. so, think that disabling the RPC as the ultimate way to secure against an attack on public node
< achow101>
oh, perhaps #12763 already implements some of this?