Why not?
I mean players who bet real Money, why would they not accept that the game is revealed at the end of the game?

If we say this then: When everyone has left the table, and the table is empty, AND the game is finished, then the game is revealed.

OK can find it acceptable that the random table join is not a good idea, but at least make sure only one running game per IP is allowed.
If the tables are large enough, it wont be possibe to deduce the unknown player's cards by collusion.

And why require accounts? It would be better with this:
1: You go to lets say wwww.dabsbitcoinpoker.com.
2: Then a bitcoin adress appears. Send your total bet (chips you want to purchase).
3: Once transaction appears on network, Your poker identity = Your bitcoin adress.
4: You can now proceed to select table and play poker.

All deck hashes are avaiable on the site, and maybe deck selected is based on all partipicants bitcoin adresses.

Leaving the site (by X in the corner) or any other means, will cashout your current chips provided that theres enough confirmations.
This will simply send all Money you have to your bitcoin adress.

Detecting leave, can be done in a multiple ways, but a easy way is to have some resource which refresh each 30 second, which reset a timer on 300 seconds.
if timer of 300 seconds goes to 0, player has leaved.


When the table is completely empty and all games at that table is finished, the game log including all revealed cards, are made available on site.

A poker player who uses a strategy he don't want to reveal, because it can be countered easly, can easly launder his bitcoin coins, to hide his prior poker identity, and then
join the poker with a new adress. Then any player who play against him, wont know that "hey its that player with the easy strategy".

gmaxwell: Thats why the deck needs to be generated long Before any player enters the party.

Since the "house" does not know who is gonna play when he generates the deck, still same security is given.
Another random numbers can be txids and such.

This to be able to provide sufficent security for user, even if all that is provided to user is a bitcoin adress to put in her bet on.

gmaxwell: Its a better idea to use the player's bitcoin adresses as randoms. That of course means the decks need to be generated Before any player joins the party.

Another important thing is that the player's positions in table needs to be randomed too. If the player joins a game, is assigned a table at random, is assigned a random position, and the table using a random deck, and each IP can only have one single running game at the same time.

Everything is provable cryptographically.

Then theres no collusion, chipdumping or anything, that can make the experience bad for any other player. Its simply not possible to colluse with other players to reveal unknown player's cards.

Dabs: Whats the problem with revealing the whole poker deck, and all other playe's cards, after the game is completed?

Now I mean when the WHOLE game is over. For a single poker session, one game = one deck.
In this simple case - reveal the deck after game is finished OR reveal all decks after day's end.
With "whole game over", is that this game must be done, nothing from this game may affect later games.
This means the game is consisted of completed when any player is free to leave any time.

In a competition, one game = multiple decks, where one single game consisting of say 100 entrants that are ejected one by one until theres one Winner left, can consist of multiple "sessions" with one deck each.
In a competition, its a forfeit to leave the game Before one single Winner is selected, and thus, all games affect all future games.

Thus if you want to hold a competition, use a other "deck secret" for this that are kept aside from "public" matches, that are kept secret until competition end.



To prevent people Learning other's strategies, you could make it so only a bitcoin adress is needed to join (like satoshidice), and people are advised to use a new bitcoin adress each game, so each game is Anonymous.
About chipdumping and collusion, its nothing to worry about, since chipdumping is only a problem in a economy where Money-launderying is non-permitted. In bitcoin economy, people are encouraged to Money-launder, to keep transactions Anonymous, so using your poker game to "chipdump" can be Another idea for such people who want high anonymity.


To prevent large scale collusion, where one single entrant may enter the game under multiple identities so theres only one foregin player, to then be able to find out the player's cards based on their own, make this:
1: No player can select a table, every player are assigned a table at random.
2: Each player can only be in one game concurrently, and this is identified by IP. You can hash the IP for anonymity.

A idea is simply to create a game-specific secret, which are unique per gaming session, and card secret.

for example, the game-specific secret could be some random letters + the unix time of the game start. The random letters are unique for each game.
Then you PUBLISH the hashes of the whole deck.
The hashes is sha256(game-secret + card-symbol + card-number)

example, for aces of spades: sha256("lsjldslggdljdg1377684944SA")
example, for 5th of hearts: sha256("lsjldslggdljdg1377684944H5")
example, for king of diamonds: sha256("lsjldslggdljdg1377684944DK")
example, for queen of clubs: sha256("lsjldslggdljdg1377684944CQ")

So simply, you publish the hashes of the whole deck at game start. Nobody knows the content of the deck unless they can crack the random letters "lsjldslggdljdg". Thus the random letters need to be longer than in this example.

Any player are free to save the list of hashes.
All hidden cards should also display its hash, so your opponents cards will show the hashes.
Your cards will show hashes + the actual card value.

And the game should be recorded in a step-by-step file with all cards revealed. This file is stored on server.


When the game is over, and revelation of this game do not have any consequences to the outcome, you simply reveal the game-secret.
Every player who have saved the list of hashes to their computer or on paper or whatsoever, can validate that the deck randomization was not changed during the game.

The step-by-step file, is also revealed at game end, where player, can step the completed game step-by-step, but with all cards revealed.
Thus the player can validate that the game was conducted in a fair manner.


If multiple rounds are gonna being played before any game can be revealed, you can have deck serialization numbers:
example, for queen of clubs: sha256("lsjldslggdljdg1377684944CQ01")
01 means deck 01.
when next round is gonna played, you simply randomize a new deck, which will be called 02.



You could even have a daily secret like satoshidice has, so all decks for the next day's games is prepared one day before, and hashed being published.
And yesterday's secret is being published, proving that the deck for all the games during that day couldn't be changed without any noticing.
Then you would propably need 6-digit deck IDs, but then its even harder to cheat, since the decks are randomized daily.

To maintain security, you would need to have a way to determite player order. A good idea is to take the bitcoin adress, and give each player a position in the table that is equal to the numeric value of their bitcoin adress, so a player with adress 11111111111111111111111111111111111 will get their turn before a player with adress 1ZZZZZZZZZZZZZZZZZZZZZZZZZZZZ effectively making the order random.

Can be 2 causes:

1: Certain clients use these transactions as "ping" or "keepalive" to make sure NATs do not tear down the Connection due to inactivity.
2: Malwritten clients, when served with a amount to send = 0 BTC by the end user (propably by mistake, user simply forgot to enter amount), do not validate that the clients amount exceed 0 Before attempting to create a transaction. When the client attempt to create the transaction, it finds out that theres no need for inputs anymore ("do until"-loop) because the amount has been fulfilled. And theres no outputs to add, because the client automatically deletes any outputs with amount=0.
Then it ends up with a "empty" transaction, and sends the "empty" transaction.

Those transactions should not harm the network, since each client can only "hold" one such transaction at one time, since its not unique. So its not possible to "flood" a client with such transactions since it will only store one copy of each transaction newertless.

So each block will only store one single copy of these transactions, and each client will only store one such transaction in memory.

So maybe its not a bad idea to keep the possibility for these transactions since they propably fulfil a function to keep holes in NAT open.

TiagoTiago: No. Revealing or breaking ECDSA in bitcoin does not help anything to reveal anyone's identitity, worse, it would make it even harder to track since 2 users of same wallet make it harder to correlate who owns the wallet.
The anonymity lies in that the correlation between the wallet and the user is unknown. The anonymity is NOT dependant of the secrety of the private key.

The only thing that is dependant of the secrety of the private key, is the safety and ownership of the coins. Eg, if the private key leaks, someone can steal your coins, but nobody can reveal your identity.



smolen: Given that SHA256 is fully safe, the resulting number can be seen as a random value itself. Its not possible to solve for anything in SHA256, since SHA256 is essentially a modulus function, and a modulus function has unlimited number of inputs for a given output.
So a such change is safe. And its not possible to get the counter value and correlate transactions, even if the privkey is stolen. Not even if you know the latest counter value (eg if someone's device is stolen) , since the random value is unknown.
And as you know, there is larger problems than correlated transactions, if the private key is stolen.


So lets implement the change Nonce: sha256(message||privkey||random||counter), that would make the system 100% guranteed safe.
That could be part of the bitcoin specification, so all coders that write a bitcoin client automatically do this by "default".

now I understand fully...

I misintepreted your post in the beginning of the thread, that the CURRENT technology was that nonce was generated as sha256(message||privkey||Random).
And that had been "cracked" due to bad RNGs.


So if I understand your correctly, the developers have did just nonce = Random_value, where Random_value come from a bad RNG?

gmaxwell:
Then, what causes the privkey to be revealed? (What this thread is about)

What I have understand, is that if the nonce are reused in a ECDSA signature, the privkey can be calculated, given that you know that the 2 nonces are equal, even if the nonce is unknown, since you simply solve a equation to get the privkey?

since nonce = sha256(message||privkey||random), this means, for nonce to be equal in 2 signatures, message must be identical, privkey must be identical, and the random value must be identical.
So when the bad RNG reuses a random value, for a identical transaction, the privkey can be calculated?

The thing that affects is then that if 2 identical transactions are posted, (same amount and same input and output) then you reveal your privkey.

So I Think that its what happened in android here, identical transactions (m1 == m2) + identical privkey (k1 == k2) and bad RNG (R1 == R2) causes system to generate identical nonces. since sha256(m1||k1||R1) == sha256(m2||k2||R2) if m1 == m2, k1 == k2 and R1 == R2.

if R is then a simple counter, it gurantees against bad RNGs.


Maybe a better idea:

Make nonce be: sha256(message||privkey||random||counter), and "counter" is stored locally.
If RNG is bad/frozen/behaving strange/reusing random numbers, then counter will prevent same nonce from be reused, since its incremented for each transaction, and stored locally.

counter does not need to be published or stored centrally, since its extremely unlikely that 2 RNGs in 2 different clients, generate the same random number for the same transaction, even if the RNGs are extremely bad.

gmaxwell: how? I Think I misused the term "nonce" in my previous text, I mean the random value that is used in nonce calculation, that may not be reused.

If nonce is selected as sha256(message||privkey||R), and you can guess R, you would still need the message (known) and the privkey (secret) to compute the privkey?
so it would be a moment 22 for the attacker?

So then, solving for the private key when one msg is signed with sha256(message||privkey||R) and the other is signed with sha256(message||privkey||R+1), would be impossible unless you can break sha256 in a way allowing solving for privkey?


The flaw here was that if 2 R's was equal, you wouldn't need to compute the unknown value, like solving 2 equations with a unknown, but equal solution X.


Or is it something I have missed?

But if nonce is selected as "sha256(message||privkey||random value)", you actually don't need a random value.
You can use a simple static 256 bit counter. That would gurantee that no value is ever reused.



What i understand, it does not matter if anyone can guess the nonce, the privkey can ONLY be recovered if 2 signatures share the same nonce.

If then, the counter value could even be published in the transaction, so if multiple clients share the same wallet, they still don't generate conflicting nonces. (The client only search backwards until it reach one of its own transactions, increments that counter with +1 and then signs it own transaction.

Email can in fact be authenticated securely.

I have for example authentication set up for my outgoing mail. Try doing a TXT lookup for "sebbe.eu" and you will se this: "v=spf1 +mx -all"
This means:
"Only accept email originating from a sebbe.eu domain that is sent from a mailserver that has the IP set as the A records for the domains in my MX records, in other ways - dns1.sebbe.eu (193.13.142.178) or dns2.sebbe.eu (46.59.86.163)"

Also DKIM is a Another email authentication system based on signing.

And don't get me wrong. Rerouting emails in transit will change its origin - thus SPF will fail. Only way to "fake" a SPF message is to modify it WHILE in transit, and thats much harder, since you would need access to one Point in the path between mailservers. And thats not a easy thing. Modifying a email over for example Wifi are not being viable for attackers, since the customer needs to download a "Merchant Email Bill" just in the same time as the attacker sits on the same Wifi.

Normally, your upstream server (your incoming SMTP) authenticates mail, but you can also authenticate mails yourself - provided that you trust your email provider's server to insert a Received:-line in the mail, for example if your email provider does not authenticate SPF.
The topmost Received:-line is then trustworthy, and the rest of them should be considered spoofed.
DKIM can be authenticated locally without any trust for your mail provider.

DNS based authentication can also be used for Bitcoin - just put up a TXT record with the bitcoin adress. The bitcoin client could have a extension so upon receiving a domain name as adress - lookup in TXT record and picks the first valid bitcoin adress it gets.
Merchants could simply publish per-customer domains, like "Sebastian_nielsen.customer.thismerchant.com" that will Point to the merchant's payment adress for my order.

The main idea is not to protect copyrighted work or proof that a idea existed in Before, since you only proof that your work existed at time T, but you cannot proof that anyone other work similiar to your work DID NOT exist at T-x. For that, we would need every work to be timestamped, which would require a law change that states that copyright or patent is invalid without a certified timestamp.

Rather, its to securely proof that data was unchanged at a specific Point of time.


Examples where timestamping can be very useful:
Corporate bookkeeping: For example here in sweden, Bookkeeping requires a software that MUST be closed-source, to be able to proof that data was unchanged at a specific Point of time. If we instead cryptographically proof it, it cant be changed without detection.

Physical contracts: It can be good to have certified time on contracts to proof that the contract was established for example Before a ID-card was revoked/barred/expired. Because if the ID-card was revoked/barred/expired at the Point of establishment, the contract can be invalid per the law. Certifying a contract can be done by for example scanning it, timestamping it and then saving the image file as proof, while still keeping the original.
Signing at "Sign with name and date" is not enough in some cases, contracts can be back-signed (by the issuer by prefilling the date, to be able to establish the contract knowing that the ID-card is stolen) or future-signed (by the signer, to be able to protest the contract after barring the ID-card as stolen). If the issuer timestamp the received signed contract, there will be clear proof that the signer future-signed it, and the signer can easly protest a back-signed contract that lacks a timestamp if all other contracts by the issuer bear a timestamp.

Digital contracts: Here the same thing - but with revoking or expiration of private keys that is the key Point here.

No.
Thats what many shops sells today. "gift cards" are they called, and for the gift card, they promise to give you Products of value in return.
So essentially, gift cards are "bearer bonds".

However, the legisation around ANYTHING value-filled (even a metro card), is pretty harsh in EU, and you need to Know your customer and be viligant against Money laundering and financying of terrorism.

Another security idea is to use a printer which support on-site Printing, eg you put a Picture or PDF on a USB or SD card, and then you print with the printer "stand alone".

Many printers today have the capatibility to print files from a USB or SD card.

Since the computer cannot know which off-line stand-alone printer you use, the risk of getting a "fake firmware update" is negligible. Many printers also have a sequence that needs to be triggered Before it will accept a firmware upload via USB/SD, so its completely secure. For example Power on the printer with the firmware update USB/SD inserted. So never turn on the printer with a SD or USB inserted to be on the safe side.


For a leak to sucessfully travel from your printer to internet, the printer would have to "infect" the usb with a autorun software containing the private key AND a "payload" that transmits the private key home. And for such infection to exist in the printer, it would have to travel from computer to printer via USB/SD, and for that to happen, the printer must be able to receive software updates arbitary via USB and the computer needs to know the exact model of your printer.

Yes its because nobody uses the promise, therefore it could be removed without any notice.
The promise was required in the history to assert that the trustee did not "produce" more "notes" than gold/silver. They knew that if there was any doubt in the value of the note, they could simply go to the trustee and exchange the note back to gold/silver, and if there would be more notes than gold/silver, the trustee would lose reputation very fast and nobody would trust those notes anymore.

Basically a IOU translation between gold/silver and money.
Basically, the promise would be used by those that had any doubts on the values of the notes. Since everyone trust the notes today (as opposed to history), theres no need for a bearer promise backend.

Currently, instead, people trust the state and government, and thus the money does have value since the state/government produces money with a specified rate, and thus, people find value in money since they are rare. In other words, the bearer promise does not have any value today. In the same way, Bitcoin is a democratic system where all the partipicants of the bitcoin network regulate the creation rate of "notes" collectively.
Even tought the bank would not satisfy the promise, you could always go to a jewellry shop to get your notes translated into gold or silver.
Same with the digits stored in a bank's computer. Those digits have value since the state/government regulates the system so no bank could create "fake" money. If they would, they would lose the bank license.

Actually, the promises are not false, they just have superseded the bearer promise since nobody today uses it.
I think it would in actually get the promise gone through but that would propably require much paperwork and application fees.

The bearer promise come from the history. In the history, you paid by using gold bars, gold coins, metal weights and such, that had a real value. It become a bit unpractical to pay things by gold and such since it was heavy.

Instead the buyer went to a place which both the seller and buyer trusted, and traded the gold for a paper slip that said "I promise to pay whoever that gives me this paper slip, 100 grams of gold". And voilá, the paper slip got the same value as 100 grams of gold.

That was how paper notes was "invented". Since there was many different trustees and hard to work out whichever a seller could trust, the government launched a paper note system with the same inner workings, that everyone could trust.

And in the late decenniums, the "bearer promise" does not have any meaning today, people trust the currency because its rare - like gold, exact in the same way as people trust bitcoins, because they are rare, not because they are backed by something. In other words, the history banknotes had value because they was tied to gold somewhere, today's banknotes have value in itself, like bitcoins.
So basically, both bitcoins and banknotes have the value in itself like gold!

retep: You can always pad the git ID with 24 zeroes to get it 256bit:

Here is the gitID of Webconverger 18.0 padded with 24 zeroes:
57437d19b849af2622850a27f6e065afeede54dc000000000000000000000000

what the OP means, is that if you go to <someone> and buys coins, and then use these coins to buy goods and services - thats OK without FinCEN reg, regardless of the <someone>'s FinCEN reg status.
If you go to <someone> and buy coin, save then, and the sell them again to <someone>, you are trading in speculative purpose and its OK without FinCEN reg - as long as <someone> is FinCEN registred.

However if you mine X coins, and then sell them to MtGox, you need a FinCEN reg.
And if you sell your stereo for X bitcoins, and then sell to MtGox, you also need a FinCEN reg.

Bitcoins are fungible, so FinCEN does not care if you take your 10 mined bitcoins and sell back to MtGox when you have bougt 10 bitcoins from MtGox.
However, you are allowed to mine X bitcoins and purchase good/services for that, except services that can be expressed in real currency, like store gift cards, prepaid cards, mobile top-ups and such.

What FinCEN cares about, is that you DONT sell more bitcoins for real currency than you buy for real currency!

So in short:
If you have goods/services to sell, you are allowed to do that. The Bitcoins for those goods/services may NOT be exchanged to real currency or any good/service that can be expressed in real currency.

If you have Money, you are allowed to buy bitcoins for that Money by anyone. That bitcoins may only be sold to the same person/entity as long as the person has FinCEN registration. Only purchasing bitcoins does not require FinCEN reg at all.

If you have Bitcoins, you are allowed to buy any goods/services for this - EXCEPT goods/services that can be expressed in real currency. In this category, is present, but NOT limited to:
-Store gift cards
-Game cards, Wii Points cards, such*
-Prepaid VISA cards
-Mobile Top-ups*
-Gold, Silver, Oil, and other materials that can be expressed in real currency
-Bonds/shares
-Currency valid in any country
-Discount coupons expressed in a fixed value. (For example, a coupon that gives 1$ off a burger king burger may not be bought with bitcoin without FinCEN reg, but a coupon that gives 10% off is allowed)

* (Only if these are expressed in a currency. A mobile top-up that gives free calls and internet for 30 Days is OK to buy. Same with a game card that gives item X, that does not have a set store price. But a mobile topup for 10$ = forbidden. A game card that gives 50$ ingame store = forbidden.)

If you have Bitcoins, you are also allowed to sell them to a FinCEN registred entity, but ONLY if you bought the bitcoins from the EXACT same entity. However, since bitcoins are fungible, it does not matter which coins (eg which outputs) you use.