Ich habe am Freitag die Erstattung auf meinem Konto gehabt.
Hatte auf das Commerzbank Konto überwiesen.
Damit bin ich ohne einen Sathosi / Cent Verlust davongekommen.
Beschreib mal bitte genau was Du wann wie gemacht hast! (Ticket/E-Mail/Anwalt/etc...) |
|
|
|
|
If you would be willing to let John K escrow the BTC until you prove that you got it running with said specs and are ready to deliver, I'm sure you will get a lot more interest on this.
|
|
|
|
Liste kommt gleich. Leider haben uns einige den Widerruf per Email geschickt ohne Nennung ihres Bitcointalk Namens. Sind gerade am recherchieren wer das sein könnte
Den ganzen Zirkus hättest Du Dir sparen können wenn Du von Anfang an (und auch jetzt beim Rückkauf) konsequent die mit den Anteilen verknüpfte Bitcoin-Adresse als eindeutiges und alleiniges Identifizierungsmerkmal verwendet hättest. Dann brauchst Du keine Klarnamen, eigentlich noch nichtmal Forennamen und auch keine Kontonummern denn Du kannst ja dann bequem in BTC zahlen. Alles was Du bräuchtest wäre zu verlangen (und zu prüfen) daß die Gegenseite per Bitcoin Signatur nachweist daß ihr diese Adresse auch wirklich gehört. Die ECDSA Signatur ist eine "fortgeschrittene Elektronische Signatur" und als solche per EU-Signaturrichtlinie Artikel 5 Absatz 2 vor Gericht als Beweismittel zuzulassen. Das selbe gilt auch für Transaktionen in der Blockchain, die sind auf die selbe Art und Weise elektronisch signiert (und darüber hinaus noch zusätzlich vom Netzwerk beglaubigt und archiviert) und somit ebenfalls beweiskräftig, eine erfolgte BTC-Zahlung läßt sich also ohne weiteres vor Gericht (sollte es dazu kommen) beweisen. Es gibt also überhaupt keinen Grund für diesen ganzen unsäglichen Zirkus, zahl doch einfach an die jeweiligen hinterlegten Inhaber-Adressen und schreib Dir die Transaktionsnummer auf für den Fall daß Du später einen Beweis brauchst für die erfolgte Zahlung. Schön geschrieben. Das hat jetzt ja nur knapp ~40 Seiten in diversen Threads gedauert....  Jedoch wie Boumer und andere vor ihm schon geschrieben hat geht es candoo lediglich darum Zeit zu schinden (jeden Tag Fiat aufm Konto gibt ein paar %chen) und die Leute zu nerven mit der Hoffnung das sie evtl. aufgeben und sich die Vorderung im Sand verläuft. Auf Transparenz, geschweige denn Kunden/User-freundlichkeit bzw. Gemeinschaftlichkeit kann man bei candoo leider nicht hoffen. Mittlerweile sollte jedem hier klar sein das für ihn nur sein alleiniger Profit zählt, alles andere ist nebensächlich. |
|
|
|
I previously published a method using the block hash as a pseudo-random number generator for raffle ticket picking. The block hash is quite random: the only way of manipulating future block hashes is to be a significant miner and discard winning block hashes if they don't meet a criteria, which gives you even less chance of influence than your hashrate would indicate in addition to discarding 50 BTCs: http://we.lovebitco.in/raffle.htmlHey guys, okay, first of all I'm new to this crypto stuff and I know the issue of "Provably Fair" has been discussed over and over again. Yet I haven't quiet found any definite answer to my approach. What I want to do is make the RNG more transparent by taking the information of the next/current block found (txconf=1). My approach so far looks like this: hmac_sha512($blockhash, $nonce) Using a 512 bit hash gives the illusion that there is more entropy than there is. The block hash can be considered as a random number generator, with an even distribution of results between 0 and the current difficulty target, currently 0000000000000031679C00000000000000000000000000000000000000000000. That's currently less than 198 bits of entropy. It would be more appropriate to re-hash the block hash with a secure 160 bit algorithm such as RIPEMD-160 just to be clear in algorithms that that is the depth of the randomness. A block hash not the best secret for a gambling site, as it not a secret, and your salting method may be discoverable. It is good when a future random number pick will determine a winner and the picking method needs to be verifiable by all. Yeah, I've seen your approach last week and find it very interesting for the idea I got. It's basically exactly what I need. Also I might rainbow the result with the txs that went into the raffle. This is both transparent for everyone and adds even more entropy. |
|
|
|
|
Again guys, I don't want to use any server secret, client/server seed technique and no external rng. This topic is specificly for using the information we got on the blockchain to generate solid & transparent random numbers. I think I got quiet a good idea for my project now, thanks.
|
|
|
|
Miners can potentially select the block hash to meet some characteristic. They'd do so at great cost, but that being a viable attack depends on what exactly you're using this for, what information is available to miners, etc. As soon as the current txs are confirmed (1), I need a provably fair 0-9 RNG. So my idea was to hmac the blockhash + something else (it can't be anything I control or know) and take the first digit the hmac produces and thats our winning number. Maybe I should just take the current blockhash (conf=1) + something of the last block (size/nonce/merkle/whatever) (conf=2). That would mean that miners need to manipulate 2 blocks in a row to rig the game. |
|
|
|
words Not sure if this is a troll or not but I will say this much: All I wanted to know is if the blockhash is totally random and can't possibly be known in advance, so I can use it as a transparent RNG seed, one guy said it sure is, so this issue is settled then. |
|
|
|
I just want it to be a full transparent RNG layer on top of the block chain.
And the usual method does not qualify? (I had hoped for a yes or no, with more info following in the case of yes.) In my oppinion the second the site operator knows more about the possible outcome than the user, they got the advantage. If that advantage is relevant for the RNG or even gets actively exploited doesn't matter, because the principle is the same. I just want my approach to be as transparent, seamless & integrated as possible, using the given bitcoin protocol. |
|
|
|
Could you describe a specific use case? i'm having a hard time imaging what the hmac_sha512 of a blockhash could be used for.
You could for instance take the first decimal via pregmatch and use it as a 0-9 RNG. My test script that I ran hundred of times (1 billion iterations each) verifies that it's evenly distributed 0-9 and no number is in favor. Since I think the nonce is fairly random Are you referring to the nonce in the block header? If so, it's not necessarily random (it's possible to mine with nonce set to a constant, for example), and it's certainly quite biased. Okay, how about taking the exact blocksize as the second secret then? That should be unguessable before the block gets found/generated?Then how would you know it beforehand to use it yourself? Not beforehand, the second a new block is found the information is there and I can use it for 1 conf txs. Are you familiar with the usual techniques existing sites use to accomplish "provably fair" ?
If so what is it about their method(s) that make them unsuitable for your use-case (and thus requires you to re-invent their apparently not so elegant after-all wheel)?
I just want it to be a full transparent RNG layer on top of the block chain. |
|
|
|
HMAC is usually used where the first argument is secret, and the "message" is the second argument.
You can use the blockhash, or the merkle root hash, both are random and practically unpredictable. The nonce for most gaming sites are usually incrementing, unless you are talking about the blockchain nonce used for that particular block.
The block time would be optional and not needed.
What is your intended purpose? Some game? You mention "Provably Fair". I personally like this kind of topic.
If you use public information for your RNG, then the results are predictable after the fact. This is good for games where the results are needed later, such as raffles or lottos. Not so much for games where you want the results now, such as dice games.
Yeah, in PHP it's the other way around  http://www.php.net/manual/en/function.hash-hmac.phpSo I could just hmac the blochhash and merkleroot and would get a non-predictable hash. That's good to know! I will run a couple of tests with merkleroots then. |
|
|
|
Could you describe a specific use case? i'm having a hard time imaging what the hmac_sha512 of a blockhash could be used for.
You could for instance take the first decimal via pregmatch and use it as a 0-9 RNG. My test script that I ran hundred of times (1 billion iterations each) verifies that it's evenly distributed 0-9 and no number is in favor. Since I think the nonce is fairly random Are you referring to the nonce in the block header? If so, it's not necessarily random (it's possible to mine with nonce set to a constant, for example), and it's certainly quite biased. Okay, how about taking the exact blocksize as the second secret then? That should be unguessable before the block gets found/generated? |
|
|
|
Hey guys, okay, first of all I'm new to this crypto stuff and I know the issue of "Provably Fair" has been discussed over and over again. Yet I haven't quiet found any definite answer to my approach. What I want to do is make the RNG more transparent by taking the information of the next/current block found (txconf=1). My approach so far looks like this: hmac_sha512($blockhash, $nonce) Since I think the nonce is fairly random and could never be guessed, using it as the secret would give me quiet a strong random variable which is also transparent at the same time. Now I read a lot of stuff about blockhashes tending towards lower numbers, so I should add something to the hash to make it even more random. Would you think adding the blocktime would make it even more random or isnt necessary: hmac_sha512($blockhash, $nonce+$blocktime) Cheers |
|
|
|
Hi
Payment will be done within 12 hours. We had some technical issues and made worse with staff illnesses.
Thanks for your patience.
Grab your popcorn ladies and gentlemen, this is going to get interesting.  |
|
|
|
Is this the reason the $/฿ price dropped like 10% over the last few hours?
If this thing is real, i would suspect your theory is correct. They will be taking a shitload of money out of the BTC economy! Ouch! Imagine if they build themselves a dozen or more?  This particular setup isn't any different than just buying 13 CoinTerra TerraMiner IV's at $13k each. That will set you back $169k for 26 TH, shipping in December. The VMC Fast-One Platinum 25 TH will cost $353k (you need 6 expansion cases), and it also ships in December. They must be targeting this at people who don't know how to use Google... PS: Faster mining doesn't affect the price of BTC. 25 BTC's are generated every 5 to 10 minutes, regardless of the speed of the network. Fast mining just affects other miners. They ship in january. Also you need a powerline that can supply 20kWatt.... Their machines are way overpriced for the performance they are bringing imho |
|
|
|
Sieht ja schick aus! Nur fallen mir 14 Dinge auf die dort fehlen.... |
|
|
|
There is no escrow, such as John K, for this, correct?
JohnK has verified my identity and my details will be released in case of any defaults
Then you should have no problem with accepting John K as full escrow, to hold the coins until the miner is verified as up and running by John K. If this is no problem for you I would be happy to invest some coins into your project, sir. |
|
|
|
Was ist das momentan kann man da schon wieder von einem abwärtstrend reden? Will diesmal nicht zu spät verkaufen Na dann warte mal Donnerstag bzw. das Wochenende ab.... |
|
|
|
Wieso bekommt rrrix für 12 shares 7,36% vom Pool und jemand der für 12 neu einsteigt nur 4,8%?
Die Anzahl der Tot. Shares ist massgebend, wie ich anfänglich im Projekt erwähnt habe ... werden bei jeder weiteren Investition Anteile, als Bonus ausgezahlt. Das wird wieder der Fall sein wenn diese restlichen 12 Shares weg sind. -> Quintessenz: Früher investieren lohnt sich!
Ich glaube nach dieser "Punktlandung+" von BitFury bezüglich Termin & Leistung, können wir davon ausgehen das auch die kommenden 225 GH zeitlich geliefert werden. Das Risiko wie es anfangs des Projektes bestand ist nun geringer. Der Bonus widerspiegelt einen fairen Entgelt für das Vertrauen das Sie mir bereits anfangs des Projektes geschenkt haben. Alles klar, klingt logisch und fair. Hut ab für ein bis jetzt sauberes Projekt. |
|
|
|
|
Show Posts
