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 - pc

Pages: 1 ... 20 21 22 23 24 25 26 [27] 28 29 30 31 32 33 34 ... 102
391
Beyond Bitcoin [closed] / Re: How to Obtain BROWNIE POINTS.
« on: August 07, 2017, 07:33:20 pm »
Brownie points are a UIA given away by Dan Larimer to people who he felt deserved them. That is all. No promises were made that they would be useful for anything at any time, and he can take them back whenever he wants.

392
General Discussion / Re: [Public Testnet] testnet.bitshares.eu
« on: August 04, 2017, 05:03:18 pm »
I did not find any explanation how the settings related to account history affect the functionality of the node.
Does it affect witness? block generation? API operations?

These settings don't affect block generation. But you only query the account history for those accounts that you track, so some API operations are affected.

Why in the hell the node should keep so much data _in memory_ by default?

For speed, mostly.

393
Openledger / Re: What Is a Sharedrop?
« on: August 04, 2017, 04:39:56 pm »
A sharedrop is a giveaway of some tokens to a certain group of people, for example to all BTS owners in proportion to their holdings.

394
General Discussion / Re: [Public Testnet] testnet.bitshares.eu
« on: August 03, 2017, 06:49:54 pm »
You must get voted in before you can sign blocks.

395
Technical Support / Re: witness_node doesn't work well
« on: July 31, 2017, 11:14:20 am »
1. how to run witness_node smoothly even after restarting it?

If the node didn't exit cleanly you should restart it with --replay-blockchain.

2. do I have to set enable-stale-production = true  and add some winness-id ?
I see some thread in forum saying  to add some witness-id = "1.7.*
but in my config file, I can only add some "1.6.*", and I'v no idea what they are.

No. Never use enable-stale-production. You don't need to set a witness id if you don't plan to run an actual witness.

3. I heard the witness_node requires 8 ~ 24GB memory, closing it with Ctrl-C need to wait more than 10 minutes unitll it finish write data to disk,
but I only have 4GB memory, not SWAP, not SSD. but I never saw it use all of the memory, usually around 1GB,
though there is a time it did crashed with std::bad_alloc, but system still have lots of free memory, no OOM-killer message in system logs.
also closing it with a single Ctrl-C doesn't need to wait at all .

are these saying that I'm using wrong witness_node ?

Although the witness_node with the partial-operations flag and a small list of tracked accounts uses less than 4 GB of RAM, a 4GB system with no swap space configured may be too small. Depends on what else is running.

4. is witness_node + cli_wallet enough to run a trading bot ? (with wintness_node default setting)

Depending on how your bot creates transactions, you may not need the cli_wallet.


5. is there any public witness_node I can connect to ? then I can stop making my witness_node work, is it safe to run bot with public node ?

Some people are running public API servers, but it would probably be a good idea to run your own. Again, this depends on your bot.

396
I think you're mixing up two things here.

One thing is the issue with margin calls eating up limit orders before they can match the orders sitting on the book. We're investigating that.

The issue with whaleshares you are reporting is unrelated to that. Whaleshares is a UIA, not a smartcoin. Margin calls do not happen there. What I suspect is the problem there is rounding issues. Whaleshares can only be traded in whole units, which means that you will see huge rounding errors when trading only 2 units, for example.


Regarding the margin calls, I have created a unit test that reproduces the issue. https://github.com/bitshares/bitshares-core/pull/341/commits/aa60533269d7ca5e534bedb8a63ac4742d50164c
The test also demonstrates that the issue appears only in a limited price range, i. e. between the call price of a margin call and the MSSP.

Your suggested fix simply lets the margin call match the order at the price of highest buy in the book. I think that's reasonable. I would still prefer a slightly modified version that uses the MSSP if the highest buy is higher than the MSSP. Resolving margin calls is important to the health of the bitasset, and margin calls only execute up to the MSSP.

397
Status update

I have just created two PRs on github, completing the first two milestones from my proposal:

  • https://github.com/bitshares/bitshares-core/pull/340 - this is the initial implementation of the features discussed in the proposal. Unit tests are included (and pass, obviously). The code is able to replay the current chain. I have also let the hardfork pass on a local node, without problems (but also without consequences, of course). I urge developers and witnesses to review this PR!
  • https://github.com/bitshares/bitshares-core/pull/339 - since my worker proposal includes support during the hardfork, and (hopefully unnecessary) debugging should any problems arise, and due to experience gained from the recent blockchain halt, this PR intends to improve startup time after a node crashes. This should speed up debugging and restart significantly, should it become necessary. This change is not consensus-related and can be applied immediately by node operators who feel brave enough. :-)

As of today, the worker has accumulated about 88k BTS, which would at today's price on CMC cover about half of my requested pay.

Next steps:
  • wait for review of PRs
  • make adjustments, if any are deemed necessary
  • integrate into testnet after PR has been accepted

398
Technically, this is not a bug. A user places an order on the exchange, and it gets filled at the specified price.

Nevertheless, I have come to agree that the behaviour is less than optimal and should be improved.

We must find a balance between the interests of traders and those of the blockchain. The blockchain must try to keep short positions sufficiently collateralized, but of course it should pay a reasonable price for that.

P.S.  I understand there are several fixes queued up for the next hard fork.  Does anyone know when that is expected to happen?  If it's not soon, perhaps a temporary fix should be made in the UI pending the next hard fork containing this fix?

I expect the BSIP-0018 hardfork to happen in the next two months or so, but a date has not been set yet.

399
Technical Support / Re: Error Converse OPEN.BTC to BTS
« on: July 26, 2017, 10:07:21 am »
The fee pool is empty again.

400
- https://github.com/bitshares/bitshares-core/issues/325
i am having some problems with this one, i sent it to @pc who will take a look in the next days. i think he may be the right person to change the flat_index we have left. i may came back to it if he can't make it but i had to move on.

I've created a PR on your personal repo: https://github.com/oxarbitrage/bitshares-core/pulls

401
General Discussion / Re: EOS Token Questions
« on: July 21, 2017, 10:53:13 am »
Why didn't they just create an EOS token on BitShares and sell that? Isn't that a main feature of BitShares?

I suppose they did it on ETH because recent ICOs on ETH have yielded insane amounts of money. I doubt an ICO on BTS could have matched that.

403
For BTS-1.0 BM had put up a bounty for creating a snapshot from the PTS chain.
IIRC there were at least two winning submissions, one of which was mine. I don't think my implementation from back then would scale to today's BTC chain, though.
I'm sure there are better ways today. Basically, you need a snapshot of BTC's UTXO database at a specific point in time.

404
Beyond Bitcoin [closed] / Re: Followup to yesterday's hangout
« on: July 16, 2017, 10:10:16 pm »
I would agree that changing the MSSR in mid-game is a bad move.

405
Technical Support / Re: Closing HERO Position fails
« on: July 16, 2017, 08:18:04 pm »
Right now you have only 0.5207 HERO in your account, but you're trying to pay back your debt of 1 HERO.

Pages: 1 ... 20 21 22 23 24 25 26 [27] 28 29 30 31 32 33 34 ... 102