Bitcoin Forum
April 23, 2024, 08:48:35 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Proof by public ip or by bitcoin balance  (Read 260 times)
aaboelela (OP)
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile
December 13, 2017, 05:20:39 AM
Last edit: December 13, 2017, 06:22:16 AM by aaboelela
 #1

I read this article https://www.coindesk.com/short-guide-blockchain-consensus-protocols/

How about if we use Proof by public ip? this is something which can be proved and the node can't change it. The node with the closest public ip address to the ip address of the node which created the last block, will create the next block. For example node A which created the last block has ip 10.0.0.1 and we have node B with ip 10.0.0.9 and node C with ip 10.0.0.3 then node C will be chosen as its ip is closer in value to node A

Or even easier than that, we can choose according to the node bitcoins balance, i.e. the node with the closes balance of bitcoins to the node which win last. So if node A was the last to commit to chain and has balance of 3.0 bitcoins, and we have node B with balance 4.0 and node C with balance 3.5, then node C wins. or to even make it more random to avoid group of users from tempering with their balances in order to win in order, we can hash the balance with their public key, then compare to last committer hashed balance. And this is something which can easily be proved from the ledger that everybody have.
1713905315
Hero Member
*
Offline Offline

Posts: 1713905315

View Profile Personal Message (Offline)

Ignore
1713905315
Reply with quote  #2

1713905315
Report to moderator
1713905315
Hero Member
*
Offline Offline

Posts: 1713905315

View Profile Personal Message (Offline)

Ignore
1713905315
Reply with quote  #2

1713905315
Report to moderator
1713905315
Hero Member
*
Offline Offline

Posts: 1713905315

View Profile Personal Message (Offline)

Ignore
1713905315
Reply with quote  #2

1713905315
Report to moderator
The network tries to produce one block per 10 minutes. It does this by automatically adjusting how difficult it is to produce blocks.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1713905315
Hero Member
*
Offline Offline

Posts: 1713905315

View Profile Personal Message (Offline)

Ignore
1713905315
Reply with quote  #2

1713905315
Report to moderator
1713905315
Hero Member
*
Offline Offline

Posts: 1713905315

View Profile Personal Message (Offline)

Ignore
1713905315
Reply with quote  #2

1713905315
Report to moderator
1713905315
Hero Member
*
Offline Offline

Posts: 1713905315

View Profile Personal Message (Offline)

Ignore
1713905315
Reply with quote  #2

1713905315
Report to moderator
ranochigo
Legendary
*
Offline Offline

Activity: 2954
Merit: 4163


View Profile
December 13, 2017, 10:14:08 AM
Merited by Foxpup (4), ABCbits (3)
 #2

How about if we use Proof by public ip? this is something which can be proved and the node can't change it. The node with the closest public ip address to the ip address of the node which created the last block, will create the next block. For example node A which created the last block has ip 10.0.0.1 and we have node B with ip 10.0.0.9 and node C with ip 10.0.0.3 then node C will be chosen as its ip is closer in value to node A
Doesn't work. Nodes do not hold a database for the IPs which runs a Bitcoin node. If this were to happen, all of the nodes on the network would have to be actively pinging each other to find out which of the nodes have the closest IP to the last block creator. This would effectively just be a DOS on everyone in the world.

Needless to say, its not incredibly expensive to obtain IPs in the same block. Most of the IPs are dynamic IP so it would change periodically and its hard to keep up.

Or even easier than that, we can choose according to the node bitcoins balance, i.e. the node with the closes balance of bitcoins to the node which win last. So if node A was the last to commit to chain and has balance of 3.0 bitcoins, and we have node B with balance 4.0 and node C with balance 3.5, then node C wins. or to even make it more random to avoid group of users from tempering with their balances in order to win in order, we can hash the balance with their public key, then compare to last committer hashed balance. And this is something which can easily be proved from the ledger that everybody have.
Nodes do not have a balance to it, addresses do. Nodes would have to prove that they own a specific amount of Bitcoin and with that, you'll have to get the signed message broadcasted to everyone. That's very inefficient to do with the number of nodes in the network. By telling everyone which node owns which addresses, you will be compromising privacy.

It's easy to manipulate if I setup thousands of nodes with a satoshi difference with each other.

.
.HUGE.
▄██████████▄▄
▄█████████████████▄
▄█████████████████████▄
▄███████████████████████▄
▄█████████████████████████▄
███████▌██▌▐██▐██▐████▄███
████▐██▐████▌██▌██▌██▌██
█████▀███▀███▀▐██▐██▐█████

▀█████████████████████████▀

▀███████████████████████▀

▀█████████████████████▀

▀█████████████████▀

▀██████████▀▀
█▀▀▀▀











█▄▄▄▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
.
CASINSPORTSBOOK
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
▀▀▀▀█











▄▄▄▄█
bob123
Legendary
*
Offline Offline

Activity: 1624
Merit: 2481



View Profile WWW
December 14, 2017, 08:15:33 AM
Merited by Foxpup (3), ABCbits (2)
 #3

This would not work for several different reasons. One would be the following:
Anyone with a C-class network (or a small portion of it) could just mine blocks almost without an ending ,
if he had 2+ nodes (e.g. 10.0.0.4 and 10.0.0.5). A Class C network includes 254 ip addresses (2^8 - 2).
Therefore if i own 10.0.0.1 - 10.0.0.254 (.0 = Network / .255 = Broadcast) and my node at .4 mines a block,
 the next mined Block will be from .5 and the next again from .4.
This would go forth and back until 1 of these 2 nodes crashed somehow.
A Class C network is the cheapest one to buy.
A small 'investment' for being able to generate all future blocks and control BTC. Proof by IP can not work.
Already thought about IPv6 when everyone will have 64.000+ ip's available?

aaboelela (OP)
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile
December 14, 2017, 07:02:43 PM
Last edit: December 14, 2017, 07:26:34 PM by aaboelela
 #4

Yes I was thinking to limit it to ipv6 only. Can that work?
Also the next winning node doesn’t have to be the closest in address. It can be a hashing function which takes the ip and the previous block ID as inputs. A 3rd input to this lottery function can be the highest balance of bitcoins this node own. The higher the balance, the bigger chance they can win.
ranochigo
Legendary
*
Offline Offline

Activity: 2954
Merit: 4163


View Profile
December 15, 2017, 02:12:03 AM
 #5

Yes I was thinking to limit it to ipv6 only. Can that work?
Also the next winning node doesn’t have to be the closest in address. It can be a hashing function which takes the ip and the previous block ID as inputs. A 3rd input to this lottery function can be the highest balance of bitcoins this node own. The higher the balance, the bigger chance they can win.
Won't work. No matter how you do it, each of the network's node will have to be connected to each other, without exception. Individual nodes do not know which IPs are running a full node and they cannot know without pinging everyone.

The main flaw you have is also the fact that each node is seeing things differently. Unless each of the node is seeing the same set of IPs globally, they would assume different IPs as being the lowest. This would just result in many many forks.

.
.HUGE.
▄██████████▄▄
▄█████████████████▄
▄█████████████████████▄
▄███████████████████████▄
▄█████████████████████████▄
███████▌██▌▐██▐██▐████▄███
████▐██▐████▌██▌██▌██▌██
█████▀███▀███▀▐██▐██▐█████

▀█████████████████████████▀

▀███████████████████████▀

▀█████████████████████▀

▀█████████████████▀

▀██████████▀▀
█▀▀▀▀











█▄▄▄▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
.
CASINSPORTSBOOK
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
▀▀▀▀█











▄▄▄▄█
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!