[bitcoin-dev] Post-mix(coinjoin) usage with multisig and cpfp in bitcoin core wallet
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 Does it make sense to add such options in bitcoin core wallet and how is the overall idea once we have taproot because for now people can check if the tx involves a multisig address? Reading Peter Wuille's reply here it seems taproot will improve privacy for multisig: https://www.reddit.com/r/Bitcoin/comments/etagx4/please_explain_taproot_and_schnorr_signatures/fffljnl/ Looking for some feedback to work on this idea and don't want it to just remain an article on medium. Thanks Prayank ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
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. > > 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) > > 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. And expertise is easy to copy, it is only the initial expertise that is hard to create in the first place, once knowledge is written down it can be copied. > > 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. I doubt there is any good software-only solution to the problem; the physical world remains the basis of the virtual one, and the virtual utterly dependent on the physical, and abstractions are always leaky (any non-toy software framework inevitably gains a way to query the operating system the application is running under, because abstractions inevitably leak): and energy, or the lack thereof, is the hardest to abstract away, which is the entire point of using proof-of-work as a reliable, unfakeable (i.e. difficult to virtualize) clock in the first place. Still, feel free to try: perhaps you might succeed. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] hashcash-newhash
Good afternoon ZmnSCPxj, Thanks for holding your end of this discussion with me. Sorry I am so verbose; I am still learning to communicate efficiently. > 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. 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). 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 takes some work and care? 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. > 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? 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? Would you agree that an increase in the price of bitcoin would make the availability of hardware matter much more, because the price of electricity would matter much less? Something to raise here is that all of these things take time
Re: [bitcoin-dev] hashcash-newhash
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 the difficulty. > > > > You could develop the frequency of introduction of new hashes such that > once present-day ASICs are effectively obsolete anyway due to competition, > new ones do not have time to develop. > > > >
