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/1239Change the proof of work algorithm2018-12-07T14:22:42+01:00Cédric MoreauChange the proof of work algorithmAs discussed here: https://mastodon.xyz/web/statuses/99174770035035196
It seems that the current PoW chain (`SHA256(Ed25519_sign(SHA256("InnerHash:...Nonce: <nonce>")))`) is still ASIC compliant, in that an ASIC could still handle this ...As discussed here: https://mastodon.xyz/web/statuses/99174770035035196
It seems that the current PoW chain (`SHA256(Ed25519_sign(SHA256("InnerHash:...Nonce: <nonce>")))`) is still ASIC compliant, in that an ASIC could still handle this computation.
@aeris suggests to either use ARGON2 or scrypt currently, because these functions introduce a tradeoff between CPU and memory.
I'm not an expert, so I can just believe this assertion right now.
Anyway, as long as the number of ASIC powered member nodes is low compared to the number of non-ASIC powered member nodes, it won't be a big problem. But it would still be annoying, even more later if Ğ1 growth.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/1182Separate network key and block computing key2020-10-04T18:45:31+02:00ÉloïsSeparate network key and block computing keyTo allow anonymization of nodes on the network, a member should be able to use a non-member anonymous network key.
The key dedicated to signing the calculated blocks would never be shared on the network.
The blocks that the node will c...To allow anonymization of nodes on the network, a member should be able to use a non-member anonymous network key.
The key dedicated to signing the calculated blocks would never be shared on the network.
The blocks that the node will compute. It would submit them to the network via ws2p in the same way as it relays any other block received. For the nodes that receive its blocks, it would be impossible to know if they are blocks that he has calculated himself or that he simply relays.2.0https://git.duniter.org/nodes/typescript/duniter/-/issues/1102WS2P: prevent JSON injection2017-11-28T16:49:16+01:00Cédric MoreauWS2P: prevent JSON injectionWS2P parses received JSON. We need to take a big care on the received JSON because it could carry invalid content.WS2P parses received JSON. We need to take a big care on the received JSON because it could carry invalid content.Horizonhttps://git.duniter.org/nodes/typescript/duniter/-/issues/764Create issues for covering the protocol global rules2018-03-07T22:18:30+01:00Cédric MoreauCreate issues for covering the protocol global rulesWe should aim at covering every single rule of the protocol, at least for the global scope rules.
The idea is to reproduce what has been done in 50886de5c5577f1470fd4e6d8a2931eeabe27ce6.
We should create an issue per rule, so anyon...We should aim at covering every single rule of the protocol, at least for the global scope rules.
The idea is to reproduce what has been done in 50886de5c5577f1470fd4e6d8a2931eeabe27ce6.
We should create an issue per rule, so anyone could take the issue and focus on it.
Eventually, we could go further and do the same (create an issue) for the computation rules (BR_G01 to BR_G48).Horizon