Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - arubi

Pages: [1] 2 3 4 5 6 7 8 ... 14
1
Here's to hoping we don't end up with another one of those..
http://arstechnica.com/information-technology/2009/04/oracle-acquires-sun-ars-explores-the-impact-on-open-source/


All the best, Daniel and team. I'll either want to hug you all or forget all your names after this is all over and done.

2
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.

3
General Discussion / Re: [Wiki] Chainservers
« on: March 26, 2015, 04:11:40 pm »
Does anyone know how much bandwidth these take up on average?
I might run one if its not /too/ demanding.

4
General Discussion / Re: BTS 0.8.1 is forking
« on: March 26, 2015, 03:38:24 pm »

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.

5
General Discussion / Re: BTS 0.8.1 is forking
« on: March 26, 2015, 02:10:19 pm »
how do I know if I'm on the wrong chain?

That's what I get:
Code: [Select]
"blockchain_average_delegate_participation": "90.99 %"
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

That's correct.  It doesn't mean that it is switching to that fork, it just means it has connected to someone with the fork and it will start downloading and indexing those blocks until it hits the first one it considers invalid, then it disconnects.

I've made a checkpoints.json here with ~hourly checkpoints since the last hard fork.  None of my clients have yet wandered off onto a minority fork so I'm not sure where things are going astray.  Depending on when the minority fork(s?) appeared and how many blocks they contain, one checkpoint might not be enough to force your client to sync to the right fork.  I *think* the json file hash enough checkpoints that you could reindex instead of redownload, but I'd just as soon download from scratch.

I still don't understand why minority fork clients don't just discard whatever short chain they're on and join the main chain where we have >90% delegates participation. We can't rely on checkpoints for long :(

6
General Discussion / Re: BTS 0.8.1 is forking
« on: March 26, 2015, 12:22:43 pm »
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

7
General Discussion / Re: BTS 0.8.1 is forking
« on: March 25, 2015, 11:59:30 am »
Why is this a problem?
Isn't this the perfect time to hire some delegates?  :D

8
DAC PLAY / Re: Decentralized Poker Research
« on: February 21, 2015, 10:45:33 am »
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?

9
DAC PLAY / Re: Decentralized Poker Research
« on: February 20, 2015, 09:21:23 am »
This has been a dream of mine since last year :)

10
General Discussion / Re: BitShares 0.6.1 Feedback
« on: February 13, 2015, 09:18:31 am »
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.

11
General Discussion / Re: Import PTS wallet from a year ago
« on: January 10, 2015, 09:28:09 am »
Hi

No problem for the delay :-)
I am running the OSX version so I can't manually delete and re-download the blockchain?

You can.
I don't have access to an osx machine at the moment. If I had to guess I'd say the folders chain and peers.leveldb are at:

Code: [Select]
~/Library/Application Support/BitShares
So navigate there, and delete only chain and peers.leveldb.
To be on the safe side, you could make a copy of the entire BitShares folder on your desktop before deleting anything.
Then just re-launch the client.

12
General Discussion / Re: Import PTS wallet from a year ago
« on: January 09, 2015, 06:44:49 pm »
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:

Code: [Select]
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

13
General Discussion / Re: Import PTS wallet from a year ago
« on: January 06, 2015, 12:24:19 pm »
--resync-blockchain is a flag.
It's used as an option when calling the Bitshares executable.

For example, on linux:

Code: [Select]
./bitshares_client --resync-blockchain
Also, 0.4.27.1 is not the latest release:
https://github.com/BitShares/bitshares/releases


14
General Discussion / Re: Import PTS wallet from a year ago
« on: January 05, 2015, 02:17:10 pm »
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
Code: [Select]
--resync-blockchainFlag.

15
General Discussion / Re: Import PTS wallet from a year ago
« on: January 04, 2015, 02:11:08 pm »
Can you (both) try issuing a rescan?
From the console:

Code: [Select]
rescan

Pages: [1] 2 3 4 5 6 7 8 ... 14