Bitcoin Core Github
44 subscribers
121K links
Download Telegram
💬 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?
🤔 l0rinc reviewed a pull request: "[IBD] multi-byte block obfuscation"
(https://github.com/bitcoin/bitcoin/pull/31144#pullrequestreview-3026774129)
Thanks for the hints, the latest version simplifies reading the obfuscation key by using the new `Obfuscation` object's serialization paths + reading back the new key directly after generating a new one.

The `obfuscation_constructors` test was also changes to validate the new `HexKey` conversion which we need since we're logging the generated obfuscations keys so we need to peek into the object.

It also avoids a possible `Obfuscation` copy used in `GetObfuscation` and removed the `obfuscat
...
💬 l0rinc commented on pull request "[IBD] multi-byte block obfuscation":
(https://github.com/bitcoin/bitcoin/pull/31144#discussion_r2211528848)
Done