On Tue, Dec 06, 2022 at 12:39:40AM -0500, Peter Todd via bitcoin-dev wrote:
> 10 or 20 nodes is completely meaningless. Pools run nodes themselves, which by
> default connect to 8 outgoing peers. There's about 5000 IPv4 listening nodes
> on
> the network. When a node learns of a new block, it tell
On Mon, Dec 05, 2022 at 09:20:58AM -0300, El_Hoy wrote:
> The only option I see against the attack Peter Todd is doing to opt-in RBF
> and 0Conf bitcoin usage is working on a bitcoin core implementation that
> stops propagation of full-rbf replaced blocks. Running multiple of such
> nodes on the ne
On Fri, Dec 02, 2022 at 05:35:39PM -0500, Antoine Riard via bitcoin-dev wrote:
> To recall, the original technical motivation of this option, and the wider
> smoother deployment was to address a DoS vector affecting another class of
> use-case: multi-party transactions like coinjoin and contracting
Antoine,
> In the direction of removing the current option from Bitcoin Core, I think
> the prerequisite to address are the qualification of enough economic flows
> at risk and the presence of a sizable loss in miners income.
Are such prerequisites for feature removal published somewhere? I don
note: if it was possible to enforce this, we wouldn't need proof of work at
all. since it isn't possible, proof of work is strictly necessary.
On Mon, Dec 5, 2022 at 9:53 AM Rijndael via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Good morning,
>
> That sounds like a very dan
You are doing quite big claims without explaining those, let me add a few
questions inline:
On Mon, Dec 5, 2022 at 10:39 AM Greg Sanders wrote:
This will greatly centralize the network as well as not actually achieve
> the intended goal which is literally impossible.
>
Why would this centralize
> That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun
> wallet developers) could work on a fork and run several nodes with such
> functionality.
Daniel Lipshitz has been working on BSV apparently [0] so I guess anything is
possible with him. But as others have said turnin
>
> The perception seems to be that Core adding the full RBF option is
> increasing the risk to zero-conf users, but I'm not convinced that that is
> the case.
If this "perception" were not true, RBF & full-RBF would not be necessary
at all. Think about it.
It's always been the risk of getting d
Good morning,
That sounds like a very dangerous mode of operation. You can already hand a
transaction to a miner privately. I hand a transaction to a miner with some
reasonable fee, and then I go and broadcast a different transaction with a
minimal fee that spends the same inputs. The whole net
This will greatly centralize the network as well as not actually achieve
the intended goal which is literally impossible.
On Mon, Dec 5, 2022, 8:27 AM El_Hoy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> The only option I see against the attack Peter Todd is doing to opt-in RB
Core adding full RBF is a change of node policy that may be highly inconvenient
for zero-conf users, but there has always been and will always be a risk of a
double-spend for anyone that treats zero-confirmation transactions as settled.
It's literally in the name - this transaction has zero conf
The only option I see against the attack Peter Todd is doing to opt-in RBF
and 0Conf bitcoin usage is working on a bitcoin core implementation that
stops propagation of full-rbf replaced blocks. Running multiple of such
nodes on the network will add a risk to miners that enable full-rbf that
would
12 matches
Mail list logo
