On Wed, 8 Feb 2023 at 02:56, Antoine Riard wrote:
> From what I understand, there are many inputs for the coinjoin transaction,
> the latest signer provides an inflated witness downgrading the multi-party
> transaction feerate.
Yep!
> It doesn't sound to me a fee siphoning as occurring with
## Summary
Since Taproot (more generally any kind of MAST) spends have variable size which
depends on the path being used, the last such input to be signed in a multiparty
transaction can always use a larger than estimated signature to unfairly extract
a fee contribution from the other parties to
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
On Sat, 12 Nov 2022, 11:01 Pieter Wuille via bitcoin-dev, <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I think we can just merge the two and have a single variable-length
> command structure that can be used for both: command encodings are 1 to 12
> bytes, each byte's top bit indicating
On Fri, 26 Feb 2021 at 20:57, Keagan McClelland via bitcoin-dev
wrote:
> The goals are to increase data redundancy in a way that more uniformly shares
> the load across nodes, alleviating some of the pressure of full archive nodes
> on the IBD problem. I am working on a draft BIP for this
On Sat, 27 Feb 2021 at 22:09, Yuval Kogman wrote:
> and there is work on fountain codes. There is also some work on
apologies, the first half of this line should have been deleted as it
was worked into the next sentence.
___
bitcoin-dev mailing list
Hi,
As part of research into how CoinJoins in general and Wasabi in
particular can be improved, we'd like to share a new building block
we're calling WabiSabi, which utilizes keyed verification anonymous
credentials instead of blind signatures to verify the honest
participation of users in
Hi,
On Sun, 29 Dec 2019 at 10:23, ZmnSCPxj wrote:
>
> Indeed, this is a problem still of equal-valued CoinJoin.
> In theory the ZeroLink protocol fixes this by strongly constraining user
> behavior, but ZeroLink is not "purely" implemented in e.g. Wasabi: Wasabi
> still allows spending pre- and
On Sun, 29 Dec 2019, 05:31 Yuval Kogman, wrote:
> n = # inputs + # indistinguishable outputs
>
sorry, this is really wrong (although of no consequence to my arguments) -
n is the smaller of these two numbers, not their sum.
___
bitcoin-dev mailing
Hi,
On Sat, 28 Dec 2019 at 01:29, nopara73 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
I haven't read the whole thing in detail (and fwiw, I don't think I will by
this point), but I do want to respond to section about the combinatorics as
well as the proof, since both the
Hi,
On Fri, 19 Jul 2019 at 17:49, Mike Brooks wrote:
> Users will adopt whatever the client accepts - this feature would be
> transparent.
>
My skepticism was based in an assumption on my part that most such data is
produced by actors with a track record of neglecting transaction
efficiency.
Hi,
On Fri, 19 Jul 2019 at 14:00, Mike Brooks via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
Giving scripts the ability to refer to data on the blockchain will reduce
> transaction sizes because key material does not have to be repeated in
> every Script.
>
Given that address
Hi,
On Sat, 1 Dec 2018 at 05:06, James MacWhyte wrote:
> Is the intention that someone would open their non-private wallet, and
> choose an option that slowly siphons their funds into a different app?
>
Yes, that's the idea. And then send them back in a controlled manner.
> Why would anyone
Hello,
I would like to propose a method based on BIP32 (and optionally BIP44) for
improving fungibility and on chain privacy with wallets for which this is
not a primary concern, requiring minimal changes to allow such wallets to
safely forward change outputs to more specialized wallets. This is
14 matches
Mail list logo
