Bitcoin Core Github
44 subscribers
121K links
Download Telegram
πŸ’¬ Cryptomaster001 commented on issue "Bitcoin Core - Transaction without permition":
(https://github.com/bitcoin/bitcoin/issues/29049#issuecomment-1849020345)
Hello @hugomenezes85,
can you post the transaction hash?
πŸ’¬ hugomenezes85 commented on issue "Bitcoin Core - Transaction without permition":
(https://github.com/bitcoin/bitcoin/issues/29049#issuecomment-1849020706)
Hi,YesCumprimentosHugo MenezesNo dia 10/12/2023, Γ s 16:58, Cryptomaster001 ***@***.***> escreveu:ο»Ώ
Hello @hugomenezes85,
can you post the transaction hash?

β€”Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
πŸ’¬ hugomenezes85 commented on issue "Bitcoin Core - Transaction without permition":
(https://github.com/bitcoin/bitcoin/issues/29049#issuecomment-1849021340)
> Hello @hugomenezes85, can you post the transaction hash?

Hi, i think its this picture.
![bitcoin2](https://github.com/bitcoin/bitcoin/assets/153444557/49d9013b-b730-42a3-bad4-5fd87f8179d8)
πŸ’¬ TheCharlatan commented on pull request "kernel: Streamline util library":
(https://github.com/bitcoin/bitcoin/pull/29015#issuecomment-1849026409)
Re https://github.com/bitcoin/bitcoin/pull/29015#issuecomment-1848935768

> Does it make sense to improve https://github.com/bitcoin/bitcoin/blob/master/doc/design/libraries.md by expressing the idea from the quotes above more clearly? As for now, it reads:

This seems like the right place to talk about the relationship between the util and kernel library. My work on the kernel library has been focusing on reducing its essence to validation code, pruning external dependencies, and stripping
...
πŸ’¬ kashifs commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1421789507)
This should read:

`@param std::vector<OutputGroup>& utxo_pool The UTXO groups that we are choosing from.`
πŸ’¬ kashifs commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1421790528)
this should read:

`@param CAmount change_target The minimum budget for creating a change output that we add to the selection_target.`
πŸ‘ hebasto approved a pull request: "test: detect OS in functional tests consistently using `platform.system()`"
(https://github.com/bitcoin/bitcoin/pull/29034#pullrequestreview-1774073057)
ACK 878d914777a03a04ecb84217152e8b7fd73a5062, I have reviewed the code and it looks OK.
πŸ’¬ ariard commented on pull request "[WIP] BIP300 (Drivechains) consensus-level logic":
(https://github.com/bitcoin/bitcoin/pull/28311#issuecomment-1849045560)
> > My invitation to discuss in person about the topic of Bitcoin consensus change at a conference during the coming years stays open, or on the mailing list if it’s a communication medium you think it’s better suited.

Held my words here. A twitter space did happen end of last week between one of the PR author and myself, which was pleasant overall.

I made it clear I didn’t have any strong thoughts on drivechain, though I took time to express 2 generic concerns I think affecting all bitcoi
...
πŸ’¬ ariard commented on pull request "Ephemeral Anchors":
(https://github.com/bitcoin/bitcoin/pull/29001#issuecomment-1849051771)
> BIP text here: https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki

"Be 0-fee”

This is uncertain to me how this rule works with trimmed HTLCs on LN commitment transactions making their fees non-zero, even assuming anchor outputs where second-stage txn are signed with 0-feerate.

Beyond, I think it should add an information section at destination of use-cases developers discouraging the usage of anyone-can-spend ephemeral anchor. Otherwise a time-sensi
...
πŸ’¬ instagibbs commented on pull request "Ephemeral Anchors":
(https://github.com/bitcoin/bitcoin/pull/29001#issuecomment-1849066824)
@ariard I'd rather talk downstream details over here https://github.com/bitcoin/bips/pull/1524
⚠️ sinetek opened an issue: "The logo icon doesn't show properly under Wayland"
(https://github.com/bitcoin-core/gui/issues/781)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

There should be a bitcoin logo icon when running the application under a wayland session.
Right now it looks like this on my machine.

![image](https://github.com/bitcoin-core/gui/assets/5908875/4bfbb61e-9ed3-4e43-a723-13fb9f2d51e7)



### Expected behaviour

It should look like this (run on the same machine, same everything, but with platform xcb):

![image](https://github.com/bitc
...
πŸ‘ TheCharlatan approved a pull request: "Add a note to msvc readme re building Qt for Bitcoin Core."
(https://github.com/bitcoin/bitcoin/pull/29048#pullrequestreview-1774091824)
ACK d08e820abf5da2be09b8a84b5bd3450d1a55a039
πŸ’¬ douglaz commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1849086282)
Concept NACK.

This is an attempt to increase transaction censorship under the guise of a bugfix.
πŸ’¬ LarryRuane commented on pull request "test: test_bitcoin: allow -testdatadir=<datadir>":
(https://github.com/bitcoin/bitcoin/pull/26564#discussion_r1421821961)
> The default test behavior creates a random directory path within the OS temp directory; therefore, we don't need to remove anything on this execution path.

No, in current master, the test framework does delete the directory _after_ the test: https://github.com/bitcoin/bitcoin/blob/3e691258d8789a4a89cce42e7e71b130491594d7/src/test/util/setup_common.cpp#L162 and I think that's a good thing or else running many tests could fill up your temp directory. If the test stops unexpectedly, I think th
...
πŸ’¬ Retropex commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1849100398)
> Concept NACK.
>
> This is an attempt to increase transaction censorship under the guise of a bugfix.

Bitcoin Core already standardizes the insertion of arbitrary data above 83 bytes and inscriptions are a diverted way to bypass this limit so it is a bug fix.
πŸ’¬ aviv57 commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1849105666)
Concept NACK.

I think ordinals and inscriptions will make a lot of people invest in shit jpegs.

But the way to stop people from encoding arbitrary data on the chain is not by adding censorship.

It's by waiting for it to be much more expensive to do it on bitcoin than doing it on other networks / centralized services
πŸ’¬ TheCharlatan commented on pull request "ci: Use Ubuntu 24.04 Noble for asan,tsan,tidy,fuzz":
(https://github.com/bitcoin/bitcoin/pull/28992#issuecomment-1849106727)
When I apply this patch and run `FILE_ENV="./ci/test/00_setup_env_native_tidy.sh" ./ci/test_run_all.sh`, I get
```
131.2 CMake Error at /usr/lib/llvm-17/lib/cmake/clang/ClangTargets.cmake:833 (message):
131.2 The imported target "libclang" references the file
131.2
131.2 "/usr/lib/llvm-17/lib/libclang-17.so.1"
131.2
131.2 but this file does not exist. Possible reasons include:
131.2
131.2 * The file was deleted, renamed, or moved to another location.
131.2
131.2 * An
...
πŸ’¬ ajtowns commented on pull request "kernel: Streamline util library":
(https://github.com/bitcoin/bitcoin/pull/29015#issuecomment-1849208455)
Would it make sense to just merge common into util; but have a "stripped" version of util available for the kernel, that excludes stuff that doesn't match the 5 points above? That way the difference is just at the build system level, it doesn't involve moving files around or moving code between namespaces...

Then the advice would be: (a) just put things in util, (b) but only add things to the "util-core" section of the build file when they're needed by the kernel; (c) keep things in the util:
...
πŸ’¬ hmisty commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1849244134)
Concept ACK.

Makes sense to consider the way inserting data as a trick and abuse of the taproot script.
πŸ’¬ hmisty commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1849261876)
> Concept ACK.
>
> Makes sense to consider the way inserting data as a trick and abuse of the taproot script.

Since the obfuscated data in the script are neither verified nor enforced by the consensus, and these data are to any extent eventually rely on off-chain indexers to proceed, a more elegant way could be to move all data out of the chain for the off-chain indexers to store and deal with, while leaving only a hash on chain which fits well into the design intent with minimal on-chain
...
πŸ’¬ mmgen commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1849289963)
Concept NACK. The ordinals transactions will end up in the blockchain anyway via private mempools, so this PR does nothing to solve/mitigate the problem of blockchain spam.

And as Peter Todd noted, blockchain propagation will be adversely impacted, as regular nodes will be seeing the ordinals TXs only when the block is announced.