Pages:
Author

Topic: [CERCO] Sviluppatore per creare un Exchange italiano - page 2. (Read 13111 times)

hero member
Activity: 588
Merit: 500
Perche' non c'era niente da capire ed il fatto che ora mi trovo a spiegare questo ne e' la dimostrazione.

O perchè neppure tu l'hai capito?   Roll Eyes
member
Activity: 154
Merit: 10
siete imo troppo bravi

8 pagine di coaching

considerando come si pone ha avuto sicuro di più di quello che si meritava

è bello perchè ricorda molto la filosofia che c'è dietro gnu/linux...

anche se, me povero, non è che cia abbia capito molto in questo scambio.


Perche' non c'era niente da capire ed il fatto che ora mi trovo a spiegare questo ne e' la dimostrazione.
legendary
Activity: 3766
Merit: 1742
Join the world-leading crypto sportsbook NOW!
siete imo troppo bravi

8 pagine di coaching

considerando come si pone ha avuto sicuro di più di quello che si meritava

/thread

legendary
Activity: 1316
Merit: 1481
siete imo troppo bravi

8 pagine di coaching

considerando come si pone ha avuto sicuro di più di quello che si meritava

è bello perchè ricorda molto la filosofia che c'è dietro gnu/linux...

anche se, me povero, non è che cia abbia capito molto in questo scambio.
legendary
Activity: 2506
Merit: 1120
(...)
 scombinare nuovamente i conti prima di mezzanotte;
(...)
In realtà non hai bisogno di farlo a 1/2 notte, basta segnalare la data e l'ora alla quale il conto coincide con il saldo del cliente anche se non e' 1/2 notte, potranno magari far sparire qualcosa ma sarebbero cifre molto minori del totale.
L'idea di mettere tutto in finte transazioni ha il difetto di pubblicare tutti i saldi e forse non e' il massimo ....
legendary
Activity: 1274
Merit: 1001
"shh, he's coding..."
Quindi il rischio è che comunque il risparmio sia "inutile" in quanto comunque va rifatto, e questo per molti utenti (facilmente chi scambia al mattimo magari da una controllata e uno scambio pure alla sera, per intenderci).
Sì, per ottimizzare l'algoritmo questo dovrà dare maggiore priorità agli utenti che abitualmente fanno poche transazioni giornaliere, e che quindi più probabilmente non andranno a scombinare nuovamente i conti prima di mezzanotte; oppure (non per forza in alternativa, i due approcci possono anche coesistere) dare maggiore priorità a chi non ha offerte sull'order book, o ne ha poche, o ha offerte che difficilmente saranno eseguite a breve. Oppure... beh, dai, facciamo spremere il cervello un pochino anche al programmatore che vorrà implementare un meccanismo di questo genere Smiley

Ultimo consiglio: direi che la logica fuzzy può tornare decisamente utile.

Ciao!

Personalmente trovo il tutto un po' troppo laborioso per essere implementato. Spero comunque che qualcuno possa seguire i vostri suggerimenti
legendary
Activity: 2450
Merit: 1008
Quindi il rischio è che comunque il risparmio sia "inutile" in quanto comunque va rifatto, e questo per molti utenti (facilmente chi scambia al mattimo magari da una controllata e uno scambio pure alla sera, per intenderci).
Sì, per ottimizzare l'algoritmo questo dovrà dare maggiore priorità agli utenti che abitualmente fanno poche transazioni giornaliere, e che quindi più probabilmente non andranno a scombinare nuovamente i conti prima di mezzanotte; oppure (non per forza in alternativa, i due approcci possono anche coesistere) dare maggiore priorità a chi non ha offerte sull'order book, o ne ha poche, o ha offerte che difficilmente saranno eseguite a breve. Oppure... beh, dai, facciamo spremere il cervello un pochino anche al programmatore che vorrà implementare un meccanismo di questo genere Smiley

Ultimo consiglio: direi che la logica fuzzy può tornare decisamente utile.

Ciao!
hero member
Activity: 595
Merit: 500
non può fare dump per sempre
siete imo troppo bravi

8 pagine di coaching

considerando come si pone ha avuto sicuro di più di quello che si meritava
legendary
Activity: 2506
Merit: 1120
Terzo messaggio sempre per tematiche differenti. Qui' fantastico ad occhi chiusi ...
Nel 3D si fa riferimento a tanti piccoli exchange open source, potrebbe essere una buona idea, un exchange che fa girare 100 Euro/gg non fa gola ad un hacker come uno da 1000 BTC/ora. Le risorse sarebbero limitate e i controlli ridotti, si tratterebbe di far lavorare piu' gente con meno risorse, una sorta di p2p, gli exchange potrebbero essere in collegamento tra loro in una chain e potrebbero essere clienti di loro simili con accordi commerciali tra pari, si metterebbero in piedi delle strategie comuni per relazionarsi con le banche e anche per poter arrotondare e magari in modo legale.
Se l'exchange risulta sicuro a livello crittografico forse non si rischia neanche tanto ad implementarlo.
Il problema degli exchange piccoli e' che non e' detto ci sia disponibilità, ma se si parlano tra loro attraverso api allora potremmo forse salvare capra e cavoli.
legendary
Activity: 2506
Merit: 1120
Uso due messaggi in quanto tematiche differenti (anche qui' spero di riuscire a spiegarmi).
Verifica monete fiat: si crea un indirizzo A nel quale si depositano i BTC di caparra, un indirizzo B che contiene i btc corrispondenti al saldo del contro corrente (dell'exchange) moltiplicato per il coefficiente di scambio proposto dall'exchange (es 1 BTC ogni 1000 euro) e si indicano tutti i corrispondenti importi dei vari conti piu' o meno come succede per i BTC, ciascun utente conosce i suoi indirizzi di deposito e fa la somma dei btc che ipoteticamente potrebbero contenere (in realtà stanno tutti nel B), moltiplica per il fattore di conversione e verifica che corrispondano agli euro in suo possesso, fa la somma degli address e controlla che corrisponda al saldo in B, chiama il numero verde della banca e verifica che il saldo sia quello dichiarato (ci sara' una tolleranza immagino ...). Anche cosi' si dovrebbe riuscire a dimostrare che l'exchange non usa gli Euro custoditi agli utenti.
Se un cliente chiede un BB in euro si spostano i BTC dal conto B al conto A, viceversa se se un utente deposita euro sul sull'exchange si spostano con una transazione da A a B... se finiscono i BTC in A: o si cambia il rapporto di cambio (as 1 BTC 10.000,00 Euro) o si aggiungono BTC su address A.
legendary
Activity: 2506
Merit: 1120
(Spero di spiegarmi) A pensarci bene potrebbe non servire avere una transazione in blockchain, basta un address (o piu') con depositati i BTC e i singoli saldi di tutti gli utenti (magari ad ogni utente si fanno piu' saldi per "mischiare" le carte). Tu sai qual'e' (quali sono) il tuo e puoi controllare che i tuoi BTC non vengano utilizzati. Puoi fare la somma e controllare che corrisponda all'ammontare del (degli) addres(s) di cauzione e il controllo e' fatto. Non ci sarebbe lo "spreco" di approvare una transazione.
Si crea solo un problema di privacy, splittando il saldo di ogni utente su piu' address (si userebbero gli address di deposito per evitare che usino lo stesso address per piu' utenti) ma solo "per finta" senza effettivamente inserire la tx in chain.
hero member
Activity: 588
Merit: 500
Certo, mettendo comunque un orario c'è più serietà!

A quel punto il problema di "sfruttare" rimane che se mi sincronizzi alle 16 e poi io faccio altre TX, per lanciare il messaggio che comunque a mezzanotte sono ok, dovresti tornare a sincronizzarmi comunque.

Quindi il rischio è che comunque il risparmio sia "inutile" in quanto comunque va rifatto, e questo per molti utenti (facilmente chi scambia al mattimo magari da una controllata e uno scambio pure alla sera, per intenderci).

Però certamente, sia con che senza TX sfruttando altre uscite, è una buona soluzione quella di fare degli "snapshot" e come dici anche tu, le idee sono buone, se poi qualcuno volesse pure implementarle, soprattutto per chi fa exchange senza valuta FIAT, tanto meglio!
legendary
Activity: 2450
Merit: 1008
Prendiamo questo esempio e facciamolo per 1000 utenti, credo che venga su un casino della madonna....
Certamente: la cosa andrebbe studiata con grande cura. Del resto è già tanto aver pubblicato una possibile strada: mica vogliamo anche svilupparla gratis, no? Smiley

In ogni caso, se l'algoritmo è pensato bene, quello che appare un groviglio inestricabile per un umano risulta una banalità per un calcolatore.

Quote
Certo, risparmieresti un po sulle fee, però anche ad un utente dire "ogni tanto durante il giorno sincronizzo il tuo indirizzo della blockchain con il tuo conto online per provare che siamo ok" non è molto "carino"
Io come messaggio metterei: «ogni giorno, a mezzanotte, potrai provare che siamo ok». Se poi l'aggiornamento avviene prima, tanto meglio.

Quote
si potrebbe anche sollevare il problema che, sfruttando le differenze di orario nelle transazioni, io posso comunque fare riserva frazionaria (o come vogliamo chiamarla).
No, la sincronizzazione di tutte le transazioni a spese dell'exchange, fatta una volta al giorno, va lasciata senz'altro in ogni caso, cercando però di sfruttare il più possibile anche le transazioni in uscita per risparmiare sui costi di gestione.
hero member
Activity: 588
Merit: 500
Questo implicherebbe che per dire, voi come Globobit che avete 0,1% di fee come mercato, se dovete pagare 0,022BTC ogni 1000 utenti per fare uno "snapshot", vi conviene solo se questi 1000 utenti vi hanno pagato questi 22milli a vostra volta.
In realtà, sfruttando l'idea di picchio di "scroccare" le transazioni in uscita (fatte da quelli che ritirano bitcoin dall'exchange), questo costo potrebbe essere di molti ordini di grandezza più basso, diventando sostanzialmente trascurabile.

Certo, qualche calcolo andrebbe fatto in ogni caso (e mi piacerebbe leggerlo).

Il problema che mi è venuto in mente nello scroccare le TX è che ci sarebbero tempi in cui le cose difficilmente corrisponderebbero.
Mi spiego con un esempio.

Quando fai delle transazioni su un exchange, non sono in genere tra due utenti ma magari, con una sell, coinvolgi decine di utenti. Certo, i conti alla fine devono sempre "tornare" ma magari nel momento X, in cui l'utente richiede qualcosa, è "complicato" farli tornare.

In particolare prendiamo i soliti 4 utenti, e a mezzanotte hanno:
Pippo: 1 BTC
Pluto: 4 BTC
Minnie: 3 BTC
Topolino: 10 BTC.

Hanno fatto tutti delle TX, comprando e vendendo l'uno con l'altro BTC per DOGE e alle 16, momento in cui Paperone ritira qualcosa e che vogliamo sfruttare, la loro situazione è:
Pippo: 0 BTC
Pluto: 7 BTC
Minnie: 9.9 BTC
Topolino: 1 BTC
Fee: 0.1 BTC.


Ora, per far tornare questo caso, significherebbe che alla TX di uscita di paperone bisognerebbe "allegare" tutti e 4 questi indirizzi. Infatti dire anche solo un "per ora metto a posto solo Minnie e Topolino" che sarebbe fattibile, significherebbe che il resto dovrebbe andare insieme ai BTC dell'exchange.

E si avrebbe che, alle 16, dopo la TX la situazione sarebbe:
Pippo: ipotetico 0 BTC ma da blockchain 1 BTC
Pluto: ipotetico 7 BTC ma da blockchain 4 BTC
Minnie: ipotetico 9.9 BTC e da blockchain 9.9 BTC
Topolino: ipotetico 1 BTC e da blockchain 1 BTC
Fee: ipotetico 0.1 BTC ma da blockchain 2.1 BTC

Solo più tardi, sfruttando un altra uscita, si avrebbe il sucessivo aggiornamento.

Prendiamo questo esempio e facciamolo per 1000 utenti, credo che venga su un casino della madonna....  Grin
Certo, risparmieresti un po sulle fee, però anche ad un utente dire "ogni tanto durante il giorno sincronizzo il tuo indirizzo della blockchain con il tuo conto online per provare che siamo ok" non è molto "carino" e si potrebbe anche sollevare il problema che, sfruttando le differenze di orario nelle transazioni, io posso comunque fare riserva frazionaria (o come vogliamo chiamarla).

Tanto se non ti tornano basta dire "eh ma perchè il tuo verrà aggiornato tra poco" in realtà sfrutto il giro per far mancare dei BTC.

Mentre farlo tutto insieme (che sia in 1 o 10 TX) implica che se a mezzanotte, quando viene fatto, manca anche solo 1 BTC in riserva frazionaria, qualcuno può subito sollevare il problema e dire "io stanotte non ero aggiornato".



legendary
Activity: 2450
Merit: 1008
Questo implicherebbe che per dire, voi come Globobit che avete 0,1% di fee come mercato, se dovete pagare 0,022BTC ogni 1000 utenti per fare uno "snapshot", vi conviene solo se questi 1000 utenti vi hanno pagato questi 22milli a vostra volta.
In realtà, sfruttando l'idea - geniale - di picchio di "scroccare" le transazioni sfruttando quelle in uscita (fatte da quelli che ritirano bitcoin dall'exchange), questo costo potrebbe essere di molti ordini di grandezza più basso, diventando sostanzialmente trascurabile.

Certo, qualche calcolo andrebbe fatto in ogni caso (e mi piacerebbe leggerlo).

Ciao!
hero member
Activity: 588
Merit: 500
Poche suona già meglio di unica. Bisognerebbe quantificare quante sono queste poche. E quante fee per i miners si spendono in questo passaggio.

Partendo da qui:
http://bitcoin.stackexchange.com/questions/1195/how-to-calculate-transaction-size-before-sending
in*180 + out*34 + 10 plus or minus 'in'


Quindi una TX con 1000 input e 100 output verrebbe, circa:
1000*180 + 1000*34 + 10 +- 100 => 180.000 + 34.000 + 10 +- 100 => circa 220Kb

Ho provato la formula su un paio di TX in blockchain a caso e funziona (anzi, in genere sovrastima le dimesioni).
Sarebbero quindi circa 22milli di Fee ogni 1000 utenti.

Questo implicherebbe che per dire, voi come Globobit che avete 0,1% di fee come mercato, se dovete pagare 0,022BTC ogni 1000 utenti per fare uno "snapshot", vi conviene solo se questi 1000 utenti vi hanno pagato questi 22milli a vostra volta.

Quindi hanno mosso, mediamente, almeno 0,02 BTC al giorno a testa.


Sono calcoli molto approssimativi, e mettendo la TX consigliata. In realtà si potrebbe pure abbassare ed entrerebbe comunque. Rimane che è comunque un costo che classifico medio\basso (non trascurabile, ma sicuramente non proibiltivo) per un exchange.
legendary
Activity: 1274
Merit: 1001
"shh, he's coding..."
Commissioni più alte (ci sono le fee dei miners) e tempi di transazioni lunghi (c'è da aspettare le conferme). Ci avevamo pensato per il nostro (Globobit) ma ci saremmo messi un passo indietro rispetto alla concorrenza alzando i costi e allungando i tempi d'attesa fra gli ordini.
Questo è vero se si pensa di fare in blockchain tutte le transazioni. Non se si facesse un'unica transazione al giorno.

Credo ci siano troppi movimenti (almeno se il progetto dovesse decollare) per potersi permettere una singola transazione giornaliera.

Credo che con unica intenda "poche" transazioni.

Alla fine sarebbe una TX dove hai in input e output tanti address quanti sono gli user che in quel giorno hanno fatto dei movimenti.
Questo significa che se hai 1000 user che hanno fatto movimenti di compra\vendita, avresti una TX con 1000 indirizzi di input e altrettanti di output. Parliamo di una TX di un centinaio di KB.

Poche suona già meglio di unica. Bisognerebbe quantificare quante sono queste poche. E quante fee per i miners si spendono in questo passaggio.

Mi quoto dalla discussione su Globobit al riguardo

La domanda regina a questo punto è qual'è la vostra posizione a livello di riserva frazionaria?


100% di riserva frazionaria. Non useremo mai i vostri coin. Tenete tranquillamente i coin da noi lo stretto necessario per compiere le operazioni se non vi fidate ad usarci come "conto deposito".



Purtroppo la riserva frazionaria è un problema reale.

Si potrebbe teoricamente risolvere assegnando ad ogni utente un address che non serva solo per il deposito e facendo quindi le transazioni sulla blockchain invece che nel db interno.

Il problema però sarebbero le fee da pagare per le transazioni che ci metterebbero fuori mercato (attualmente noi abbiamo scelto di tenere una commissione dello 0,10% anche per gli importi molto piccoli).
hero member
Activity: 588
Merit: 500
Commissioni più alte (ci sono le fee dei miners) e tempi di transazioni lunghi (c'è da aspettare le conferme). Ci avevamo pensato per il nostro (Globobit) ma ci saremmo messi un passo indietro rispetto alla concorrenza alzando i costi e allungando i tempi d'attesa fra gli ordini.
Questo è vero se si pensa di fare in blockchain tutte le transazioni. Non se si facesse un'unica transazione al giorno.

Credo ci siano troppi movimenti (almeno se il progetto dovesse decollare) per potersi permettere una singola transazione giornaliera.

Credo che con unica intenda "poche" transazioni.

Alla fine sarebbe una TX dove hai in input e output tanti address quanti sono gli user che in quel giorno hanno fatto dei movimenti.
Questo significa che se hai 1000 user che hanno fatto movimenti di compra\vendita, avresti una TX con 1000 indirizzi di input e altrettanti di output. Parliamo di una TX di un centinaio di KB.
legendary
Activity: 1274
Merit: 1001
"shh, he's coding..."
Commissioni più alte (ci sono le fee dei miners) e tempi di transazioni lunghi (c'è da aspettare le conferme). Ci avevamo pensato per il nostro (Globobit) ma ci saremmo messi un passo indietro rispetto alla concorrenza alzando i costi e allungando i tempi d'attesa fra gli ordini.
Questo è vero se si pensa di fare in blockchain tutte le transazioni. Non se si facesse un'unica transazione al giorno.

Credo ci siano troppi movimenti (almeno se il progetto dovesse decollare) per potersi permettere una singola transazione giornaliera.
legendary
Activity: 2506
Merit: 1120
(...)
La decentralizzazione e' quello di cui state parlando:

Magari ... siamo ancora lontani ....
Quote
trading che avviene sulla blockchain,
Il trading avviene nei db dell'exchange, gli address sono sotto il controllo del exchange (almeno 2 su 3)
Quote
ma questa e' decentralizzazione
No, e' prova di non aver (ancora) fatto uso dei tuoi BTC in alcun modo.

Quote
non prova di solvibilita' almeno per come intendo io la definizione di prova di solvibilita'.
La solvibilità richiede che i BTC non siano rubabili in alcun modo, come la intendi tu non funziona perche' hai la somma di n wallet a garanzia e ogni utente ha un solo addendo.

Come gira in questo 3d invece, grazie al fatto che gli indirizzi btc sono tantissimi e i costi relativamente bassi, ad ogni address (o piu') corrisponde un cliente e quindi puoi controllare che non siano stati ancora utilizzati e i due saldi: virtuale e reale coincidano a meno di operazioni recenti che non possono essere memorizzate sulla block chain per ovvi motivi gia' descritti (costo) e palesi non citati (10 minuti tra un blocco e l'altro). Nulla vieta di creare le transazioni a garanzia e non broadcastarle ai nodi fino ad una certa ora...
Pages:
Jump to: