* [bitcoin-dev] Proposal to reduce mining power bill
@ 2018-01-15 22:47 Enrique Arizón Benito
2018-01-16 0:10 ` nullius
[not found] ` <CAAt2M1-KTyGPkwaRY=krAfMPUv797JaZyhF1e5g8e8yjjGWhmQ@mail.gmail.com>
0 siblings, 2 replies; 6+ messages in thread
From: Enrique Arizón Benito @ 2018-01-15 22:47 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1989 bytes --]
Hi all,
just new to the list and curious to know if next proposal (or similar) for
reducing mining-power consumption has already been discussed.
The objective is to reduce the power consumption required while keeping the
network safe and the miners "motivated" and cooperative to continue mining:
The global idea is to introduce the concept of "next-coinbase" for miners.
This will work something like as follow:
- Any miner submitting a block will submit the "next-coinbase" for any new
block mined by itself. (This address can be the same one or different from
the just mined block). The miner keeps the private key associated with the
"next-coinbase" secret.
- The consensus algorithm will add next checks:
A hash from, for example, the just mined block and the previous one, will
have to match up to N bits for the next "next-coinbase" from the next block
to be valid.
That means that for the next block only 1/2^N bitcoin addresses will be
accepted from the previously submitted "next-coinbase" list.
Since the last previous block hash can be considered random, miners know in
advance whether they will be able to participate or not in the next block
depending on the just submited "next-coinbase". And since the "punishment"
is distributed uniformely random to all miners no one has any advantage
over the other. But the global miner netwok will consume much less power.
A detail rest: New miners are not allowed in such scheme so next addition
is needed:
- A miner with no previous "next-coinbase" will need to first mine an
special block, "new-miner-block", that instead of normal transactions will
register the new miner and submit a "next-coinbase". This special block
will not be rewarded with new bitcoins. The only reward will be the
permission to mine in following blocks. No reward is applied so only new
miners wanting to "enter" the mining network are expected to create such
block.
Best Regards,
E. Arizón Benito
[-- Attachment #2: Type: text/html, Size: 2432 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Proposal to reduce mining power bill
2018-01-15 22:47 [bitcoin-dev] Proposal to reduce mining power bill Enrique Arizón Benito
@ 2018-01-16 0:10 ` nullius
2018-01-17 22:34 ` Enrique Arizón Benito
[not found] ` <CAAt2M1-KTyGPkwaRY=krAfMPUv797JaZyhF1e5g8e8yjjGWhmQ@mail.gmail.com>
1 sibling, 1 reply; 6+ messages in thread
From: nullius @ 2018-01-16 0:10 UTC (permalink / raw)
To: Enrique Arizón Benito, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 7668 bytes --]
On 2018-01-15 at 22:47:54 +0000, Enrique Arizón Benito
<enrique.arizonbenito@gmail•com> wrote:
>Hi all,
>
>just new to the list and curious to know if next proposal (or similar)
>for reducing mining-power consumption has already been discussed.
>
>The objective is to reduce the power consumption required while keeping
>the network safe and the miners "motivated" and cooperative to continue
>mining:
>
>The global idea is to introduce the concept of "next-coinbase" for
>miners. This will work something like as follow:
>
>- Any miner submitting a block will submit the "next-coinbase" for any
>new block mined by itself. (This address can be the same one or
>different from the just mined block). The miner keeps the private key
>associated with the "next-coinbase" secret.
>
>- The consensus algorithm will add next checks:
> A hash from, for example, the just mined block and the previous one,
>will have to match up to N bits for the next "next-coinbase" from the
>next block to be valid.
>
> That means that for the next block only 1/2^N bitcoin addresses will
>be accepted from the previously submitted "next-coinbase" list.
>
>Since the last previous block hash can be considered random, miners
>know in advance whether they will be able to participate or not in the
>next block depending on the just submited "next-coinbase". And since
>the "punishment" is distributed uniformely random to all miners no one
>has any advantage over the other. But the global miner netwok will
>consume much less power.
>
>A detail rest: New miners are not allowed in such scheme so next
>addition is needed:
>
>- A miner with no previous "next-coinbase" will need to first mine an
>special block, "new-miner-block", that instead of normal transactions
>will register the new miner and submit a "next-coinbase". This special
>block will not be rewarded with new bitcoins. The only reward will be
>the permission to mine in following blocks. No reward is applied so
>only new miners wanting to "enter" the mining network are expected to
>create such block.
Observation: This totally destroys Bitcoin’s transaction-ordering
security. A “51% attack” could be executed by any miner who has >50% of
the hashpower *proportionate to miners who are allowed to mine a
particular block*, rather than >50% of *global* hashpower. (I infer
that this could be done retroactively, and wave my hands over some of
the details since you did not talk about reorgs.) The same applies as
for attacks requiring 33% or 25% of total hashpower.
Potential attack, assuming that N *must* be based partly or wholly on
the existing set of “next-coinbase” addresses: A large miner could
gradually push N higher, by progressively committing new “next-coinbase”
addresses which differ in the next bit for all previously seen
combinations of bits. Large miners would have a vast advantage over
small miners, insofar as deliberately incrementing N by one more bit
could only be done by a miner who creates 2^(N+1) blocks (= 2 * 2^N).
By such means, it may be possible for a very large miner to eventually
lock out all other miners altogether, and monopolize all Bitcoin mining.
Now, questions:
How is N determined? By a wave of the hands?
What part of which block hash is matched against N bits? You were quite
unclear about this, and other important details. (Much of what I say
here is based on assumptions and inferences necessary to fill in the
blanks.)
How, exactly, are reorgs handled?
How does this interact with the difficulty adjustment algorithm?
Indeed, how is difficulty determined at all under your scheme?
What happens to coinbase fees from a “new-miner-block”? The way I read
your scheme, the “new-miner-block” must necessarily have no payout
whatsoever. But you discuss only “new bitcoins”, which are a
diminishing portion of the block reward, and will eventually reach zero.
Coinbase from fees must go somewhere; but under your scheme, a “new
miner” has no payable address.
What if no existing “next-coinbase” address matches? Is N constrained
to be sufficiently short that a match is guaranteed from the existing
set, then that makes it trivial for large mining farms to collect
addresses and further dominate (or even monopolize) the network in the
attack described above. If it isn’t, then the network could suddenly
halt when nobody is allowed to mine the next block; and that would
enable *this* attack:
What stops a malicious miner (including a “new miner” creating a
“new-miner block”) from deliberately working to create a block with a
hash which does not have N bits matching any of the existing
“next-coinbase” addresses? Contra what you say, block hashes can’t be
“considered random”. Indeed, partial preimage bruteforcing of block
hashes is the entire basis of mining POW.
Asking here more generally than as for the attack described above, what
stops mining farms with large hashpower from submitting many different
“next-coinbase” addresses in many different blocks? If N be small, then
it should be feasible for a large mining farm to eventually register a
set of “next-coinbase” addresses which match any N. **This increases
mining centralization.** If N be large, then this creates the
possibility (or raises the probability) that no address will match, and
nobody will be allowed to mine the next block.
How could miner anonymity be preserved under a scheme whereby each
“next-coinbase” address can be linked to a previous “next-coinbase”
address? The only way to start fresh would be with a prohibitively
expensive no-payout block. Mining can be totally anonymous at present,
and must so remain. Miners are only identified by certain information
they choose to put in a block header, which they could choose to change
or omit—or by IP address, which is trivially changed and is never a
reliable identifier.
How does this even save electricity, when there is much mining equipment
(especially on large mining farms) which cannot be easily shut down and
restarted? (Allegedly, this is one reason why some big miners
occasionally mine empty blocks.) Though I suppose that difficulty would
drop by unspecified means.
Further observations:
This scheme drastically increases the upfront investment required for a
new miner to start mining. To mine even one new block all by oneself,
without a pool, already requires a huge investment. Add to that the
uncompensated energy cost of mining that first block with *no* payout,
and I expect that the bar would be prohibitive to almost all new
entrants. Mining costs and incentives are delicately balanced by the
design of the network. Whereas incumbents are much favoured by your
scheme, further increasing miner centralization. Large incumbents could
also use this to produce a mining permissions market, by selling the
private keys to committed “next-coinbase” addresses.
I have not even tried to imagine what oddball attacks might be possible
for any miner with sufficient hashpower to deliberately cause a small
reorg.
--
nullius@nym•zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No! Because I do nothing wrong, I have nothing to show.” — nullius
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Proposal to reduce mining power bill
2018-01-16 0:10 ` nullius
@ 2018-01-17 22:34 ` Enrique Arizón Benito
2018-01-18 5:22 ` Eric Voskuil
2018-01-18 8:24 ` Damian Williamson
0 siblings, 2 replies; 6+ messages in thread
From: Enrique Arizón Benito @ 2018-01-17 22:34 UTC (permalink / raw)
To: nullius, bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 11959 bytes --]
Thanks "nullius" for your remarks. Notice my first post was not an RFC but
just a blur idea to inspect if something similar had already been discussed
in the group. In fact your post has helped me a lot to improve my first
mail.
> Observation: This totally destroys Bitcoin’s transaction-ordering
security. A “51% attack” could be executed by any miner who has >50% of
the hashpower *proportionate to miners who are allowed to mine a particular
block*, rather than >50% of *global* hashpower. (I infer that this could
be done retroactively, and wave my hands over some of the details since you
did not talk about reorgs.) The same applies as for attacks requiring 33%
or 25% of total hashpower.
I'm not sure what you are referring to in this paragraph. Imagine for
example that there are a total of, let's say, 2^10 available
next-coinbase/miners and the algorithm just allow 50% or 2^9 of them to
mine, ¿how could it be possible that one among them could have 51% of power
by chance? (Please, read comments bellow before replying)
> Potential attack, assuming that N *must* be based partly or wholly on the
existing set of “next-coinbase” addresses: A large miner could gradually
push N higher, by progressively committing new “next-coinbase” addresses
which differ in the next bit for all previously seen combinations of bits.
Large miners would have a vast advantage over small miners, insofar as
deliberately incrementing N by one more bit could only be done by a miner
who creates 2^(N+1) blocks (= 2 * 2^N). By such means, it may be possible
for a very large miner to eventually lock out all other miners altogether,
and monopolize all Bitcoin mining.
I do not think it would be easy even for a large miner but that made me
think for an alternative algorithm. Let's introduce the concept of "spent"
next-coinbase versus "un-spent" one, something like similarly to UTXO. A
next-coinbase would only be valid if it has not been previously used to
mine a block. Simplifying, with the spent vs unspent a large miner is
restricted to a single next-coinbase as anyone else. Being more precise
it's allowed a single next-coinbase for each mined new-miner-block mined
creating a "thread" of mining blocks for each new new-miner-block.
Schematically a thread would look like:
new-miner-block:next-coinbase_1 -> mined-block:next-coinbase_2 -> ... ->
(thread expired - see comment below about expiration)
In this case a large miner A with T times more power than another one B
could potentially spent mining power to create T parallel threads for each
thread created by miner B. A solution that could fix this issue is to allow
a maximum life time for each thread expressed in number of blocks. After a
given number of blocks have being mined the miner is forced to create new
new-miner-block to continue participating. The algorithm to choose the
life-time must be such that if a miner tries to create many parallel
threads (many new-miner-block), by the time it start mining transaction
blocks the first new-miner-block will start to expire, so he will be
punished.
If the famous phrase "a degree of indirection solve all programming
problems" I think this is an example applied to blockchain. First the
consensus chooses who can participate in the next round, then selected
miners participate in the round.
> Now, questions:
>
> How is N determined? By a wave of the hands?
>
Great question. I left it unspecified in the first mail. An algorithm comes
to my mind (You are welcome to propose others). Let's imagine the list of
registered non-expired next-coinbase addresses is 2^10. The consensus
checks that for N=1 there is *about* 1/2^N == 1/2 of unspent next-coinbase
addresses that match (it must be close to 1/2 of the total 2^10 addresses
with maybe an small +/- 1% statistical deviation). Then N=1 will be
accepted. Check now for N=2. If there are 1/(2^N) = 1/4 next-coinbase
addresses matching then N=2 is accepted. The algorithm continues until some
"++N" fails. Initially N=0 and so all miners are welcome to the game. They
all will start producing next-coinbase addresses and when there are enough
different ones N will become 1, then 2, ... This system will will keep an
equilibrium naturally. If new miners stop producing new new-miner-blocks,
eventually the threads will expire and N will be automatically be
decreased. Miners will act rationally to keep enough threads open in their
own interest since that will decrease the electricity bill.
> What part of which block hash is matched against N bits? You were quite
unclear about this, and other important details. (Much of what I say here
is based on assumptions and inferences necessary to fill in the blanks.)
Thinking about it, the hash must run over "many" different blocks and it
must include the next next-coinbase (to force calculating the hash after
choosing a next-coinbase). Since it's not expected that many blocks are
mined by the same miner in a row (maybe no more than 2 o 3) the "many"
number must be for example twice as much as the expected maximum numbers of
blocks that a large miner can mine in average.
> How, exactly, are reorgs handled?
I think reorgs are not affected by this algorithm. The next-coinbase
objective is just to randomly choose which miner will be allowed for the
next round.
> How does this interact with the difficulty adjustment algorithm? Indeed,
how is difficulty determined at all under your scheme?
As I see it, if the network wants to keep the same pace of new blocks each
N seconds, and N=1 (only half of the miners are allowed to mine) then
difficulty/power-bill is lowered by two, for N=2 by 4, ...
> What happens to coinbase fees from a “new-miner-block”? The way I read
your scheme, the “new-miner-block” must necessarily have no payout
whatsoever. But you discuss only “new bitcoins”,which are a diminishing
portion of the block reward, and will eventually reach zero. Coinbase from
fees must go somewhere; but under your scheme, a “new miner” has no payable
address.
This new-miner-block will have NO transactions inside.
> What if no existing “next-coinbase” address matches? Is N constrained to
be sufficiently short that a match is guaranteed from the existing set,
then that makes it trivial for large mining farms to collect addresses and
further dominate (or even monopolize) the network in the attack described
above. If it isn’t, then the network could suddenly halt when nobody is
allowed to mine the next block; and that would enable *this* attack:
I think the previous algorithm I mention to replace the "wave of hands"
(test N=1, then N=2,... ) plus the "expiring threads" would suffice to fix
it.
> What stops a malicious miner (including a “new miner” creating a
“new-miner block”) from deliberately working to create a block with a hash
which does not have N bits matching any of the existing “next-coinbase”
addresses? Contra what you say, block hashes can’t be “considered
random”. Indeed, partial preimage bruteforcing of block hashes is the
entire basis of mining POW.
Again, that is fixed by the previous algorithm
> Asking here more generally than as for the attack described above, what
stops mining farms with large hashpower from submitting many different
“next-coinbase” addresses in many different blocks? If N be small, then it
should be feasible for a large mining farm to eventually register a set of
“next-coinbase” addresses which match any N. **This increases mining
centralization.** If N be large, then this creates the possibility (or
raises the probability) that no address will match, and nobody will be
allowed to mine the next block.
Fixed by the expiring thread model?
> How could miner anonymity be preserved under a scheme whereby each
> “next-coinbase” address can be linked to a previous “next-coinbase”
> address? The only way to start fresh would be with a prohibitively
> expensive no-payout block. Mining can be totally anonymous at present, and
> must so remain. Miners are only identified by certain information they
> choose to put in a block header, which they could choose to change or
> omit—or by IP address, which is trivially changed and is never a reliable
> identifier.
>
> The anonymity decreases in the sense that if you know a next-coinbase
address owner you know all its related next-coinbase for the expiring
(physical-time-limited) thread. The anonymity increases in the sense that
miner will consume fewer energy. Electricity bill is the easiest way today
to trace miners.
> How does this even save electricity, when there is much mining equipment
(especially on large mining farms) which cannot be easily shut down and
restarted? (Allegedly, this is one reason why some big miners occasionally
mine empty blocks.) Though I suppose that difficulty would drop by
unspecified means.
As explained above, the difficulty is reduced by 1/2^N for each round. And
of course, miners that want to save more energy will have to adapt to put
their systems on stand-by while they are not chosen for the next round. I
think based on my limited experience with ASIC mining that just by not
sending new orders to the miner the power comsumption will decrease
dramatically even if the equipment is still on.
>
> Further observations:
>
> This scheme drastically increases the upfront investment required for a
> new miner to start mining. To mine even one new block all by oneself,
> without a pool, already requires a huge investment.
Once introduced the concept of "expiring" thread I think he will be pretty
much in the same condition. To obtain bitcoins he will first need to mine a
new-miner-block to enter the game and then an standard block before the
thread expires. Notice the expire time/block-length start just after the
new-miner-block has been mined so the probabilities to mine before the
expiration time will be proportional to its mining power, as for everyone
else.
> Add to that the uncompensated energy cost of mining that first block with
*no* payout,
I think it could be clearly compensated by the save in energy for standards
blocks.
>and I expect that the bar would be prohibitive to almost all new
entrants.Mining costs and incentives are delicately balanced by the design
of the network. Whereas incumbents are much favoured by your scheme,
further increasing miner centralization.
I don't think so after the new fixes. What do you think? My opinion is
that, based on the "theory of games", miners acting in their own interest
will try to maximize "N".
> Large incumbents could also use this to produce a mining permissions
market, by selling the private keys to committed “next-coinbase”
addresses.
With the addition of thread expiration, nobody will be really motivated to
shell/buy "next-coinbase" addresses since their utility is limited.
Just a remark: Notice this algorithm reduces the electricity bill, but the
hardware needed stays the same, since for each round the miner participates
in, it will try to mine as fast as possible and so use as much hardware as
possible. No reduction costs are expected in hardware.
Best Regards,
Enrique Arizón Benito
I have not even tried to imagine what oddball attacks might be possible for
> any miner with sufficient hashpower to deliberately cause a small reorg.
> --
> nullius@nym•zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
> Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
> 3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
> “‘If you’re not doing anything wrong, you have nothing to hide.’
> No! Because I do nothing wrong, I have nothing to show.” — nullius
>
[-- Attachment #2: Type: text/html, Size: 14228 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Proposal to reduce mining power bill
2018-01-17 22:34 ` Enrique Arizón Benito
@ 2018-01-18 5:22 ` Eric Voskuil
2018-01-18 8:24 ` Damian Williamson
1 sibling, 0 replies; 6+ messages in thread
From: Eric Voskuil @ 2018-01-18 5:22 UTC (permalink / raw)
To: Enrique Arizón Benito, Bitcoin Protocol Discussion; +Cc: nullius
[-- Attachment #1: Type: text/plain, Size: 12405 bytes --]
The energy cost of mining cannot be reduced, nor is it rational to consider it “too high”.
e
> On Jan 18, 2018, at 06:34, Enrique Arizón Benito via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Thanks "nullius" for your remarks. Notice my first post was not an RFC but just a blur idea to inspect if something similar had already been discussed in the group. In fact your post has helped me a lot to improve my first mail.
>
> > Observation: This totally destroys Bitcoin’s transaction-ordering security. A “51% attack” could be executed by any miner who has >50% of the hashpower *proportionate to miners who are allowed to mine a particular block*, rather than >50% of *global* hashpower. (I infer that this could be done retroactively, and wave my hands over some of the details since you did not talk about reorgs.) The same applies as for attacks requiring 33% or 25% of total hashpower.
>
> I'm not sure what you are referring to in this paragraph. Imagine for example that there are a total of, let's say, 2^10 available next-coinbase/miners and the algorithm just allow 50% or 2^9 of them to mine, ¿how could it be possible that one among them could have 51% of power by chance? (Please, read comments bellow before replying)
>
> > Potential attack, assuming that N *must* be based partly or wholly on the existing set of “next-coinbase” addresses: A large miner could gradually push N higher, by progressively committing new “next-coinbase” addresses which differ in the next bit for all previously seen combinations of bits. Large miners would have a vast advantage over small miners, insofar as deliberately incrementing N by one more bit could only be done by a miner who creates 2^(N+1) blocks (= 2 * 2^N). By such means, it may be possible for a very large miner to eventually lock out all other miners altogether, and monopolize all Bitcoin mining.
>
> I do not think it would be easy even for a large miner but that made me think for an alternative algorithm. Let's introduce the concept of "spent" next-coinbase versus "un-spent" one, something like similarly to UTXO. A next-coinbase would only be valid if it has not been previously used to mine a block. Simplifying, with the spent vs unspent a large miner is restricted to a single next-coinbase as anyone else. Being more precise it's allowed a single next-coinbase for each mined new-miner-block mined creating a "thread" of mining blocks for each new new-miner-block. Schematically a thread would look like:
> new-miner-block:next-coinbase_1 -> mined-block:next-coinbase_2 -> ... -> (thread expired - see comment below about expiration)
>
> In this case a large miner A with T times more power than another one B could potentially spent mining power to create T parallel threads for each thread created by miner B. A solution that could fix this issue is to allow a maximum life time for each thread expressed in number of blocks. After a given number of blocks have being mined the miner is forced to create new new-miner-block to continue participating. The algorithm to choose the life-time must be such that if a miner tries to create many parallel threads (many new-miner-block), by the time it start mining transaction blocks the first new-miner-block will start to expire, so he will be punished.
>
> If the famous phrase "a degree of indirection solve all programming problems" I think this is an example applied to blockchain. First the consensus chooses who can participate in the next round, then selected miners participate in the round.
>
>> Now, questions:
>>
>> How is N determined? By a wave of the hands?
>
> Great question. I left it unspecified in the first mail. An algorithm comes to my mind (You are welcome to propose others). Let's imagine the list of registered non-expired next-coinbase addresses is 2^10. The consensus checks that for N=1 there is *about* 1/2^N == 1/2 of unspent next-coinbase addresses that match (it must be close to 1/2 of the total 2^10 addresses with maybe an small +/- 1% statistical deviation). Then N=1 will be accepted. Check now for N=2. If there are 1/(2^N) = 1/4 next-coinbase addresses matching then N=2 is accepted. The algorithm continues until some "++N" fails. Initially N=0 and so all miners are welcome to the game. They all will start producing next-coinbase addresses and when there are enough different ones N will become 1, then 2, ... This system will will keep an equilibrium naturally. If new miners stop producing new new-miner-blocks, eventually the threads will expire and N will be automatically be decreased. Miners will act rationally to keep enough threads open in their own interest since that will decrease the electricity bill.
>
> > What part of which block hash is matched against N bits? You were quite unclear about this, and other important details. (Much of what I say here is based on assumptions and inferences necessary to fill in the blanks.)
>
> Thinking about it, the hash must run over "many" different blocks and it must include the next next-coinbase (to force calculating the hash after choosing a next-coinbase). Since it's not expected that many blocks are mined by the same miner in a row (maybe no more than 2 o 3) the "many" number must be for example twice as much as the expected maximum numbers of blocks that a large miner can mine in average.
>
> > How, exactly, are reorgs handled?
> I think reorgs are not affected by this algorithm. The next-coinbase objective is just to randomly choose which miner will be allowed for the next round.
>
> > How does this interact with the difficulty adjustment algorithm? Indeed, how is difficulty determined at all under your scheme?
> As I see it, if the network wants to keep the same pace of new blocks each N seconds, and N=1 (only half of the miners are allowed to mine) then difficulty/power-bill is lowered by two, for N=2 by 4, ...
>
> > What happens to coinbase fees from a “new-miner-block”? The way I read your scheme, the “new-miner-block” must necessarily have no payout whatsoever. But you discuss only “new bitcoins”,which are a diminishing portion of the block reward, and will eventually reach zero. Coinbase from fees must go somewhere; but under your scheme, a “new miner” has no payable address.
>
> This new-miner-block will have NO transactions inside.
>
> > What if no existing “next-coinbase” address matches? Is N constrained to be sufficiently short that a match is guaranteed from the existing set, then that makes it trivial for large mining farms to collect addresses and further dominate (or even monopolize) the network in the attack described above. If it isn’t, then the network could suddenly halt when nobody is allowed to mine the next block; and that would enable *this* attack:
>
> I think the previous algorithm I mention to replace the "wave of hands" (test N=1, then N=2,... ) plus the "expiring threads" would suffice to fix it.
>
> > What stops a malicious miner (including a “new miner” creating a “new-miner block”) from deliberately working to create a block with a hash which does not have N bits matching any of the existing “next-coinbase” addresses? Contra what you say, block hashes can’t be “considered random”. Indeed, partial preimage bruteforcing of block hashes is the entire basis of mining POW.
>
> Again, that is fixed by the previous algorithm
>
>
> > Asking here more generally than as for the attack described above, what stops mining farms with large hashpower from submitting many different “next-coinbase” addresses in many different blocks? If N be small, then it should be feasible for a large mining farm to eventually register a set of “next-coinbase” addresses which match any N. **This increases mining centralization.** If N be large, then this creates the possibility (or raises the probability) that no address will match, and nobody will be allowed to mine the next block.
>
> Fixed by the expiring thread model?
>
>> How could miner anonymity be preserved under a scheme whereby each “next-coinbase” address can be linked to a previous “next-coinbase” address? The only way to start fresh would be with a prohibitively expensive no-payout block. Mining can be totally anonymous at present, and must so remain. Miners are only identified by certain information they choose to put in a block header, which they could choose to change or omit—or by IP address, which is trivially changed and is never a reliable identifier.
>>
> The anonymity decreases in the sense that if you know a next-coinbase address owner you know all its related next-coinbase for the expiring (physical-time-limited) thread. The anonymity increases in the sense that miner will consume fewer energy. Electricity bill is the easiest way today to trace miners.
>
> > How does this even save electricity, when there is much mining equipment (especially on large mining farms) which cannot be easily shut down and restarted? (Allegedly, this is one reason why some big miners occasionally mine empty blocks.) Though I suppose that difficulty would drop by unspecified means.
>
> As explained above, the difficulty is reduced by 1/2^N for each round. And of course, miners that want to save more energy will have to adapt to put their systems on stand-by while they are not chosen for the next round. I think based on my limited experience with ASIC mining that just by not sending new orders to the miner the power comsumption will decrease dramatically even if the equipment is still on.
>>
>> Further observations:
>>
>> This scheme drastically increases the upfront investment required for a new miner to start mining. To mine even one new block all by oneself, without a pool, already requires a huge investment.
>
> Once introduced the concept of "expiring" thread I think he will be pretty much in the same condition. To obtain bitcoins he will first need to mine a new-miner-block to enter the game and then an standard block before the thread expires. Notice the expire time/block-length start just after the new-miner-block has been mined so the probabilities to mine before the expiration time will be proportional to its mining power, as for everyone else.
>
> > Add to that the uncompensated energy cost of mining that first block with *no* payout,
>
> I think it could be clearly compensated by the save in energy for standards blocks.
>
> >and I expect that the bar would be prohibitive to almost all new entrants.Mining costs and incentives are delicately balanced by the design of the network. Whereas incumbents are much favoured by your scheme, further increasing miner centralization.
>
> I don't think so after the new fixes. What do you think? My opinion is that, based on the "theory of games", miners acting in their own interest will try to maximize "N".
>
> > Large incumbents could also use this to produce a mining permissions market, by selling the private keys to committed “next-coinbase” addresses.
>
> With the addition of thread expiration, nobody will be really motivated to shell/buy "next-coinbase" addresses since their utility is limited.
>
> Just a remark: Notice this algorithm reduces the electricity bill, but the hardware needed stays the same, since for each round the miner participates in, it will try to mine as fast as possible and so use as much hardware as possible. No reduction costs are expected in hardware.
>
>
> Best Regards,
>
> Enrique Arizón Benito
>
>
>
>> I have not even tried to imagine what oddball attacks might be possible for any miner with sufficient hashpower to deliberately cause a small reorg.
>>
>> --
>> nullius@nym•zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
>> Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
>> 3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
>> “‘If you’re not doing anything wrong, you have nothing to hide.’
>> No! Because I do nothing wrong, I have nothing to show.” — nullius
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 15216 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Proposal to reduce mining power bill
2018-01-17 22:34 ` Enrique Arizón Benito
2018-01-18 5:22 ` Eric Voskuil
@ 2018-01-18 8:24 ` Damian Williamson
1 sibling, 0 replies; 6+ messages in thread
From: Damian Williamson @ 2018-01-18 8:24 UTC (permalink / raw)
To: nullius, Enrique Arizón Benito, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 12467 bytes --]
It probably could be noted, although it is well known, pools, in some views, act as one large individual miner, not just when separately considering the actions of pools.
Given the operation of pools, would a pool be required to mine the new-miner-blocks, or would you propose operation in a pool be restricted individually? How would this operate?
Regards,
Damian Williamson
________________________________
From: bitcoin-dev-bounces@lists•linuxfoundation.org <bitcoin-dev-bounces@lists•linuxfoundation.org> on behalf of Enrique Arizón Benito via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Sent: Thursday, 18 January 2018 9:34:11 AM
To: nullius@nym•zone; bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Proposal to reduce mining power bill
Thanks "nullius" for your remarks. Notice my first post was not an RFC but just a blur idea to inspect if something similar had already been discussed in the group. In fact your post has helped me a lot to improve my first mail.
> Observation: This totally destroys Bitcoin’s transaction-ordering security. A “51% attack” could be executed by any miner who has >50% of the hashpower *proportionate to miners who are allowed to mine a particular block*, rather than >50% of *global* hashpower. (I infer that this could be done retroactively, and wave my hands over some of the details since you did not talk about reorgs.) The same applies as for attacks requiring 33% or 25% of total hashpower.
I'm not sure what you are referring to in this paragraph. Imagine for example that there are a total of, let's say, 2^10 available next-coinbase/miners and the algorithm just allow 50% or 2^9 of them to mine, ¿how could it be possible that one among them could have 51% of power by chance? (Please, read comments bellow before replying)
> Potential attack, assuming that N *must* be based partly or wholly on the existing set of “next-coinbase” addresses: A large miner could gradually push N higher, by progressively committing new “next-coinbase” addresses which differ in the next bit for all previously seen combinations of bits. Large miners would have a vast advantage over small miners, insofar as deliberately incrementing N by one more bit could only be done by a miner who creates 2^(N+1) blocks (= 2 * 2^N). By such means, it may be possible for a very large miner to eventually lock out all other miners altogether, and monopolize all Bitcoin mining.
I do not think it would be easy even for a large miner but that made me think for an alternative algorithm. Let's introduce the concept of "spent" next-coinbase versus "un-spent" one, something like similarly to UTXO. A next-coinbase would only be valid if it has not been previously used to mine a block. Simplifying, with the spent vs unspent a large miner is restricted to a single next-coinbase as anyone else. Being more precise it's allowed a single next-coinbase for each mined new-miner-block mined creating a "thread" of mining blocks for each new new-miner-block. Schematically a thread would look like:
new-miner-block:next-coinbase_1 -> mined-block:next-coinbase_2 -> ... -> (thread expired - see comment below about expiration)
In this case a large miner A with T times more power than another one B could potentially spent mining power to create T parallel threads for each thread created by miner B. A solution that could fix this issue is to allow a maximum life time for each thread expressed in number of blocks. After a given number of blocks have being mined the miner is forced to create new new-miner-block to continue participating. The algorithm to choose the life-time must be such that if a miner tries to create many parallel threads (many new-miner-block), by the time it start mining transaction blocks the first new-miner-block will start to expire, so he will be punished.
If the famous phrase "a degree of indirection solve all programming problems" I think this is an example applied to blockchain. First the consensus chooses who can participate in the next round, then selected miners participate in the round.
Now, questions:
How is N determined? By a wave of the hands?
Great question. I left it unspecified in the first mail. An algorithm comes to my mind (You are welcome to propose others). Let's imagine the list of registered non-expired next-coinbase addresses is 2^10. The consensus checks that for N=1 there is *about* 1/2^N == 1/2 of unspent next-coinbase addresses that match (it must be close to 1/2 of the total 2^10 addresses with maybe an small +/- 1% statistical deviation). Then N=1 will be accepted. Check now for N=2. If there are 1/(2^N) = 1/4 next-coinbase addresses matching then N=2 is accepted. The algorithm continues until some "++N" fails. Initially N=0 and so all miners are welcome to the game. They all will start producing next-coinbase addresses and when there are enough different ones N will become 1, then 2, ... This system will will keep an equilibrium naturally. If new miners stop producing new new-miner-blocks, eventually the threads will expire and N will be automatically be decreased. Miners will act rationally to keep enough threads open in their own interest since that will decrease the electricity bill.
> What part of which block hash is matched against N bits? You were quite unclear about this, and other important details. (Much of what I say here is based on assumptions and inferences necessary to fill in the blanks.)
Thinking about it, the hash must run over "many" different blocks and it must include the next next-coinbase (to force calculating the hash after choosing a next-coinbase). Since it's not expected that many blocks are mined by the same miner in a row (maybe no more than 2 o 3) the "many" number must be for example twice as much as the expected maximum numbers of blocks that a large miner can mine in average.
> How, exactly, are reorgs handled?
I think reorgs are not affected by this algorithm. The next-coinbase objective is just to randomly choose which miner will be allowed for the next round.
> How does this interact with the difficulty adjustment algorithm? Indeed, how is difficulty determined at all under your scheme?
As I see it, if the network wants to keep the same pace of new blocks each N seconds, and N=1 (only half of the miners are allowed to mine) then difficulty/power-bill is lowered by two, for N=2 by 4, ...
> What happens to coinbase fees from a “new-miner-block”? The way I read your scheme, the “new-miner-block” must necessarily have no payout whatsoever. But you discuss only “new bitcoins”,which are a diminishing portion of the block reward, and will eventually reach zero. Coinbase from fees must go somewhere; but under your scheme, a “new miner” has no payable address.
This new-miner-block will have NO transactions inside.
> What if no existing “next-coinbase” address matches? Is N constrained to be sufficiently short that a match is guaranteed from the existing set, then that makes it trivial for large mining farms to collect addresses and further dominate (or even monopolize) the network in the attack described above. If it isn’t, then the network could suddenly halt when nobody is allowed to mine the next block; and that would enable *this* attack:
I think the previous algorithm I mention to replace the "wave of hands" (test N=1, then N=2,... ) plus the "expiring threads" would suffice to fix it.
> What stops a malicious miner (including a “new miner” creating a “new-miner block”) from deliberately working to create a block with a hash which does not have N bits matching any of the existing “next-coinbase” addresses? Contra what you say, block hashes can’t be “considered random”. Indeed, partial preimage bruteforcing of block hashes is the entire basis of mining POW.
Again, that is fixed by the previous algorithm
> Asking here more generally than as for the attack described above, what stops mining farms with large hashpower from submitting many different “next-coinbase” addresses in many different blocks? If N be small, then it should be feasible for a large mining farm to eventually register a set of “next-coinbase” addresses which match any N. **This increases mining centralization.** If N be large, then this creates the possibility (or raises the probability) that no address will match, and nobody will be allowed to mine the next block.
Fixed by the expiring thread model?
How could miner anonymity be preserved under a scheme whereby each “next-coinbase” address can be linked to a previous “next-coinbase” address? The only way to start fresh would be with a prohibitively expensive no-payout block. Mining can be totally anonymous at present, and must so remain. Miners are only identified by certain information they choose to put in a block header, which they could choose to change or omit—or by IP address, which is trivially changed and is never a reliable identifier.
The anonymity decreases in the sense that if you know a next-coinbase address owner you know all its related next-coinbase for the expiring (physical-time-limited) thread. The anonymity increases in the sense that miner will consume fewer energy. Electricity bill is the easiest way today to trace miners.
> How does this even save electricity, when there is much mining equipment (especially on large mining farms) which cannot be easily shut down and restarted? (Allegedly, this is one reason why some big miners occasionally mine empty blocks.) Though I suppose that difficulty would drop by unspecified means.
As explained above, the difficulty is reduced by 1/2^N for each round. And of course, miners that want to save more energy will have to adapt to put their systems on stand-by while they are not chosen for the next round. I think based on my limited experience with ASIC mining that just by not sending new orders to the miner the power comsumption will decrease dramatically even if the equipment is still on.
Further observations:
This scheme drastically increases the upfront investment required for a new miner to start mining. To mine even one new block all by oneself, without a pool, already requires a huge investment.
Once introduced the concept of "expiring" thread I think he will be pretty much in the same condition. To obtain bitcoins he will first need to mine a new-miner-block to enter the game and then an standard block before the thread expires. Notice the expire time/block-length start just after the new-miner-block has been mined so the probabilities to mine before the expiration time will be proportional to its mining power, as for everyone else.
> Add to that the uncompensated energy cost of mining that first block with *no* payout,
I think it could be clearly compensated by the save in energy for standards blocks.
>and I expect that the bar would be prohibitive to almost all new entrants.Mining costs and incentives are delicately balanced by the design of the network. Whereas incumbents are much favoured by your scheme, further increasing miner centralization.
I don't think so after the new fixes. What do you think? My opinion is that, based on the "theory of games", miners acting in their own interest will try to maximize "N".
> Large incumbents could also use this to produce a mining permissions market, by selling the private keys to committed “next-coinbase” addresses.
With the addition of thread expiration, nobody will be really motivated to shell/buy "next-coinbase" addresses since their utility is limited.
Just a remark: Notice this algorithm reduces the electricity bill, but the hardware needed stays the same, since for each round the miner participates in, it will try to mine as fast as possible and so use as much hardware as possible. No reduction costs are expected in hardware.
Best Regards,
Enrique Arizón Benito
I have not even tried to imagine what oddball attacks might be possible for any miner with sufficient hashpower to deliberately cause a small reorg.
--
nullius@nym•zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No! Because I do nothing wrong, I have nothing to show.” — nullius
[-- Attachment #2: Type: text/html, Size: 16268 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Proposal to reduce mining power bill
[not found] ` <CAAt2M1-KTyGPkwaRY=krAfMPUv797JaZyhF1e5g8e8yjjGWhmQ@mail.gmail.com>
@ 2018-01-18 16:25 ` Natanael
0 siblings, 0 replies; 6+ messages in thread
From: Natanael @ 2018-01-18 16:25 UTC (permalink / raw)
To: Enrique Arizón Benito, Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 689 bytes --]
A large miner would only need to divide his hardware setup into clusters
that pretend to be different independent miners to create these "miner
tokens", as explained before, to significantly raise his chances that he on
nearly every single round would be able to mine.
Once each individual token is about the expire, the number just dedicates a
fraction of his mining power to renew it. At the same time he can even
create multiple new tokens given enough hardware.
This does not reduce energy use. The only notable effect is to delay income
for new miners. This makes profitability calculations more annoying.
Long term, it only behaves like an artificially raised difficulty target.
[-- Attachment #2: Type: text/html, Size: 1027 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-01-18 16:25 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-15 22:47 [bitcoin-dev] Proposal to reduce mining power bill Enrique Arizón Benito
2018-01-16 0:10 ` nullius
2018-01-17 22:34 ` Enrique Arizón Benito
2018-01-18 5:22 ` Eric Voskuil
2018-01-18 8:24 ` Damian Williamson
[not found] ` <CAAt2M1-KTyGPkwaRY=krAfMPUv797JaZyhF1e5g8e8yjjGWhmQ@mail.gmail.com>
2018-01-18 16:25 ` Natanael
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox