Version 4.x & Beyond - Feature Request

Development & Technical discussion about Timekoin.
Forum rules
Bug Collecting Database is Click Here
GitHub Account is Click Here
User avatar
PoisonWolf
Posts: 186
Joined: Fri Apr 12, 2013 10:39 am

Re: Version 4.x & Beyond - Feature Request

Post by PoisonWolf »

Another suggestion that just popped to my mind.

One of TK's biggest strength (IMHO) is that the server software is constantly getting updates. I'm a firm believer in faster and shorter update cycles than otherwise. However, I also remember a time where there were several older nodes that did not update their server software and was causing issue for the rest of the network with bad transaction data.

I was wondering if it's possible to identify and add the server version of your peers' server version? For example, currently the Peerlist Tab only shows the following

Code: Select all

timekoin.com     timekoin     80     34 secs     5 days     First Contact
I was wondering if it's beneficial to change it to

Code: Select all

[3.61] timekoin.com     timekoin     80     34 secs     5 days     First Contact
Or maybe add a whole new column

Code: Select all

timekoin.com     timekoin     80     34 secs     5 days     First Contact     3.61
This is just an idea I had in my mind. Does anyone have any opinions on whether this would have negative consequences that I am unaware of? I'm thinking of it as being more of an informative variable so that if people want to pick up-to-date permanent peers, they would know which server to keep on their list and which to purge, etc. This information can also be used to pull for awesome statistics such as 51% of the network are on which server version on timekoin's homepage. This would give us a sense of how fast server operators update their software code, etc.
warmach
Posts: 404
Joined: Thu Jun 21, 2012 5:18 pm

Re: Version 4.x & Beyond - Feature Request

Post by warmach »

PoisonWolf wrote:Another suggestion that just popped to my mind.

One of TK's biggest strength (IMHO) is that the server software is constantly getting updates. I'm a firm believer in faster and shorter update cycles than otherwise. However, I also remember a time where there were several older nodes that did not update their server software and was causing issue for the rest of the network with bad transaction data.

I was wondering if it's possible to identify and add the server version of your peers' server version? For example, currently the Peerlist Tab only shows the following

Code: Select all

timekoin.com     timekoin     80     34 secs     5 days     First Contact
I was wondering if it's beneficial to change it to

Code: Select all

[3.61] timekoin.com     timekoin     80     34 secs     5 days     First Contact
Or maybe add a whole new column

Code: Select all

timekoin.com     timekoin     80     34 secs     5 days     First Contact     3.61
This is just an idea I had in my mind. Does anyone have any opinions on whether this would have negative consequences that I am unaware of? I'm thinking of it as being more of an informative variable so that if people want to pick up-to-date permanent peers, they would know which server to keep on their list and which to purge, etc. This information can also be used to pull for awesome statistics such as 51% of the network are on which server version on timekoin's homepage. This would give us a sense of how fast server operators update their software code, etc.
I think this is tremendously important. At some point in time, a new change will be included in an update that would require all servers to use. This would be for new features but most likely a security update. I think we need to maintain a minimum acceptable version of the software. Anything below that version will be black listed from the network. Keep the bad apples out...
User avatar
PoisonWolf
Posts: 186
Joined: Fri Apr 12, 2013 10:39 am

Re: Version 4.x & Beyond - Feature Request

Post by PoisonWolf »

warmach wrote:
I think this is tremendously important. At some point in time, a new change will be included in an update that would require all servers to use. This would be for new features but most likely a security update. I think we need to maintain a minimum acceptable version of the software. Anything below that version will be black listed from the network. Keep the bad apples out...
Yeah. Initially I thought it would be great to blacklist servers...but then I thought this might be dangerous as this would allow people to "centralize" the network or something (e.g., large timekoin farms excluding the average joe, etc). I think, for example, it should be a flat code that says for version 4.00, all people that update to it will start ignoring folks lower than 3.40, etc). The server operator themselves should not be able to specify or choose which version is uploaded. It should be equal throughout. I know that technically we could still create our own personal IP blacklisting on the OS-side or on the router side...but ...hmm....but meh, this idea likely needs more fleshing out. I'm trying to think of long-term repercussions of this idea.
User avatar
KnightMB
Site Admin
Posts: 1019
Joined: Thu Feb 23, 2012 5:03 pm

Re: Version 4.x & Beyond - Feature Request

Post by KnightMB »

There is technically a way to already check the version of a peer. Every component of Timekoin already broadcast its version number and name in the headers; if you have the web server logging your HTTP traffic, you can see the version in the headers.

Example, this is from my dev machine web logs.

Code: Select all

85.214.48.205 - - [01/Feb/2016:04:02:03 -0600] "GET /timekoin/transclerk.php?action=history_hash HTTP/1.0" 200 32 "-" "Timekoin Server (Transclerk) v3.61"
188.226.141.68 - - [01/Feb/2016:04:02:03 -0600] "GET /timekoin/queueclerk.php?action=transaction&number=5efd0fabcef635451a5c2203e5bc7d78 HTTP/1.0" 200 1475 "-" "Timekoin Server (Queueclerk) v3.61"
188.166.5.156 - - [01/Feb/2016:04:02:03 -0600] "GET /timekoin/queueclerk.php?action=transaction&number=1c58b03d38e6321814f38cb6fd532bfd HTTP/1.0" 200 1475 "-" "Timekoin Server (Queueclerk) v3.61"
192.241.133.56 - - [01/Feb/2016:04:02:03 -0600] "GET /timekoin/peerlist.php?action=join HTTP/1.0" 200 2 "-" "Timekoin Server (Peerlist) v3.61"
Now, having peers poll each other for version and display it in the peer list for example would not take much coding. But you do come back to the issue, if everyone is running v4.0 for example and some security fix means all other peers are incompatible, what would you do with peers that are coded to lie about the version? Like, someone just modifies their v3.61 to say v4.0. I know that is a silly example, but if we start doing a version lock, we have to think about all possible ways to abuse it as well. :shock:
User avatar
PoisonWolf
Posts: 186
Joined: Fri Apr 12, 2013 10:39 am

Re: Version 4.x & Beyond - Feature Request

Post by PoisonWolf »

KnightMB wrote:There is technically a way to already check the version of a peer. Every component of Timekoin already broadcast its version number and name in the headers; if you have the web server logging your HTTP traffic, you can see the version in the headers.

Example, this is from my dev machine web logs.

Code: Select all

85.214.48.205 - - [01/Feb/2016:04:02:03 -0600] "GET /timekoin/transclerk.php?action=history_hash HTTP/1.0" 200 32 "-" "Timekoin Server (Transclerk) v3.61"
188.226.141.68 - - [01/Feb/2016:04:02:03 -0600] "GET /timekoin/queueclerk.php?action=transaction&number=5efd0fabcef635451a5c2203e5bc7d78 HTTP/1.0" 200 1475 "-" "Timekoin Server (Queueclerk) v3.61"
188.166.5.156 - - [01/Feb/2016:04:02:03 -0600] "GET /timekoin/queueclerk.php?action=transaction&number=1c58b03d38e6321814f38cb6fd532bfd HTTP/1.0" 200 1475 "-" "Timekoin Server (Queueclerk) v3.61"
192.241.133.56 - - [01/Feb/2016:04:02:03 -0600] "GET /timekoin/peerlist.php?action=join HTTP/1.0" 200 2 "-" "Timekoin Server (Peerlist) v3.61"
Now, having peers poll each other for version and display it in the peer list for example would not take much coding. But you do come back to the issue, if everyone is running v4.0 for example and some security fix means all other peers are incompatible, what would you do with peers that are coded to lie about the version? Like, someone just modifies their v3.61 to say v4.0. I know that is a silly example, but if we start doing a version lock, we have to think about all possible ways to abuse it as well. :shock:
Your point about how it can be abused is a very good one. We definitely don't want it to be easily tampered with when a server node broadcasts that they are version 3.5 for example. This information should not be modifiable, and should be tamper proof, IMHO.

Can the transaction encryption protocols be applied to the broadcast of the server version? Encrypt it with the 1536 RSA thingie, then use the SHA 256 to hash that encryption to make sure this server info is not tampered with? I think moving forward, knowing the state of the network accurately will be very critical to a constantly evolving network like Timekoin. I know that if this approach is taken, it might mean that there will be more space being taken up on the database. Perhaps make it such that this broadcast is only done once every 24 hours to reduce the database size strain on the network?

I know this would be crazy because it also means that when we click on the Peerlist tab, we would need to de-crypt all the provided server version numbers, and to do it constantly depending on how often the peer list tab refreshes. It is not an elegant solution, but it is one that came to mind.

After all, we have modern CPUs that can encrypt-decrypt with relative ease. I feel that we should use this feature as necessary beyond just securing transactions to make TK more secure, and ultimately more compelling as a cryptocurrency, as a whole.
collapse
Posts: 38
Joined: Sun Apr 21, 2013 2:44 pm

Re: Version 4.x & Beyond - Feature Request

Post by collapse »

Code: Select all

                                                         
# Time: 160203 12:42:39                                                                                                                                      
# *
# Thread_id: 3551  Schema: timekoin  QC_hit: No                                                                                                             
#Query_time: 26.322945  Lock_time: 0.000153  Rows_sent: 1  Rows_examined: 16748                                                                             
SET timestamp=1454499759;                                                                                                                                    
SELECT public_key_to FROM `transaction_history` WHERE `timestamp` > 1454199732 AND `attribute` = 'T' GROUP BY `public_key_to` ORDER BY RAND() LIMIT 1;
#Query_time: 26.322945

anormal? Or should be a feature request...
My TK public key:

Code: Select all

LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0KTUlIZk1BMEdDU3FHU0liM0RRRUJBUVVBQTRITkFEQ0J5UUtCd1FEQVZnL0w2OHorWUdab3dRRC92Sy93UmcwZDZLQlNoOG1DcFUzQwppZ1N4RjV4UUFMVUFWTEk4eElEUTFpTXFnUVlBanp3OFBGd1NtT0U2blpOV3dxSjVDeFRibS96NS9iQVZONnNNMys0M0VqdEZFdmhpCkxpNmhnZU9TWE05ZmsvNmlCSFQxQ0pnOVZiS25uRVlhemU1cHVKRHhtM0pWSlNZWGhNNHpqY2plMERsV1Fta1ArNnB2bTVZNkwxbEkKSHFaT0ZwdEZWV3dnVzE0NDFyd0E0MDU5YVJPOEJEbDZhS3VzWTVDblhPQnNLU251dGVUS1hHU1htK3FFam91M0dzVUNBd0VBQVE9PQotLS0tLUVORCBQVUJMSUMgS0VZLS0tLS0=
User avatar
bucket
Posts: 32
Joined: Thu May 16, 2013 8:30 pm

Re: Version 4.x & Beyond - Feature Request

Post by bucket »

collapse wrote:

Code: Select all

                                                         
# Time: 160203 12:42:39                                                                                                                                      
# *
# Thread_id: 3551  Schema: timekoin  QC_hit: No                                                                                                             
#Query_time: 26.322945  Lock_time: 0.000153  Rows_sent: 1  Rows_examined: 16748                                                                             
SET timestamp=1454499759;                                                                                                                                    
SELECT public_key_to FROM `transaction_history` WHERE `timestamp` > 1454199732 AND `attribute` = 'T' GROUP BY `public_key_to` ORDER BY RAND() LIMIT 1;
#Query_time: 26.322945

anormal? Or should be a feature request...
I ran the same query on mine, got it back in like 0.0017 something seconds. 26 real seconds seems a little extreme.
Last edited by bucket on Wed Feb 03, 2016 10:39 am, edited 1 time in total.
User avatar
bucket
Posts: 32
Joined: Thu May 16, 2013 8:30 pm

Re: Version 4.x & Beyond - Feature Request

Post by bucket »

PoisonWolf wrote:Your point about how it can be abused is a very good one. We definitely don't want it to be easily tampered with when a server node broadcasts that they are version 3.5 for example. This information should not be modifiable, and should be tamper proof, IMHO.
In a decentralized system like this, you can't really make a tamper proof response because even if the peer encrypts the response, the peer can still say what ever it likes. The only reason timekoin works in my reasoning is that certain rules are followed by all peers and any peer outside of that is removed from the game (I like game analogies). So you have two teams playing some Basketball and one of them decides to bring a ladder and set it right next to the hoop, well that player is removed from the game so it doesn't matter how many easy shots he made, his score is ignored. Only the players that play by the rules, only their points count. But if a rule was created that no player may think ill thoughts towards the other team, how would you ever enforce that? So having all the peers ignore older versions could be useful for stability, but I think knightmb had the right idea that any new rules to the game should be phased in gradually to allow everyone to upgrade/adapter/etc. So if basketball created a new rule that all players must wear shine guards while playing but the rule doesn't become legal until next year, the players have time to learn about the new rule and adapt for the day it becomes official.
warmach
Posts: 404
Joined: Thu Jun 21, 2012 5:18 pm

Re: Version 4.x & Beyond - Feature Request

Post by warmach »

KnightMB wrote: Now, having peers poll each other for version and display it in the peer list for example would not take much coding. But you do come back to the issue, if everyone is running v4.0 for example and some security fix means all other peers are incompatible, what would you do with peers that are coded to lie about the version? Like, someone just modifies their v3.61 to say v4.0. I know that is a silly example, but if we start doing a version lock, we have to think about all possible ways to abuse it as well. :shock:
Why not have the version built into blockchain? Create a network transaction that lists the current version, minimum version, and an effective time? This would allow a unified minimum version and a time when this version information would be enforced. I would guess this transaction would need to come from a specific account hard coded into software. Not sure how else to do that.

If someone is going to modify code to lie about their version, I think there will be bigger problems. This user is likely to try and exploit the network and their minimum version is probably the least of our worries.

We could build the server's current version into the currency generation. While it will not cover "client" setups, the main network servers would me the most important to have at the proper level since they essential maintain the network. A valid currency generation transaction would need to have the appropriate version checked against the version effective time.

It makes sense in my head, but let me know if what is written here needs clarified.
collapse
Posts: 38
Joined: Sun Apr 21, 2013 2:44 pm

Re: Version 4.x & Beyond - Feature Request

Post by collapse »

bucket wrote: I ran the same query on mine, got it back in like 0.0017 something seconds. 26 real seconds seems a little extreme.
In mysql cli 0.24sg, 0.0017 is really fast. Seems that only some queries are really slow.
My TK public key:

Code: Select all

LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0KTUlIZk1BMEdDU3FHU0liM0RRRUJBUVVBQTRITkFEQ0J5UUtCd1FEQVZnL0w2OHorWUdab3dRRC92Sy93UmcwZDZLQlNoOG1DcFUzQwppZ1N4RjV4UUFMVUFWTEk4eElEUTFpTXFnUVlBanp3OFBGd1NtT0U2blpOV3dxSjVDeFRibS96NS9iQVZONnNNMys0M0VqdEZFdmhpCkxpNmhnZU9TWE05ZmsvNmlCSFQxQ0pnOVZiS25uRVlhemU1cHVKRHhtM0pWSlNZWGhNNHpqY2plMERsV1Fta1ArNnB2bTVZNkwxbEkKSHFaT0ZwdEZWV3dnVzE0NDFyd0E0MDU5YVJPOEJEbDZhS3VzWTVDblhPQnNLU251dGVUS1hHU1htK3FFam91M0dzVUNBd0VBQVE9PQotLS0tLUVORCBQVUJMSUMgS0VZLS0tLS0=
Post Reply