I've updated the BIP text to allow arbitrary length tuples.
On 07/27/2022 04:44 AM, Pavol Rusnak wrote:
> On Wed, 27 Jul 2022 at 00:28, Andrew Chow wrote:
>
>> However I don't see why this couldn't generalize to any sized tuples. As
>> long as the tuples are all the same length, and the limit i
> It's pointless for individual nodes to make changes like this on their own.
It's pointless only if you assume that mining is centralized. And it's
pointless if you also assume that there is no batching. By using different
sighashes, batching is definitely possible. In case of one-input-one-out
On July 27, 2022 6:10:00 AM GMT+02:00, vjudeu via bitcoin-dev
wrote:
>> So I'd suggest removing the fixed dust limit entirely and relying purely on
>> the mempool size limit to determine what is or is not dust.
>
>Just use those settings in your node:
>
>minrelaytxfee=0.
>blockmintxfe
Thanks Andrew for proposing the BIP, I have used this syntax in Sparrow for
some time now.
I find a single, compact descriptor for a wallet is important when copying
out as a backup, particularly onto durable media. More so when it is a
multisig wallet that ideally requires a backup of all the xpu
> So I'd suggest removing the fixed dust limit entirely and relying purely on
> the mempool size limit to determine what is or is not dust.
Just use those settings in your node:
minrelaytxfee=0.
blockmintxfee=0.
dustrelayfee=0.
No changes in source code are needed, nodes
Let's assume fees don't compensate low block reward.
And for example every 10 BTC holding needs to be secured by one Antminer S19
running.
In an ideal world every large bitcoin holder will run proper amount of ASICs
and run it at loss.
The holders of less than 10 BTC - will organize "group pay
> I'm pretty sure we will have a textbook case of Prisoner's Dilemma here.
no, there is no large payoff for betrayal
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
On Wed, 27 Jul 2022 at 00:28, Andrew Chow
wrote:
> However I don't see why this couldn't generalize to any sized tuples. As
> long as the tuples are all the same length, and the limit is one tuple per
> key expression, then we don't get any combinatorial blowup issues.
>
I think it's worthwhile
