Distrib March 2019

distrib@lists.cslab.ece.ntua.gr

13 participants
26 discussions

τελευταία παράταση για την εργασία των Κατανεμημένων
by Katerina Doka 10 Mar '19

10 Mar '19

Καλημέρα, μετά από πολλά αιτήματα συναδέλφων σας, η προθεσμία παράδοσης της εργασίας παρατείνεται μέχρι τις 22/3. 21 και 22/3 θα γίνει η επίδειξη της άσκησης σύμφωνα με πρόγραμμα που θα ανακοινωθεί την Τετάρτη. Όσοι δεν έχετε γραφτεί, παρακαλώ να το κάνετε μέχρι Τρίτη βράδυ. Όσοι επιθυμούν να εξεταστούν στις 15/3, μπορούν κατόπιν συνεννόησης. Καλό τριήμερο, Κατερίνα

1 0

Απορίες για python
by kbitsak＠cslab.ece.ntua.gr 07 Mar '19

07 Mar '19

Καλησπέρα, ένα παιδί είχε τις εξής απορίες, οπότε απαντάω εδώ για να δείτε όλοι. "Αναρωτιόμαστε πώς θα υλοποιήσουμε το api και το rest εφ'όσον θα συνδεόμαστε με ssh το vm του ωκεανού.Γενικά καθώς δεν διευκρίνεζεται στην εκφώνηση τι είδους interface θα θέλατε; Και πώς θα γίνει ο τρόπος επικοινωνίας (get κλπ). " Αν συνδεθεις σε ένα vm και σηκώσεις έναν server τότε μπορείς να κάνεις browdcast σε ένα port ένα frontend. Πχ, έχεις το vm 147.10.2.3 λ.χ. Τότε αν σηκώσεις ένα flask application στο 147.10.2.3:5000 θα δεις το frontend. Το frontend ειναι προαιρετικό στην εργασία, όχι απαραίτητο. Την επικοινωνία μεταξύ των backend μπορείτε να την κάνετε μέσω του module requests της Python. Κωνσταντίνος

1 0

Re: [Distrib] Κατανεμημένα Εργασία
by Konstandinos Bitsakos 07 Mar '19

07 Mar '19

Καλησπέρα, απαντάω στη λίστα για να το δούνε όλοι. Αν συνδεθεις σε ένα vm και σηκώσεις έναν server τότε μπορείς να κάνεις browdcast σε ένα port ένα frontend. Πχ, έχεις το vm 147.10.2.3 λ.χ. Τότε αν σηκώσεις ένα flask application στο 147.10.2.3:5000 θα δεις το frontend. Το frontend ειναι προεραιτικό στην εργασία, όχι απαραίτητο. Την επικοινωνία μεταξύ των backend μπορείτε να την κάνετε μέσω του module requests της Python. K. Στις Πέμ, 7 Μαρ 2019 στις 1:03 μ.μ., ο/η george <gchatzitso(a)gmail.com> έγραψε: > Καλησπέρα, > > Αρκετές από τις απορίες μας λυθήκαν. Αναρωτιόμαστε πώς θα υλοποιήσουμε το > api και το rest εφ'όσον θα συνδεόμαστε με ssh το vm του ωκεανού.Γενικά > καθώς δεν διευκρίνεζεται στην εκφώνηση τι είδους interface θα θέλατε; Και > πώς θα γίνει ο τρόπος επικοινωνίας (get κλπ). Επίσης η συνάρτηση στην > εκφώνηση (validate chain) όπως μας λέει καλείται από τους νεοεισερχόμενους > κόμβους. Στο πρόβλημα μας όλοι οι κόμβοι προστίθονται στην αρχή και μετά > αρχίζουν να γίνονται συναλλαγές άρα τι νόημα έχει να καλείται αυτή η > συνάρτηση; Επίσης ή δημιουργία ενός wallet θα γίνεται αμέσως μετά την > προσθήκη του αντίστοιχου κόμβου; > > Ευχαριστούμε πολύ > On 6/3/19 3:04 μ.μ., Konstandinos Bitsakos wrote: > > Γράψε μου και τις θες να ρωτήσεις μήπως χρειαστεί να προετοιμάσω κάτι. > > Στις Τετ, 6 Μαρ 2019 στις 2:14 μ.μ., ο/η moaker 237 <gchatzitso(a)gmail.com> > έγραψε: > >> Ναι μια χαρά ευχαριστώ >> >> Στις Τετ, 6 Μαρ 2019, 2:08 μ.μ. ο χρήστης Konstandinos Bitsakos < >> kbitsakos14(a)gmail.com> έγραψε: >> >>> Οοκ. Απόγευμα κατά τις 5 είναι καλά; >>> >>> Κ. >>> >>> Στις Τετ, 6 Μαρ 2019 στις 1:58 μ.μ., ο/η george <gchatzitso(a)gmail.com> >>> έγραψε: >>> >>>> Καλησπέρα, >>>> >>>> Θα θέλαμε να ρωτήσουμε κάποια πράγματα για την εξαμηνιαία >>>> εργασία.Μπορούμε να περάσουμε αύριο από εκεί ; >>>> >>>> Ευχαριστούμε πολύ >>>> >>>>

1 0

Fwd: [ece-dep] Lecture by Prof. Vassilis Zikas on Security of Blockchains, Friday 8/3, 17:00, Multimedia Amphitheater
by kbitsak＠cslab.ece.ntua.gr 06 Mar '19

06 Mar '19

---------------------------- Original Message ---------------------------- Subject: Fwd: [ece-dep] Lecture by Prof. Vassilis Zikas on Security of Blockchains, Friday 8/3, 17:00, Multimedia Amphitheater From: "Georgios Goumas" <goumas(a)cslab.ece.ntua.gr> Date: Wed, March 6, 2019 9:52 am To: "Parallel and Distributed Systems Group" <pdsg(a)cslab.ece.ntua.gr> -------------------------------------------------------------------------- -------- Forwarded Message -------- Subject: [ece-dep] Lecture by Prof. Vassilis Zikas on Security of Blockchains, Friday 8/3, 17:00, Multimedia Amphitheater Date: Wed, 06 Mar 2019 08:59:15 +0200 From: Aris Pagourtzis <pagour(a)cs.ntua.gr> Reply-To: pagour(a)cs.ntua.gr Organisation: National Technical University of Athens To: Dep <dep(a)ece.ntua.gr> Αγαπητοί συνάδελφοι, Με χαρά σας προσκαλούμε σε ομιλία εξαιρετικού συναδέλφου, αποφοίτου του ΕΜΠ, που θα γίνει την Παρασκευή 8/3 στο Αμφ. Πολυμέσων, ώρα 17:00. Παρακαλώ προωθήστε σε φοιτητές και συνεργάτες σας. Με εκτίμηση, Άρης Παγουρτζής *Title:* Security of Blockchains against Incentive-Driven Attacks *Abstract: *In traditional cryptographic analysis, an application or protocol is deemed "secure" if it realizes its task against /*any */adversarial strategy, however mischievous. While this approach yields strong security guarantees, in many cases it's overpessimistic since it neglects the incentives that lead participants to deviate from their prescribed behavior, resulting in solutions that defend against unlikely attacks. In this talk we present the "Rational Protocol Design" (RPD) framework, which formally incorporates adversarial incentives into a composable cryptographic protocol design. We showcase the benefits of the framework by applying it?in combination with recent developments on the composable analysis of blockchains?to analyze blockchain protocols like Bitcoin. Our treatment captures, in a cryptographic framework, how knowledge of the attacker's incentives can be used to circumvent known impossibility results and/or derive a fallback rational-security notion. *?? * ** *Bio: Vassilis Zikas is an Associate Professor and Vice-Director of the Blockchain Technology Laboratory at the University of Edinburgh. He is also a Research Fellow (Area Leader: Secure Multiparty Computation) of the blockchain company IOHK. He was previously Assistant Professor at the Computer Science department at Rensselaer Polytechnic Institute (RPI), Senior Research Associate in Cryptography and Information Security at ETH Zurich, Research Fellow of the Simons Institute for the Theory of Computing, UC Berkeley, and postdoctoral researcher at UCLA and at the University of Maryland. His research has been supported by a career development (Ambizione) grant and a postdoctoral fellowship from the Swiss National Science Foundation. *Vassilis received his PhD from the Computer Science Department of ETH Zurich and his diploma from the School of Applied Mathematical and Physical Sciences at NTUA, and has been a long-term affiliate of the Computation and Reasoning Lab (CoReLab) of NTUA.

1 0

(Πολλές) απορίες για την εργασία
by Σωτήρης Νιάρχος 05 Mar '19

05 Mar '19

Καλησπέρα! Έχουμε πολλές απορίες που μας εμποδίζουν να προχωρήσουμε την εργασία, κυρίως σχετικά με το κομμάτι του consensus και τον χειρισμό των UTXO: 1) Δεδομένου του ότι όλοι οι nodes είναι και miners και πως όλοι ακούν όλα τα transactions (και κάθε κόμβος/miner βάζει όλα τα transactions στο μπλοκ που, όταν ολοκληρωθεί, θα το κάνει mine), όλοι καταλήγουν να κάνουν mine ακριβώς τα ίδια blocks, με τα ίδια transactions (θεωρούμε δεδομένο ότι δεν χάνονται transactions στο δίκτυο). Αυτό σημαίνει ότι υπάρχει η περίπτωση, για παράδειγμα, να συμπληρωθούν "ταυτόχρονα" από όλους τα transactions που απαιτούνται για να γίνει mine το πρώτο block. Συνεπώς, αρχίζουν όλοι "ταυτόχρονα" να κάνουν mine τα block τους. Τέλος, "ταυτόχρονα" προσθέτουν το block που έκαναν mine στο τοπικό τους blockchain και έπειτα το κάνουν "ταυτόχρονα" broadcast. Σε αυτήν την περίπτωση, θα βρεθούμε να έχουμε στο δίκτυο n διαφορετικές αλυσίδες μήκους 2, με n διαφορετικά δεύτερα blocks (το πρώτο είναι το genesis που είναι κοινό). Πώς μπορεί να δουλέψει σε αυτήν την περίπτωση το consensus όπως το περιγράφετε στην εκφώνηση, από τη στιγμή που δεν υπάρχει αλυσίδα μεγαλύτερου μήκους; Μπορεί να χρειαστεί να ασχοληθούμε με threads (ένα thread να ακούει για εισερχόμενα blocks, ένα για να κάνει mine); 2) Πώς πρέπει να διαχειριστούμε το γεγονός ότι κάποιο block μας μπορεί να καταλήξει να γίνει orphaned; Έχει νόημα να διατηρούμε κάποιο transaction pool, από τη στιγμή που όλα τα transactions είναι ίδια για όλους (όλοι τα ακούνε, όλοι τα κάνουν mine και μάλιστα στα ίδια ακριβώς blocks); 3) Εν τέλει, ποιο είναι το νόημα του consensus στο noobcoin από τη στιγμή που (α) όλοι δημιουργούν ΑΚΡΙΒΩΣ τα ίδια blocks με ΑΚΡΙΒΩΣ τις ίδιες συναλλαγές και (β) εάν μιλάμε για αλυσίδα μεγαλύτερου μήκους, εκ των πραγμάτων δεν μιλάμε για 51% consensus, αφού αρκεί ένας από τους κόμβους να μας δώσει τη μεγαλύτερη αλυσίδα; 4) Κατά την εκτέλεση της resolve_conflict() δεν θα πρέπει να παίρνουμε και blockchains από τους άλλους, εκτός από το μήκος τους; Εάν ναι, τότε δεν θα πρέπει και εδώ να καλείται η validate_chain() κάθε φορά (στην εκφώνηση αναφέρετε ότι καλείται μόνο κατά την είσοδο ενός κόμβου στο δίκτυο); 5) Δεδομένου του ότι τα transaction μας δεν έχουν fees, φαίνεται redundant να δημιουργούνται τα transaction outputs κατά τη δημιουργία του (πριν γίνει broadcasted), αφού όλοι μπορούν να τα υπολογίσουν όταν το λάβουν και το κάνουν validate, όπως περιγράφετε και στην εκφώνηση. Συνεπώς, τα outputs φτιάχνονται κατά την validate και το transaction γίνεται broadcasted χωρίς αυτά ή φτιάχνονται πριν και περιέχονται στο broadcast; Εάν πούμε ότι φτιάχνονται κατά την validate (όπως λέτε ρητά στην εκφώνηση), πότε θα τα φτιάξει ο ίδιος ο κόμβος που έφτιαξε το transaction; Πριν κάνει broadcast το transaction (που φαίνεται πιο λογικό αλλά πηγαίνει ενάντια στην εκφώνηση) ή μετά (το οποιο υποννοεί ότι θα το κάνει broadcast και στον εαυτό του για να μπει στη διαδικασία του validation, το οποίο ακούγεται χαζό); 6) Το timestamp των blocks πρέπει να αντιπροσωπεύει την στιγμή (α) που το block αρχίζει να γίνεται mine (οπότε και θα περιέχεται στο hash) ή (β) όταν θα μπει στο blockchain, οπότε εκ των πραγμάτων δεν θα μπορεί να περιέχεται στο hash (αλλά θα φέρει πιο ακριβή πληροφορία ως προς το πότε ένα σύνολο συναλλαγών θεωρήθηκε έγκυρο και μέρος του blockchain);

2 1

transaction_input, transaction_output, σκελετός Python
by Vakalopoulou Myrsini 01 Mar '19

01 Mar '19

Καλησπέρα, Προσπαθούμε να καταλάβουμε πώς θα δουλεύει η διαδικασία με τα transaction_input, transaction_output, UTXO. Κάθε φορά που γίνεται αίτημα για μεταφορά από ένα wallet (έστω w1) σε ένα άλλο (έστω w2), δημουργείται ένα νέο Transaction object. Ως transaction_input σε αυτό θα βάζουμε όσα UTXO του sender αρκούν για να συμπληρώνεται το ποσό που θέλει να στείλει. Ως transaction_output αυτά που λέτε. (ερ. 1) Τα πεδία αυτά transaction_input, transaction_output, πρέπει να συμπληρωθούν μαζί με τη δημιουργία του Transaction object; (ερ. 2) Οι τοπικές λίστες με τα UTXO στα nodes ανανεώνονται με το broadcast transaction, έτσι; (ερ. 3) Υπάρχει κάποιος συγκεκριμένος τρόπος για επιλογή από τα UTXO; (ερ. 4) Το πεδίο hash τι θέλουμε ακριβώς να hashαρει από τα πεδία του Transaction object; (Αυτήν την απορία για το hash την έχουμε και για το Block). Ευχαριστούμε πολύ.

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Distrib March 2019