[bitcoin-dev] draft proposal: change forwarding (improved fungibility through wallet interoperability)

2018-11-06 Thread Yuval Kogman via bitcoin-dev
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

Re: [bitcoin-dev] draft proposal: change forwarding (improved fungibility through wallet interoperability)

2018-12-02 Thread Yuval Kogman via bitcoin-dev
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

Re: [bitcoin-dev] PubRef - Script OP Code For Public Data References

2019-07-19 Thread Yuval Kogman via bitcoin-dev
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.

Re: [bitcoin-dev] PubRef - Script OP Code For Public Data References

2019-07-19 Thread Yuval Kogman via bitcoin-dev
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

Re: [bitcoin-dev] Non-equal value CoinJoins. Opinions.

2019-12-29 Thread Yuval Kogman via bitcoin-dev
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

Re: [bitcoin-dev] Non-equal value CoinJoins. Opinions.

2019-12-29 Thread Yuval Kogman via bitcoin-dev
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

Re: [bitcoin-dev] Non-equal value CoinJoins. Opinions.

2019-12-28 Thread Yuval Kogman via bitcoin-dev
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

[bitcoin-dev] WabiSabi: a building block for coordinated CoinJoins

2020-06-11 Thread Yuval Kogman via bitcoin-dev
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

Re: [bitcoin-dev] A design for Probabilistic Partial Pruning

2021-02-27 Thread Yuval Kogman via bitcoin-dev
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

Re: [bitcoin-dev] A design for Probabilistic Partial Pruning

2021-02-27 Thread Yuval Kogman via bitcoin-dev
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