Distrib

distrib@lists.cslab.ece.ntua.gr

180 discussions

(no subject)
by kbitsak＠cslab.ece.ntua.gr 12 Mar '19

12 Mar '19

"Καλημέρα! Δεδομένου του ότι τόσο ο σκελετός που μας έχετε δώσει όσο και μια προηγούμενη απάντηση στη λίστα υπονοούν χρήση flask και requests για το κομμάτι της επικοινωνίας, ήθελα να ρωτήσω εάν υπάρχει κάποιος ενδεδειγμένος τρόπος για να καταφέρουμε να έχουμε π.χ. ένα non-blocking post request με χρήση της requests (το documentation παραπέμπει σε άλλες βιβλιοθήκες για αυτήν την δουλειά). Για παράδειγμα, εάν το broadcast ενός transaction γίνεται με την requests (σε μια for loop) και ένας από τους κόμβους συμπληρώσει με αυτό το transaction ένα block, τότε αναγκαστικά ο αποστολέας του transaction θα μπλοκάρει μέχρι ο παραλήπτης να τελειώσει το mining. Υπάρχει κάποιος τρόπος να καταφέρουμε να το γλιτώσουμε αυτό με χρήση αυτών των βιβλιοθηκών ή θα χρειαστεί να βρούμε άλλες βιβλιοθήκες (ή/και να καταφύγουμε σε threads);" Καλησπέρα! Ναι στο πρόβλημά σου η λύση είναι ένα thread ανά κόμβο, αφού έχουμε συγκεκριμένο προκαθορισμένο αριθμό κόμβων, για να μην καταφεύγεις σε πιο εξεζητημένες λύσεις. Κωνσταντίνος

1 0

(no subject)
by kbitsak＠cslab.ece.ntua.gr 12 Mar '19

12 Mar '19

"Κάθε φορά που πάω να μετατρέψω σε json κάποιο transaction (και γενικά οτιδήποτε είναι ή περιέχει rsa public key) μου λέει ότι το RsaKey δεν είναι JSON serializable. Σε κάποιες περιπτώσεις που δεν ήταν ανάγκη να έχω το ακριβές public key του wallet το έστειλα ως str(my_key.publickey().exportKey("OpenSSH")). Για να στείλω όμως ένα transaction (κατά το broadcast transaction πχ) θα πρέπει να έχω το πραγματικό pubkey για να κάνω verify. Πώς το αντιμετωπίζω αυτό; Πώς δηλαδή θα στείλω rsa public key μέσω διαύλου; " Ας υποθέσουμε πως ακολουθείς την παρακάτω διαδικασία για τη δημιουργία του private key σου. Kάνοντας αυτά που έχω εδώ, θα πρέπει να σε αφήνει να στείλεις το κλειδί σου σαν request. ... random_gen = Crypto.Random.new().read private_key = RSA.generate(1024, random_gen) response = { 'private_key': binascii.hexlify(private_key.exportKey(format='DER')).decode('ascii'), } return jsonify(response) .... Σε απάντηση και για την προηγούμενη ερώτηση για το object->json, πρέπει να σκεφτούμε κάθε φορά τι πληροφορία χρειάζεται να στείλουμε στο δίκτυο των κόμβων; Χρειάζεται πχ να τους στείλουμε όλο το object μιας transaction, όπως το έχουμε αποθηκευμένο locally, ή μπορούμε συγκεκριμένα attributes του object μας να τα βάλουμε σε ένα απλό dict, που θα το κάνουμε json και ύστερα broadcast στο δίκτυο; Πχ το object transaction που έχετε φαντάζομαι έχει και κάποιες methods μέσα. Αυτές δεν υπάρχει κάποιος λόγος να σταλθούν με ένα request. Κωνσταντίνος

1 0

(no subject)
by kbitsak＠cslab.ece.ntua.gr 12 Mar '19

12 Mar '19

"Καλησπέρα, Υπάρχει κάποιος τρόπος να στέλνουμε κατευεθείαν ένα object με flask; Μέχρι στιγμής στέλνω ότι χρειάζεται μέσω url-query. Δοκίμασα την jsonpickle για μετατροπή αντικειμέμενου σε json για να συμπεριληφθεί στο url-query η οποία δούλεψε με αποστολή απλού dictionary αλλά φαίνεται να μην παίζει για την αποστολή Block π.χ.. Yποψιάζομαι ότι έχει να κάνει με το ότι το Block έχει εμφωλευμένο αντικείμενο Transaction. Υπάρχει κάποιος τρόπος να λυθεί αυτό ή πρέπει να στέλνουμε ένα ένα τα πεδία; Υπάρχει περίπτωση να φταίει κάτι άλλο; Ευχαριστώ πολύ." Δοκίμασες να το κάνεις μέσω jsonify (http://flask.pocoo.org/docs/1.0/api/#flask.json.jsonify) ή json.dumps ? Είναι προτιμότερα από το pickle. Επίσης το jsonify σου επιστρέφει ένα json έτοιμο σαν flask.response που σημαίνει ότι δεν πρέπει να δηλώσεις εσύ τον Content-Type header στο request που θα κάνεις. Αν δοκιμάσεις με αυτά και δεν παίξει, καλύτερα κάνε ένα git repo και ανέβασε τον κώδικα, να δω τι μπορεί να φταιει και στείλε μου ένα full trace με τα errors που σου πετάει. Κωνσταντίνος

1 0

Ανάγκη non-blocking επικοινωνίας σε Python
by Σωτήρης Νιάρχος 12 Mar '19

12 Mar '19

Καλημέρα! Δεδομένου του ότι τόσο ο σκελετός που μας έχετε δώσει όσο και μια προηγούμενη απάντηση στη λίστα υπονοούν χρήση flask και requests για το κομμάτι της επικοινωνίας, ήθελα να ρωτήσω εάν υπάρχει κάποιος ενδεδειγμένος τρόπος για να καταφέρουμε να έχουμε π.χ. ένα non-blocking post request με χρήση της requests (το documentation παραπέμπει σε άλλες βιβλιοθήκες για αυτήν την δουλειά). Για παράδειγμα, εάν το broadcast ενός transaction γίνεται με την requests (σε μια for loop) και ένας από τους κόμβους συμπληρώσει με αυτό το transaction ένα block, τότε αναγκαστικά ο αποστολέας του transaction θα μπλοκάρει μέχρι ο παραλήπτης να τελειώσει το mining. Υπάρχει κάποιος τρόπος να καταφέρουμε να το γλιτώσουμε αυτό με χρήση αυτών των βιβλιοθηκών ή θα χρειαστεί να βρούμε άλλες βιβλιοθήκες (ή/και να καταφύγουμε σε threads);

1 0

αποστολή object μέσω flask, python
by Vakalopoulou Myrsini 11 Mar '19

11 Mar '19

Καλησπέρα, Υπάρχει κάποιος τρόπος να στέλνουμε κατευεθείαν ένα object με flask; Μέχρι στιγμής στέλνω ότι χρειάζεται μέσω url-query. Δοκίμασα την jsonpickle για μετατροπή αντικειμέμενου σε json για να συμπεριληφθεί στο url-query η οποία δούλεψε με αποστολή απλού dictionary αλλά φαίνεται να μην παίζει για την αποστολή Block π.χ.. Yποψιάζομαι ότι έχει να κάνει με το ότι το Block έχει εμφωλευμένο αντικείμενο Transaction. Υπάρχει κάποιος τρόπος να λυθεί αυτό ή πρέπει να στέλνουμε ένα ένα τα πεδία; Υπάρχει περίπτωση να φταίει κάτι άλλο; Ευχαριστώ πολύ.

1 0

τελευταία παράταση για την εργασία των Κατανεμημένων
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

← Newer
1
...
8
9
10
11
12
13
14
...
18
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

Distrib