Dear Wendy, thanks a lot for taking your time and providing us with the comments concerning our draft (draft-hommes-alto-blockchain-01). Here my comments in line:
---------- Section 4, second & third paragraphs: If I read these correctly, the 2nd paragraph says that an ALTO server can give a new blockchain client a set of existing peers, so the new client can bootstrap itself. Then the 3d paragraph says that is a bad idea, because it centralizes trust in the ALTO server, and hence "the use of ALTO should be reduced to a role of guidance on what peers to select". However, unless I missed it, an ALTO server simply cannot provide a new blockchain client with set of existing peers to use to bootstrap itself. A new peer must obtain that list from somewhere else. All an ALTO server can do is advise the client about the costs of communicating with that set. So it seem like the 2nd paragraph suggests doing something which ALTO cannot, and then the 3d paragraph goes on to say that's a bad idea. If that is the case, then what is the point of those two paragraphs? So I suggest deleting the 2nd paragraph and the first part of the third paragraph. [Stefan]: A good point, it is not clearly stated. If I understood correctly, there are basically two possible ways: 1) ALTO is calculating the cost to reach peers by providing ALTO a list of potential peers, and 2) ALTO has the knowledge about the peers since it is connected to a resource directory, which contains all list of available peers. In the second case, if I understood correctly, ALTO could be used to bootstrap a blockchain peer by providing the peer with the address of an ALTO server. The ALTO server could then afterwards propose the best peer(s) by requesting them from the resource directory. Correct? Section 5: "approximately every 10 seconds a new block is added" Not quite! It's really every 10 minutes. If you're lucky, that is. The distribution has a long tail. [Stefan]: Yes, it should be minutes instead of seconds. Section 5, 4th paragraph: That paragraph implies that an ALTO server tells a client about the relay network. I believe that is misleading. An ALTO server can certainly give the client the costs to/from the peers in the relay network, but the client must determine the peers in the relay network for itself. Perhaps you mean that a peer could look at the ALTO server's full cost map, including the costs between all the blockchain peers known to the client, and infer the "relay network" from that? E.g, if nodes 1-6 are known to be blockchain peers, and if the costs between nodes 1, 2 and 3 are much lower than the costs between the other peers, then the client could infer that 1,2,3 are better connected and it will get faster results if it connects to them rather than 4, 5 or 6. If so, then please say that instead. [Stefan]: I think this can be solved in a similar way as described in the previous section. Section 5, last paragraph: "ALTO could further be used to exchange information with the DNS seeds, or filtering their response of peers by adding other relevant information obtained by its global view on the network." Could you explain that in more detail, and/or give an example of how an ALTO server would do that? [Stefan]: I will better describe this part. But my idea was that ALTO could give a recommendation to a peer after it has received a potential list of peers from the DNS server. Section 6: "This requires that the ALTO server is aware of the different roles and which metrics need to be applied for each role." I disagree with that sentence as phrased: I believe an ALTO server does not, and should not, know the client's role. What I think you are getting at is that different clients need different cost metrics. For example, a miner is concerned with delay, and would want a cost metric that reflects delay. So I suggest rephrasing to say that a blockchain-friendly ALTO server should provide several different cost metrics, tuned to the different roles clients play, so that a client can select the appropriate metric for that client's role. As it stands now it, that section implies that an ALTO server knows the client's role and automatically selects the appropriate cost metric. I disagree with that. [Stefan]: In case that the ALTO server has no knowledge about the available peers, I agree that the peer should propose in the request which metric that needs to be applied, and ALTO requires no knowledge about the different roles. But when ALTO has a resource directory that contains all potential nodes, I believe it would make sense to give ALTO the information about what peer is belonging to each role in order to give a proper recommondation. ------------------------ Kind Regards, Stefan -----Original Message----- From: alto [mailto:[email protected]] On Behalf Of [email protected] Sent: 12 July 2016 11:25 To: [email protected] Subject: alto Digest, Vol 92, Issue 27 Send alto mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/alto or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of alto digest..." Today's Topics: 1. Draft: Alto for the blockchain (Wendy Roome) 2. my email address (Jan Seedorf) 3. Re: Draft: Alto for the blockchain (Stefan HOMMES) 4. Re: Draft: Alto for the blockchain (Stefan HOMMES) ---------------------------------------------------------------------- Message: 1 Date: Mon, 11 Jul 2016 15:55:52 -0400 From: Wendy Roome <[email protected]> To: IETF ALTO <[email protected]> Subject: [alto] Draft: Alto for the blockchain Message-ID: <d3a97208.7d4ecb%[email protected]> Content-Type: text/plain; charset="US-ASCII" Comments on ALTO for the blockchain, draft-hommes-alto-blockchain-01: Section 4, second & third paragraphs: If I read these correctly, the 2nd paragraph says that an ALTO server can give a new blockchain client a set of existing peers, so the new client can bootstrap itself. Then the 3d paragraph says that is a bad idea, because it centralizes trust in the ALTO server, and hence "the use of ALTO should be reduced to a role of guidance on what peers to select". However, unless I missed it, an ALTO server simply cannot provide a new blockchain client with set of existing peers to use to bootstrap itself. A new peer must obtain that list from somewhere else. All an ALTO server can do is advise the client about the costs of communicating with that set. So it seem like the 2nd paragraph suggests doing something which ALTO cannot, and then the 3d paragraph goes on to say that's a bad idea. If that is the case, then what is the point of those two paragraphs? So I suggest deleting the 2nd paragraph and the first part of the third paragraph. Section 5: "approximately every 10 seconds a new block is added" Not quite! It's really every 10 minutes. If you're lucky, that is. The distribution has a long tail. Section 5, 4th paragraph: That paragraph implies that an ALTO server tells a client about the relay network. I believe that is misleading. An ALTO server can certainly give the client the costs to/from the peers in the relay network, but the client must determine the peers in the relay network for itself. Perhaps you mean that a peer could look at the ALTO server's full cost map, including the costs between all the blockchain peers known to the client, and infer the "relay network" from that? E.g, if nodes 1-6 are known to be blockchain peers, and if the costs between nodes 1, 2 and 3 are much lower than the costs between the other peers, then the client could infer that 1,2,3 are better connected and it will get faster results if it connects to them rather than 4, 5 or 6. If so, then please say that instead. Section 5, last paragraph: "ALTO could further be used to exchange information with the DNS seeds, or filtering their response of peers by adding other relevant information obtained by its global view on the network." Could you explain that in more detail, and/or give an example of how an ALTO server would do that? Section 6: "This requires that the ALTO server is aware of the different roles and which metrics need to be applied for each role." I disagree with that sentence as phrased: I believe an ALTO server does not, and should not, know the client's role. What I think you are getting at is that different clients need different cost metrics. For example, a miner is concerned with delay, and would want a cost metric that reflects delay. So I suggest rephrasing to say that a blockchain-friendly ALTO server should provide several different cost metrics, tuned to the different roles clients play, so that a client can select the appropriate metric for that client's role. As it stands now it, that section implies that an ALTO server knows the client's role and automatically selects the appropriate cost metric. I disagree with that. - Wendy Roome ------------------------------ Message: 2 Date: Mon, 11 Jul 2016 21:59:12 +0200 From: Jan Seedorf <[email protected]> To: IETF ALTO <[email protected]> Subject: [alto] my email address Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8"; format=flowed Dear all, my new email address is "[email protected]". It has come to my attention that some of you are still using my NEC email address; that does not work anymore. So please use "[email protected]" in the future for individual mails to me. See you all in Berlin, - Jan -- **************************** Prof. Dr. Jan Seedorf [email protected] **************************** Hochschule f?r Technik Stuttgart Fakult?t Vermessung, Informatik und Mathematik Schellingstr. 24 D-70174 Stuttgart www.hft-stuttgart.de **************************** ------------------------------ Message: 3 Date: Tue, 12 Jul 2016 08:20:58 +0000 From: Stefan HOMMES <[email protected]> To: wang xin <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]>, Mathis STEICHEN <[email protected]> Subject: Re: [alto] Draft: Alto for the blockchain Message-ID: <[email protected]> Content-Type: text/plain; charset="us-ascii" Hello Xin, thanks a lot for providing us a feedback to our draft. In the bitcoin network, the broadcasting of the availability of new blocks and transactions to other peers (inv message) consumes a lot of traffic, since peers receive such messages from all neighbor peers that they are connected with. Our idea was to use ALTO in order to optimize the population of those messages. We are interested to use ALTO in a way that it is not centralising too much of the Bitcoin peer-to-peer protocol, which would be against the idea of having a decentralized architecture, but is nevertheless improving the current network protocol. Kind Regards, Stefan From: wang xin [mailto:[email protected]] Sent: 08 July 2016 14:25 To: Stefan HOMMES <[email protected]>; [email protected]; [email protected] Cc: [email protected]; Mathis STEICHEN <[email protected]> Subject: Re: Draft: Alto for the blockchain Dear Stefan and other authors, I am not an expert of Bitcoin or any virtual currency, but I do learn a lot from your draft. I realize that network communication also plays an important role in the blockchain architecture besides the computation of mining. It's great that ALTO has a potential to accelerate the development of that. I am also interested in how ALTO can be used for broadcasting mechanism in blockchain. I can imagine how ALTO works by selecting reply nodes, but I am not sure this is the only location for ALTO. I find that I am not familiar with blockchain networking architecture, and it should be the starting point for the whole integration. Finally I hope ALTO can contribute a lot for the development of blockchain. Thanks, Xin ________________________________ From: alto <[email protected]<mailto:[email protected]>> on behalf of Stefan HOMMES <[email protected]<mailto:[email protected]>> Sent: Thursday, July 7, 2016 11:36:57 PM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; Mathis STEICHEN Subject: [alto] Draft: Alto for the blockchain Dear ALTO group, I am a research associate from the University of Luxembourg, and we have submitted a draft that is using ALTO for the blockchain: https://datatracker.ietf.org/doc/draft-hommes-alto-blockchain/ We are very curious and interested to receive some feedback about this draft. Please feel free to send us your comments. We highly appreciate your opinion and looking forward to the IETF meeting in Berlin. Kind Regards, Stefan ------------------------------------------------------------------------- Dr. Stefan Hommes Research Associate, SEDAN team, Room C003 Mail: [email protected]<mailto:[email protected]> Phone: (+352) 46 66 44 5834 University of Luxembourg Interdisciplinary Centre on Security Reliability and Trust (SnT) 4, Rue Alphonse Weicker, L2721 Luxembourg ------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mailarchive.ietf.org/arch/browse/alto/attachments/20160712/b18ea7c5/attachment.html> ------------------------------ Message: 4 Date: Tue, 12 Jul 2016 09:24:50 +0000 From: Stefan HOMMES <[email protected]> To: Shenshen Chen <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [alto] Draft: Alto for the blockchain Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8" Hello Chen, thanks a lot for providing us a feedback to our draft. Here my comments to your mail: 1. ?Be more general-purpose for block chain?: That?s a good point. Indeed, the draft should not focus only on the Bitocin network but on blockchain in general, which was the reason why I have removed the Bitcoin part from the introduction and described it in a more general way. We will have a look on other chains as well. 2. ?Consider about security?: A good point as well. I am not sure how we should tackle this issue for the moment. 3. ?Let applications aware of the different roles?: In my opinion, there are two ways on how ALTO could answer to a request from a peer: (1) Either ALTO sends an information that is specific to the role of the peer that send the request, or (2) it proposes an answer that is independent of the role, meaning the answer can be used by all types of peers and the peer decides further based on his role. The second way reduces also the information that is provided to ALTO, which might be an advantage with regards to privacy. But I think that ALTO should have some information about the roles, in order to propose different routes by applying different kind of metrics. Of course the roles should be as general as possible, and not be linked to the Bitcoin networks since it is only one example of such a network. Is it foreseen to have such a functionality in ALTO? Kind Regards, Stefan From: Shenshen Chen [mailto:[email protected]] Sent: 11 July 2016 14:52 To: Stefan HOMMES <[email protected]> Cc: [email protected] Subject: Re: [alto] Draft: Alto for the blockchain Dear authors, I read your draft and get interested in utilizing ALTO for block chain. I have considered about it over the past few days. Here are some comments: 1. Be more general-purpose for block chain I noticed that there?re some parts of introduction about bitcoin have been removed from the first version and believed this draft is not specified for bitcoin. Also mentioned in title, this draft is about block chain. But it only mentioned bitcoin as use case of block chain. In bitcoin wiki, it said ?Block chains were invented specifically for the Bitcoin project but they can be applied anywhere a distributed consensus needs to be established in the presence of malicious or untrustworthy actors.? Despite it may cost too much to implement block chain for non-financial cases, mentioning some other use cases (e.g. alternative chain) could make the draft looks more general-purpose for block chain. 2. Consider about security Compare to traditional data base, I thought the block chain was invented to solve the security problem. So, it is necessary to consider about security which is much more important than efficiency. For example, ALTO server may accept some suboptimal results to improve the randomness and avoid the prediction mentioned in section 7. 3. Let applications aware of the different roles In section 6, it said ?This requires that the ALTO server is aware of the different roles?. But roles like wallet, miner and relay nodes are specified for bitcoin, it may have different roles in other use cases of block chain. Including such information in ALTO protocol is not general-purpose for block chain. By the other hand, ALTO is invented to provide low-level network information which application can?t get before. Since the information about different roles is not low-level, it could be more appropriate for ALTO to let applications maintain the map relationship between each node and its role. Hope these helps. :) Best Regards, Shenshen Chen 2016-07-07 23:36 GMT+08:00 Stefan HOMMES <[email protected]<mailto:[email protected]>>: Dear ALTO group, I am a research associate from the University of Luxembourg, and we have submitted a draft that is using ALTO for the blockchain: https://datatracker.ietf.org/doc/draft-hommes-alto-blockchain/ We are very curious and interested to receive some feedback about this draft. Please feel free to send us your comments. We highly appreciate your opinion and looking forward to the IETF meeting in Berlin. Kind Regards, Stefan ------------------------------------------------------------------------- Dr. Stefan Hommes Research Associate, SEDAN team, Room C003 Mail: [email protected]<mailto:[email protected]> Phone: (+352) 46 66 44 5834<tel:%28%2B352%29%2046%2066%2044%205834> University of Luxembourg Interdisciplinary Centre on Security Reliability and Trust (SnT) 4, Rue Alphonse Weicker, L2721 Luxembourg ------------------------------------------------------------------------- _______________________________________________ alto mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/alto -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mailarchive.ietf.org/arch/browse/alto/attachments/20160712/79d1dfea/attachment.html> ------------------------------ Subject: Digest Footer _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto ------------------------------ End of alto Digest, Vol 92, Issue 27 ************************************ _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
