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 <[email protected]> on behalf of Jordi Paillissé
Vilanova <[email protected]>
*Date: *Wednesday 4 July 2018 at 13:28
*To: *David Mazieres expires 2018-09-30 PDT
<mazieres-pebagr7ysjghwpqkcqqnjjf...@temporary-address.scs.stanford.edu>,
"[email protected]" <[email protected]>, "[email protected]" <[email protected]>,
Stephane Bortzmeyer <[email protected]>, "[email protected]"
<[email protected]>, Greg Skinner <[email protected]>,
"[email protected]" <[email protected]>, "Alberto Rodriguez Natal (natal)"
<[email protected]>, "Vina Ermagan (vermagan)" <[email protected]>,
"Fabio Maino (fmaino)" <[email protected]>, Albert Cabellos
<[email protected]>, "[email protected]" <[email protected]>
*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<[email protected]> <mailto:[email protected]>
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
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
