Karl [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2020-05-23 to 2021-12-12
💬 Posted a total of 22 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 13:04:33

- reply

📅 Original date posted:2021-12-06
📝 Original message:
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211206/f3253ec4/attachment.html>

2023-06-07 23:01:11

- reply

📅 Original date posted:2021-12-12
📝 Original message:On Sun, Dec 12, 2021, 7:42 AM Aymeric Vitte via bitcoin-dev <
bitcoin-dev at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211212/b747ded8/attachment.html>

2023-06-07 23:00:50

- reply

📅 Original date posted:2021-12-06
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211206/f3253ec4/attachment.html>

2023-06-07 22:58:09

- reply

📅 Original date posted:2021-08-19
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210819/566d8d96/attachment.html>

2023-06-07 22:54:00

- reply

📅 Original date posted:2021-05-24
📝 Original message: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.

2023-06-07 22:53:58

- reply

📅 Original date posted:2021-05-23
📝 Original message:>> 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.

2023-06-07 22:53:57

- reply

📅 Original date posted:2021-05-23
📝 Original message:On 5/23/21, ZmnSCPxj via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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
<bitcoin-dev at lists.linuxfoundation.org> 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.

2023-06-07 22:53:28

- reply

📅 Original date posted:2021-05-16
📝 Original message:> 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 <zachgrw at gmail.com> 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.

2023-06-07 22:53:27

- reply

📅 Original date posted:2021-05-16
📝 Original message:On 5/16/21, Eric Voskuil via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> 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.

2023-06-07 22:53:26

- reply

📅 Original date posted:2021-05-16
📝 Original message:[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.

2023-06-07 22:52:39

- reply

📅 Original date posted:2021-05-08
📝 Original message:>
> What is more important;
> Bitcoin mining introduces the first free-market demand for the cheapest
> energy source.
This is a really great idea but I think access to technologically advanced
hardware is a stronger component than energy here.
Making open community chip fabs might change that. Then anybody could get
on the bandwagon. But right now the hardware barrier keeps the common
person out.
If you can build a chip fab, you may also be able to build a powerplant.
Not many others can do that to compete with you. The energy economy still
has more supply than competition or renewable energy would quickly
outcompete nonrenewable as the price dropped.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210508/416f416a/attachment.html>

2023-06-07 22:52:38

- reply

📅 Original date posted:2021-05-09
📝 Original message:On Sun, May 9, 2021, 6:21 AM R E Broadley <
rebroad+linuxfoundation.org at gmail.com> wrote:
> On Sat, 8 May 2021 at 15:36, Karl via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210509/6cd06ec8/attachment-0001.html>

2023-06-07 22:52:37

- reply

📅 Original date posted:2021-05-08
📝 Original message: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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210508/0f6fc4e7/attachment.html>

2023-06-07 22:52:07

- reply

📅 Original date posted:2021-04-30
📝 Original message: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 at 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
> > <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
> > <bitcoin-dev at lists.linuxfoundation.org
> > <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> >
> > On Sat, Apr 24, 2021 at 04:42:12AM +0000, 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 at lists.linuxfoundation.org
> > <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210430/1ee7c171/attachment.html>

2023-06-07 18:24:48

- reply

📅 Original date posted:2020-05-24
📝 Original message: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 <ZmnSCPxj at protonmail.com> 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.
> >
> > I'm interested in hearing thoughts and concerns.
> >
> > Karl Semich
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200524/3d22a130/attachment-0001.html>

2023-06-07 18:24:47

- reply

📅 Original date posted:2020-05-23
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200523/624d6e42/attachment.html>