Bitcoin Core Github
44 subscribers
121K links
Download Telegram
💬 brunoerg commented on pull request "fuzz: wallet: add target for tx scanning":
(https://github.com/bitcoin/bitcoin/pull/32993#issuecomment-3079741494)
> https://cirrus-ci.com/task/4897452429410304?logs=ci#L6267:
>
> ```shell
> [10:48:30.374] Run wallet_scan with args ['/ci_container_base/ci/scratch/build-x86_64-pc-linux-gnu/bin/fuzz', '-max_total_time=60']INFO: Running with entropic power schedule (0xFF, 100).
> [10:48:30.374] INFO: Seed: 1927962085
> [10:48:30.374] INFO: Loaded 1 modules (634026 inline 8-bit counters): 634026 [0x5573df666fb8, 0x5573df701c62),
> [10:48:30.374] INFO: Loaded 1 PC tables (634026 PCs): 634026 [0x5573df70
...
💬 maflcko commented on issue "GUI bitcoin core shows wrong amount":
(https://github.com/bitcoin/bitcoin/issues/32976#issuecomment-3079753017)
coin control is an expert feature, but you can enable it in

Settings > Options > Wallet
Check "Enable coin control features (experts only!)"

The RPC has a manual, you can just go to "Window"->"Console" and type `help`.
💬 instagibbs commented on pull request "Reduce minrelaytxfee to 100 sats/kvB":
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3079770986)
> If, at the time the figure was set, you had asked "But what happens if later bitcoin is trading at 100x what it is now?" you would have gotten a (near-)unanimous and hesitation free "then the setting can be adjusted down 100x"

I don't think I was around then, so maybe or maybe not :)

I assume the same logic holds for incremental rate?

> There is a secondary reason it exists

Not sure I understood this point.
Galoretka closed a pull request: "fix: Python 3 bytes comparison in linearize-data.py"
(https://github.com/bitcoin/bitcoin/pull/32978)
sr-gi closed a pull request: "Adds transaction propagation information to mempool transactions"
(https://github.com/bitcoin/bitcoin/pull/32986)
💬 sr-gi commented on pull request "Adds transaction propagation information to mempool transactions":
(https://github.com/bitcoin/bitcoin/pull/32986#issuecomment-3079819547)
> I'm generally not in favour of making bespoke changes to production code or extending the public interface just to facilitate tests, monitoring, ... if there exists a workaround, especially for temporary projects. In this case, after speaking with @sr-gi offline a bit more, it seems it seems like tracepoints, logging, small patchsets, ... are feasible alternatives, so I'm Concept NACK on this one. (but I am open to making minimal changes to ensure the necessary erlay simulations can be ran)

...
💬 gmaxwell commented on pull request "Reduce minrelaytxfee to 100 sats/kvB":
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3079827081)
> I assume the same logic holds for incremental rate?

I think that the incremental rate, like dust limit, would in an ideal world be just a pure function of the "actual" feerate, but we don't have access to the actual feerate and the actual rate is fluctuating while it's preferable for these to be more stable so the minrelay fee gets used as a proxy.

> Not sure I understood this point.

If there is a sustained period of low demand (such that few blocks are full) then absent artificial li
...
💬 instagibbs commented on pull request "validation: docs and cleanups for MemPoolAccept coins views":
(https://github.com/bitcoin/bitcoin/pull/32973#discussion_r2211313016)
s/has now been spent/has now been spent in the mempool/ ?
💬 glozow commented on pull request "wallet, rpc: add v3 transaction creation and wallet support":
(https://github.com/bitcoin/bitcoin/pull/32896#discussion_r2211351922)
maybe these should live in mempool_util?
💬 glozow commented on pull request "wallet, rpc: add v3 transaction creation and wallet support":
(https://github.com/bitcoin/bitcoin/pull/32896#discussion_r2211362713)
Might want to assert that it's v2
💬 glozow commented on pull request "wallet, rpc: add v3 transaction creation and wallet support":
(https://github.com/bitcoin/bitcoin/pull/32896#discussion_r2211355006)
This looks like it was copy-pasted from the test framework - can we just use the existing method, perhaps with a wrapper if needed?
💬 glozow commented on pull request "wallet, rpc: add v3 transaction creation and wallet support":
(https://github.com/bitcoin/bitcoin/pull/32896#discussion_r2211375162)
Could you also add `v2_tx_spends_confirmed_v3_tx` and `v3_tx_spends_confirmed_v2_tx` to check that version mismatches are fine there?
💬 glozow commented on pull request "wallet, rpc: add v3 transaction creation and wallet support":
(https://github.com/bitcoin/bitcoin/pull/32896#discussion_r2211372152)
Should there also be a test where Alice tries to spend her change after Bob has spent from the parent? That wouldn't require `include_unsafe` IIUC
💬 glozow commented on pull request "wallet, rpc: add v3 transaction creation and wallet support":
(https://github.com/bitcoin/bitcoin/pull/32896#discussion_r2211379860)
What does "two outputs" mean here? This has 1 output, no?
💬 glozow commented on pull request "wallet, rpc: add v3 transaction creation and wallet support":
(https://github.com/bitcoin/bitcoin/pull/32896#discussion_r2211390451)
Isn't this just...?
```suggestion
alice_v2_unspent = self.alice.listunspent(minconf=1)[0]
```
💬 glozow commented on pull request "wallet, rpc: add v3 transaction creation and wallet support":
(https://github.com/bitcoin/bitcoin/pull/32896#discussion_r2211381702)
Will Alice's wallet attempt to rebroadcast her transaction if/when the parent + Bob's confirm? Can we do an RBF of Alice's transaction to evict Bob's?
💬 glozow commented on pull request "wallet, rpc: add v3 transaction creation and wallet support":
(https://github.com/bitcoin/bitcoin/pull/32896#discussion_r2211385875)
```suggestion
# send a v2 output to alice and confirm it
````
💬 glozow commented on pull request "wallet, rpc: add v3 transaction creation and wallet support":
(https://github.com/bitcoin/bitcoin/pull/32896#discussion_r2211403206)
Can this be consolidated with `v3_conflict_removed_from_mempool` since they are mostly the same?