Bitcoin Forum
May 12, 2024, 10:59:03 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: [Discussion] Quo vadis, XCN?  (Read 866 times)
gnasirator (OP)
Full Member
***
Offline Offline

Activity: 175
Merit: 113


View Profile
September 14, 2017, 07:53:51 AM
 #21

That's an interesting thought. Nodes could test each other for availability and send each other certificates asserting a certain uptime which then could be used as a foundation for POS minting.
That way, the more certificates a node collects, the higher the chance for minting.
That approach would not only reward uptime but also connectivity, e.g. the more connections to other nodes a node has, the more certificates it receives per time.
And if the certificates have some kind of points system, the ping time between the nodes could be used as a bonus multiplier. The lower the ping times, the more points each node gets from the others.

Interesting idea, but we must ensure everyone is incentivized; for example, why would a node send certificate to other nodes? they would, for example, need to benefit from it, at least in part.
And it must be possible for all the other nodes to check it some way, or there is no consensus and one could send certificates back and forth between his nodes.

Yes, agree. One incentive for sending the certificates is that the node wants the others to also send certificates back. If A sends a cert to B and B doesn't send one to A, a surely wouldn't send another one to B in the next round -> incentive for B.
The part about all the other nodes to check it is where I don't know enough about current POS systems and how they work. In normal POS, other nodes also must get a consensus about how much stake a node has accumulated and the resulting odds for minting. I think the same mechanism applies here.

Problem is that ping and uptime measurement may differ from node to node, difficult to have consensus on those.

I don't think that's a problem. Let's assume we want to establish the total amount of points for node A. So node A gets a certificate form B. The connection between A and B is pretty good. Low ping. And the uptime of A is really long. So B is going to send back a certificate containing a lot of points.
Node C has just come online and has a bad connection. It pings A, slow, and can only assert an uptime for A that is equal to C's own uptime. So it's going to send a certificate with only very few points.
Both certificates are signed by the senders so that other nodes can easily confirm the validity using publicly known public keys (I'm thinking of a system similar to PGP/GPG where people can sign messages using their private key and others can easily confirm the signatures using the signee's publicly known key).

That way, in the end, every node would collect a number of certificates per round from its neighbours and therefore have a total sum of points and every other node could request the total number of points and confirm the validity by confirming each certificate's signature.

Would that make sense?

XCN: CJSECkHi7tTTTA1ze9qYRkkUCKfFiF8EEG
1715554743
Hero Member
*
Offline Offline

Posts: 1715554743

View Profile Personal Message (Offline)

Ignore
1715554743
Reply with quote  #2

1715554743
Report to moderator
Each block is stacked on top of the previous one. Adding another block to the top makes all lower blocks more difficult to remove: there is more "weight" above each block. A transaction in a block 6 blocks deep (6 confirmations) will be very difficult to remove.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715554743
Hero Member
*
Offline Offline

Posts: 1715554743

View Profile Personal Message (Offline)

Ignore
1715554743
Reply with quote  #2

1715554743
Report to moderator
pallas
Legendary
*
Offline Offline

Activity: 2716
Merit: 1094


Black Belt Developer


View Profile
September 14, 2017, 08:48:54 AM
 #22

That's an interesting thought. Nodes could test each other for availability and send each other certificates asserting a certain uptime which then could be used as a foundation for POS minting.
That way, the more certificates a node collects, the higher the chance for minting.
That approach would not only reward uptime but also connectivity, e.g. the more connections to other nodes a node has, the more certificates it receives per time.
And if the certificates have some kind of points system, the ping time between the nodes could be used as a bonus multiplier. The lower the ping times, the more points each node gets from the others.

Interesting idea, but we must ensure everyone is incentivized; for example, why would a node send certificate to other nodes? they would, for example, need to benefit from it, at least in part.
And it must be possible for all the other nodes to check it some way, or there is no consensus and one could send certificates back and forth between his nodes.

Yes, agree. One incentive for sending the certificates is that the node wants the others to also send certificates back. If A sends a cert to B and B doesn't send one to A, a surely wouldn't send another one to B in the next round -> incentive for B.
The part about all the other nodes to check it is where I don't know enough about current POS systems and how they work. In normal POS, other nodes also must get a consensus about how much stake a node has accumulated and the resulting odds for minting. I think the same mechanism applies here.

Problem is that ping and uptime measurement may differ from node to node, difficult to have consensus on those.

I don't think that's a problem. Let's assume we want to establish the total amount of points for node A. So node A gets a certificate form B. The connection between A and B is pretty good. Low ping. And the uptime of A is really long. So B is going to send back a certificate containing a lot of points.
Node C has just come online and has a bad connection. It pings A, slow, and can only assert an uptime for A that is equal to C's own uptime. So it's going to send a certificate with only very few points.
Both certificates are signed by the senders so that other nodes can easily confirm the validity using publicly known public keys (I'm thinking of a system similar to PGP/GPG where people can sign messages using their private key and others can easily confirm the signatures using the signee's publicly known key).

That way, in the end, every node would collect a number of certificates per round from its neighbours and therefore have a total sum of points and every other node could request the total number of points and confirm the validity by confirming each certificate's signature.

Would that make sense?

the other nodes will need to verify the ping and uptime values, not just the signature of the certificate.
otherwise one could put up two nodes, then send valid certificates with random ping and uptime values between themselves.

gnasirator (OP)
Full Member
***
Offline Offline

Activity: 175
Merit: 113


View Profile
September 14, 2017, 07:46:57 PM
 #23

That's an interesting thought. Nodes could test each other for availability and send each other certificates asserting a certain uptime which then could be used as a foundation for POS minting.
That way, the more certificates a node collects, the higher the chance for minting.
That approach would not only reward uptime but also connectivity, e.g. the more connections to other nodes a node has, the more certificates it receives per time.
And if the certificates have some kind of points system, the ping time between the nodes could be used as a bonus multiplier. The lower the ping times, the more points each node gets from the others.

Interesting idea, but we must ensure everyone is incentivized; for example, why would a node send certificate to other nodes? they would, for example, need to benefit from it, at least in part.
And it must be possible for all the other nodes to check it some way, or there is no consensus and one could send certificates back and forth between his nodes.

Yes, agree. One incentive for sending the certificates is that the node wants the others to also send certificates back. If A sends a cert to B and B doesn't send one to A, a surely wouldn't send another one to B in the next round -> incentive for B.
The part about all the other nodes to check it is where I don't know enough about current POS systems and how they work. In normal POS, other nodes also must get a consensus about how much stake a node has accumulated and the resulting odds for minting. I think the same mechanism applies here.

Problem is that ping and uptime measurement may differ from node to node, difficult to have consensus on those.

I don't think that's a problem. Let's assume we want to establish the total amount of points for node A. So node A gets a certificate form B. The connection between A and B is pretty good. Low ping. And the uptime of A is really long. So B is going to send back a certificate containing a lot of points.
Node C has just come online and has a bad connection. It pings A, slow, and can only assert an uptime for A that is equal to C's own uptime. So it's going to send a certificate with only very few points.
Both certificates are signed by the senders so that other nodes can easily confirm the validity using publicly known public keys (I'm thinking of a system similar to PGP/GPG where people can sign messages using their private key and others can easily confirm the signatures using the signee's publicly known key).

That way, in the end, every node would collect a number of certificates per round from its neighbours and therefore have a total sum of points and every other node could request the total number of points and confirm the validity by confirming each certificate's signature.

Would that make sense?

the other nodes will need to verify the ping and uptime values, not just the signature of the certificate.
otherwise one could put up two nodes, then send valid certificates with random ping and uptime values between themselves.

True. Well uptime is no problem. Node A will be able to confirm any other node B's uptime as long as it is shorter than A's.
With regard to pings, yes that is hard to validate from a 3rd party's perspective.

XCN: CJSECkHi7tTTTA1ze9qYRkkUCKfFiF8EEG
Pages: « 1 [2]  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!