Bitcoin Core Github
43 subscribers
122K links
Download Telegram
💬 1ma commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665903498)
> For readers of the thread who are not familiar with the STAMPS community, people are going around the OP_RETURN limit and doing things like embedding data in bare multisig: https://mempool.space/tx/1c61f2d4000e1bc2ce27ec24e4fcbbb376c2bd19641e071403e68d84d48eea8a
This creates many unprunable outputs and takes up more blockspace, so its bad for block capacity and utxoset bloat.

The stamps "community" can only route around OP_RETURN because back in 2014 Mike Hearn derailed the discussion to m
...
💬 RicYashiroLee commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665924680)
IMV from too many commentary I have seen already from Peter, this is just another massive example of altcoining mindset, of many wishful thinking ideas coming from Peter Todd, detrimental to Bitcoin Full Node Operators, and only giving, as a direct consequence, more power to a central hub of Core Devs who are in high risk of conflict of interests, as he is included in such risk group of service providers and centralizers, 'scaling' business oriented. Full Node operators, on the contrary, are the
...
💬 YellowRoseCx commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1665933394)
> With having full-rbf by default privacy would be increased for transactions created by bitcoin core, this is very important pull request.
>
> Maybe that's the thing we don't like in this proposal?
>
> Anyone claiming they are accepting 0-conf bitcoin transaction over internet is spreading FUD and that having full-rbf by default does anything bad to their non-existent payment system.

How long do you want Bitcoin users to stand waiting in a store before they can leave with their groceri
...
💬 jonatack commented on pull request "refactor: Add util::Result failure values, multiple error and warning messages":
(https://github.com/bitcoin/bitcoin/pull/25665#discussion_r1284653088)
835f094 It looks like this empty vector might be declarable `constexpr`, at least with clang 16.0.6 arm64.
🤔 jonatack reviewed a pull request: "refactor: Add util::Result failure values, multiple error and warning messages"
(https://github.com/bitcoin/bitcoin/pull/25665#pullrequestreview-1563250744)
ACK 9e80d0b754a28733c79a52c8e0431616c31d071c

Nice documentation, code, and commit message improvements. Some non-blocking comments.
💬 jonatack commented on pull request "refactor: Add util::Result failure values, multiple error and warning messages":
(https://github.com/bitcoin/bitcoin/pull/25665#discussion_r1284654294)
9ec1bda Can `Base` here be private instead of protected?
💬 jonatack commented on pull request "refactor: Add util::Result failure values, multiple error and warning messages":
(https://github.com/bitcoin/bitcoin/pull/25665#discussion_r1284664601)
9ec1bda
```
src/util/result.h:300: OT ==> TO, OF, OR, NOT
src/util/result.h:301: OT ==> TO, OF, OR, NOT
^ Warning: codespell identified likely spelling errors. Any false positives? Add them to the list of ignored words in test/lint/spelling.ignore-words.txt
```
💬 petertodd commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1665939229)
> With having full-rbf by default privacy would be increased for transactions created by bitcoin core, this is very important pull request.

That is correct. The BIP125 flag is a way to distinguish transactions from different wallets, and Chainanalysis certainly makes use of this. Deployment of Full-RBF would eliminate the need for any wallet to set BIP125 flags, allowing all wallets to eventually transition to having identical characteristics.

> Anyone claiming they are accepting 0-conf bi
...
💬 RicYashiroLee commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665951546)
> For readers of the thread who are not familiar with the STAMPS community, people are going around the OP_RETURN limit and doing things like embedding data in bare multisig: https://mempool.space/tx/1c61f2d4000e1bc2ce27ec24e4fcbbb376c2bd19641e071403e68d84d48eea8a This creates many unprunable outputs and takes up more blockspace, so its bad for block capacity and utxoset bloat.

The key word IMV is making things cumbersom for any out of scope use of Bitcoin, not more relaxed. And enable Node o
...
💬 rot13maxi commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665971141)
If you believe that core shouldnt be making policy decisions on behalf of users, then shouldnt the default be that there is no default policy and that users can set it to whatever they want? Thats what this PR would do (for this policy item).

On Fri, Aug 4, 2023 at 1:25 PM, Richard Yashiro Lee ***@***.***(mailto:On Fri, Aug 4, 2023 at 1:25 PM, Richard Yashiro Lee <<a href=)> wrote:

>> For readers of the thread who are not familiar with the STAMPS community, people are going around the OP_RETUR
...
💬 pinheadmz commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1284699462)
🕺 ah nice! I thought there might be something wrong with the transactions themselves, but when I restarted without sensitive relay everything broadcast fine. I didn't think of serialization being the issue! So, great catch.
💬 RicYashiroLee commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665978948)
> If you believe that core shouldnt be making policy decisions on behalf of users, then shouldnt the default be that there is no default policy and that users can set it to whatever they want? Thats what this PR would do (for this policy item).
> […](#)
> On Fri, Aug 4, 2023 at 1:25 PM, Richard Yashiro Lee ***@***.***(mailto:On Fri, Aug 4, 2023 at 1:25 PM, Richard Yashiro Lee <<a href=)> wrote: > For readers of the thread who are not familiar with the STAMPS community, people are going around
...
💬 Sjors commented on pull request "Bump python minimum version to 3.9":
(https://github.com/bitcoin/bitcoin/pull/28211#issuecomment-1665980580)
Don't forget to bump `.python-version`
💬 RicYashiroLee commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665986103)
>

That is a twisted logic. It is not because it is already bad that anyone is centrally allowed to make it worse.
💬 nikicat commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665988600)
The individuals opposing this PR, believing they protect Bitcoin from centralization, ironically desire to dictate to all other people how they should and should not use Bitcoin. This type of standardness paternalism could eventually prompt the creation of other ways to include non-standard transactions in the blockchain, like a transaction marketplace for miners, which would totally eliminate standardness checks as a way to regulate Bitcoin.
💬 RicYashiroLee commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1665996720)
> > I understand that, it's a matter of trust. What I mean is that if the Bitcoin developers end up sanctioning such an obvious sabotage on the system I won't trust them as a group to continue developing the reference implementation.
>
> We still "sanction" even more "obvious sabotage" by the fact that bare multisig outputs are relayed by default. If you have a complaint, I'd suggest you start there rather than on OP_Return, a mechanism designed specifically for low impact and vigorously disc
...
💬 RicYashiroLee commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666014187)
> The individuals opposing this PR, believing they protect Bitcoin from centralization, ironically desire to dictate to all other people how they should and should not use Bitcoin. This type of standardness paternalism could eventually prompt the creation of other ways to include non-standard transactions in the blockchain, like a transaction marketplace for miners, which would totally eliminate standardness checks as a way to regulate Bitcoin.

Every supposedly weakness of Bitcoin (IMV any ex
...
💬 iBeizsley commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666017121)
> If you believe that core shouldnt be making policy decisions on behalf of users, then shouldnt the default be that there is no default policy and that users can set it to whatever they want? Thats what this PR would do (for this policy item).

A value of infinity is still a value. You're suggesting a change from current default policy. You're making a policy decision on behalf of others.

It should be configurable. We already have configuration options (one of which this PR _removes_). If a ch
...
💬 RicYashiroLee commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1666025993)
> > Concept NACK unless you keep the default at `MAX_OP_RETURN_RELAY`. Depending on adoption we can always drop that default later. No need to make pull requests more controversial than necessary.
>
> @ChristopherA is paying me $1000 for 10 hours work to do this pull-req. Since the other sub-change got mired in controversy, I decided to meet my client requirement in a time-efficient manner. Obviously, I can't promise to him that this will actually get merged. But I can promise to him that I'l
...
📝 Retropex opened a pull request: "set DEFAULT_PERMIT_BAREMULTISIG to false"
(https://github.com/bitcoin/bitcoin/pull/28217)
The default activation of the `permitbaremultisig` option proposes an enhancement for the Bitcoin network. By refusing non-P2SH multisignature transactions from the outset, this modification would contribute to reducing spam attempts and maintaining a healthy decentralization by discouraging undesirable activities. It would also promote the adoption of best practices.

This would strengthen the Bitcoin ecosystem by encouraging the use of compliant transactions.