Show Posts

1516

Technical Support / Re: The potential for DDoS in DPOS

« on: December 10, 2014, 10:37:46 am »

Quote from: Riverhead on December 10, 2014, 10:16:18 am

Svk pretty much said it. Since delegates are just block signers and not miners it's easy to abandon a host under attack and switch to the failover. For a ddos attack to be effective they'd need to hit literally dozens of delegates at the same time. The network would then slow down for a few minutes while the delegates brought up new hosts.

It might be worse than you think. Typically hosting companies will actually remove the server under attack from their network in order to preserve their other customer's service. Then the control is out of the hands of the delegate under attack.

1517

Technical Support / Re: Time format changed in v0.4.25-RC1 RPC API?

« on: December 10, 2014, 09:46:59 am »

Quote from: svk on December 10, 2014, 09:10:32 am

Will start updating my backend to handle this later today, hope it won't break everything.. I used moment.js to parse the old date format, might just be a case of updating my parser function I guess.

What I did was to check the length of the string, if it was too short to be ISO standard, I parse it manually, as you have - if not, send it to the regular system date parser. That way you handle both cases

1518

Technical Support / Re: Best way to tell if transaction is a deposit via RPC?

« on: December 09, 2014, 08:52:38 pm »

Quote from: vikram on December 09, 2014, 08:35:56 pm

Depends what you mean by deposit?

The individual operations you see from something like blockchain_get_transaction represent exactly what happened to the DAC.

My difficulty was in understanding which was a deposit to my account (deposit from their account) and which was a withdraw from my account (withdraw from their account).

1519

Technical Support / Re: Best way to tell if transaction is a deposit via RPC?

« on: December 09, 2014, 08:10:14 pm »

Quote from: jsidhu on December 09, 2014, 06:21:33 pm

the toaccount of wallet_account_transaction_history will tell you it was sent to you (thus deposit). This list will only update if wallet is unlocked.

If you register your own account the to and from are both you inside the transaction, so this rule doesn't quite work

1520

Technical Support / Re: Time format changed in v0.4.25-RC1 RPC API?

« on: December 09, 2014, 08:01:55 pm »

Quote from: abit on December 09, 2014, 06:07:38 pm

For example,
with v0.4.24, "last_update": "20141208T051234"
Now, "last_update": "2014-12-08T05:12:34"

Woohoo! ISO correctness

1521

Technical Support / Best way to tell if transaction is a deposit via RPC?

« on: December 09, 2014, 11:18:46 am »

I'm trying to find the best way to determine whether a given transaction is a deposit.

Using wallet_account_transaction_history, we have a structure returned which contains multiple ledger entries and I'm not sure if you could have both a deposit and a withdraw inside that array?

Using blockchain_get_transaction we have an array of 'operations' inside the 'trx' field which typically contains both withdraw_op_type and deposit_op_type.

Is there an easy way to tell whether a given transaction is a deposit? Just some clarity on the subject would be great

Cheers, Paul.

1522

Technical Support / Re: Market of Interest Rates

« on: December 09, 2014, 09:15:09 am »

Quote from: RenaudGagne on December 09, 2014, 06:32:31 am

I want to have a portion of my portfolio in bitUSD and BTS to earn interest.

Now, how do I know which bitasset has the highest rate?

Btw, that it a HUGE selling point ;-) I never bought crypto before and that is what moved the needle for me.

The term is 'yield' and it's not quite the same as an interest rate exactly, although you are rewarded for holding currency. Yield comes from the interest that short trades pay for borrowing BTS. So, the market with the most volume would have the most yield. Yield is only paid on the bitAssets, not on BTS.

1523

General Discussion / Re: Feeds - why do you vote for delegates without feeds?

« on: December 08, 2014, 10:35:15 pm »

Quote from: clayop on December 08, 2014, 09:49:08 pm

To publish feed, do we need to pay fees?

Yes, each publish is a transaction.

1524

Stakeholder Proposals / Re: avoiding delegate downtime while upgrading client

« on: December 08, 2014, 08:02:12 pm »

Upgrade went smooth enough after shutting down the main client - no reindexing was needed this time.

1525

Stakeholder Proposals / Re: avoiding delegate downtime while upgrading client

« on: December 08, 2014, 06:53:06 pm »

Hmmm, after building the latest and running the client (with the current delegate still going) I get this:

Code: [Select]

 ./bitshares_client
Loading blockchain from: /root/.BitShares/chain
Loading config from file: /root/.BitShares/config.json
------------ error --------------
10 assert_exception: Assert Exception
_map->is_open(): Database is not open!

1526

Stakeholder Proposals / Re: avoiding delegate downtime while upgrading client

« on: December 08, 2014, 05:02:34 pm »

Quote from: xeroc on December 08, 2014, 04:50:40 pm

be reminded that sometimes the database has to be reindex when restarting the client after an update .. that reindex might take longer than a round of delegates

Hmm, I don't fancy re-indexing the DB on one build while the other is producing blocks, surely that's a recipe for disaster?

1527

Stakeholder Proposals / Re: avoiding delegate downtime while upgrading client

« on: December 08, 2014, 04:43:13 pm »

Thanks, guys

1528

Stakeholder Proposals / avoiding delegate downtime while upgrading client

« on: December 08, 2014, 04:22:44 pm »

What is the best way to avoid delegate downtime while upgrading the bitshares client?

Is there a way to know when you've just produced a block, to give you maximum time before your turn comes around again?

1529