WIP: RFC 1 : Abstract Syntax Tree-based output script locks
Update 2 : Rewriting with way better format to fix flaws of the first draft.
In the current Duniter protocol input and output conditions are stored in machine-readable BNF text format. This is good for human readability, but it requires parsing and takes place due to its textual format.
To lower blocksize and transactions weights; or to allow more complex conditions, it could be preferable to use a more simple binary format which need little or no parsing, close to memory and that can be converted back to text format. It can also allow to add new features without hard-forking the protocol.
Merge request reports
Activity
assigned to @Insoleet
assigned to @c-geek
assigned to @nanocryk
added 1 commit
- 0d71c303 - OR and AND operator can accept any number of arguments
assigned to @librelois
assigned to @nanocryk
added 1 commit
- f1d6bed8 - Children count size; More precise HASH specification
I finally found time to read his specs ! All this seems to me very good, I think that what will help us to understand is a few examples of complete transaction document that use this DIP can you write it for us @nanocryk ?
@librelois Why not, but it will be very incomplete since the complete transaction document format is being worked in DIP0002. I'll add more exemples (in code, not visualisations) of more complex scripts.
added 1 commit
- b38657fd - Sizes precisions; Changed input parameters format
added 1 commit
- 462b775e - New operator to fetch document signatures + usage; Corrected not updated input format
added 1 commit
- df010fa3 - Forbidden embeded signatures; Removed redudancy
- DIP0001.md 0 → 100644
275 2 : DOCSIG 1 # signature c 276 3 : GE 2 277 SUM 3 278 ED 2 279 U32 <public_key_a> 280 EXT 0 # Signature in parameter 0 281 MASTH <hash of this unused branch> 282 ED 2 283 U32 <public_key_c> 284 EXT 2 # Signature in parameter 2 285 U8 2 286 ``` 287 288 # Size limit 289 290 To prevent spam and abuses, script and inputs should have a maximum size. It's not defined yet but could follow the usage, like more transactions are accepted in blocks if the previous block have some. Well, hmm... yes that's a difficult problem. However I would not be shocked by a fixed size but large enough to fit most of the potential cases you imagine.
I remember that in Bitcoin, an overwhelming majority of transactions are just key2key scripts.
So if advanced scripts are a very little portion of transactions, let's limit their potential dangerosity in terms of block size consumption. If it was really required to increase the size, let's do this in another version of the protocol.
We need to remember that the priority of Duniter is libre money, not complex money spending which is cool and will probably boost its usage, but is not necessary.
Edited by Cédric MoreauFor block size I have a combination of the two worlds:
- a default maximum size (500 lines)
- a dynamic maximum size: this limit of 500 lines can be overtaken depending on the preceding blocks content in the current window
But the problem is that attackers would precisely put their effort to make the average size grow, so they can influence this size limit. That's the real problem: we should not set a limit for a set of people A and simultaneously give the tool to A to push back this limit.
-
Since we're in a binary format, there are no lines and we must think in bytes. We can compare we the actual format and compute the size in bytes.
In other cryptocurrencies it's possible to limit spams with fees, since bigger transactions cost more. But since we have no fees, it seems difficult to block spams while allowing users to create their legit transactions. A dynamic size seems difficult to use : if most users use only "key to key" transactions, there will be no room for new usages of more complex scripts. I think a fixed max size and the usage of merkelized script should be suffisent.
In this case we should have a blocksize limit and not a transaction count limit, since transactions can have largely different sizes.
We could classify each transaction based on it's weight in categories. Let's say we want in a block
60% light / 30 % medium / 10 % heavyfor transactions (in used bytes). We fill these categories with pooled transactions, and stop when they are full.If one of the category is not full, we can then add more transaction of the other categories if needed. For exemple if we have
40% light / 30 % medium / 10 % heavy, there is room for 20% of the space. We can split this space in 30/40% for additional medium transactions, and 10/40% for more heavy transactions. Again if we run out of transaction in a category, we allow other to use this spare space.We just need to define the number of categories (and their intervals) and there proportion of the blocksize they're allowed to use. Each proportion and the total blocksize could be adjusted with an average (+room for small increase) of uses from a past window of blocks, with a minimum so a now unused category can't just disappear in the limbo. With this we can't block legit user small transactions with spammed heavy ones, while allowing heavy transactions to be used.
It seems a bit complicated, but i'll try to define it correctly if you found the basic idea interesting.
Edited by nanocryk -
Indeed. So we can remove the overflow system. The adaptive system by block average however cannot be attacked since an attacker cannot calculate consecutive blocks.
Edited by nanocryk changed this line in version 23 of the diff
-
@c-geek What do you think about it ? Can I add it in DUIP-2 ?
added 1 commit
- 13137ebc - Multiple scripts as functions and constraints
added 12 commits
-
dd6d541f...103cfa20 - 11 commits from branch
master - 12679dd7 - Merge branch 'master' into dip/0001
-
dd6d541f...103cfa20 - 11 commits from branch
added 1 commit
- 506982f1 - (feature) all current operators + corrections
added 1 commit
- bf782cf5 - (refractor) added "update note" + removed old document
added enhancement help wanted ~178 labels
added 2 commits
