Ugh.

$ ps -xv | grep bitshares
 2797 pts/6    Sl+   18:01   4478 33385 1064798 955000 46.4 bitshares_client --server --httpport 9989

$ ps -xv | grep bitcoind
 6659 ?        Ssl  112:09   1230  4509 742338 595268 28.9 bitcoind

Both are accepting a maximum of 8 connections + both are not accepting incoming connections*
Bitshares also runs an http daemon (sure, it's technically nothing) but an extra 400~ MB in ram is acceptable (swap is set to 0 in this machine)

* - Don't worry, I have a different machine for seeding Bitcoin and Bitshares. I'm doing my part

--

Oh, if you're interested what the "research" machine's stats are:

$ ps -xv | grep bitshares
 2341 pts/1    Sl+    6:02  24446 34648 2913743 1160992 14.1 bitshares_client --statistics-enabled --server --httpport 9989

$ ps -xv | grep bitcoind
11852 ?        SLsl  71:12   5032  4865 2020482 892552 10.8 bitcoind

* - This still isn't the seed machine. Both instances are full indexing nodes. Bitshares also runs the http daemon. Both are connected to 8 peers. No incoming connections.

--

Oh! I forgot to add, bitcoind listens as an RPC server in both instances.

We only save the undo state for about an hour's worth of blocks (maintaining it is expensive).  For short forks this works out well, but if you get on a fork with >360 blocks on it, you won't have enough undo history available to roll your blockchain back to the fork point, thus you'll never be able to rejoin the main chain even if your client knows it is better and has downloaded all the blocks on the main chain.  If you don't have the undo history to get there, the only other way to get back to the fork point is to reindex or re-download the blockchain from the beginning.  And when re-downloading, as long as there are publicly-accessible nodes out there serving up the wrong blockchain, there's a chance you'll connect to them first and download the wrong blockchain and end up back in the same state, unless you force your client to reject the wrong chain with checkpoints.  Fortunately, as more public clients switch over to the main chain, the chance anyone will end up syncing to a minority fork decreases.

I see. Thanks.
Hopefully in the future clients could perform a re-index from a specific block height (like Bitcoin's re-org) on their own without the user's intervention.

Not quite sure what is going on with my delegate, got this in the output:

Code: [Select]

--- there are now 44 active connections to the p2p network
--- syncing with p2p network, 13991 blocks left to fetch
--- in sync with p2p network
--- syncing with p2p network, 121260 blocks left to fetch
--- in sync with p2p network

which suggests it's having trouble trying to figure out which fork to sync to, yet info returns this:

Code: [Select]

  "blockchain_average_delegate_participation": "83.47 %",
which seems to imply its on the main fork...

I'm seeing this too. My guess is that forked clients want to tell us about their alternative chain and our client drops the connection once it sees their chain is alternative to our own

Seems like we all pretty much agree that decentralized poker is possible.
Can we list some reasons why is might be impossible \ too fragile?

By impossible I mean, for example, if there's no way to:

• Deal a deck
• Play a hand
• Pay the winner(s)

Without relaying on a trusted party \ arbitrator (which is not chosen randomly from within the party) \ oracle.

So far it seems that dealing a deck has more or less been solved. If a group of nodes on the network can somehow decide they all want to play a hand together, then dealing a deck between themselves and then knowing which of their secret keys goes to which player is possible.
I don't know enough about Cryptography to know which encryption function will be safe to use though. One reason "Dealing a deck" might be impossible is if there isn't a function that works properly for this use case.


Playing a hand is also easy assuming we have an encryption function that works.
All players should follow the rules of the game, so all players should know which of their private keys they need to publish so all players could see the correct cards for the flop, turn and river.
The hard parts are:

• Betting
• Player drop

Betting is pretty hard. Where do the bets go?
Bitshares is cool since it kinda provides a mechanism for locking value in the blockchain and later release it given some conditions. A reason why this might not be usable is if all parties would require their own fork of the blockchain, since that would mean they now have to delegate it themselves, and that means an easily attackable chain.
Note: Relaying on delegates in this case does not mean using oracles. The entire economy of the decentralized poker room is internal. There's no need to fetch information from outside.

Player drops is a major problem for this protocol. A paper linked in this thread:
Dropout-Tolerant TTP-Free Mental Poker
Looks promising.


Now that we've played a hand, we need to pay the winners.
In normal, real life poker, the bets would be on the center of the table and the winning player(s) would take his\their share. If someone tries to steal from the pot or not pay his share when he loses, there is a physical solution to make him pay.
On the network, bets would have to be released to the winners from a state where they are not reachable to anyone (not delegates, not other players, not the player himself), and the release mechanism should be able to figure out, from a given hand of poker, who the winners of the hand are and to release the funds to them (taking into account all side pots, differences in all-ins, etc.)

Decentralized poker is difficult. Relaxing even a single item on this list would mean that the game is no longer purely decentralized and that would unfortunately mean there is no major advantage over the current online casinos.

Thoughts?

CLI works as expected. Always nice to see new commands.

I like the new GUI, but I have a couple of issues:

1.
The GUI on Firefox is dead slow. I see a constant 100% CPU usage when the gui is loaded in firefox. Chrome handles it very well though.

Linux Mint 17.1
Firefox version 35.0.1
Build identifier: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0

2.
When first unlocking (going past the welcome screen), the main account in the wallet is active (shown on the upper right corner near the "Lock" button). This is expected, but after clicking on the main account and choosing a different active account, now the only way to go back to the main account is only possible by going to the Dashboard and actually clicking the main account on the Accounts list. IMO it should also be available from the drop down on the upper right like all other accounts.

Sorry guys, between work and finals at uni. I just can't find the time to log into the forum and reply.

If you can't run --blockchain-resync , then you'll have to manually delete the blockchain and re-download.
On windows the blocks are found at:

C:\Users\UserName\AppData\Roaming\BitShares\
(change Username to your own username)
Delete the folders:

• chain

• peers.leveldb

And re-launch.

DO NOT DELETE THE wallets FOLDER

Quote from: Peiming on January 05, 2015, 04:55:10 am

The balance is still 0 after a rescan. However, I noticed the following error notification:

signature is not canonical

You are either using an old client version, or you are on an old fork of the chain. Upgrade your client and re-sync.

Yep. ^^
After upgrading, re-sync by running the software with the
--resync-blockchainFlag.