Re: [Din] [OPSEC] blockchain for IP addresses draft update

[Jordi Paillissé Vilanova <[e-mail]>]

Hi Roque,

We have built an open-source prototype [1], and it works like you 
mentioned: the genesis block includes the public keys that the RP has to 
trust. It is a one-time action in which you trust the source code and 
the keys contained in it.

Thanks for your comments, we'll include them in the next version.

Regards,

Jordi

[1] https://github.com/OpenOverlayRouter/blockchain-mapping-system


El 04/07/18 a les 14:09, Roque Gagliano (rogaglia) ha escrit:
>
> Hi Jordi,
>
> Very good document.
>
> I hate to ask things without providing code but I believe it would be 
> great if you add a section regarding the “relying party”, how would 
> the validation algorithm would look like and what is the bootstrap 
> process. I can see that some public key info would need to be known by 
> the RP.
>
> Regards,
>
> Roque
>
> *From: *OPSEC <[e-mail]> on behalf of Jordi Paillissé 
> Vilanova <[e-mail]>
> *Date: *Wednesday 4 July 2018 at 13:28
> *To: *David Mazieres expires 2018-09-30 PDT 
> <[e-mail]>, 
> "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, 
> Stephane Bortzmeyer <[e-mail]>, "[e-mail]" 
> <[e-mail]>, Greg Skinner <[e-mail]>, 
> "[e-mail]" <[e-mail]>, "Alberto Rodriguez Natal (natal)" 
> <[e-mail]>, "Vina Ermagan (vermagan)" <[e-mail]>, 
> "Fabio Maino (fmaino)" <[e-mail]>, Albert Cabellos 
> <[e-mail]>, "[e-mail]" <[e-mail]>
> *Subject: *Re: [OPSEC] [Din] blockchain for IP addresses draft update
>
> Hi David,
>
> Indeed, we did not delve deeper into the PoS algorithm. This depends 
> on the specific implementation, our opinion is that an Algroand-like 
> would be a good option, and if it can tolerate a large portion of 
> offline participants even better. In addition, we think that punishing 
> or deposit mechanisms are not desirable because they don't fit the 
> characteristics of the scenario. Overall the incentive is "a more 
> secure Internet", we believe that this is well-aligned with the 
> economical interests of the participants.
>
> Regarding SCP, the fact that you only need to trust your neighbours 
> may prove very convenient in this scenario. As you said, it reflects 
> current Internet trust schemes, this basically means that BGP Peering 
> = Trust = Stellar quorum slices. We'll look into this for the next 
> iteration of the draft.
>
> Thanks
>
> Jordi
>
> El 02/07/18 a les 17:59, David Mazieres ha escrit:
>
>     Jordi Paillissé Vilanova<[e-mail]> <mailto:[e-mail]>  writes:
>
>         (apologies for cross-posting)
>
>         Dear all,
>
>         We have submitted a new version of the draft addressing comments
>
>         received both on the mailing list and IETF meetings.
>
>         Thanks to all of you for taking the time to read the draft :)
>
>         Regards,
>
>         Jordi
>
>     Very interesting draft.  One high-level comment, I would avoid terms
>
>     like "tamper-proof" or really anything-"proof" except possibly in the
>
>     context of information-theoretic security, in favor of tamper-resistant.
>
>     This is particularly important in the context of blockchains that have
>
>     experienced a number of forks in practice and where it would likely take
>
>     only a few tens of millions of dollars a day to tamper with history.
>
>     I think the draft would benefit from a much finer-grained consideration
>
>     of several different forms of proof-of-stake, because there are a number
>
>     of assertions that do not hold for all forms of proof of stake.  E.g.,
>
>     will there be delegation like peercoin, randomization like algorand,
>
>     penalties like Casper, sleepy nodes like snowwhite?
>
>     And while of course I'm biased on this issue, I think that a
>
>     Byzantine-agreement-based approach like SCP
>
>     (https://datatracker.ietf.org/doc/draft-mazieres-dinrg-scp/) would work
>
>     better than PoS.  SCP is well matched to the Internet peering model,
>
>     which we already know is a workable decentralized governance model.  You
>
>     may not agree, but it would at least be nice for the document to explain
>
>     why you reject this approach.
>
>     David
>
>
>