Re: [bitcoin-dev] Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet
Good morning Prayank, > 1. Peer 1 doesn't need to be a trusted third party, it can be implemented in > a way that some peers involved in this system can provide liquidity for > others and incentives can be a small fee. It is not clear in the article, but you mention using a 2-of-3, and show 3 participants. It seems to me that Peer 1 and Peer 3 (2-of-3) can simply sign to spend the funds coming from Peer 2, and split the funds of Peer 2 among them, without getting input from Peer 2. That is the reason why I consider this tr\*sted --- Peer 2 has to trust Peer 1 does not collude with Peer 3 to steal the funds of Peer 2. Unless I have misunderstood your article, which is why I asked for clarification. > 2. Yes joinmarket is awesome and its payjoin will be better to achieve the > same but I was trying to contribute and add more options for people to > improve privacy on Bitcoin. If we have different ways to mix it will be > harder for spy companies to analyze of some of the transactions. * While JoinMarket has *a* PayJoin implementation, what I described in the previous email was not a PayJoin, it is standard CoinJoin where one of the equal-valued outputs is to the payee. * In particular, PayJoin requires the cooperation of the payee, what I described does *not* require anything from the payee other than a destination address and an amount to pay. * Your described technique (as I understand it) is not too different from what JoinMarket already does for normal sends, with the JoinMarket technique having the advantage that it works with the current paradigm of "send payment to this address" without reconnecting to the payee. The advantage you describe is largely had only if the technique is significantly different. For instance, CoinSwap and CoinJoinXT are different enough from CoinJoin to be valuable in this respect. > 3. Also one such setup might not make a huge difference but a chain of such > mixers will surely work better if everything done correctly. > > 4. Maybe multisig usage is not ideal for such things right now and I am not > the best person when it comes to coding but think that better privacy for > multisig will make it possible for lot of ideas to be implemented on Bitcoin > using different multisig setups and combination of other things that we > already have. Schnorr (which is introduced as a package deal with Taproot) already makes all n-of-n look the same as 1-of-1 without tr\*sted setup, and makes hidden m-of-n possible with some kind of setup (possibly untrusted I think, but I am not enough of a mathist to describe this, in any case my base understanding is that the setup for m-of-n Schnorr requires a complex ritual involving a number of communication rounds). Taproot allows to hide explicit m-of-n in a script behind some kind of n-of-n or m-of-m. So multisignature usage would automatically gain such advantage once Taproot gets deployed. In any case, if you are still interested in protocol design with some amount of focus on privacy, please consider reading this article as well: https://zmnscpxj.github.io/offchain/generalized.html What exactly is your goal here. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility
=== Abstract === Imagine a future where a user Alice has bitcoins and wants to send them with maximal privacy, so she creates a special kind of transaction. For anyone looking at the blockchain her transaction appears completely normal with her coins seemingly going from address A to address B. But in reality her coins end up in address Z which is entirely unconnected to either A or B. Now imagine another user, Carol, who isn't too bothered by privacy and sends her bitcoin using a regular wallet which exists today. But because Carol's transaction looks exactly the same as Alice's, anybody analyzing the blockchain must now deal with the possibility that Carol's transaction actually sent her coins to a totally unconnected address. So Carol's privacy is improved even though she didn't change her behaviour, and perhaps had never even heard of this software. In a world where advertisers, social media and other companies want to collect all of Alice's and Carol's data, such privacy improvement would be incredibly valuable. And also the doubt added to every transaction would greatly boost the fungibility of bitcoin and so make it a better form of money. This undetectable privacy can be developed today by implementing CoinSwap, although by itself that isn't enough. There must be many building blocks which together make a good system. The software could be standalone as a kind of bitcoin mixing app, but it could also be a library that existing wallets can implement allowing their users to send Bitcoin transactions with much greater privacy. == CoinSwap == Like CoinJoin, CoinSwap was invented in 2013 by Greg Maxwell[1]. Unlike CoinJoin it is relatively complicated to implement and so far has not been deployed. But the idea holds great promise, and fixes many of the problems of some kinds of CoinJoins. CoinSwap is the next step for on-chain bitcoin privacy. CoinSwap is a way of trading one coin for another coin in a non-custodial way. It is closely related to the idea of an atomic swap. Alice and Bob can trade coins with each other by first sending to a CoinSwap address and having those coins then sent to Bob: Alice's Address 1 > CoinSwap Address 1 > Bob's Address 1 An entirely separate set of transactions gives Bob's coins to Alice in return: Bob's Address 2 > CoinSwap Address 2 > Alice's Address 2 Where the symbol > is a bitcoin transaction. Privacy is improved because an observer of the blockchain cannot link Alice's Address 1 to Alice's Address 2, as there is no transaction between them. Alice's Address 2 could either be an address in Alice's wallet, or the address of someone else she wants to transfer money to. CoinSwap therefore breaks the transaction graph heuristic, which is the assumption that if a transaction A -> B is seen then the ownership of funds actually went from A to B. CoinSwap doesnt break any of bitcoin's assumptions or features like an auditable supply or pruning. It can be built on today's bitcoin without any new soft forks. CoinSwap can't improve privacy much on its own, so it requires other building block to create a truly private system. === ECDSA-2P === The original CoinSwap idea uses 2-of-2 multisig. We can get a slightly bigger anonymity set by using 2-of-3 multisigs with a fake third public key. For a much greater anonymity set we can use 2-party ECDSA to create 2-of-2 multisignature addresses that look the same as regular single-signature addresses[2]. Even the old-style p2pkh addresses starting with 1 can be CoinSwap addresses. Because the transactions blend in with the rest of bitcoin, an application based on CoinSwap would provide much more privacy than the existing equal-output coinjoin apps (JoinMarket, Wasabi Wallet and Samourai Wallet's Whirlpool). CoinSwaps would also be cheaper for the same amount of privacy, as CoinJoin users usually create multiple CoinJoins to get effective privacy, for example JoinMarket's tumbler script does between 7-12 coinjoins (which are bigger than regular transactions too) when run with default parameters. Schnorr signatures with Musig provide a much easier way to create invisible 2-of-2 multisig, but it is not as suitable for CoinSwap. This is because the anonymity set for ECDSA would be much greater. All addresses today are ECDSA, and none are schnorr. We'd have to wait for schnorr to be added to bitcoin and then wait for users to adopt it. We see with segwit that even after nearly 3 years that segwit adoption is only about 60%, and segwit actually has a sizeable financial incentive for adoption via lower fees. Schnorr when used for single-sig doesn't have such an incentive, as Schnorr single-sig costs the same size as today's p2wpkh, so we can expect adoption to be even slower. (Of course there is an incentive for multisig transactions, but most transactions are single-sig). As schnorr adoption increases this CoinSwap system could start to use it, but for a long time I suspect it will mostly be using
Re: [bitcoin-dev] Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet
Hello ZmnSCPxj, Thanks for the feedback. 1. Peer 1 doesn't need to be a trusted third party, it can be implemented in a way that some peers involved in this system can provide liquidity for others and incentives can be a small fee. 2. Yes joinmarket is awesome and its payjoin will be better to achieve the same but I was trying to contribute and add more options for people to improve privacy on Bitcoin. If we have different ways to mix it will be harder for spy companies to analyze of some of the transactions. 3. Also one such setup might not make a huge difference but a chain of such mixers will surely work better if everything done correctly. 4. Maybe multisig usage is not ideal for such things right now and I am not the best person when it comes to coding but think that better privacy for multisig will make it possible for lot of ideas to be implemented on Bitcoin using different multisig setups and combination of other things that we already have. Prayank May 25, 2020, 12:24 by zmnsc...@protonmail.com: > Good morning Prayank > >> I have explained the whole idea with a proof of concept in this link: >> https://medium.com/@prayankgahlot/post-mix-usage-using-multisig-and-cpfp-e6ce1fdd57a1 >> > > The article is not clear I think, so please confirm my understanding below. > > Participants: > > * "Peer 3" - Payee > * "Peer 2" - Payer > * "Peer 1" - Enabling tr\*sted third party > > Goal: Payer wants to pay to the payee 0.006BTC > > Current Conditions: > > * Payer owns 0.01 BTC in a single UTXO > * Third Party owns 0.05 BTC in a single UTXO > > Protocol: > > 1. Payer and Third Party compute a 2-of-3 address with the public keys of > Payer, Payee, and Third Party. > 2. Payer and Third Party individually pay their owned funds to the 2-of-3 > address. > 3. After confirmation, they consume the new outputs into another transaction > with equal-valued outputs, hiding who owns which coins. > > Is my understanding correct? > > If so, I believe JoinMarket has a superior technology, which does not require > a tr\*sted third party; it simply requires one or more UNtrusted third > parties to participate in signing a single transaction that does not require > paying to an intermediate m-of-n address (thus all inputs are singlesig). > > Basically JoinMarket allows the market taker to decide how much the > equal-value outputs are, and to define the address it goes to. > The destination address need not be one the market taker controls, it can be > to a payee. > This technique is the only out-of-the-box way that a JoinMarket wallet can > spend funds from a JoinMarket wallet. > > JoinMarket as well already includes how to get in touch with enabling third > parties (called "market makers"). > > > Regards, > ZmnSCPxj > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] hashcash-newhash
Hi ZmnSCPxj, We have been addressing many concepts. Let's try to slowly trim it down for simplicity. > Reddit claims two entities controlled 62% of the hashrate recently: > https://old.reddit.com/r/CryptoCurrency/comments/gmhuon/in_the_last_24_hours_bitcoins_nakamoto/ > . Compromising the systems of these two groups seems like it is all that > is needed to compromise the entire blockchain (to the limited degree a 51% > attack does). > > You seem to be equating "break of the hash function" with "centralization > of hashrate", which I do not quite agree with. > I am trying to say that both of these different things result in danger to the integrity of the transaction log, which would be reduced by changing the hash function. They both have those 2 similarities. Most human beings cannot think without constant communication with other > human beings. Thus, it is unlikely that a private break of the hash function is possible. > I disagree with you here: Andrew Wiles solved Fermat's Last Theorem in isolation, academic research paper culture supports researching and then publishing once you have privately developed results, and the CVE database has 136k system vulnerabilities that were developed and shared privately before public release, to prevent chaos. This shows private advances in ways to produce bitcoins are likely. > Would it be helpful if I outlined more ideas that address your concerns? > I want to make sure the idea of changing the algorithm is acceptable at all > first. > > Go ahead. > Thanks: are you saying you would support changes if they addressed the concerns you've listed? Or are those concerns only the tip of the iceberg, per se? > > > You mention the cost of power as the major factor influencing > decentralized mining. Would you agree that access to hardware that can do > the mining is an equally large factor? Even without ASICs you would need > the physical cycles. Including this factor helps us discuss the same set > of expected situations. > > > > > > No, because anyone who is capable of selling hardware, or the > expertise to design and build it, can earn by taking advantage of their > particular expertise. > > > > > > Generally, such experts can saturate the locally-available energy > sources, until local capacity has been saturated, and they can earn even > more by selling extra hardware to entities located at other energy sources > whose local capacities are not still underutilized, or expanding themselves > to those sources. > > > Other entities might be in better position to take advantage of > particular local details, and it may be more lucrative for the > expert-at-building-hardware to just sell the hardware to them than to > attempt to expand in places where they have little local expertise. > > > > It sounds like you are saying that the supply of electricity is > exhausted and the supply of hardware is not. > > > > Is that correct? > > Given that electricity is consumed very quickly, and hardware takes a long > time to truly consume or obsolete, yes: rate of consumption of electricity > is expected to dominate compared to the rate of consumption of hardware. > I'm considering short-term obsolescence here. Since hashrate rises exponentially, only top-of-the-line hardware is competitively profitable. > I've seen that most of the time mining hardware distributors are sold out > of their top-of-the-line mining equipment, mostly selling in preorders. > Are implying most of the mining is done by privately built equipment? > > It seems the most lucrative thing to do, that if you have a new generation > of hardware, to mine with them yourself, until the price of local > electricity has increased due to your consumption, and it becomes more > lucrative to sell the hardware to other potential miners who now have lower > electricity prices compared to yours (because you have been saturating the > local electricity supply with your own mining operations and causing the > local prices to rise up, or equivalently, until some governmental or other > limits your usable electricity supply, which is equivalent to saying that > the price of even more electricity would be your incarceration or other > punishment, which might be too expensive for you to pay, thus selling the > hardware is more lucrative). > If consumers who do not have the capacity to build their own hardware fast enough to be competitive, do not have as much access to such hardware, then their excess electricity is not being used to mine bitcoins. A bit below you propose spreading access via mass teaching, but I'm not aware of that happening for now. You could also analyze the transient economic behaviors here, specifically > that an increase in Bitcoin price makes it more lucrative to mine in more > places, which would start to put in orders for more hardware, and the > hardware will take time to deliver, so the price at those places will > increase only after a long while, etc. > But those are transient
Re: [bitcoin-dev] hashcash-newhash
Hi Ariel, Thanks for your reply. You state that once "the entire world" can quickly find a hash that it then "needs to be changed", but that that "won't happen in a day". It sounds like you believe compromise of the algorithm as a concern provides a _lot_ of time to migrate to a new hash function, and that it is indeed important to do so when it becomes needed. Let's talk about relaxing the time scale. Making such plans seems more important than agreeing on how soon they happen. It's possible it could be decades before having a new hash is actually needed to protect financial security. Who knows. How does that land? Is the idea more available with a looser time scale? It seems to me with ongoing cryptanalysis research, new things like quantum computers, conventional computer hardware always advancing, that some day far in the future it will be easy to find an sha256 preimage on a personal device, somehow. Let's improve the security of the blockchain. On Sun, May 24, 2020, 7:51 PM Ariel Lorenzo-Luaces wrote: > On May 24, 2020, at 1:26 PM, Karl via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> You mention ASICs becoming commoditized. I'd remind you that eventually >> there will be a public mathematical breaking of the algorithm, at which >> point all ASICs will become obsolete regardless. Would you agree it would >> be better to prepare for this by planning algorithm change? >> >> Cryptographic algorithms don't usually break this way. In the case of >> hash functions it may be possible to find an exploit that reduces the >> function's security from 256 bits to 128 for example. So an algorithm that >> could find 80 zero bits per energy unit before can now find 160 zero bits >> per energy unit with an exploit. >> >> If this exploit can be deployed as a software patch to most ASICs then >> the issue will sort itself out on the next difficulty adjustment. >> >> If the exploit instead requires an entirely new ASIC then GPUs and FPGAs >> that could previously find 40 zero bits per energy unit can now compete >> with the less adaptive ASICs until new ASICs that use the exploit start >> getting produced and shipped. >> >> There's never any official "public breaking" of a hash function. The >> function will just loose security over time until it's deemed to not be >> "secure enough" for certain applications. Thankfully mining is an >> application where the only important thing is that the difficulty can be >> increased. In other words, if the entire world can consistently find 256 >> zero bits of SHA-256 in under 10 minutes then definitely the hash function >> needs to be changed. But this won't happen in a day. >> > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] hashcash-newhash
On May 24, 2020, 1:26 PM, at 1:26 PM, Karl via bitcoin-dev wrote: >Hi ZmnSCPxj, > >Thanks for your reply. I'm on mobile so please excuse me for >top-posting. > >I'd like to sort these various points out. Maybe we won't finish the >whole >discussion, but maybe at least we can update wiki articles like >https://en.bitcoin.it/wiki/Hashcash#Cryptanalytic_Risks with more >points or >a link to conversations like this. > >Everything is possible but some things take a lot of work. > >You mention ASICs becoming commoditized. I'd remind you that >eventually >there will be a public mathematical breaking of the algorithm, at which >point all ASICs will become obsolete regardless. Would you agree it >would >be better to prepare for this by planning algorithm change? > >You mention many coordinated hardforks. Would you agree that if we >came up >with a way of programmatically cycling the algorithm, that only one >hardfork work be needed? For example one could ask nodes to consent to >new >algorithm code written in a simple scripting language, and reject old >ones >slowly enough to provide for new research. > >You mention the cost of power as the major factor influencing >decentralized >mining. Would you agree that access to hardware that can do the mining >is >an equally large factor? Even without ASICs you would need the >physical >cycles. Including this factor helps us discuss the same set of >expected >situations. > >You describe improving electricity availability in expensive areas as a >way >to improve decentralization. Honestly this sounds out of place to me >and >I'm sorry if I've upset you by rehashing this old topic. I believe >this >list is for discussing the design of software, not international energy >infrastructure: what is the relation? There is a lot of power to >influence >behavior here but I thought the tools present are software design. > >On Sat, May 23, 2020, 9:12 PM ZmnSCPxj wrote: > >> Good morning Karl, >> >> > Hi, >> > >> > I'd like to revisit the discussion of the digest algorithm used in >> hashcash. >> > >> > I believe migrating to new hashing algorithms as a policy would >> significantly increase decentralization and hence security. >> >> Why do you believe so? >> >> My understanding is that there are effectively two strategies for >ensuring >> decentralization based on hash algorithm: >> >> * Keep changing the hash algorithm to prevent development of ASICs >and >> ensure commodity generic computation devices (GPUs) are the only >practical >> target. >> * Do not change the algorithm, to ensure that knowledge of how best >to >> implement an ASIC for the algorithm becomes spread out (through >corporate >> espionage, ASIC reverse-engineering, patent expiry, and sheer >engineering >> effort) and ASICs for the algorithm are as commoditized as GPUs. >> >> The former strategy has the following practical disadvantages: >> >> * Developing new hash algorithms is not cheap. >> The changes to the hashcash algorithm may need to occur faster than >the >> speed at which we can practically develop new, >cryptographically-secure >> hash algorithms. >> * It requires coordinated hardforks over the entire network at an >> alarmingly high rate. >> * It arguably puts too much power to the developers of the code. >> >> On the other hand, the latter strategy requires us only to survive an >> intermediate period where ASICs are developed, but not yet >commoditized; >> and during this intermediate period, the centralization pressure of >ASICs >> might not be more powerful than other centralization pressures >> >> -- >> >> Which brings us to another point. >> >> Non-ASIC-resistance is, by my understanding, a non-issue. >> >> Regardless of whether the most efficient available computing >substrate for >> the hashcash algorithm is CPU, GPU, or ASIC, ultimately miner >earnings are >> determined by cost of power supply. >> >> Even if you imagine that changing the hashcash algorithm would make >CPUs >> practical again, you will still not run it on the CPU of a mobile, >because >> a mobile runs on battery, and charging a battery takes more power >than what >> you can extract from the battery afterwards, because thermodynamics. >> >> Similarly, geographic locations with significant costs of electrical >power >> will still not be practical places to start a mine, regardless if the >mine >> is composed of commodity server racks, commodity video cards, or >commodity >> ASICs. >> >> If you want to solve the issue of miner centralization, the real >solution >> is improving the efficiency of energy transfer to increase the areas >where >> cheap energy is available, not stopgap >change-the-algorithm-every-6-months. >> >> >> Regards, >> ZmnSCPxj >> >> >> > >> > I believe the impact on existing miners could be made pleasant by >> gradually moving the block reward from the previous hash to the next >(such >> that both are accepted with different rewards). An appropriate rate >could >> possibly be calculated from
Re: [bitcoin-dev] hashcash-newhash
Good morning Kari, > > > You mention ASICs becoming commoditized. I'd remind you that eventually > > > there will be a public mathematical breaking of the algorithm, at which > > > point all ASICs will become obsolete regardless. Would you agree it > > > would be better to prepare for this by planning algorithm change? > > > > Possibly, but then the reason for change is no longer to promote > > decentralization, would it? > > > It helps to be clear about what your goals are, because any chosen solution > > might not be the best way to fix it. > > I admit that, if the problem were to be avoid the inevitable obsoletion of > > SHA-2, then this is the only solution, but that is not the problem you > > stated you were trying to solve in the first place. > > To be up front, the reason for decentralization is due to concern around the > security of the hashing. Having a public breakage of the function simply > makes the urgency obvious. Now that I have thought about it more: again, the important thing about the proof-of-work technique is not so much the algorithm itself, only that executing it requires energy. And all algorithms require energy in order to execute. Even if some technique is found which partially breaks the hash function and allows faster generation of hashes for the amount of energy consumed, this is not a problem for mining itself: the difficulty adjusts and mining continues. The execution of this technique is unlikely to require no computation, only reduced computational effort; and all that is needed is *some* measure of computational effort done, the *scale* of that measure is not really material for the purpose of ordering atomic transactional updates to the UTXO set. Of course, things like the Merkle tree and txids and so on would need changing in case of even a partial break of the hash function, which would require a hardfork to survive; you might as well change the proof-of-work function as well then. > > Reddit claims two entities controlled 62% of the hashrate recently: > https://old.reddit.com/r/CryptoCurrency/comments/gmhuon/in_the_last_24_hours_bitcoins_nakamoto/ > . Compromising the systems of these two groups seems like it is all that is > needed to compromise the entire blockchain (to the limited degree a 51% > attack does). You seem to be equating "break of the hash function" with "centralization of hashrate", which I do not quite agree with. Most human beings cannot think without constant communication with other human beings. Thus, it is unlikely that a private break of the hash function is possible. Instead, a break of the hash function is likely to be discovered in various ways by multiple human beings who have been communicating with each other. Even historically, inventions never arose fully-formed from the head of the inventor, like Athena from the brow of Zeus; every invention has predecessors, successors, and peers in the inhabited milieu. Instead, you can look up the costs of local electricity globally, and notice where those entities have their largest mines geographically located. > > Hence I see decentralization and cryptanalysis of the algorithm to be roughly > similar security concerns. > > It sounds like you agree that a change of algorithm is needed before the > current one is publicly broken. > > > > You mention many coordinated hardforks. Would you agree that if we came > > > up with a way of programmatically cycling the algorithm, that only one > > > hardfork work be needed? For example one could ask nodes to consent to > > > new algorithm code written in a simple scripting language, and reject old > > > ones slowly enough to provide for new research. > > > > Even *with* a scripting language, the issue is still what code written in > > that language is accepted, and *how*. > > > > Do miners vote on a new script describing the new hashing algorithm? > > What would their incentive be to obsolete their existing hardware? > > (using proof-of-work to lock in a hashing change feels very much like a > > chicken-and-egg problem: the censorship-resistance provided by Bitcoin is > > based on evicting any censors by overpowering their hashpower, but requires > > some method of measuring that hashpower: it seems unlikely that you can > > safely change the way hashpower is measured via a hashpower election) > > > > Do nodes install particular scripts and impose a switchover schedule of > > some sort? > > Then how is that different from a hardfork, especially for nodes that do > > not update? > > (notice that softforks allow nodes to remain non-updated, at degraded > > security, but still in sync with the rest of the network and capable of > > transacting with them) > > I'm expressing that in considering this we have two options: repeated hard > forks or making repeated change a part of the protocol. There are many ways > to approach or implement it. It sounds like you're noting that the second > option
Re: [bitcoin-dev] Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet
Good morning Prayank > I have explained the whole idea with a proof of concept in this link: > https://medium.com/@prayankgahlot/post-mix-usage-using-multisig-and-cpfp-e6ce1fdd57a1 The article is not clear I think, so please confirm my understanding below. Participants: * "Peer 3" - Payee * "Peer 2" - Payer * "Peer 1" - Enabling tr\*sted third party Goal: Payer wants to pay to the payee 0.006BTC Current Conditions: * Payer owns 0.01 BTC in a single UTXO * Third Party owns 0.05 BTC in a single UTXO Protocol: 1. Payer and Third Party compute a 2-of-3 address with the public keys of Payer, Payee, and Third Party. 2. Payer and Third Party individually pay their owned funds to the 2-of-3 address. 3. After confirmation, they consume the new outputs into another transaction with equal-valued outputs, hiding who owns which coins. Is my understanding correct? If so, I believe JoinMarket has a superior technology, which does not require a tr\*sted third party; it simply requires one or more UNtrusted third parties to participate in signing a single transaction that does not require paying to an intermediate m-of-n address (thus all inputs are singlesig). Basically JoinMarket allows the market taker to decide how much the equal-value outputs are, and to define the address it goes to. The destination address need not be one the market taker controls, it can be to a payee. This technique is the only out-of-the-box way that a JoinMarket wallet can spend funds from a JoinMarket wallet. JoinMarket as well already includes how to get in touch with enabling third parties (called "market makers"). Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
