duniter issueshttps://git.duniter.org/nodes/typescript/duniter/-/issues2020-10-04T18:43:43+02:00https://git.duniter.org/nodes/typescript/duniter/-/issues/1244Change BR_G50 "Block size"2020-10-04T18:43:43+02:00Cédric MoreauChange BR_G50 "Block size"Currently the block size is dynamic, i.e. it can grow if the last blocks are full. But this rule is dangereous right now, because the size limit growth is exponential: https://git.duniter.org/nodes/typescript/duniter/blob/master/doc/Prot...Currently the block size is dynamic, i.e. it can grow if the last blocks are full. But this rule is dangereous right now, because the size limit growth is exponential: https://git.duniter.org/nodes/typescript/duniter/blob/master/doc/Protocol.md#br_g50-block-size
Let's make it logarithmic instead.2.0https://git.duniter.org/nodes/typescript/duniter/-/issues/1208Key delegated to block computing2017-12-15T04:20:38+01:00ÉloïsKey delegated to block computinghttps://forum.duniter.org/t/idee-cle-deleguee-au-calcul-de-blocs/2698/1
The idea of the delegated key is to be able to delegate the computation of blocks to a subkey, in order to put the main keychain in safety.
This subkey has the...https://forum.duniter.org/t/idee-cle-deleguee-au-calcul-de-blocs/2698/1
The idea of the delegated key is to be able to delegate the computation of blocks to a subkey, in order to put the main keychain in safety.
This subkey has the ability to revoke the associated member account.
The member may at any time declare a new delegated Key that cancels and replaces the previous delegated Key.
To avoid spam it will be necessary to add a parameter preventing to declare a new delegated key before `x` seconds.2.0https://git.duniter.org/nodes/typescript/duniter/-/issues/1207Planning the improvement of DUP protocol for duniter 2.02017-12-05T14:28:51+01:00ÉloïsPlanning the improvement of DUP protocol for duniter 2.0## Approved developments
- [ ] Pay to pubkey hash #1002
- [ ] Add function P2SH : Pay to script hash #1165
- [ ] Change handicap formula : replace the median by second tiercile #1169
## Developments under discussion
- [ ] Key ...## Approved developments
- [ ] Pay to pubkey hash #1002
- [ ] Add function P2SH : Pay to script hash #1165
- [ ] Change handicap formula : replace the median by second tiercile #1169
## Developments under discussion
- [ ] Key delegated to block computing #1208
2.0https://git.duniter.org/nodes/typescript/duniter/-/issues/1169Change handicap formula : replace the median by second tiercile2017-12-11T21:03:02+01:00ÉloïsChange handicap formula : replace the median by second tiercilehttps://forum.duniter.org/t/noeud-raspberry-pi-toujours-suffisant-pour-calculer/3514/6?u=eloishttps://forum.duniter.org/t/noeud-raspberry-pi-toujours-suffisant-pour-calculer/3514/6?u=elois2.0https://git.duniter.org/nodes/typescript/duniter/-/issues/1165Add function P2SH : Pay to script hash2019-09-25T00:07:28+02:00ÉloïsAdd function P2SH : Pay to script hashThey allow transactions to be sent to a script hash instead of a public key hash (addresses starting with 1. To spend coins sent via P2SH, the recipient must provide a script matching the script hash and data which makes the script evalu...They allow transactions to be sent to a script hash instead of a public key hash (addresses starting with 1. To spend coins sent via P2SH, the recipient must provide a script matching the script hash and data which makes the script evaluate to true.
Pour qu'il soit possible de verser de la monnaie a un compte défini par un ensemble complexe de règles de déblocage sans connaitre cet ensemble de règles, il suffit d'en connaitre une adresse virtuelle qui serait publiée quelque part et qui contient le hash de l'ensemble des conditions de déblocage.
le compte `P2SH(A)` ne pourra consommer ses sources que s'il fourni un ensemble de conditions de déblocage qui à pour hash `A`.
La fonction `XHX()` ne peut pas assurée ce rôle car le script des conditions de déblocage peut contenir la fonction`XHX()`. Il faut donc une fonction a part dont l'usage récursif sera interdit : PS2H
Cf. comment le bitcoin gère cela : https://en.bitcoin.it/wiki/Pay_to_script_hash2.0https://git.duniter.org/nodes/typescript/duniter/-/issues/1100Allow certification cancelling2017-11-28T16:49:16+01:00Cédric MoreauAllow certification cancellingThe discussion is here: https://forum.duniter.org/t/annulation-de-certification/3233
It is still being discussed.The discussion is here: https://forum.duniter.org/t/annulation-de-certification/3233
It is still being discussed.Horizonhttps://git.duniter.org/nodes/typescript/duniter/-/issues/1099Have a dynamic stock of certifications2017-11-28T16:49:16+01:00Cédric MoreauHave a dynamic stock of certificationsThe discussion is here: https://forum.duniter.org/t/stock-de-certifications-dynamique/3232
For now this is still an under discussion feature.The discussion is here: https://forum.duniter.org/t/stock-de-certifications-dynamique/3232
For now this is still an under discussion feature.Horizonhttps://git.duniter.org/nodes/typescript/duniter/-/issues/1002Pay to pubkey hash2019-09-25T00:10:10+02:00insoPay to pubkey hashI think it could be interesting to send money to pubkey hash instead of directly the pubkey. This is what bitcoin calls "addresses".
This would be a first step in anonymization : we could send money to a second wallet, but this second...I think it could be interesting to send money to pubkey hash instead of directly the pubkey. This is what bitcoin calls "addresses".
This would be a first step in anonymization : we could send money to a second wallet, but this second wallet would be hidden from the public until some money is spent from it.2.0https://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/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.0https://git.duniter.org/nodes/typescript/duniter/-/issues/462XDP: eXtensible Duniter Protocol?2017-11-28T16:49:19+01:00Cédric MoreauXDP: eXtensible Duniter Protocol?*Created by: M5oul*
#### XMPP
You may know that XMPP stand for eXtensible Messaging and Presence Protocol.
XMPP could be extended with XEP, XMPP Extension Protocol.
For instance, there is XEP for file transfert, [VoIP, visioconference...*Created by: M5oul*
#### XMPP
You may know that XMPP stand for eXtensible Messaging and Presence Protocol.
XMPP could be extended with XEP, XMPP Extension Protocol.
For instance, there is XEP for file transfert, [VoIP, visioconference](https://en.wikipedia.org/wiki/Jingle_%28protocol%29), [MAM](https://xmpp.org/extensions/xep-0313.html)…etc
There is also [Extensible Authentication Protocol](https://en.wikipedia.org/wiki/Extensible_Authentication_Protocol).
#### XDP
What could be the advantage for Duniter protocol to be extensible?
This could strengthen Duniter protocol be give the possibility to make evolve the protocol by changing of extension.
I don't know if it could be a great to have this feature.
We could have a base protocol.
Then, have extensions for WoT, transactions or whatever, I am giving ideas.
##### Extensible blockchain protocol
Just an idea, which is bigger than Duniter project would be to have an extensible blockchain protocol to allow extensions to store transactions, membership, properties, DNS records, any kind of documents…
Horizonhttps://git.duniter.org/nodes/typescript/duniter/-/issues/440Change account password2018-03-09T10:02:49+01:00Cédric MoreauChange account password*Created by: M5oul*
Could it be possible to change the account password?
Or, it is hard coded in the public key?
*Created by: M5oul*
Could it be possible to change the account password?
Or, it is hard coded in the public key?
Horizon