Bitcoin Forum
May 07, 2024, 10:40:37 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1] 2 3 4 »  All
  Print  
Author Topic: 51% can be prevented so long as all nodes agree.  (Read 2763 times)
S4VV4S (OP)
Hero Member
*****
Offline Offline

Activity: 1582
Merit: 502


View Profile
June 17, 2014, 01:14:21 PM
 #1

Hi guys,

I just came up with a theory also posted here: https://bitcointalk.org/index.php?topic=652858.msg7361312#msg7361312

If the protocol was to be changed as to not allow a node to submit x number of blocks within x time, and all nodes agree to this, it would be a start.

Hashing power is measured by how many blocks are solved by one pool or miner at the day right?

If you can limit that then problem solved.

Basically, if the core dev team makes a small change on how blocks are submitted then we will not have 51% attack problems and all pools will grow together as miners will split/point their equipment to various pools at the same time.

Thus eliminating the fear of a 51% attack and all pools can grow together yet remain at decent % levels as to not cause panic again.

What do you guys think?

1715121637
Hero Member
*
Offline Offline

Posts: 1715121637

View Profile Personal Message (Offline)

Ignore
1715121637
Reply with quote  #2

1715121637
Report to moderator
Every time a block is mined, a certain amount of BTC (called the subsidy) is created out of thin air and given to the miner. The subsidy halves every four years and will reach 0 in about 130 years.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
gtraah
Sr. Member
****
Offline Offline

Activity: 420
Merit: 250



View Profile
June 17, 2014, 01:29:52 PM
 #2

This seems like it could work in theory, but I am no BTC protocol genius to make an educated comment .

I am yet to see any devs comment on this 51% problem that many people are afraid off and is definitely a splinter in Bitcoins foot that keeps itching away at it's reputation. Is this something that is being worked on as I am speaking? If its not then it seems the devs either are clueless or don't give a shit.

I have seen more than 5 media articles claiming that BTC is controlled by one entity, worst fears have now leaked to the media and the media is spinning it sideways, as they do.. How fukn embarrassing is this to see, I absolutely love the idea of BTC and see this just fukn hurts.

Can someone with protocol power please make an announcement and get onto this asap.



DannyHamilton
Legendary
*
Offline Offline

Activity: 3388
Merit: 4653



View Profile
June 17, 2014, 01:30:45 PM
 #3

What do you guys think?

I think you haven't thought this through very well.

How are you going to determine how many blocks a node has submitted?
TimS
Sr. Member
****
Offline Offline

Activity: 250
Merit: 253


View Profile WWW
June 17, 2014, 01:33:22 PM
 #4

If the protocol was to be changed as to not allow a node to submit x number of blocks within x time, and all nodes agree to this, it would be a start.

Hashing power is measured by how many blocks are solved by one pool or miner at the day right?

If you can limit that then problem solved.
The problem is that you can't really tell what makes a node. Starting to hit the limit? Just use Tor to switch to a new IP, and voila, you're (indistinguishable from) a new node!

The only thing we trust is the proof of work. If one entity controls more than half of that, then they control the blockchain. Simple as that.
S4VV4S (OP)
Hero Member
*****
Offline Offline

Activity: 1582
Merit: 502


View Profile
June 17, 2014, 01:35:21 PM
 #5

What do you guys think?

I think you haven't thought this through very well.

How are you going to determine how many blocks a node has submitted?

I am not an expert here but if each node is assigned a signature then IP doesn't matter does it?
ljudotina
Legendary
*
Offline Offline

Activity: 1260
Merit: 1029


View Profile
June 17, 2014, 01:36:53 PM
 #6

Well this idea can be extended. Add in some kind of "trust" level to nodes that nodes gain working over period of time. New nodes, low trust level, more restrictions (can submit less blocks). Higher trust level, less restrictions (can submit more blocks than low trust ones). Trust is gained by submiting blocks over period of time. That would disable switching form ip to ip.

S4VV4S (OP)
Hero Member
*****
Offline Offline

Activity: 1582
Merit: 502


View Profile
June 17, 2014, 01:38:41 PM
 #7

Well this idea can be extended. Add in some kind of "trust" level to nodes that nodes gain working over period of time. New nodes, low trust level, more restrictions (can submit less blocks). Higher trust level, less restrictions (can submit more blocks than low trust ones). Trust is gained by submiting blocks over period of time. That would disable switching form ip to ip.

^^^ there you have it.
We are already starting to expand on the idea.

Who knows, maybe we can come up with a working solution for this once and for all.
TimS
Sr. Member
****
Offline Offline

Activity: 250
Merit: 253


View Profile WWW
June 17, 2014, 01:39:03 PM
 #8

Well this idea can be extended. Add in some kind of "trust" level to nodes that nodes gain working over period of time. New nodes, low trust level, more restrictions (can submit less blocks). Higher trust level, less restrictions (can submit more blocks than low trust ones). Trust is gained by submiting blocks over period of time. That would disable switching form ip to ip.
So a new, honest miner (or a pool whose IP is not static) who publishes a few blocks in a short time period is punished, while large pools just switch to a new IP for every block, if need be. Sorry, this isn't the solution we're looking for.
ljudotina
Legendary
*
Offline Offline

Activity: 1260
Merit: 1029


View Profile
June 17, 2014, 01:41:19 PM
 #9

Well this idea can be extended. Add in some kind of "trust" level to nodes that nodes gain working over period of time. New nodes, low trust level, more restrictions (can submit less blocks). Higher trust level, less restrictions (can submit more blocks than low trust ones). Trust is gained by submiting blocks over period of time. That would disable switching form ip to ip.
So a new, honest miner who publishes a few blocks in a short time period is punished, while large pools just switch to a new IP for every block, if need be. Sorry, this isn't the solution we're looking for.

You got it 100% wrong.
New honest miner and large pool that just changed IP would be at same position, "low trust level". They would have to work and over time they would get more and more trust ie. being able to submit more blocks. Smaller new and honest miner wont loose anything as they can not submit alot of blocks anyway, but large pool that switched would be loosing ALOT of BTC by switching IP, as they coudlnt submit all blocks they mine, so they just wouldnt switch IP as it would hurt em alot.

newuser01
Sr. Member
****
Offline Offline

Activity: 434
Merit: 250


View Profile
June 17, 2014, 01:44:38 PM
 #10

Well this idea can be extended. Add in some kind of "trust" level to nodes that nodes gain working over period of time. New nodes, low trust level, more restrictions (can submit less blocks). Higher trust level, less restrictions (can submit more blocks than low trust ones). Trust is gained by submiting blocks over period of time. That would disable switching form ip to ip.

Trust is what we are trying to get away from, not move towards it..

sorry, I don't think this will work.
ljudotina
Legendary
*
Offline Offline

Activity: 1260
Merit: 1029


View Profile
June 17, 2014, 01:47:09 PM
 #11

Well this idea can be extended. Add in some kind of "trust" level to nodes that nodes gain working over period of time. New nodes, low trust level, more restrictions (can submit less blocks). Higher trust level, less restrictions (can submit more blocks than low trust ones). Trust is gained by submiting blocks over period of time. That would disable switching form ip to ip.

Trust is what we are trying to get away from, not move towards it..

sorry, I don't think this will work.

Ehm, "mathematical trust that is calculated by whole network"...not "i trust you" trust...Whole btc newtork is based on calculated trust. It just isnt centralized trust, it's decentralized one. This would be exactly that.

S4VV4S (OP)
Hero Member
*****
Offline Offline

Activity: 1582
Merit: 502


View Profile
June 17, 2014, 01:47:30 PM
 #12

Well this idea can be extended. Add in some kind of "trust" level to nodes that nodes gain working over period of time. New nodes, low trust level, more restrictions (can submit less blocks). Higher trust level, less restrictions (can submit more blocks than low trust ones). Trust is gained by submiting blocks over period of time. That would disable switching form ip to ip.

Trust is what we are trying to get away from, not move towards it..

sorry, I don't think this will work.

There never was trust.
It is supposed to be trustless in the manner of one does not have to trust one other to make a transaction.
The whole network has to agree.

And if all nodes agree that one node is getting a lot of hashing power fast to the point that it is dangerous for the protocol then that node is capped as to allow other nodes to even things out.

That will also cause a "decentralized" kind of pool mining as users will have their miners pointed at various pools
DannyHamilton
Legendary
*
Offline Offline

Activity: 3388
Merit: 4653



View Profile
June 17, 2014, 01:47:55 PM
 #13

I am not an expert here but if each node is assigned a signature then IP doesn't matter does it?

And you can somehow keep a pool from being assigned multiple signatures?

Explain.

Well this idea can be extended. Add in some kind of "trust" level to nodes that nodes gain working over period of time. New nodes, low trust level, more restrictions (can submit less blocks). Higher trust level, less restrictions (can submit more blocks than low trust ones). Trust is gained by submiting blocks over period of time. That would disable switching form ip to ip.

^^^ there you have it.
We are already starting to expand on the idea.

Who knows, maybe we can come up with a working solution for this once and for all.

If we are going to choose to trust an authority, then we don't need a blockchain.

The revolutionary thing about Bitcoin is that it is decentralized, requiring no trust in any single authority.

Go use a bank if you prefer to give trust to an entity.

Furthermore, a large pool can just get a new signature for every block.  Sure, they'll be limited to a single block since they'll have such low "trust", but that doesn't matter since they can use a brand new signature for the next block.
S4VV4S (OP)
Hero Member
*****
Offline Offline

Activity: 1582
Merit: 502


View Profile
June 17, 2014, 01:50:40 PM
 #14

I am not an expert here but if each node is assigned a signature then IP doesn't matter does it?

And you can somehow keep a pool from being assigned multiple signatures?

Explain.

Bro, like I said, even though I do my own software (which only recently involves BTC) I am not an expert on the matter.

It might not have to be a signature but I am sure that if we can track someone by their address then we can keep someone from cheating.

Don't you think?

S4VV4S (OP)
Hero Member
*****
Offline Offline

Activity: 1582
Merit: 502


View Profile
June 17, 2014, 01:52:45 PM
 #15

I am not an expert here but if each node is assigned a signature then IP doesn't matter does it?

And you can somehow keep a pool from being assigned multiple signatures?

Explain.

Well this idea can be extended. Add in some kind of "trust" level to nodes that nodes gain working over period of time. New nodes, low trust level, more restrictions (can submit less blocks). Higher trust level, less restrictions (can submit more blocks than low trust ones). Trust is gained by submiting blocks over period of time. That would disable switching form ip to ip.

^^^ there you have it.
We are already starting to expand on the idea.

Who knows, maybe we can come up with a working solution for this once and for all.

If we are going to choose to trust an authority, then we don't need a blockchain.

The revolutionary thing about Bitcoin is that it is decentralized, requiring no trust in any single authority.

Go use a bank if you prefer to give trust to an entity.


Furthermore, a large pool can just get a new signature for every block.  Sure, they'll be limited to a single block since they'll have such low "trust", but that doesn't matter since they can use a brand new signature for the next block.

What a lame thing to say Danny.

Can't you see that we CAN NOT trust the blockchain coz it can be exploited
ljudotina
Legendary
*
Offline Offline

Activity: 1260
Merit: 1029


View Profile
June 17, 2014, 01:53:51 PM
 #16


If we are going to choose to trust an authority, then we don't need a blockchain.


Did you read my post AT ALL? No you did not , as if you did, than you would know that i did not propose to trust "authority" but to "trust" network decision. Blockchain is exactly that. Ledger that we all trust to that is created by network. This would be "trust ledger" created by whole network.

Peter R
Legendary
*
Offline Offline

Activity: 1162
Merit: 1007



View Profile
June 17, 2014, 01:57:24 PM
 #17

I am not an expert here but if each node is assigned a signature then IP doesn't matter does it?

And you can somehow keep a pool from being assigned multiple signatures?

Explain.

By submitting an application to, and receiving approval from, the Federation of Decentralized Bitcoin Miners, of course.   Cheesy

The irony in the concept of a centralized organization committed to decentralization was intentional.

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
S4VV4S (OP)
Hero Member
*****
Offline Offline

Activity: 1582
Merit: 502


View Profile
June 17, 2014, 01:59:29 PM
 #18

I am not an expert here but if each node is assigned a signature then IP doesn't matter does it?

And you can somehow keep a pool from being assigned multiple signatures?

Explain.

By submitting an application to, and receiving approval from, the Federation of Decentralized Bitcoin Miners, of course.   Cheesy

The irony in the concept of a centralized organization committed to decentralization was intentional.


I am guessing you are talking about TBF  Grin Grin Grin Grin Grin Grin Grin

Seriously what happened to "decentralization" and NO central authority?
DannyHamilton
Legendary
*
Offline Offline

Activity: 3388
Merit: 4653



View Profile
June 17, 2014, 02:00:40 PM
 #19

I am not an expert here but if each node is assigned a signature then IP doesn't matter does it?

And you can somehow keep a pool from being assigned multiple signatures?

Explain.

Bro, like I said, even though I do my own software (which only recently involves BTC) I am not an expert on the matter.

Clearly.  Not only aren't you an expert, but you really aren't even thinking this through.

You want to be able to stop someone with more than 50% of the hashing power from having the power that having more than 50% of the hashing power provides.  Unfortunately wanting something doesn't mean its possible.  Throwing out ideas that haven't been thought through, and that have already been discussed dozens of times, just means that people are going to point out the problems with your idea that have already been discovered (dozens of times).

It might not have to be a signature but I am sure that if we can track someone by their address then we can keep someone from cheating.

But, since we don't have an address that we can track someone by, we can't keep them from cheating.  Not unless we give some sort of trust to a centralized authority.

This is a problem that has plagued the idea of a cryptocurrency for decades.  There was no way to maintain an consensus without a centralized authority.  Using a blockchain and a proof-of-work, Satoshi came up with a revolutionary concept for distributed consensus.  The problem with his solution is that if someone can supply the majority of the proof-of-work, then they can control the consensus.  If you can find a way to reach consensus without the proof-of-work, then we don't need proof-of-work mining any more at all.  Instead of using your new system to reach consensus on the block submitted, we can just create a coin that uses your amazing new consensus system to reach consensus on the transactions themselves.

ljudotina
Legendary
*
Offline Offline

Activity: 1260
Merit: 1029


View Profile
June 17, 2014, 02:02:55 PM
 #20

Ok screw this. I have too much "trust" in human intelect. I should have known that barely anyone will read my post with at least half brain turned on, so here it is again, stupid proof and changed so no "trust" is involved:

Well this idea can be extended. Add in some kind of "proirity" level to nodes that nodes gain working over period of time. Priority would be assigned by whole network which is basic idea of BTC....things being decided by whole newtork.
New nodes would have low priority level which would have more restrictions (they could submit less blocks).
Higher priority level nodes would have less restrictions (they could submit more blocks than low priority nodes).

Priority is gained by submiting blocks over period of time. That would disable switching form ip to ip. How?

Her's an example.

(numbers are just figurative)
Pool A = large pool that submits 50 blocks per hour
Poll B = new, small pool that just started working and is submiting 5 block per hour

Pool A has high priority level and can submit up to 100 blocks per hour
Pool A starts growing and gets to 101 blck per hour and starts loosing BTC. They change IP after 100th block is submited to enable themselves to submit that 101th block and they become low priority pool.
Now pool A can submit only 10 blocks per hour and gain 1 extra block every day. While Pool B which is still on same IP is going great, growing slowly and gaining proiroty.

What basicly happened, Pool A shot itself in the foot and is loosing ALOT of BTC because they tried to cheat the system, while new honest pool is growing steady.


Is it now much clearer?

Pages: [1] 2 3 4 »  All
  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!