Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network

[Karl via bitcoin-dev]

On Sun, Dec 12, 2021, 7:42 AM Aymeric Vitte via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Indeed, I reiterate that using the Tor network for Bitcoin or whatever
> protocol not related to the Tor Browser (ie browsing and HS) does not make
> sense, for plenty of reasons
>

Please cite this.  It is very hard to believe.

Personally, I have encountered network blocking of bitcoin peers, and Tor
is one way to reconnect with the network when this happens.


Regardless, reasonable rebroadcasting of nonlocal transactions is a
hands-down good thing.  This does not make them anonymous, but it does make
it a little harder to track their origin, and additionally it makes their
transmission more robust.

Every extra measure is a good thing, as everything eventually fails.

>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Sending OP_RETURN via Bitcoin Lightning

[Karl via bitcoin-dev]

Hi,

I'm not a bitcoin developer.

On Mon, Dec 6, 2021, 5:05 AM Héctor José Cárdenas Pacheco via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello all,
>
> I’ve been thinking about how OP_RETURN is being used to create and trade
> NFTs on Bitcoin (think RarePepes, SoG and other new ones) and was wondering
> if it’s possible to
>

Do you have a link to any of these protocols?

make transactions with this opcode via Lightning.
>
> More specific questions could be:
>
>1. Can opcodes like OP_RETURN be inside a channel’s opening or closing
>transaction?
>2. If so, could that OP_RETURN change hands within that channel or
>network of channels?
>
> OP_RETURNs do not have ownership according to the bitcoin network.  It is
not hard to define a protocol that associates an OP_RETURN with ownership,
and ownership could then be transferred via lightning by sending associated
currency via lightning.  Robustness improvements seem possible.


>1. If possible, could the OP_RETURN be divisible? Could one person
>send a piece of a OP_RETURN just like one can do right now on the primary
>ledger or would it need to maintain the OP_RETURN code intact?
>
> OP_RETURNs themselves do not have ownership, but you can define a protocol
that gives them divisible ownership, including via lightning.

I’m assuming that, if possible, this would need a protocol layer parallel
> to Bitcoin/Lightning that stores and reads all Bitcoin transactions and the
> ones which involve the node's channels as well as the ones with the
> OP_RETURN, just like CounterParty does right now with the primary ledger.
>
> Thank in advance.
> ——
>
> *Héctor Cárdenas*@hcarpach
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

[Karl via bitcoin-dev]

Something that could work really well here could be having a norm of using
the checksum for bright colors, weights, sizes, capitalizations, and/or
spacing of the characters of the address, making different addresses more
clearly visually distinct.

Ethereum uses mixed case to do this a little bit:
https://eips.ethereum.org/EIPS/eip-55#implementation

It seems to me the checksum at the end of the address is sufficient for
differentiating error, but making a checksum more visually distinctive is
indeed an opportunity to add another digest, reducing collisions and such.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Removing the Dust Limit

[Karl via bitcoin-dev]

Why would removing the dust limit impact decentralisation of mining if
miners can reconfigure the dust limit for their mined blocks?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Reducing block reward via soft fork

[Karl via bitcoin-dev]

If bitcoin were to ever consider changing their PoW algorithm a
little, it seems that would immediately make purchased ASIC mining
equipment partially or wholly unusable to compromise the chain (and
temporarily reduce energy usage without necessarily reducing
security).  One possible plan to deter a multibillionaire attack.

Also regarding the word "security" here, a 51% attack impacts some
parts of chain operations, but not others.

It seems to me bitcoin's biggest vulnerabilities are either covert
compromise of mining pool operations, or widespread compromise of
networked mining systems and client nodes.  Far easier than
outcompeting the mining network with hardware.

I don't see why it would necessarily be made public if a government
compromised their nation's mining farms.  Governments have skilled
operatives for things like that.  People would guess it happened, and
the government would cover up the guesses with more powerful stories.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Reducing block reward via soft fork

[Karl via bitcoin-dev]

>> The turn-around time for that takes a population of both users and
>> miners to cause. Increasing popularity of bitcoin has a far bigger
>> impact here, and it is already raising fees and energy use at an
>> established rate.
>>
>> If it becomes an issue, as bandwidth increases block size could be
>> raised to lower fees.
>>
>
> Which increases block rewards somewhat (at least to some level that matches
> the overall security of the network) and you still have the same amount of
> energy consumed.

If you mean to implicitly propose that even if halved all the way with
very large blocks, block rewards would just increase to the same
level, meaning that any attempt to decrease them has no effect, I
disagree.I expect that if you raise the block size, eventually
there is so much supply for transactions that there are no fees at all
(nor security).  The numbers are all things the devs, miners, and
users can together control.

> How to prove this is not happening?
> The best you can do is to have some number of authorities sign off on
> whether or not they are doing this.
> The problem is that authorities are bribeable.

You could make the proof of work be a proof of environmental kindness
by coding incentives for people to place and verify proof on the
chain, and then rewarding people for acting on it as desired.  You
could code the chain to pay people to investigate and prove miners'
business practices, for example.  You could define the main chain as
one where everyone consents the proofs are valid.  There are a lot of
issues to resolve and it would be a very different chain.

There is not a single solution here.  There are innumerable possible
solutions, any one of which could be made to work with enough brains
working on it.  To use one, we need to agree on what kinds of
solutions are acceptable.

> Alternately, other entities in the locality can use force to require the
> polluting entity to clean up or suffer significant consequences.
> This at least is better incentive-wise, as they others in the same locality
> are the ones most affected, but the ability to enforce may be difficult due
> to various political constructions; the miners could be in such deep cahoots
> with the local government that the local government would willingly hurt
> other local entities in the vicinity of the polluting entity.

As bitcoin grows, if people ask some locality to enforce behavior,
they may need to be willing to enforce it themselves, too, or they
might outcompete the locality.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Reducing block reward via soft fork

[Karl via bitcoin-dev]

On 5/23/21, ZmnSCPxj via bitcoin-dev
 wrote:
> Good morning James,
>
>> Background
>> ===
>> Reducing the block reward reduces the incentive to mine. It reduces the
>> maximum energy price at which mining is profitable, reducing the energy
>> use.
>>
>
> If people want to retain previous levels of security, they can offer to pay
> higher fees, which increases the miner reward and thereby increasing the
> energy use again.

The turn-around time for that takes a population of both users and
miners to cause.  Increasing popularity of bitcoin has a far bigger
impact here, and it is already raising fees and energy use at an
established rate.

If it becomes an issue, as bandwidth increases block size could be
raised to lower fees.

> Properly account for the entropy increase (energy usage) of all kinds of
> pollution, and the free market will naturally seek sustainable and renewable
> processes --- because that maximizes profitability in the long run.

There is little economic incentive to fine carbon emissions because
there is no well-established quick path to gain profit from reducing
them.  The feedback paths you describe take decades if not hundreds of
years.

But it sounds like you are saying you would rather the energy issue
stay a political one that does not involve bitcoin.  Your point is
quite relevant because bitcoin is not the largest consumer of energy;
those who care about reducing energy use would be better put to look
at other concerns.

The reason to reduce _bitcoin's_ energy use, would simply be to aid
its popularity and quell public concern.  Without doing this, people
move to an altcoin, because increasing the value of bitcoin via
spreading its use, increases the demand for mining.  That human
decision is part of the honesty you describe.

> What is needed is to enforce that pollution be paid for by those who cause
> it --- this can require significant political influence to do (a major world
> government is a major polluter, willing to pay for high fuel costs just to
> ship their soldiers globally, polluting the environments of foreign
> countries), and should be what true environmentalists would work towards,
> not rejecting Bitcoin as an environmental disaster (which is frankly
> laughable).
>
> Remember, the free market only works correctly if all its costs are
> accounted correctly --- otherwise it will treat costs subsidized by the
> community of human beings as a resource to pump.

It sounds like you would prefer a proof-of-work function that directly
proved carbon offsetting?  And an on-chain tax for environmental harm?

On 5/23/21, Anton Ragin via bitcoin-dev
 wrote:
> Well, it is done automatically every 4 years :) It is a self-balancing
> system - more people shout about Bitcoin being dirty -> less adoption ->
> lower the price -> less energy consumption. Add on top the fact that in
> 2024 block rewards will fall 50% anyway and someday it will be zero.

Is hashrate rising slower than the block reward is dropping, that you
mention the 4 years halving?  Do you see a problem with dropping the
block reward to make faster change to the hashrate curve, that you
mention the existing system's weaker approach?

I personally wasn't aware that Elon had complained; I've been hearing
the complaint from scads of people for many years.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy

[Karl via bitcoin-dev]

On 5/16/21, Eric Voskuil via bitcoin-dev
 wrote:
> https://github.com/libbitcoin/libbitcoin-system/wiki/Efficiency-Paradox
> https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Memory-Fallacy

The chain security actually reduces by 10% in this proposal.  So the
efficiency paradox is not violated, it is just the real cost of
confirming a transaction is reduced, because there is actually less
security. This eventually reduces the price of bitcoin and reduces the
amount of electricity the block reward can eventually buy.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy

[Karl via bitcoin-dev]

> 1. Has anyone considered that it might be technically not possible to 
> completely 'power down' mining rigs during this 'cool-down' period of time? 
> While modern CPUs have power-saving modes, I am not sure about ASICs used for 
> mining.

Sounds like a point to consider, note the economic pressure of course
so most people will find a way to power down.

> 2. I am not a huge data-center specialist, but it was my understanding that 
> they charge per unit of installed (maximum) electricity consumption. It would 
> mean that if the miner needs X kilowatts-hour within that 1 minute when they 
> are allowed to mine, he/she will have to pay for the same X for the remaining 
> 9 minutes - and as such would have no economic incentive not to draw that 
> power when idling.

That sounds kind of exotic, could you take charge of checking to see
how true it is?

> (a) Environmental concerns cause Bitcoin to be less popular and thus push the 
> price lower, which in turn lowers miner's power consumption (lower Bitcoin 
> price => less they can afford to spend on electricity). So it is a 
> self-stabilizing system to begin with.

I like the idea but history shows that money outcompetes cute animals.

> (b) Crazy power consumption may be a temporary problem, after the number of 
> halving events economic attractiveness of mining will decrease and power 
> consumption with it.

If hashrate flattens, the chain security situation changes too.

> 4. My counter-proposal to the community to address energy consumption 
> problems would be to encourage users to allow only 'green miners' process 
> their transaction. In particular:

This cool idea of providing a way for users to support different
miners with their transactions is not in conflict with reducing mining
time.  Both of these ideas are great ones; they are very different.

On 5/16/21, Zac Greenwood  wrote:
>> if energy is only expended for 10% of the same duration, this money must
> now be spent on hardware.
>
> More equipment obviously increases the total energy usage.

Are there people who can freely produce new mining equipment to an
arbitrary degree?  As I mentioned already and you didn't address, I
thought the supply was limited.

> For your proposal again this means that energy usage would not be likely to 
> decrease appreciably, because large miners having access to near-free energy 
> use the block-reward sized budget fully on equipment and other operational 
> expenses.

Purchasing equipment with the same funds is unrelated to whether or
not the machines are running full blast during a theoretical 90%
downtime when a hash cannot succeed.  If their electricity is free,
they have no new funds to buy equipment with.

Additionally, you claim that all these people use renewable energy so
I don't know why they are being discussed at all.

> On the other hand, roughly every four years the coinbase reward halves, which 
> does significantly lower the miner budget, at least in terms of BTC.

Adjusting that could be another good approach to influencing
properties of the chain.  I think there's another thread around it,
rather than this one.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy

[Karl via bitcoin-dev]

[sorry if I haven't replied to the other thread on this, I get swamped
by email and don't catch them all]

This solution is workable but it seems somewhat difficult to me at this time.

The clock might be implementable on a peer network level by requiring
inclusion of a transaction that was broadcast after a 9 minute delay.

Usually a 50% hashrate attack is needed to reverse a transaction in
bitcoin.  With this change, this naively appears to become a 5%
hashrate attack, unless a second source of truth around time and order
is added, to verify proposed histories with.

A 5% hashrate attack is much harder here, because the users of mining
pools would be mining only 10% of the time, so compromising mining
pools would not be as useful.

Historically, hashrate has increased exponentially.  This means that
the difficulty of performing an attack, whether it is 5% or 50%, is
still culturally infeasible because it is a multiplicative, rather
than an exponential, change.

If this approach were to be implemented, it could be important to
consider how many block confirmations people wait for to trust their
transaction is on the chain.  A lone powerful miner could
intentionally fork the chain more easily by a factor of 10.  They
would need to have hashrate that competes with a major pool to do so.

> How would you prevent miners to already compute the simpler difficulty 
> problem directly after the block was found and publish their solution 
> directly after minute 9? We would always have many people with a finished / 
> competing solution.

Such a chain would have to wait a longer time to add further blocks
and would permanently be shorter.

> Your proposal won’t save any energy because it does nothing to decrease the 
> budget available to mine a block (being the block reward).

You are assuming this budget is directly related to energy
expenditure, but if energy is only expended for 10% of the same
duration, this money must now be spent on hardware.  The supply of
bitcoin hardware is limited.

In the long term, it won't be, so a 10% decrease is a stop-gap
measure.  Additionally, in the long term, we will have quantum
computers and AI-designed cryptography algorithms, so things will be
different in a lot of other ways too.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Opinion on proof of stake in future

[Karl via bitcoin-dev]

On Sun, May 9, 2021, 6:21 AM R E Broadley <
rebroad+linuxfoundation@gmail.com> wrote:

> On Sat, 8 May 2021 at 15:36, Karl via bitcoin-dev
>  wrote:
> > Bitcoin would get better mainstream public reputation if the block
> reward were reduced to reduce mining.  This would quickly and easily reduce
> energy expenditure.
>
> You're in luck then, as the block reward is being reduced by 50%, every 4
> years.
>

I'm aware of that and it is why I mentioned "block reward termination" in
the next paragraph... did you receive the rest of my message?  Or why do
you say this?

>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Opinion on proof of stake in future

[Karl via bitcoin-dev]

Bitcoin would get better mainstream public reputation if the block reward
were reduced to reduce mining.  This would quickly and easily reduce energy
expenditure.

A system would be needed to do that with consensus, to make it political.
For example, making a norm of extending the block reward termination
farther into the future, spreading the remaining coins out more thinly, but
never doing the opposite.

PoS can be made to work but it's hard to do so amid such disagreement.  It
is so hard to express one's relevant information concisely and effectively.

I recommended earlier finding or hiring an experienced facilitator who
could make sure all concerns around the chain are included by engaging all
the dialog more productively.  Somebody would need to be available to do
the work of finding such a person and any compensation they might need.

On Fri, May 7, 2021, 7:05 PM Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fallacy
>

This wiki states things as impossible but does not at all demonstrate them
to be so.

The assumption that something is impossible always relies on many other
assumptions, and the reader may have different ones from the author.

Quote from Proof-of-Stake-Fallacy
> In Other Means Principle it is shown that censorship resistance depends
on people paying miners to overpower the censor.
> Overcoming censorship is not possible in a PoS system, as the censor has
acquired majority stake and cannot be unseated.

If the link in that text is followed you get,

Quote from Other Means Principle:
> Given that mining is necessarily anonymous, there is no way for the
economy to prevent state participation in mining.

The article then goes on to assume this, but "no way" is a circular link
back to Proof-of-Stake-Fallacy!

Never is it demonstrated that a censor will always be able to have majority
stake.  In a PoS system, they would have to be able to form false chain
histories to do that.  In a PoW system, they would have to outcompete the
work.

These are not inherent limitations.  The whole world is open.  Consider a
proof of work algorithm that requires the freeing of prisoners: a state a
very different state if it does this.  Or a communication protocol that
already cannot be intercepted.  These things are exotically hard, but not
impossible, and show that the logic of the articles is not valid.

Another random idea: incentivising out-of-band channels, for example.
Mining blocks based on finding and uniting illegitimate forks.  Now a chain
functions by defeating its own censorship.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm

[Karl via bitcoin-dev]

A good solution here is to make it clear to visitors that facilitation,
mediation, and organisation help is badly needed in the core development
team.

People with such expertise can even be hired directly.

A good facilitator opens communication paths between all parties, leaving
everyone satisfied with decisions.  Don't accept a compromise if you can
look for something better.

On Fri, Apr 30, 2021, 8:00 AM Amir Taaki via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> A committee to guide the committee? You guys truly have lost the plot.
>
> All the good minds and cryptographers have left Bitcoin. What remains is
> an empty echo chamber.
>
> Truth is these problems start with lack of vision and long-term roadmap,
> not with the processes themselves.
>
> And the Bitcoin Core monopoly created this situation; one coin, one
> client, one vision. And the inevitable infighting for ultimate power.
>
> Really if we want to go down this route, there should be a long period
> of self reflection about where the problems began rather than patching
> some process and moving on.
>
> I propose Bitcoin Core is dissolved as the official Bitcoin project. The
> community is free to elect their preferred version of Bitcoin. And most
> importantly, Bitcoin developers commit to a fully specced standard that
> all implementations move towards using.
>
> On 4/28/21 12:30 AM, Jaime Caring via bitcoin-dev wrote:
> > Kalle should not be made an editor by an ad-hoc process. I reiterate
> > Greg's NACK.
> >
> > I propose that we form a stewardship committee of frequent contributors,
> > including you, Greg, and 21 others. The stewards appoint a small set of
> > editors with permanent oversight by the stewards. A defined process
> > prevents this controversy from arising in the future and makes
> > proceedings clear.
> >
> > My proposal has been moderated off of this list, but may be viewed here:
> > https://github.com/bitcoin/bips/pull/1113
> > 
> >
> > I care not for the role of initial transitory editor. I would be pleased
> > should any responsible community member shoulder this onus in my stead.
> >
> > Peace be upon you,
> >
> > JC
> >
> > On Mon, 26 Apr 2021 at 00:37, David A. Harding via bitcoin-dev
> >  > > wrote:
> >
> > On Sat, Apr 24, 2021 at 04:42:12AM +, Greg Maxwell via
> > bitcoin-dev wrote:
> > > I am opposed to the addition of Kalle Alm at this time.  Those who
> > > believe [this] will resolve the situation [...] re: PR1104 are
> > > mistaken.
> >
> > PR1104 has been merged.  Do you continue to oppose the addition?
> >
> > Thanks,
> >
> > -Dave
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > 
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > 
> >
> >
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Statechain coinswap: assigning blame for failure in a two-stage transfer protocol.

[Karl via bitcoin-dev]

Coinswap has been a struggling goal for many years now.  Consider that
bitshares' dexbot just recently lost their funding.

Please make your projects usable before you announce you are working on
them, to keep your work safe from distraction or harm.

On Sun, Sep 13, 2020, 7:11 PM Tom Trevethan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> We are designing an off-chain coin-swap protocol that will work with the
> statechain implementation we are developing (
> https://github.com/commerceblock/mercury). The general idea is that coins
> deposited with a statechain entity (statecoins) can be transacted
> peer-to-peer off-chain in a way that the statechain entity (SCE) is
> trusted, but the statecoins always remain in the custody of the owners. A
> statecoin swapping service would enable owners to mix their coins with
> other users, giving the same privacy benefits of on-chain CoinSwap
> protocols, but by being off-chain statecoin swaps would be much faster and
> cheaper.
>
> The swapping service (conductor) would not have custody of the statecoins
> at any point. The aim is to have the conductor coordinate the swap amongst
> a group of statecoins (i.e. determine the which statecoin should be sent to
> which new random owner in the group) without being able to learn the link
> between owners and their provided addresses. To do this we will use a blind
> signature scheme in a similar way to the zerolink protocol.
>
> Here is a high-level description of how this blinding can operate - with
> the aim that the conductor does learn how the ownership of individual coins
> has changed.
> For example, imagine 4 individuals (A,B,C and D) who own equal value
> statecoins utxo1, utxo2, utxo3 and utxo4 respectively. They want to swap
> ownership privately, trusting the conductor/SCE to enforce atomicity. In
> other words, the conductor will randomly assign each statecoin to one of
> the owners (the mix), but will not be able to gain knowledge of that
> assignment.
> 1. A,B,C and D signal their participation by signing the swap_token (which
> has details of the swap) with the proof-key of their input coin. (A
> statecoin address is formed of a concatenation of the proof key and backup
> address).
> 2. Each of A,B,C and D then generate a new statecoin address (where they
> what to receive the swapped coin), which they blind (encrypt) and sign with
> the proof key of their input coin: add1, add2, add3 and add4 and send to
> the conductor.
> 3. The conductor authenticates each signature and then signs each payload
> (i.e. the blinded destination addresses) with a blinded signature scheme
> and returns these signatures to A,B,C and D.
> 4. Each of A,B,C and D then reconnects over TOR with a new identity.
> 5. Each of A,B,C and D then send their unblinded destination address with
> the conductor signature to the conductor (the conductor now knows that
> these 4 addresses belong to A,B,C and D, but not which ones map to each
> input.)
> 6. The conductor randomly assigns each address to one of utxo1, utxo2,
> utxo3 and utxo4 (e.g. utxo1:add3, utxo2:add1, utxo3:add4 and utxo4:add2)
> and requests each participant to initiate the transfer to the given
> address.
> 7. Each participant then finalises each transfer - if any transfer fails
> (due to a participant disappearing or acting maliciously) then all
> transfers are reverted - here atomicity is guaranteed by the SCE.
>
> The interesting problem we have with this protocol is how to assign blame
> in the case that one or more participants in the swap causes it to fail, so
> that the corresponding statecoins can be penalized (prevented from
> participating in further swaps for some timeout) to make any DoS attack
> costly. In the case of an on-chain coinjoin, this is easy: whoever didn't
> sign their input is to blame. However, in our statechain system a statecoin
> transfer is a two stage process (to update the private key shares): the
> sender performs an operation with the SCE (transfer_sender) and then sends
> an encrypted value to the receiver, who then performs the second operation
> with the SCE (transfer_reciever) which updates the UTXO private key shares
> for the new owner (
> https://github.com/commerceblock/mercury/blob/master/doc/statechains.md
> for more details). If the second stage fails (i.e. the values used for the
> key update protocol are wrong) this could be due to either the sender
> sending a bad/manipulated value to the receiver, or the receiver using bad
> values in the second operation with the SCE. Essentially, either the sender
> or the receiver can cause the transfer to fail, and it is not possible to
> determine which one is malicious without revealing the encrypted value sent
> between the sender and receiver (which must be kept secret from the SCE).
>
> All this means that if a multi-party coinswap fails, we will know which
> statecoin was involved in the failure, but we cannot determine whether the
> sender or receiver of that 

Re: [bitcoin-dev] hashcash-newhash

[Karl via bitcoin-dev]

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

[Karl via bitcoin-dev]

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

[Karl via bitcoin-dev]

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.
> >
> > 

Re: [bitcoin-dev] hashcash-newhash

[Karl via bitcoin-dev]

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 

[bitcoin-dev] hashcash-newhash

[Karl via bitcoin-dev]

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.

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.

I'm interested in hearing thoughts and concerns.

Karl Semich
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev