<rodarmor>
I wrote a script to build an mdbook from the markdown docs in bitcoin/bitcoin. It's a bit of a mess, and uses Rust to generate the docs, so it's not really fit to merge in its current state, but it's pretty nice.
Guyver2 has left #bitcoin-core-dev [Closing Window]
gf2718 has quit [Ping timeout: 272 seconds]
gf2718 has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 260 seconds]
S3RK has joined #bitcoin-core-dev
S3RK_ has quit [Ping timeout: 252 seconds]
Guest28 has joined #bitcoin-core-dev
Guest28 has quit [Client Quit]
maflcko has quit [Ping timeout: 245 seconds]
maflcko has joined #bitcoin-core-dev
Artea has joined #bitcoin-core-dev
gf2718 has quit [Ping timeout: 246 seconds]
gf2718 has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 252 seconds]
gf2718 has quit [Ping timeout: 252 seconds]
gf2718 has joined #bitcoin-core-dev
gf2718 has quit [Ping timeout: 272 seconds]
gf2718 has joined #bitcoin-core-dev
Guest91 has joined #bitcoin-core-dev
jespada has quit [Read error: Connection reset by peer]
jespada has joined #bitcoin-core-dev
TheRec has quit []
jespada has quit [Ping timeout: 248 seconds]
gf2718 has quit [Ping timeout: 276 seconds]
jespada has joined #bitcoin-core-dev
TheRec has joined #bitcoin-core-dev
gf2718 has joined #bitcoin-core-dev
gf2718 has quit [Ping timeout: 252 seconds]
gf2718 has joined #bitcoin-core-dev
gf2718 has quit [Ping timeout: 260 seconds]
gf2718 has joined #bitcoin-core-dev
gf2718 has quit [Ping timeout: 260 seconds]
gf2718 has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
gf2718 has quit [Ping timeout: 252 seconds]
<jamesob15>
This has two pretty well qualified ACKs and a number of concept ACKs. Is there anything else I can do to get some maintainer consideration on this? #30708
<sipa>
jamesob15: i like the change, but is there really no way i can convince you to drop the "spend-from address" part?
<instagibbs>
im reviewing now btw.... thanks for the reminder
ghost43 has joined #bitcoin-core-dev
ghost43_ has quit [Remote host closed the connection]
Guest91 has quit [Quit: Client closed]
<kevkevin>
taking a look at the PR as well rn, might need to finish up reviewing later today
flooded has joined #bitcoin-core-dev
<jamesob15>
sipa: I'd really like it in there as an end user for this wallet thing I'm writing. I want to understand your concern - is there something above and beyond "this is just inconsistent with RPCs never having attempted to infer an address for spend coins before"?
<jamesob15>
*spent
<sipa>
jamesob15: yes
<sipa>
jamesob15: there are two models of looking at the ledger that are common. the "wallet" model, where addresses are entry points into a wallet, but don't hold a balance of their own; it's the wallet that holds a balance in aggregate by having control of a number of coins. You can't "spend from" an address at all, because that is not where coins are held.
<sipa>
the other is the "explorer" model, where addresses hold a balance of their own, and transactions have to-address and from-addresses, which increment and decrement that balance
<sipa>
both of these models are wrong (addresses don't exist at all at the protocol level), but some models are useful
<sipa>
i'm strongly of the opinion that the "explorer" model is harmful
<instagibbs>
fwiw any library can do spk->address formatting, so downstream wallets can trivially support whatever they want here
<jamesob15>
sipa: I think there's a simple counterexample use. Let's say for the sake of convenience, I want to withdrawal coins from different exchanges and have them bucketed somehow by exchange. I generate an address that I use for river, one for cashapp, ... In certain cases, I may want to pull from _only_ the coins I have received from one exchange.
<jamesob15>
Asking the wallet to "spend from this address" is a convenient interface in that case.
<jamesob15>
instagibbs: but then the client has to implement the address logic, which is not trivial. It's nice to be able to reuse Core's implementation.
<sipa>
jamesob15: yeah, that's the "coin control" idea; in my view it's a useful expert feature, but it's not how things should be presented in general (i also think that multiwallet is realistically far more useful than coin control, because it's just so trivial to get it wrong)
<jamesob15>
I really don't see what the harm is of just including it. It's cheap to generate and it's not like it sets some precedent that has to be abided by other RPC calls.
<sipa>
i'm philosophically opposed to supporting a model that i consider harmful to bitcoin
<jamesob15>
But you just said that "an expert feature" would make use of this model?
<instagibbs>
the extra hoop is integrate any real library that does it, or call decodescript. I left my order of preferences in the PR anyways
<sipa>
jamesob15: you have a point
<bitcoin-git>
[bitcoin] maflcko opened pull request #31295: refactor: Prepare compile-time check of bilingual format strings (master...2411-trans-fmt-prepare) https://github.com/bitcoin/bitcoin/pull/31295
<sipa>
it's still the case that no RPC really uses the "spend from" model; even scantxoutset just lists the address a coin was last sent to, but it's fair to say that coin control inherently exposes the user to an address-based model
<achow101>
it would probably be better to make it align with how we do it everywhere else with calling it "prevout" or "scriptPubKey" and having the address in that breakdown
<achow101>
e.g. getrawtranasction with verbosity 2
<achow101>
this is at least not unprecedented, and I think the way of presenting it as information attached to the output that was spent, rather than the input, is a reasonable compromise
<jamesob15>
achow101: so you're talking about just namespacing some of the information about the prevout in a nested dict?
<achow101>
jamesob15: yeah
<sipa>
i think that makes sense, it's consistent with other RPCs
<sipa>
(i also don't want to nack things if overall opinion is that including the address is not a big deal)
<jamesob15>
well getrawtransction verbosity 2 doesn't seem to return the address by default (at least according to the RPC doc), so I'm not sure if there's even a consistency to be had there. Nesting or not nesting doesn't seem like a big deal to me, and I tend to like flatter, but if that would somehow appease everyone I can do it
<achow101>
jamesob15: it should be the same decoding stuff as is used for outputs. the optionality of the address is just that some scriptPubKeys don't have addresses
<jamesob15>
achow101: ahh yes, I see - `ScriptPubKeyDoc()`
<achow101>
which, I guess is also something getdescriptoractivity would have to handle (idk, haven't read the pr yet) since you can do raw(whatever)
<instagibbs>
well right now it returns a blank string for address, I'd rather it be optional result
<jamesob15>
I would be happy to do optional result but I literally can't figure out how to get our RPCResult doc stuff to work with that. On the client side, really the difference between "empty string" and "key no exists" is immaterial
<jamesob15>
I'll see about reworking this to use `ScriptPubKeyDoc()` as achow101 suggested
<sipa>
i think it'd make sense to say have for outputs have an "output": { dict with information about UTXO which can include txid, vout, amount, scriptpubkey, address, descriptor, ...}, and for inputs have an "prevout" { dict with the exact same information as "output" }
<achow101>
jamesob15: one of the constructors for RPCResult has an "optional" parameter
<jamesob15>
achow101: yeah I had been trying to use that but then was getting runtime errors or something about the return value being out of conformance
<jamesob15>
will try again
<bitcoin-git>
[bitcoin] ryanofsky opened pull request #31296: wallet: Translate [default wallet] string in progress messages (master...pr/dtran) https://github.com/bitcoin/bitcoin/pull/31296
jetpack_ has quit [Ping timeout: 246 seconds]
EPiSKiNG- has quit [Ping timeout: 272 seconds]
jetpack has joined #bitcoin-core-dev
EPiSKiNG- has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] Sjors opened pull request #31297: mining: add early return to waitTipChanged() (master...2024/11/waittipchanged) https://github.com/bitcoin/bitcoin/pull/31297
zeropoint has joined #bitcoin-core-dev
gf2718 has quit [Ping timeout: 248 seconds]
jarthur has joined #bitcoin-core-dev
gf2718 has joined #bitcoin-core-dev
gf2718 has quit [Ping timeout: 252 seconds]
ubbabeck has quit [Quit: WeeChat 4.4.3]
ubbabeck has joined #bitcoin-core-dev
gf2718 has joined #bitcoin-core-dev
kevkevin has quit [Remote host closed the connection]
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Remote host closed the connection]
kevkevin has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] furszy closed pull request #31291: test: group executed tests within the same directory (master...2024_test_global_path) https://github.com/bitcoin/bitcoin/pull/31291
gf2718 has quit [Ping timeout: 260 seconds]
jon_atack has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 248 seconds]
jonatack has quit [Ping timeout: 252 seconds]
__DuBPiRaTe__ has quit [Quit: Leaving]
gf2718 has joined #bitcoin-core-dev
gf2718 has quit [Ping timeout: 252 seconds]
kevkevin has joined #bitcoin-core-dev
jespada has quit [Ping timeout: 252 seconds]
Guest16 has joined #bitcoin-core-dev
Guest16 has quit [Client Quit]
gf2718 has joined #bitcoin-core-dev
gf2718 has quit [Changing host]
gf2718 has joined #bitcoin-core-dev
Talkless has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] adamandrews1 opened pull request #31298: rpc: combinerawtransaction now rejects unmergeable transactions (master...combinerawtransaction-check) https://github.com/bitcoin/bitcoin/pull/31298
kevkevin has quit [Remote host closed the connection]
jon_atack has quit [Ping timeout: 252 seconds]
jonatack has joined #bitcoin-core-dev
Talkless has quit [Remote host closed the connection]