# \[v0.9.0\] New node ID format
**URL:** https://forum.syncthing.net/t/v0-9-0-new-node-id-format/478
**Category:** Announce
**Created:** [June 30, 2014, 12:05am UTC](https://forum.syncthing.net/t/v0-9-0-new-node-id-format/478 "2014-06-30T00:05:13Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@calmh](https://forum.syncthing.net/u/calmh)
#### Post date: [June 30, 2014, 12:05am UTC](https://forum.syncthing.net/t/v0-9-0-new-node-id-format/478/1 "2014-06-30T00:05:14Z")
v0.9 introduces a new format for node ID:s. It’s quite similar to the old one. The old format:
```
P56IOI-7MZJNU-2IQGDR-EYDM2M-GTMGL3-BXNPQ6-W5BTBB-Z4TJXZ-WICQ
```
And the new format:
```
P56IOI7-MZJNU2Y-IQGDREY-DM2MGTI-MGL3BXN-PQ6W5BM-TBBZ4TJ-XZWICQ2
```
The differences are:
1. There are four more characters (56 vs the old 52). The extra bits of data are check characters. When a node ID is input or loaded from configuration, the check characters are verified to make sure the node ID has been correctly copied.
2. The grouping is changed to groups of seven. This nicely divides the new node ID into eight equal groups.
The placement of the check digits are as follows:
```
aaaaaaa-aaaaaaA-bbbbbbb-bbbbbbB-ccccccc-ccccccC-ddddddd-ddddddD
```
`aaaaaaa-aaaaaa` are data, checked by the immediately following `A` character, and similarly for `b`, `c`, and `d`. That is, each two seven-character groups contain their own check digit.
The GUI will provide some useful feedback (i.e. green/red letter groups) when entering a node ID, based on the correctness of the check digits.
The console logs and configuration now all contain the new format node ID:s (with the configuration accepting the old format as well).
Trivial copying errors (O to 0, I to 1 and B to 8) are corrected silently and automatically.
---
### Author:  [@Nutomic](https://forum.syncthing.net/u/Nutomic)
#### Post date: [July 4, 2014, 12:35am UTC](https://forum.syncthing.net/t/v0-9-0-new-node-id-format/478/2 "2014-07-04T00:35:21Z")
Does the API also provide the correct (grouped) format? This isn’t the case yet.
Also, could you document the checking? (or at least link to the implementation).
---
### Author:  [@jedie](https://forum.syncthing.net/u/jedie)
#### Post date: [July 4, 2014, 12:23pm UTC](https://forum.syncthing.net/t/v0-9-0-new-node-id-format/478/3 "2014-07-04T12:23:28Z")
Related ticked is:
[https://github.com/calmh/syncthing/issues/269](https://github.com/calmh/syncthing/issues/269)
---
### Author:  [@calmh](https://forum.syncthing.net/u/calmh)
#### Post date: [July 4, 2014, 1:44pm UTC](https://forum.syncthing.net/t/v0-9-0-new-node-id-format/478/4 "2014-07-04T13:44:26Z")
The API speaks new format (but accepts the old format as input), in v0.9 (i.e. master, currently). The checking uses the [Luhn mod N algorithm](http://en.wikipedia.org/wiki/Luhn_mod_N_algorithm) with N being 32 and the digits being the base32 alphabet. The Go implementation is [here](https://github.com/calmh/syncthing/blob/master/luhn/luhn.go). There’ll either be one in Javascript for the GUI or an API call to do the check in question.
---
### Author:  [@dapperstout](https://forum.syncthing.net/u/dapperstout)
#### Post date: [November 25, 2014, 8:43pm UTC](https://forum.syncthing.net/t/v0-9-0-new-node-id-format/478/5 "2014-11-25T20:43:09Z")
Hi Jakob, I was implementing the Luhn mod N algorithm in Swift, and found a discrepancy between the Swift port and the Go original. When I calculate the first check digit for P56IOI7MZJNU2, I get an “S” instead of a “Y”.
I went through the Go code, and if I read it correctly you iterate through the string left-to-right, alternating between a factor of 1 and 2. However, in the wikipedia article about the Luhn Mode N algorithm it is specified that you should iterate right-to-left, alternating between a factor of 2 and 1.
Can you verify whether my conclusion is correct? And if it is indeed an error in the Go code, will you change it, or shall I adopt the ‘wrong’ implementation in Swift?
---
### Author:  [@calmh](https://forum.syncthing.net/u/calmh)
#### Post date: [November 25, 2014, 9:10pm UTC](https://forum.syncthing.net/t/v0-9-0-new-node-id-format/478/6 "2014-11-25T21:10:09Z")
You’re right - my implementation is wrong. The annoying thing is that I took the test cases (`abcdef` =\> check digit `e`) from that page, and that specific string works in either case since it contains an even number of characters. But on node IDs it checks on groups of 13 characters, where the difference matters. Doh! 😬
Correcting the calculator is trivial, but renders all current node IDs invalid so that would need to handled carefully. I think we’ll leave it as is for the moment…
---
### Author:  [@dapperstout](https://forum.syncthing.net/u/dapperstout)
#### Post date: [November 25, 2014, 10:07pm UTC](https://forum.syncthing.net/t/v0-9-0-new-node-id-format/478/7 "2014-11-25T22:07:39Z")
All right, I have adapted the Swift code to the current Go implementation.
In the following commit you can find some test cases that I used to derive the Swift algorithm. Might be useful should you one day decide to change the Go implementation.
>
---
### Author:  [@calmh](https://forum.syncthing.net/u/calmh)
#### Post date: [June 23, 2015, 7:47pm UTC](https://forum.syncthing.net/t/v0-9-0-new-node-id-format/478/8 "2015-06-23T19:47:46Z")
---
### Author:  [@calmh](https://forum.syncthing.net/u/calmh)
#### Post date: [June 23, 2015, 7:47pm UTC](https://forum.syncthing.net/t/v0-9-0-new-node-id-format/478/9 "2015-06-23T19:47:51Z")