Bitcoin Forum
April 25, 2024, 10:29:37 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Idle Mining Development  (Read 1115 times)
aTg (OP)
Legendary
*
Offline Offline

Activity: 1358
Merit: 1000



View Profile
October 23, 2014, 05:52:02 PM
 #1

Hi, I am looking for people in the community who wants to collaborate on a new concept of mining based on collusion, is a complex project so I can not take all the development myself and the truth is I having a hard time finding people interested in this idea.

This is put into practice a concept very well explained here:
https://docs.google.com/file/d/0ByJFkp_AfSQuZ1JmbnBGY2lIVG8/preview?pli=1

How to make it work without complex contracts compliance difficult?

There goes my idea would be to create a pool where coexist the two algorithms, one active and one Idle miners, the reward would go divided among all the miners with a slightly higher proportion to the active miners.

The pool could be called collusion.io for example, I put at the disposal of the project this domain.

We should develop the algorithm to work with inactive miners available that would register the idle power in the statics of a pool.

If anyone is interested in this idea please feel free to participate in the thread, bitcoin benefits would be large, power consumption of the mining network could contain.

There is a phrase of Satoshi in the era of the VGA that said something like make a gentleman's agreement to stop increase the difficulty, that is the idea.
1714040977
Hero Member
*
Offline Offline

Posts: 1714040977

View Profile Personal Message (Offline)

Ignore
1714040977
Reply with quote  #2

1714040977
Report to moderator
1714040977
Hero Member
*
Offline Offline

Posts: 1714040977

View Profile Personal Message (Offline)

Ignore
1714040977
Reply with quote  #2

1714040977
Report to moderator
"Bitcoin: mining our own business since 2009" -- Pieter Wuille
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714040977
Hero Member
*
Offline Offline

Posts: 1714040977

View Profile Personal Message (Offline)

Ignore
1714040977
Reply with quote  #2

1714040977
Report to moderator
1714040977
Hero Member
*
Offline Offline

Posts: 1714040977

View Profile Personal Message (Offline)

Ignore
1714040977
Reply with quote  #2

1714040977
Report to moderator
1714040977
Hero Member
*
Offline Offline

Posts: 1714040977

View Profile Personal Message (Offline)

Ignore
1714040977
Reply with quote  #2

1714040977
Report to moderator
deepceleron
Legendary
*
Offline Offline

Activity: 1512
Merit: 1025



View Profile WWW
October 23, 2014, 05:58:01 PM
 #2

It seems like you would need to have proof that the idle computing devices were actually idling. Maybe by having them do some cryptographic hashes of blocks that are lower than the full difficulty in their idle time, and then submitting those to the pool to measure the hashrate of the device (so that everyone is compensated fairly for idling their mining devices). This could be a benefit to all members of the pool, because there is a change that these idle-time proof-of-works could sometimes even solve full difficulty blocks.
aTg (OP)
Legendary
*
Offline Offline

Activity: 1358
Merit: 1000



View Profile
October 23, 2014, 06:54:09 PM
 #3

The document proposes this.

Quote
At the specified time, I issue a challenge:

(Apubkey, R, Tfin) Aaddr = A’s pubkey, R = random number, Tfin = due date. (I also sign this msg)

Say the due date is in 30 seconds. You then run:

SHA256(Bpubkey, R, nonce), iterating the nonce. You then

send your best (best 100) inputs, which I verify.

I now have a good estimate of your hash power.

(or less if for some reason you hold back)
Luke-Jr
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
October 26, 2014, 07:27:10 PM
 #4

The document proposes this.

Quote
At the specified time, I issue a challenge:

(Apubkey, R, Tfin) Aaddr = A’s pubkey, R = random number, Tfin = due date. (I also sign this msg)

Say the due date is in 30 seconds. You then run:

SHA256(Bpubkey, R, nonce), iterating the nonce. You then

send your best (best 100) inputs, which I verify.

I now have a good estimate of your hash power.

(or less if for some reason you hold back)
Now how do you prove I wasn't mining on some other pool up until your challenge?

aTg (OP)
Legendary
*
Offline Offline

Activity: 1358
Merit: 1000



View Profile
October 26, 2014, 10:55:58 PM
 #5

Now how do you prove I wasn't mining on some other pool up until your challenge?

The way that I can think of is to make a p2pool, so that the miner no have other place to go.
Crowex
Member
**
Offline Offline

Activity: 111
Merit: 10


View Profile
October 27, 2014, 11:10:11 PM
 #6


Now how do you prove I wasn't mining on some other pool up until your challenge?

I think that the idea is that the miners should be mining before you issue the challenge.

The challenge is to show how much the total network hashing power should reduce by when you stop hashing and agree to be idle. Then you observe if block production reduces and only pay the bonus to the idlers if this reduction happens. This agreement is enforced by a combination of nlocktime and multisig.

I don't know if this will work with just one pool doing it (i.e. only a small percentage of mining power) because all of the other miner's on the network will benefit and not just the miner paying the bonus and the slow down in block production will not be noticeable enough.

I think it's really interesting from a theoretical point of view but wouldn't work in practise unless nearly all miners were involved (probably wouldn't work then either - I can think of loads of reasons why)

Here's the video of a talk on it:  http://www.youtube.com/watch?v=QN2TPeQ9mnA

If you compare the increase in mining hardware to an arms race then this is the equivalent of a cold war. All of the miners are in a huge stand off, all of them ready to switch on their huge asic hash farms the minute someone breaks the agreement resulting in apocalyptic energy consumption. In bitcoin mining the apocalyptic war has already started so it's probably more likely to end up in mutual destruction than a negotiated peace. Smiley

It's a great idea though.



S4VV4S
Hero Member
*****
Offline Offline

Activity: 1582
Merit: 502


View Profile
October 28, 2014, 02:04:44 PM
 #7


Now how do you prove I wasn't mining on some other pool up until your challenge?

I think that the idea is that the miners should be mining before you issue the challenge.

The challenge is to show how much the total network hashing power should reduce by when you stop hashing and agree to be idle. Then you observe if block production reduces and only pay the bonus to the idlers if this reduction happens. This agreement is enforced by a combination of nlocktime and multisig.

I don't know if this will work with just one pool doing it (i.e. only a small percentage of mining power) because all of the other miner's on the network will benefit and not just the miner paying the bonus and the slow down in block production will not be noticeable enough.

I think it's really interesting from a theoretical point of view but wouldn't work in practise unless nearly all miners were involved (probably wouldn't work then either - I can think of loads of reasons why)

Here's the video of a talk on it:  http://www.youtube.com/watch?v=QN2TPeQ9mnA

If you compare the increase in mining hardware to an arms race then this is the equivalent of a cold war. All of the miners are in a huge stand off, all of them ready to switch on their huge asic hash farms the minute someone breaks the agreement resulting in apocalyptic energy consumption. In bitcoin mining the apocalyptic war has already started so it's probably more likely to end up in mutual destruction than a negotiated peace. Smiley

It's a great idea though.





^^^ I will agree with this.
It's an excellent idea, however, getting it to work.......

Remember, what drives the economy is greed (unfortunately)......
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!