Define contract number generation for new contracts

[mguentner]

Currently,

ProcessingContracts are in the range of 60000-60076 with a fixed addition of 0. e.g. 60000/0

MeteringPointContracts are in the range of 90000-90129 without an addition.

LocalpoolPowerTakerContracts are fixed to their ProcessingContract and count upwards. e.g. 60000/1 60000/2 60000/3 and so on.

Release 1.0

@evaklopp @drthth @Justus3000,

we need a precise definition which contract should have which range and how contracts should reference themselves.

Should we open up a new range for new Powertakers? e.g. 40000-49999 or should they stay the addition of the processing contract number. Keep in mind that terminating a ProcessingContract is tricky here as the old contract number will be referenced by the PowerTakerContracts even though the current ProcessingContract number has changed.

Our data model allows basically everything. From looking at the code, it seems that this was envisioned, but I don't know the whole story.

[mguentner]

Update from a talk with pho:

For LocalPoolProcessing we keep 6xxxx range, addition is semi-fixed to 0 For LocalPoolPowerTaker we use the contract number of the group's LocalPoolProcessing contract and count upwards the addition. This behavior is the one beekeeper currently uses.

For now, I need no further investigation.

[drthth]

Yes! The logic/agreement is:

• 20000-39999: distributed Power Taker (some very old dPT had 1xxxx)
• 40000-49999: distributed Power Giver (some very old dPG had 1yyyy)
• 60000-69999: local Energy Groups, local Power Giver and local Power Taker
• 70000-89999: Account Numbers (Where 7xxxx are accounts who first had a powergiver contract and 8xxxx are accounts who first had a powertaker contract, this rule is on my opinion not a constraint)
• 90000-99999: Metering contracts

i.E. 50000-59999 is free

[mguentner]

I think this is done.