On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev wrote:
> Hi all,
>
> Chiming in on this thread as I feel like the real dangers of RBF as default
> policy aren't sufficiently elaborated here. It's not only about the
> zero-conf (I'll get to that) but there is an even
Hi Sergej,
Thanks for the insightful posting, especially highlighting the FX risk
which was far from being evident on my side!
I don't know in details the security architecture of Bitrefill zeroconf
acceptance system, though from what I suppose there is at least a set of
full-nodes
--- Original Message ---
On Wednesday, October 19th, 2022 at 2:40 PM, angus wrote:
>> Let's allow a miner to include transactions until the block is filled, let's
>> call this structure (coining a new term 'Brick'), B0. [brick=block that
>> doesn't meet the difficulty rule and is
--- Original Message ---
On Wednesday, October 19th, 2022 at 10:34 PM, G. Andrew Stone
wrote:
> Consider that a miner can also produce transactions. So every miner would
> produce spam tx to fill their bricks at the minimum allowed difficulty to
> reap the brick coinbase reward.
Consider that a miner can also produce transactions. So every miner would
produce spam tx to fill their bricks at the minimum allowed difficulty to
reap the brick coinbase reward.
You might quickly respond with a modification that changes or eliminates
the brick coinbase reward, but perhaps that
Another downside is that the sender may not opt into a non-pinnable future
format like "V3 transactions", making CPFP difficult. They may spend a lot
of fees to do this however, so maybe we're really reaching here.
On Wed, Oct 19, 2022 at 12:07 PM Sergej Kotliar via bitcoin-dev <
It's an interesting idea, presumably it would work w the new package relay.
Scorched earth bidding war is definitely fine to deter this type of abuse.
Need to consider it more thoroughly from all sides tho. CPFP on the server
side generally has a couple of downsides:
* Requires a hot wallet to
Thanks all for your responses.
so is it a no-go is because "reduced settlement speed is a desirable feature"?
I don';t know what weights more in this consideration:
A) to not increase the workload of full-nodes, being "less difficult to
operate" and hence reduce the chance of some of them giving
Isn't the extreme of this that the merchant tries to lock in gains on the
upswing via CPFP, and users on the downswing, both doing scorched earth,
tossing the delta to fees?
Seems like a MAD situation?
On Wed, Oct 19, 2022 at 11:44 AM Jeremy Rubin via bitcoin-dev <
If they do this to you, and the delta is substantial, can't you sweep all
such abusers with a cpfp transaction replacing their package and giving you
the original txn?
On Wed, Oct 19, 2022, 7:33 AM Sergej Kotliar via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi all,
>
>
I'm also very happy to see this proposal, since it gets us closer to having
a mechanism that allows the contribution to feerate in an "unauthenticated"
way, which seems to be a very helpful feature for vaults and other
contracting protocols.
One possible advantage of the sponsors interface -- and
> Currently Lightning is somewhere around 15% of our total bitcoin
payments. This is very much not nothing, and all of us here want Lightning
to grow, but I think it warrants a serious discussion on whether we want
Lightning adoption to go to 100% by means of disabling on-chain commerce.
Is this
Hi all,
Chiming in on this thread as I feel like the real dangers of RBF as default
policy aren't sufficiently elaborated here. It's not only about the
zero-conf (I'll get to that) but there is an even bigger danger called the
american call option, which risks endangering the entirety of BIP21
> currently, a miner produce blocks with a limited capacity of transactions
that ultimately limits the global settlement throughput to a reduced number
of tx/s.
reduced settlement speed is a desirable feature and isn't something we need
to fix
the focus should be on layer 2 protocols that allow
Hi,
On Wed, Oct 19, 2022 at 6:34 AM mm-studios via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Fully filled brick B0, with a hash that doesn't meet the difficulty rule,
> would be broadcasted and nodes would have it on in a separate fork as usual.
>
Check out the previous
> Let's allow a miner to include transactions until the block is filled, let's
> call this structure (coining a new term 'Brick'), B0. [brick=block that
> doesn't meet the difficulty rule and is filled of tx to its full capacity]
> Since PoW hashing is continuously active, Brick B0 would have
> IIRC, here I think we also need _package relay_ in strict addition of
_package RBF_,
Yes, sorry if that wasn't clear. Package Relay -> Package RBF -> V3 ->
Ephemeral Anchors
> If we allow non-zero value in ephemeral outputs, I think we're slightly
modifying the incentives games of the channels
Hi Bitcoin devs,
I'd like to share an idea of a method to increase throughput in the bitcoin
network.
Currently, a miner produce blocks with a limited capacity of transactions that
ultimately limits the global settlement throughput to a reduced number of tx/s.
Big-blockers proposed the removal
Hi aj,
> I mean, I guess I can understand wanting to reduce that responsibility
> for maintainers of the github repo, even if for no other reason than to
> avoid frivolous lawsuits, but where do you expect people to find better
> advice about what things are a good/bad idea if core devs as a
> Full RBF doesn't need a majority or unanimity to have an impact; it needs
> adoption by perhaps 10% of hashrate (so a low fee tx at the bottom of
> a 10MvB mempool can be replaced before being mined naturally), and some
> way of finding a working path to relay txs to that hashrate.
Yes, this
When Satoshi wrote the first version of bitcoin, s/he made what was almost
certainly an unintentional mistake. A bug in the original CHECKMULTISIG
implementation caused an extra item to be popped off the stack upon completion.
This extra value is not used in any way, and has no consensus
21 matches
Mail list logo
