eddig múkodik :
- kapcsolódás csak megfelelő név/jelszó párossal
- stratum csomagok módosítása, hogy a megadott felh.névre naplózzon a pool
- share accept/reject naplózás
- a kijelölt pool-ra kapcsolódik

és ami még hátravan:
- figyelni a pool váltást
- kapcsolatot bontani ha szükséges
- kernelinfót elérhetővé tenni
- kliens oldalon az indítóscript-et megálmodni
+ valami UI Mesternek, hogy tudjon váltogatni a pool-ok között.

[ Szerkesztve ]

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

eredetiben

[ Szerkesztve ]

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

na, erről jól lemaradtam. Nem értem az elakadás tárgyát.
Hol? Kinek? Mit? Miért?
ha 'standalone' proxy-t írsz, akkor a kliens kapcsolódása után fork, és a child process-ből nyiss socketet a pool-hoz. Így megoldódik a kinek-mit küldjünk probléma.
Nem tudom linux vagy ablakOS alatt dolgozol e, én linux alatt csinálom, és az xinetd megoldja ezt a problémát (viszont elakadtam azon, hogy nem minden esetben tudom lekezelni, hogy bezáródott az STDIN -pl. ha kill-el kilövöm az sgminert- így a proxy futva marad, a pool meg tolja kifelé a feladatot ... az meg elvész az éterben, szóval ezen még agyalok 1 sort)

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

c#-ban irodik az en kodom, monoval kivaloan fut linux serveren.
pontosan jol irtad a megvalositas: socketaccept, fork, majd ebben tovabb konnektalas a poolba.
ez azert egyszerubb mint az "osszegyujto" moka, mert nemkell az "id"-ket maskolni (poolba sajat id, majd kliensnek a valaszban visszairni a sajat request id-t).

meg most belefutottam egy problemaba: ha worker alapjan akarom szetosztani a gepeket tobb poolra, akkkor megkell varnom mig authol. viszont elotte mar el kell kuldenem neki az extranonce erteket, amit viszont csak a nagy poolhoz csatlakozas utan tudok meg.
ha erre nem talalok valami megoldast, akkor viszont csak az "osszegyujtos" felepitesu proxy mukodokepes.

a sharek loggolasakor figyelni kell kinek mekkora a diff-je, mert nem mind1 hogy valaki 128-as sharet kuldbe vagy 16-ost.

erdekessegkeppen: nodejs alapu stratum protokol

most nezem ezt a stratum-mining-proxy, es ez nemcsak getwork-stratum kozott tud proxyzni, hanem stratum-stratum kozott. ez is erdekes lehet alapnak... csak pythonos

nem kell "külön" figyelni.
elvi folyamat:
packet recvd -> json parse -> userdiff = (isset(mining->set_difficulty) ? mining->set_difficulty->params[0] : userdiff) ....
submitshare -> storesubmit & store userdiff

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

proxyhoz ujabb megallapitas: valahogy a nonce1 parametert valtoztatni kell minden klienshez, kulonben mindenki ugyanazt a a hash-ekez probalja vegig, az meg nekunk nagyon nemjo!

hmmm ... releváns részlet a bfgminer-ből :
void stratumsrv_mining_subscribe(struct bufferevent *bev, json_t *params, const char *idstr, uint32_t *xnonce1_p)
{
char buf[90 + strlen(idstr) + (_ssm_client_octets * 2 * 2) + 0x10];
char xnonce1x[(_ssm_client_octets * 2) + 1];
int bufsz;
...
if (!*xnonce1_p)
{
uint32_t xnonce1;
for (xnonce1 = MAX_CLIENTS; _ssm_xnonce1s[xnonce1]; --xnonce1)
if (!xnonce1)
return_stratumsrv_failure(20, "Maximum clients already connected");
*xnonce1_p = htole32(xnonce1);
}

bin2hex(xnonce1x, xnonce1_p, _ssm_client_octets);
bufsz = sprintf(buf, "{\"id\":%s,\"result\":[[[\"mining.set_difficulty\",\"x\"],[\"mining.notify\",\"%s\"]],\"%s\",%d],\"error\":null}\n", idstr, xnonce1x, xnonce1x, _ssm_client_xnonce2sz);

...

void *stratumsrv_thread(__maybe_unused void *p)
{
pthread_detach(pthread_self());
RenameThread("stratumsrv");

for (uint64_t n = MAX_CLIENTS; n; n >>= 8)
++_ssm_client_octets;
_ssm_client_xnonce2sz = 2;

Ennek alapján, a kliensek egyedi nonce1 -et kapnak -kellene kapniuk- (a _ssm_client_octets alapján számolja, az pedig minden connect alkalmával növekszik, nem látok okot arra, hogy ez nagyban ne így működjön -még nem elemeztem a forgalmat 1-nél több kliens kapcsolódása esetén), még nem teszteltem az elméletet, előbb átírom ami napközben eszembe jutott, aztán kipróbálom 2 klienssel.

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

jah kozben mar en is megcsinaltam a sajat kodomban a pythonos otlete alapjan: nonce1 kap me'g 2 egyedi karaktert, a nonce2size meg csokken kettovel. igy a kliens 10 karakterhez ad 6 sajatot, submitkor a proxy meg visszaallitja a tenyleges 8 karaktert.

rohatt php ... hogy rohadna el aki kitalálta & || nem javította a tetves bugot 100000 éve
$buff = socket_read($socket,64);

"socket_read() returns the data as a string on success, or FALSE on error (including if the remote host has closed the connection)."

az isten verné a bizalmát abba a nyomorultba, aki ezt még nem javította.
hiba esetén, ha a socket bezáródott és nincs adat a stack-ben "" (üres string) a visszatérési érték, míg ha a socket él, ===false, ráadásul a socket_lasterror = 11! (ez mondjuk mindkét esetben 11, szóval ez valami konstans érték lehet)

[ Szerkesztve ]

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

hehe, ezert hasznalok ertelmes programnyelvet.

bar en is irtam minden szutykot phpban, a nyelvet sajna nem erre talaltak ki...

ebben igazad van, de arra, hogy valamit gyorsan kipróbálj (működőképes e az 5let), tökéletesen megfelel.
nem kell foglalkozni a memóriafoglalással (CLI esetén azért van csapda ... a felszabadítással igen, ez is 1 vicc)
na, de vissza a témára. nem lehet megbízhatóan xinetd -vel megoldani
szerencsére minimális változtatásokkal önállóan is működésre tudtam kelteni, így már működik.
de ... a franc ebbe a protokolba. Nem elég, hogy kliens oldalon is összevon csomagokat, a szerver is képes időben egymástól távol kapott kérdésekre egyszerre küldeni a választ. (na nem megoldhatatlan, tartott vagy 2 percig, csak meglepett)

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

hat ha van egy kis c# skilled, akkor megnezheted az en projectem.

a proxy resze mar mukodik (ertsd: egy cgminerrel mar banyaszott ), most meg az uzembiztos mukodest kell belekodolni (thread-safe reszek, hibakezeles mindenhol, stb)

nem vagyok benne biztos, hogy "piszkálni" kell a nonce1 -et

bal : 280x
jobb: 290
eltérő diff-en, pedig egyszerre lettek indítva.

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

hüm ... nem sokat konyítok hozzá, bár az alapvető dolgokat értem. Holnap (ma) megpróbálom értelmezni.

Már biztos vagyok benne, hogy nem kell a nonce-t módosítani. a 280x-en a diff lement 16->...->224->192->160, míg a 290-nek maradt 224
(tesztelési célzattal Lmentem túrni egy kist LTC-t a givemecoins-ra, szóval a szerveren múlik, lesz e eltérő diff a klienseknél, vagy mindenki azonos diffel nyomul).

viszont gond van a protokollal. időnként eltűnik a <CR>, és még ötletem sincs mi váltja ki (vagy csak így sikerül kliensoldalon összerakni a csomagot?)
ezt köpte ki (persze érthető miért nem tudta értelmezni):
{"params": ["dodo", "1395192247 18756", "04000000", "5328f1b7", "da895400"], "id": 110, "method": "mining.submit"}{"params": ["dodo", "1395192247 18756", "04000000", "5328f1b7", "bff35700"], "id": 111, "method": "mining.submit"}
és ez így, <CR> nélkül jött-ment (tcpdump-al néztem a forgalmat) a 290-es kártya beküldött egyszerre 2 share-t, szóval a readline nem 100%-os megoldás.

akkor én is eldicsekszek az enyémmel pastebin (felraktam 1 hétre), ha megy 24 órát hiba nélkül (igen, a fent jelzett már kiderült, csak el kell hárítani), átírom C-be (bár így sem eszik sokat, 1% körül terheli a cpu-t/thread, mondjuk ez 100 miner esetén már nem egészséges )

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

juteszembe. sgminer-t használok csak. lehet azzal van baj. (de ez ettől függetlenül probléma)

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

-P parameterrel inditsd, akkor latod mi kuldozget stratumnak. nonce1-et minden kapcsolatnak mast kuld a stratum server, igy oldja meg hogy tuti mindenki mas adatoknon keresse a helyes hash.

ravasz, nem nagyon nézegettem a kapcsolóit, jó tudni, hogy ilyet is tud

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

Sziasztok!

Végre megvan a topik.
Szerintem az egész rendszert teljesen zárt módon kellene kialakítani, evvel megvédjük magunkat eleve az általad említett támadásoktól (DDOS stb...)
A másik dolog, nem tudom valaki összeadta már hogy mennyi MHs-t tudunk összedobni mi a fórumról? Csak azért mert szerintem nem túl szerencsés óriás hasrattel nekiesni egy kiszemelt új coinnak. Még ha csak 1 napot is megy a móka, akkor is lehet annyi jön ki, hogy soha el nem tudjuk adni. A multipoolok ezért is hoznak ilyen fránya eredményeket, mert annyi gagyi coint halmoznak fel ami per. pill. jó volt, hogy később nem tudják eladni, vagy csak fél-, negyedáron.
Ha óriás Mhs, Ghs-el esünk neki, akkor a diff is hamar fog megugrani, ami meg kevesebb coint jelent.
Szóval szerintem valahol kéne húzni egy határt és nem mindenkit beengedni a poolba.

nah, nézegettem, még nem jelenteném ki, hogy teljesen értem, de ...
ha jól értelmezem, serverString = serverReader.ReadLine(); & clientString = miner.clientReader.ReadLine(); ezek ugye addig várnak, amíg nem érkezik vlami. Ez nem biztos, hogy jó ötlet. Ha felmegy a diff az egekbe, lesz, hogy percekig nem kommunikálnak (icmp csomagok meg nem közlekednek, a keepalive pedig a tcp protokol része, 0 tartalommal, csak arra jó, hogy fenntartsa a kapcsolatot).

ha megnézed az enyémet, nonblock beállítás van, és így figyeli érkezett e bármi. ha van mit, olvas, ha nincs, vár 500 usec -et (ha megszakadt a kapcsolat, akkor kilép), így timeout -ot biztos nem kapok olvasásra.

(nem ismerem a c#-t, nem tudom hogyan kezeli a timeout-ot)

jah ... az egymásba érő submitshare, visszaraktam éjjel a cleverre, 512-es diffel már nem történt ilyen

[ Szerkesztve ]

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

A pool mérete nem lesz akkora, hogy ettől kelljen félnünk. Néha látok olyan sebességeket, hogy a hajam égnek áll tőle! és mégis eredményesen lehet bányászni az érmét. Ha nagyobb a hash, akkor több érme jön ki az elején, amikor még alacsonyabb a diff. Nem hiszem, hogy olyan sokat tudnánk 1 nap alatt bányászni, hogy ne tudnánk eladni.

A pool a jelenlegi számítások szerint 50-100 Mhs között lesz valahol, egyelőre inkább az 50-hez közelebb.

A biztonság témára visszatérve, a Coinex-es baki miatt is, meg már egyszer elmondtam, hogy az én nézetem és jelenlegi gyakorlatom is az, hogy nem dolgozok váltóra, ha más pénzével is operálok, akkor mindenképpen a laptopon, offline tárcában lévő érme tárolást fogom alkalmazni. A tárcákat esténként szinkronizálom, hogy gyorsan lehessen utalni belőlük, de csak az utalás és szinkronizálás idejére lesz online a gép!

2014 január óta bányász és kriptoérme szakértő

készülj
este kijavítom azt a hibát, ami még felmerült, megcsinálom az indító scripteket, összerakok 1 egyszerű felületet, amin tudod próbálgatni (pool/coin beállítások), és átirányítok tesztelésre 1.5MHs -t (ez elvileg ma, de legkésőbb holnap este-éjjel meg is történik), aztán lehet kattintgatni

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

Perl a baratod.

wallethez csakis forrasbol forgass helyben kliens (linuxhoz konnyu, csak neha kicsit modositani kell par dolgot a makefajlokban). illetve apparmor-ral be lehet "zarni" oket, igy nem tudjak egymas walletjeit ellopni.

ha kell help szolj

és ami még hátravan:
- figyelni a pool váltást
- kapcsolatot bontani ha szükséges
- kernelinfót elérhetővé tenni
- kliens oldalon az indítóscript-et megálmodni
+ valami UI Mesternek, hogy tudjon váltogatni a pool-ok között.
telnettel egyszerűen elérhető információk :
kernel (ami az adott coin-hoz kell), coin (mit), pool (hol)
{"get":"kernel"} || {"get":"coin"} || {"get":"pool"}

pool váltás ellenőrzése 1 percenként,
ha más kernelre van szükség, akkor HUP előtt küld egy üzenetet a klienseknek:
{"id":null,"result":true,"method":"quit","error":null}
ennek a kezeléséhez módosítani kell a minert (ez a könnyebbik része ... remélem)

ha nem kell kernelt cserélni (csak másik poolra megy a csapat), akkor lezárja a socketet, kliensek azonnal próbálnak újrakapcsolódni (ami sikerül is nekik), és máris megy a meló tovább (ezt sgminerrel ltc-clever között már teszteltem)

@Reggie0: annyit tudok róla mint a c#-ről, ami kb ennyiben kimerül: van.
láttam már de nem ismerem/értem.

[ Szerkesztve ]

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

Szuper. Csak azért, hogy előre legyen nyoma. BitcoinScryptet bányásztam 1 napot. Van belőle 150 db-om. Tegnap óta megduplázódott az ára a Cryptorush-on, jelenleg az 1 napi bányászatom értéke (2,1 Mhs) 0,07 BTC vagyis 0,035BTC/Mhs/nap. Ez kb. 5 napnyi multipool. Ha a Spaincoin-t is hozzá veszem, akkor ezzel a 2 érmével megvan vagy 2 hétnyi bányászat.

(mindezt nem dicsekvésnek szánom, csupán jelzem, hogy még mindig lehet nyereségesen bányászni és én mindent megteszek, hogy ez a jövőben is így legyen.)

2014 január óta bányász és kriptoérme szakértő

fog meg ez feljebb menni?

és ami még hátravan:
- figyelni a pool váltást
- kapcsolatot bontani ha szükséges
- kernelinfót elérhetővé tenni
- kliens oldalon az indítóscript-et megálmodni
+ valami UI Mesternek, hogy tudjon váltogatni a pool-ok között.

egyenlőre scrypt poolok között lehet váltogatni (folyamatban van az indítóscript + az s/c-gminer módosítás)

PM!

[ Szerkesztve ]

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

nah, jelentem működik. még nem próbáltam ki a többivel (csak scrypt-re), de ha váltok, kilép, és üzenget (mert nem tud mit elindítani jelenleg)
a kívánt miner indítását kezelő script:
#!/bin/bash
while [ 1 ]
do
KERNEL=`/root/kernel.sh | telnet 2>/dev/null | grep -E "kernel: (.*)" | awk -F': ' '{print $2}'`;
date
case "$KERNEL" in
scrypt )
sh /root/miner_scrypt.sh
;;
* )
echo "**** not configured : ${KERNEL}"
;;
esac
done

a kernel.sh tartalma :
#/bin/bash
echo "open 94.199.178.108 3334"
sleep 1
echo "{\"get\":\"kernel\"}"
sleep 1

szükséges módosítás a miner util.c forrásában (sgminer 4.1.0 / 1719.sor):
bool parse_method(struct pool *pool, char *s)
{
json_t *val = NULL, *method, *err_val, *params;
json_error_t err;
bool ret = false;
char *buf;
....
if (!strncasecmp(buf, "mining.set_difficulty", 21) && parse_diff(pool, params)) {
ret = true;
json_decref(val);
return ret;
}

+ if (!strncasecmp(buf, "client.quit", 11)) {
+ ret = true;
+ kill_work();
+ json_decref(val);
+ return ret;
+ }

if (!strncasecmp(buf, "client.reconnect", 16) && parse_reconnect(pool, params)) {
ret = true;
json_decref(val);
return ret;
}

(kezdőknek: a '+' -al jelzett sorokat kell beszúrni, értelemszerűen a '+' jel nélkül, aztán make, majd make install)
egyenlőre csak az sgminer-t néztem, de mivel mind(?) cgminer fork, 1000%, hogy megoldható(?) a többiben is

holnap (ma) megnézem még a cgminer 3.7.3 -at (keccak féle) + a bfgminer-t, és csinálok patch file-t a könnyebb telepíthetőség végett.

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

az a kernel.sh hely hasznalj netcatot! pont ezt tudja.

ez fog futni windows alatt is?

igen, elvileg menne netcat-at, de az most nincs felrakva, olyan progikat próbáltam, amik valószinüleg a legtöbb disztrón fent vannak.

vindóz alatt: nem tudom, nem vagyok perfect a windows scriptelési lehetőségeiből (annyit tudok erről, hogy van vmi powershell, ami állítólag sokat tud). legrosszabb esetben megírom c/delphi -ben amit kell, de azt nem tudom, hogy mikor. ill. cygwin, amit ilyen esetekre ajánlani szoktak, de erről még annyit se tudok mint a powershell-ről

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

telnet?

vagy curl

ezt nem értem: "telnet?"
curl nem jó, netcat-ot majd megnézem este (vindózra van netcat? , am részletkérdés, grep, awk nincs, szóval arra ettől függetlenül kell vmi megoldást találni)

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

"fog futni vindóz alatt?" : pontosan melyik részére gondolsz? Azt már írtam, hogy a minert módosítani kell, hogy a 'client.quit' üzenetet értelmezze. Ezt vindózon is meg kell tenni (util.c átír, miner ujrafordít).
A külön porton történő quit/restart kommunikáció kezelését (pedig ez lenne a legkényelmesebb) végül elvetettem, túl komplikált, sőt, abban sem vagyok biztos, hogy egyáltalán megvalósítható.
Ha valaki tud (talál) megoldást a script vindózra portolásának problémájára , akkor az is menni fog, ellenkező esetben kell rá írni egy programot (legfeljebb megírom azt is, de még halványlila sejtésem sincs mikor jutok el addig, linuxon is van még mit megcsinálni)

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

amugy van ez a cgwatcher nevu ize, ha jol latom ez .net frameworkos, ami meg fut monoval. ebben lehet kezelni tobb profile-t, es ugy inditja a cgminert. meg is van oldva a scrypt valtas.

ez kozponti helyrol meg van iranyitva a dolog.

Elbandi

ok, kell hozzá ablakOS szerver, vagy olyan linux, amire húztak X-et (még nem hegesztettem mono-t, nem tudom mekkora szopás vagy simán első kattintásra működik). Nekem nincs.

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

am cgwatcher egész véletlenül nem az API-n keresztül kommunikál?
Ha NAT-olt hálózaton vagy, vagy egy olyan fűzfal mögött, ahol nem tudod megoldani, hogy valami bejusson a gépedig, máris felejtős.

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

Találtam egy ilyet, ezzel talán könnyebben lehetne követni mindenkinek az érméket, amiket bányászunk, hiszen a cím, ahová mennének az érmék, mindenki által ismert lenne.

2014 január óta bányász és kriptoérme szakértő

milyen ilyet?

ez a btcs is bejott, de mar nemigen eri meg nyomatni elegge raugrottak. next coin?

VPN erre jo megoldas lehet.

Hehe, csak a linket felejtettem el beszúrni! 8) EZT

A következő érmét még bányászom kicsit, a jelenlegi diffel, majd éjszaka küldöm, hogy mi az! 8))

2014 január óta bányász és kriptoérme szakértő

hamachi-t használva máris el lehet érni a NAT-ot is.
CGWatcher-el csak a gépen futó cgminer-t tudod megnézni, CGremote amire gondoltál sztem.

Ne csigázz, melyik coint is kell most bányászni?:-D Egyébként izgatottan figyelem a fejleményeket, le a kalappal előttetek. Szívesen leszek beta tesztelő is ha kell, igaz csak 2,4MHsem van...

hilfe

a hogyan számoljuk ki az userek jussát című körkérdés következik

nem pontosan értem hol-hogyan kellene figyelembe venni az accept mellett a diff-et

például. a poolban van 2 user, és fabatkát bányásznak. 16 ill. 512 -es diffel, ketten kikaparnak 15 fabatkát.
(a) usernek 4 accept 16-os diffel, az 64
(b) usernek 4 accept 512-es diffel az 2048

így összesen 2048+64 = 2112
64/2112 = 0,0303*
2048/2112 = 0,9696*
15 * 0,0303 = 0,4545 fabatka
15 * 0,9696 = 14,544 fabatka

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

na elarulod mit lenne jo most banyaszni?

Helló, helló! Azért mindent nem lehet készpénznek venni, amit mondok, nem mindenható vagyok, csak egy kicsit hatékonyabb mint az átlag!

A helyzet az, hogy megnéztem a Mintpal-os szvazásokat és mind olyan érmék, amik már nagyon kifutott darabok, legalábbis szerintem nem éri meg már őket bányászni, meg nem is látom bennük a lehetőséget.

Én most PLNcoin-t bányászom, ez a lengyelek nemzeti érméje. Tudom, volt már ilyen, AUR, SiliconValley, stb. De a helyzet az, hogy elég alacsony a kitermelhető mennyiség, kellemesen nehéz bányászni, szóval szerintem értékes lesz, ha felkerül egy váltóra. 1 napnál tovább nem fogom azonban bányászni, az biztos.

A processzoraimat ráizzítottam a Populacecoinra, ez most a MIntpal első.

Hát én ennyit tudok most mondani.

2014 január óta bányász és kriptoérme szakértő

vaze, majd' leestem a székről
nézem mit írtál itt, na, gondoltam hozzáadom, oldal újratölt, erre ... megelőztél

közben megpiszkáltam a cgminer-t (is), simán vált script<>sha között, tehát múkodik.
a 3.7.3 meg tud keccak-ot is, szóval az is megvan

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem

Szia, akartam mondani, hogy próbálgattam az oldalt, de azért vigyázzunk, csak kis időre válts rá, mert az a beírás egyelőre nekem számol, erre nem akartam újból regisztrálni! 8))

2014 január óta bányász és kriptoérme szakértő

hát ... lehet, hogy valamit eddig félreértettél?
átmenetileg mindenki neked fog számolni
7végén megcsinálom az egyenleg kiírós/elszámolós részt is, ideje lenne már élesben használni

az url kicsit változott, a végére : /admin

[ Szerkesztve ]

Egyszerű életet élek. Ami üres megtöltöm, ami tele van kiűritem