nodes issueshttps://git.duniter.org/groups/nodes/-/issues2017-11-28T16:49:16+01:00https://git.duniter.org/nodes/typescript/duniter/-/issues/902Scaling up the certifications pools with a DHT2017-11-28T16:49:16+01:00insoScaling up the certifications pools with a DHTAs we can see, since it takes a long time for one to become a member, the data pools are filled up and it is stucking the entrance of new members.
Here, I'm suggesting an evolution to be able to scale up the pools. We already discusse...As we can see, since it takes a long time for one to become a member, the data pools are filled up and it is stucking the entrance of new members.
Here, I'm suggesting an evolution to be able to scale up the pools. We already discussed it on the chat some time ago, but I wanted to trace the idea.
The certifications are blocked because, for one new member, you need 5 certifications.
The nodes can locally only have locally the MS+IDTY documents and a partial view of the certifications. Thus, we only need to distribute the certifications on the DHT.
The overall idea is :
- The nodes have the identities and memberships in their pools. They don't necessary have all the identities or all the memberships.
- The nodes are distributing throught a DHT the certifications documents
- The nodes use the DHT to discover which identity can become a member when forging new blocks
## The DHT
I suggest to use Kademlia DHT, for example using KAD framework for node js : https://github.com/kadtools/kad.
The format of the keys could be :
```
CERT:[PUBKEY_TO]
```
- [PUBKEY_TO] corresponds to the pubkey being certified
The format of the values would be the raw certification documents valid and writable for the given timestamp target.
## The forging of blocks
- During the computation of block "N", the node would check which identity could become a member in block "N+1".
- For all Identities+Membership in the pool, if they don't have enough certifications locally, they would ask the network for valid certifications about this identity and membership.
- When block "N" is computed, the node would start computing block "N+1" with the data received by the network during the computation of block "N" .
## Duniter plugins required for Kad
- A middleware using pubkey of peers to protect the network against classic sybil attacks
- A middleware to append data to keys when receiving documents throught BMA
https://git.duniter.org/nodes/typescript/duniter/-/issues/898snap package2017-11-28T16:49:17+01:00Cédric Moreausnap package*Created by: Thatoo*
I wanted to try to install duniter on my ubuntu phone but for that I understood I needed a snap package, not a deb package.
I had a look at how to make a snap package out of github repository thanks to
https://...*Created by: Thatoo*
I wanted to try to install duniter on my ubuntu phone but for that I understood I needed a snap package, not a deb package.
I had a look at how to make a snap package out of github repository thanks to
https://snapcraft.io/docs/build-snaps/ci-integration
With the help of RavanH, I think we managed to do all except making the snapcraft.yaml file that need to be added to github for the packaging to work.
Here are instruction how to make this file :
https://snapcraft.io/docs/build-snaps/your-first-snap
If someone can make that file, I think we'd have the snap package ready here and update automatically anytime github repo is updated : https://code.launchpad.net/~duniter/+snap/duniter
An other thing I don't know is what to tick in this list of processor (it's optional so I let the default stuff) :
+ AMD x86-64 (amd64)
ARM ARMv8 (arm64)
+ ARM ARMv7 Hard Float (armhf)
+ Intel x86 (i386)
PowerPC (powerpc)
PowerPC64 Little-Endian (ppc64el)
IBM System z (s390x
Edit : I ticked also ARM ARMv7 Hard Float for Rasp Pi 3
I found also that page that might help for making snapcraft.yaml file :
https://snapcraft.io/docs/build-snaps/syntaxhttps://git.duniter.org/nodes/typescript/duniter/-/issues/888The main entry of the PowerClearRequest is not found2017-11-28T16:49:17+01:00Cédric MoreauThe main entry of the PowerClearRequest is not found*Created by: Patator65*
Hi,
I have an issue when i try to start Duniter.
This is the error message i get (i do my own translation fr to en of this message) :
The main entry of the PowerClearRequest is not found in the lib of dynamic ...*Created by: Patator65*
Hi,
I have an issue when i try to start Duniter.
This is the error message i get (i do my own translation fr to en of this message) :
The main entry of the PowerClearRequest is not found in the lib of dynamic links KERNEL32.dll.
Hope it is correctly translanted :)
My PC works with Vista x64.https://git.duniter.org/nodes/typescript/duniter/-/issues/901Desktop: after a resync, PoW blocks are not shared2017-11-28T16:49:17+01:00Cédric MoreauDesktop: after a resync, PoW blocks are not shared> (18:15:42) jytou: re passage en coup de vent: je confirme que tant que je n'ai pas redémarré mon nœud après une syncho, il trouvait des blocs mais n'arrivait pas à les publier, pas d'erreur apparente dans les logs mais plein de « found...> (18:15:42) jytou: re passage en coup de vent: je confirme que tant que je n'ai pas redémarré mon nœud après une syncho, il trouvait des blocs mais n'arrivait pas à les publier, pas d'erreur apparente dans les logs mais plein de « found » sans publication, et hop je suis reparti
(18:20:43) cgeek: jytou: tu parles de la version desktop ?
(18:22:18) bruno a quitté le salon (Disconnected: closed)
(18:24:22) jytou: cgeek: ouiHorizonhttps://git.duniter.org/nodes/typescript/duniter/-/issues/891Node kept UP if a web server is running at same address and the node is down2017-11-28T16:49:17+01:00Cédric MoreauNode kept UP if a web server is running at same address and the node is down*Created by: M5oul*
I turned off my node on my YunoHost instance, and the node on my desktop keep staying the other one is still running:
```bash
2017-03-14T17:10:13+01:00 - info: Sibling endpoints: 0=BMAS duniter.moul.re 443, 1=BMAS ...*Created by: M5oul*
I turned off my node on my YunoHost instance, and the node on my desktop keep staying the other one is still running:
```bash
2017-03-14T17:10:13+01:00 - info: Sibling endpoints: 0=BMAS duniter.moul.re 443, 1=BMAS duniter.moul.re 78.227.107.45 2a01:e34:ee36:b2d0:83:6ff:fe43:6546 443
2017-03-14T17:10:13+01:00 - info: External access: desktop.moul.re:10901
```
In fact, there is still an http server running behind this address, but not a duniter node.
How is checked the fact there is a running node?
Only by checking if the address answer or if it could get something for the BMA?
I wasn't able to found how the check is done on the [crawler](https://github.com/duniter/duniter-crawler/blob/master/lib/crawler.js).
Horizonhttps://git.duniter.org/nodes/typescript/duniter/-/issues/890Dynamic IP: detect the public IP changing2018-12-07T14:10:25+01:00Cédric MoreauDynamic IP: detect the public IP changingSee https://forum.duniter.org/t/noeud-qui-pedale-dans-la-choucroute/2176See https://forum.duniter.org/t/noeud-qui-pedale-dans-la-choucroute/2176Horizonhttps://git.duniter.org/nodes/typescript/duniter/-/issues/886BMA Network: listen on all interfaces (and with the interface name)2017-11-28T16:49:17+01:00Cédric MoreauBMA Network: listen on all interfaces (and with the interface name)*Created by: Tortue95*
Hi,
can you add the possibility to listen on all interfaces
and at the same time the possibility to listen on one interface name (not the IP)*Created by: Tortue95*
Hi,
can you add the possibility to listen on all interfaces
and at the same time the possibility to listen on one interface name (not the IP)https://git.duniter.org/nodes/typescript/duniter/-/issues/880wotb module don't have the full inventory of certifications2017-11-28T16:49:17+01:00Cédric Moreauwotb module don't have the full inventory of certificationsI see 486 links un wotb, whereas 551 were written.
I see 486 links un wotb, whereas 551 were written.
Horizonhttps://git.duniter.org/nodes/typescript/duniter/-/issues/874Node didn't resync after restart2017-11-28T16:49:17+01:00Cédric MoreauNode didn't resync after restart*Created by: M5oul*
I started my node after a night turned off, and it didn't retrieved new blocks from the network.
I had to restart the node and it retrieved blocks from the network and was sync.
The fact there is two nodes using sa...*Created by: M5oul*
I started my node after a night turned off, and it didn't retrieved new blocks from the network.
I had to restart the node and it retrieved blocks from the network and was sync.
The fact there is two nodes using same pubkey could be explain why this happen.
Similar to https://github.com/duniter/duniter/issues/683.Horizonhttps://git.duniter.org/nodes/typescript/duniter/-/issues/871Bug on money management?2017-11-28T16:49:17+01:00Cédric MoreauBug on money management?*Created by: M5oul*
```bash
2017-03-04T10:48:48+01:00 - info: Will pull blocks from the network in 0 min 20 sec
2017-03-04T10:48:53+01:00 - info: Transaction 2B2D20EA1D2FA145EEB597495F2A2E1028EF5A23AA2E6B4DC056A86F25C2A2BB added to bl...*Created by: M5oul*
```bash
2017-03-04T10:48:48+01:00 - info: Will pull blocks from the network in 0 min 20 sec
2017-03-04T10:48:53+01:00 - info: Transaction 2B2D20EA1D2FA145EEB597495F2A2E1028EF5A23AA2E6B4DC056A86F25C2A2BB added to block
2017-03-04T10:48:53+01:00 - error: Error: It cannot exist 2 identical sources for transactions inside a given block
at Error (native)
at /opt/duniter/sources/app/lib/rules/local_rules.js:327:13
at next (native)
at onFulfilled (/opt/duniter/sources/node_modules/co/index.js:65:19)
at /opt/duniter/sources/node_modules/co/index.js:54:5
at co (/opt/duniter/sources/node_modules/co/index.js:50:10)
at Object.checkTxSources (/opt/duniter/sources/app/lib/rules/local_rules.js:317:30)
at /opt/duniter/sources/app/lib/rules/local_rules.js:416:24
at next (native)
at onFulfilled (/opt/duniter/sources/node_modules/co/index.js:65:19)
at process._tickCallback (internal/process/next_tick.js:103:7)
2017-03-04T10:48:53+01:00 - error: Error: It cannot exist 2 identical sources for transactions inside a given block
at Error (native)
at /opt/duniter/sources/app/lib/rules/local_rules.js:327:13
at next (native)
at onFulfilled (/opt/duniter/sources/node_modules/co/index.js:65:19)
at /opt/duniter/sources/node_modules/co/index.js:54:5
at co (/opt/duniter/sources/node_modules/co/index.js:50:10)
at Object.checkTxSources (/opt/duniter/sources/app/lib/rules/local_rules.js:317:30)
at /opt/duniter/sources/app/lib/rules/local_rules.js:416:24
at next (native)
at onFulfilled (/opt/duniter/sources/node_modules/co/index.js:65:19)
at runMicrotasksCallback (internal/process/next_tick.js:58:5)
at _combinedTickCallback (internal/process/next_tick.js:67:7)
at process._tickCallback (internal/process/next_tick.js:98:9)
2017-03-04T10:48:53+01:00 - error: Error: It cannot exist 2 identical sources for transactions inside a given block
```Horizonhttps://git.duniter.org/nodes/typescript/duniter/-/issues/868Have an harder personal handicap2017-11-28T16:49:17+01:00Cédric MoreauHave an harder personal handicapToday the handicap is defined as:
PERSONAL_HANDICAP = FLOOR(LN(1 + PERSONAL_EXCESS) / LN(1.189))
So this is a purely linear difficulty augmentation: if our computer is 16 times stronger than the co-calculators, our difficulty w...Today the handicap is defined as:
PERSONAL_HANDICAP = FLOOR(LN(1 + PERSONAL_EXCESS) / LN(1.189))
So this is a purely linear difficulty augmentation: if our computer is 16 times stronger than the co-calculators, our difficulty will go through:
* `PERSONAL_EXCESS = 1` => 18% harder than normally
* `PERSONAL_EXCESS = 2` => 41% harder than normally
* `PERSONAL_EXCESS = 3` => 68% harder than normally
* `PERSONAL_EXCESS = 4` => 100% harder than normally
With this algorithm, the difficulty increases with a delay, and may never handicap us to our have a difficulty corresponding to our effective superiority.
To reach it more quickly, we could simply use an exponential:
PERSONAL_HANDICAP = FLOOR(LN(1 + PERSONAL_EXCESS) / LN(1.189))*2
The result would be:
* `PERSONAL_EXCESS = 1` => 41% harder than normally
* `PERSONAL_EXCESS = 2` => 100% harder than normally
* `PERSONAL_EXCESS = 3` => 182% harder than normally
* `PERSONAL_EXCESS = 4` => 300% harder than normally
Have to study a bit more this before release.Horizonhttps://git.duniter.org/nodes/typescript/duniter/-/issues/867Fix the value of `percentRot` parameter2017-11-28T16:49:17+01:00Cédric MoreauFix the value of `percentRot` parameterCurrently this is an initial parameter from block#0. But for some reason this value could have an interest to be changed: for example in ĞTest we've put a wrong value which leads to an effective 50% PoW exclusion, instead of the 33% expe...Currently this is an initial parameter from block#0. But for some reason this value could have an interest to be changed: for example in ĞTest we've put a wrong value which leads to an effective 50% PoW exclusion, instead of the 33% expected.
This 33% rule could be hard coded. So percentRot would always equal 33%.Horizonhttps://git.duniter.org/nodes/typescript/duniter/-/issues/866Sign releases2020-04-30T22:10:23+02:00Cédric MoreauSign releasesThe releases should be signed + have a checksum to verify their integrity.
However this supposes to have our own building machines + a way to reproduce them on our own environement, so any allowed developer of Duniter organization cou...The releases should be signed + have a checksum to verify their integrity.
However this supposes to have our own building machines + a way to reproduce them on our own environement, so any allowed developer of Duniter organization could make a build.
Maybe we could use Vagrant or something to build the environement, then building scripts.Horizonhttps://git.duniter.org/nodes/typescript/duniter/-/issues/813Network problems in duniter-desktop-0.90.4 & -0.90.62017-11-28T16:49:16+01:00Cédric MoreauNetwork problems in duniter-desktop-0.90.4 & -0.90.6*Created by: Fatsie*
I'm still having network problems in duniter desktop.
My config:
* running in a container with local ip address 10.0.7.2 port 8999, this IP is not routable on the internat only on the LAN.
* have firewall with IP...*Created by: Fatsie*
I'm still having network problems in duniter desktop.
My config:
* running in a container with local ip address 10.0.7.2 port 8999, this IP is not routable on the internat only on the LAN.
* have firewall with IPv4 address 178.238.229.211 with NAT port forwarding of 8999 to 10.0.7.2:8999; firewall does not support UPnP
* container has no IPv6 network config (yet)
* This is in conf.json:
> "port": 8999,
> "ipv4": "10.0.7.2",
> "upnp": false,
> "remotehost": null,
> "remoteipv4": "178.238.229.211",
> "remoteport": 8999,
Server seems to be running: http://178.238.229.211:8999/network/peering
Duniter says network is not reachable:
![home_2017-01-28_12-05-36](https://cloud.githubusercontent.com/assets/11200448/22396159/a5eb4cb6-e552-11e6-8b54-e255a577fec5.png)
Network settings seem to be OK in GUI:
![netsettings_2017-01-28_12-07-15](https://cloud.githubusercontent.com/assets/11200448/22396166/b709bfe6-e552-11e6-8d92-6698edbfd34b.png)
Cesium can't show currency information:
![currency_2017-01-28_12-07-46](https://cloud.githubusercontent.com/assets/11200448/22396170/c6ab6e40-e552-11e6-81f8-c2681d53f55a.png)
nor 'My Account':
![cesiummyaccount_2017-01-28_12-08-30](https://cloud.githubusercontent.com/assets/11200448/22396187/087a75c8-e553-11e6-883e-b3083adfa694.png)
This is a node upgraded from 0.80.x after 'Full reset of the node' in Settings->DATA from the GUI.
https://git.duniter.org/nodes/typescript/duniter/-/issues/859Systematically error + dumped2017-11-28T16:49:16+01:00Cédric MoreauSystematically error + dumped*Created by: galuel*
J'ai toujours un plantage sous Ubuntu 64 bits, lors du premier lancement de duniter-desktop, depuis tout le temps je crois bien. J'y ai pas trop porté d'attention, car au deuxième lancement ça fonctionne généralemen...*Created by: galuel*
J'ai toujours un plantage sous Ubuntu 64 bits, lors du premier lancement de duniter-desktop, depuis tout le temps je crois bien. J'y ai pas trop porté d'attention, car au deuxième lancement ça fonctionne généralement...
$ duniter-desktop
2017-03-01T12:36:23+01:00 - debug: Plugging file system...
2017-03-01T12:36:23+01:00 - debug: Loading conf...
2017-03-01T12:36:24+01:00 - debug: Configuration saved.
2017-03-01T12:36:24+01:00 - debug: Opening SQLite database "/home/galuel/.config/duniter/duniter_default/duniter.db"...
2017-03-01T12:36:24+01:00 - debug: Upgrade database...
2017-03-01T12:36:24+01:00 - info: Duniter server listening on http://192.168.0.77:30118
2017-03-01T12:36:24+01:00 - info: UPnP: configuring...
2017-03-01T12:36:24+01:00 - trace: UPnP: mapping external port 30118 to local 30118...
2017-03-01T12:36:24+01:00 - info: Crawling the network...
2017-03-01T12:36:24+01:00 - info: Pulling blocks from the network...
2017-03-01T12:36:25+01:00 - trace: Checking if node DZRR5W is UP... (88.190.82.70:30118)
2017-03-01T12:36:25+01:00 - info: Sibling endpoints:
2017-03-01T12:36:25+01:00 - trace: Try with 90.9.227.204:8999 7iBkcy
2017-03-01T12:36:25+01:00 - info: Crawling done.
2017-03-01T12:36:25+01:00 - info: External access: 88.190.82.70:30118
2017-03-01T12:36:25+01:00 - debug: Generating server's peering entry based on block#8697...
2017-03-01T12:36:26+01:00 - error:
Abandon (core dumped)
- deuxième lancement :
$ duniter-desktop
2017-03-01T12:36:44+01:00 - debug: Plugging file system...
2017-03-01T12:36:45+01:00 - debug: Loading conf...
2017-03-01T12:36:45+01:00 - debug: Configuration saved.
2017-03-01T12:36:45+01:00 - debug: Opening SQLite database "/home/galuel/.config/duniter/duniter_default/duniter.db"...
2017-03-01T12:36:45+01:00 - debug: Upgrade database...
2017-03-01T12:36:45+01:00 - info: Duniter server listening on http://192.168.0.77:30118
2017-03-01T12:36:45+01:00 - info: UPnP: configuring...
2017-03-01T12:36:45+01:00 - trace: UPnP: mapping external port 30118 to local 30118...
2017-03-01T12:36:45+01:00 - info: Crawling the network...
2017-03-01T12:36:45+01:00 - info: Pulling blocks from the network...
2017-03-01T12:36:46+01:00 - info: Crawling done.
2017-03-01T12:36:46+01:00 - debug: Will check that node DZRR5W (88.190.82.70:30118) is UP in 1440 min...
2017-03-01T12:36:46+01:00 - info: Sibling endpoints:
2017-03-01T12:36:46+01:00 - trace: Try with 90.9.227.204:8999 7iBkcy
2017-03-01T12:36:46+01:00 - info: External access: 88.190.82.70:30118
2017-03-01T12:36:46+01:00 - debug: Generating server's peering entry based on block#8698...
2017-03-01T12:36:46+01:00 - info: Changing conf to: {"prefix":10} on engine#1
2017-03-01T12:36:46+01:00 - info: Changing conf to: {"prefix":10} on engine#2
2017-03-01T12:36:46+01:00 - info: Next peering signal in 10 min
2017-03-01T12:36:46+01:00 - warn: Waitinghttps://git.duniter.org/nodes/typescript/duniter/-/issues/857Sync may lead to empty BINDEX2017-11-28T16:49:16+01:00Cédric MoreauSync may lead to empty BINDEXUnder certain circumstances, after a full sync and then a start, the BINDEX is empty.
I suspect this has some link with the block number being a multiple of the chunk, or something related.Under certain circumstances, after a full sync and then a start, the BINDEX is empty.
I suspect this has some link with the block number being a multiple of the chunk, or something related.Horizonhttps://git.duniter.org/nodes/typescript/duniter/-/issues/852Do not launch PoW engines if not a member2017-11-28T16:49:16+01:00Cédric MoreauDo not launch PoW engines if not a memberHorizonhttps://git.duniter.org/nodes/typescript/duniter/-/issues/845Double-spending try on block generation2017-11-28T16:49:16+01:00Cédric MoreauDouble-spending try on block generationI noticed that some nodes were trying to include double-spending transactions.
I have backup `jytou2` to test this.I noticed that some nodes were trying to include double-spending transactions.
I have backup `jytou2` to test this.Horizonhttps://git.duniter.org/nodes/typescript/duniter/-/issues/846Have a minimal proof-of-work level2018-03-07T21:15:45+01:00Cédric MoreauHave a minimal proof-of-work levelWe noticed that during a hard-fork event there is a strong time acceleration which makes the PoW easier and easier as new blocks comes in, to a point where the difficulty become so easy that a block is issued within few seconds leading t...We noticed that during a hard-fork event there is a strong time acceleration which makes the PoW easier and easier as new blocks comes in, to a point where the difficulty become so easy that a block is issued within few seconds leading to breaking the synchronization of the nodes.
A minimal proof-of-work level could avoid such situations.Horizonhttps://git.duniter.org/nodes/typescript/duniter/-/issues/840DEP#001 Difficulty agreement protocol2020-10-04T19:22:26+02:00Cédric MoreauDEP#001 Difficulty agreement protocol* Related to: blockchain, proof-of-work
* Requires protocol upgrade: Yes
# Problem description
As of Duniter Protocol v1.0, the blockchain can be written only by members following this rule: at any moment, any member can issue a new bl...* Related to: blockchain, proof-of-work
* Requires protocol upgrade: Yes
# Problem description
As of Duniter Protocol v1.0, the blockchain can be written only by members following this rule: at any moment, any member can issue a new block with the contents of its will.
This implies 3 problems:
1. **Empty block easiness**: an empty block is faster to compute than a full one, because the proof-of-work can be started immediately without extra computing due to the inclusion of new data (trying to include transactions, identities, certifications and check all the rules). So if a malicious node wanted to slow down the inclusion of new data in the blockchain, it would just need to compute empty blocks. Not only is this behavior annoying, but it will also have some computing advantage because of the non-inclusion of new data.
2. **Empty blockchain**: if a group of malicious nodes was to adopt the behavior described in 1), and was also big and powerful enough compared to the rest of the computing nodes, this group could easily break the currency by making empty blocks.
3. **Deliberate forks**: if a group of malicious nodes similar to 2) was trying to make blockchain forks deliberately — thanks to its high computing power, he could compute 2 valid blocks and spread each of them to half of the network, creating a fork — this could slow down the blockchain seriously.
# Proposed enhancement
![image](https://cloud.githubusercontent.com/assets/969136/23123529/047045fc-f769-11e6-923e-f9363b6a67ba.png)
The proposition would be to have an additional global handicap, depending on current computing members. This additional handicap would be decreased for each **agreement** received by other nodes and included in the computed block.
The agreements are signed by their issuer, and are issued between each proof-of-work. **Only computing members** can issue them. Computing members are known to be the issuers of the last `IssuersCount` block in the blockchain.
In the above example, we see Node 1 (N1) has a difficulty of 60, like N2, N3, N4. This difficulty = N1's difficulty + global handicap. Let's say that here, N1's difficulty = 56 and global handicap = 4, because we have 4 computing nodes. So the basic difficulty for N1 = 60.
N1 receives 3 *agreements*:
* N2's agreement `6TX:B30A`: translation « *you can lower your difficulty by one if the block you compute contains at least 6 transactions, and is based on previous block #30, hash `A`* ».
* N3's agreement `4TX:B30A`: translation « *you can lower your difficulty by one if the block you compute contains at least 4 transactions, and is based on previous block #30, hash `A`* ».
* N4's agreement `4TX:B30F`: translation « *you can lower your difficulty by one if the block you compute contains at least 4 transactions, and is based on previous block #30, hash `F`* ».
If we consider N1, it's final difficulty varies depending on the block it computes:
* computing `B30A`, with 6 transactions: N1's `D = 60 - 1 - 1 = 58`, because he received 2 agreements from other nodes complying with this situation.
* computing `B30A`, with 4 transactions: N1's `D = 60 - 1 = 59`, because he received 1 agreement from other nodes complying with this situation.
* computing `B30A`, with 3 transactions: N1's `D = 60`, because he did not receive any agreements from other nodes complying with this situation.
* computing `B30F`, with 4 transactions: N1's `D = 60 - 1 = 59`
* computing `B30G`, with 10 transactions: N1's `D = 60`
* computing `B30G`, with 20 transactions: N1's `D = 60`
* computing `B30G`, with 1000 transactions: N1's `D = 60`
# Consequences
1. **Block easiness**: making empty block, whereas most of the network is expecting 4 transactions (because they see these transactions pending in their sandbox), would require the maximum difficulty, which is equal to "personal difficulty + global handicap". So the computing members will have a word on what can be and what cannot be the next block. Note how this does not prevent a malicious node to compute an empty block, but it will be harder to go against the global agreement. The more we have computing members, the harder is to go against the global will.
2. **Empty blockchain**: since it is harder to make empty blocks, it is even harder to make an empty blockchain.
3. **Deliberate forks**: even under the hypothesis of a special task force able to create blocks on their will before anyone, and make the network fork, at least this would be costly for them. It will be even more costly as they don't integrate expected data. So we have more chances that even if they create forks, at least some data is in each fork.
4. **Global difficulty decrease**: with such an algorithm, it becomes possible to *encourage low nodes to compute blocks*. Indeed, each node is free to share its agreement with the nodes it wants. If a node or a group of node decide to favor nodes with low computing power, they can do it. They can also not favor nodes they consider malicious.
# Precautions
Of course if some nodes stop sending agreements, this would globally increase the difficulty. This is very likely to happen, since all nodes are not permanent but daytime nodes.
Also, since an Agreement is issued at every block and to potentially all the computing nodes, this would make a lot of network data. We could consider a high limit for the global handicap equal to 80 (= 5*16 = 5 zeros ~= 1.048.576 times harder proof-of-work). So to have the lowest difficulty, a node would require 80 agreements: this value seems acceptable on long term run, even more as we expect thousands of transactions per block (5' block interval).
# Technical impacts
This would impact protocol's difficulty rule, block document structure, create a new « Agreement » document and handling Agreement's generation and interpretation.
### Difficulty rule
The rule would be changed to include a new `NB_AGREEMENTS` variable.
Formula would change from:
MAX [ HEAD.powMin ; HEAD.powMin * FLOOR (percentRot * nbPreviousIssuers / (1 + nbBlocksSince)) ] + PERSONAL_HANDICAP
to:
MAX [ HEAD.powMin ; HEAD.powMin * FLOOR (percentRot * nbPreviousIssuers / (1 + nbBlocksSince)) ] + PERSONAL_HANDICAP - NB_AGREEMENTS
### Agreement document
It should be defined an Agreement document, which could look like:
Version: VERSION
Type: NetworkAgreement
Currency: CURRENCY
NbJoiners: NB_JOINERS
NbActives: NB_ACTIVES
NbLeavers: NB_LEAVERS
NbRevocations: NB_REVOCATIONS
NbCertifications: NB_CERTS
NbTransactions: NB_TX
BOTTOM_SIGNATURE
It's inline format would look like:
NBJ:NBA:NBL:NBR::NBC:NBT:SIGNATURE
Where:
* `NBJ` is the number of expected records under `Joiners`
* `NBA` is the number of expected records under `Actives`
* `NBL` is the number of expected records under `Leavers`
* `NBR` is the number of expected records under `Revocations`
* `NBC` is the number of expected records under `Certifications`
* `NBT` is the number of expected records under `Transactions`
### Block's structure
It would be added an `NetworkAgreement` list before the `InnerHash`:
NetworkAgreement:
INLINE_NETWORK_AGREEMENT
...
### Document handling
* **On document's reception**: parse and verify the document signature and compliance with currently generated bloc.
* **On block generation**: generate a new block, count the number of each entity that is expected to be written, sign the document, pick a peer selection to which send the document.2.0