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

Pages: [1] 2 3 4 5 6 7 8 ... 14
1
BEOS / Re: BitShares EOS (BEOS) Launches - Get Yours
« on: April 11, 2019, 12:53:19 pm »
Testing BEOS staking, able to get account and move BTS to EOS, get rainfall tokens, now want to try to move BTS back - to ensure all the functionality is in place - and find no way how to withdraw BTS at stake back to my normal BTS wallet.

I see no withdrawal option on BEOS gateway page in beos webwallet either.

Any comments/explanations?

2
KeyID / Re: Post 11/5 bagholders on exchange SOL?
« on: December 28, 2014, 08:07:25 am »
Good to know.

Only thing that needed in this case is to be sure that Poloniex will keep DNS balances after Dec, 31. Is there some assurance on this from their side?

3
KeyID / Re: Post 11/5 bagholders on exchange SOL?
« on: December 27, 2014, 07:32:12 pm »
Any idea of possible resolution for similar issue?

I still have DNS at Poloniex, credited 2014-10-09 at 00:04:04, is there a way or follow-up communication with Poloniex where I can check if my DNS stuck at Poloniex can be converted to BTS?

4
Poloniex закрыл торговлю DNS и просит их снять.

https://twitter.com/Poloniex/status/545460245175472129

С учетом включения DNS в SupreDAC какой адрес указывать при снятии? Кошелек DNS я не заводил, предполагая, что потом достаточно будет импортировать ключи. Соответственно, адреса, специфичного для DNS у меня нет. Снятие BitShares PTS на Poloniex сейчас просит Memo, а DNS - нет. Достаточно ли просто указать BTSX адрес, или надо проделать какие-то специфичные процедуры?

Саппорту Poloniex вопрос задан...

yvg1900

5
Search Market is nearly unusable on Core 2 2 GHz machine with 4 Gb RAM (Win7 64-bit).

When "Bit" typed in the "Search Market" field client starts intense calculations, CPU load between 50 and 100%, and BitShares.exe process memory usage is 1.5 Gb.

Terminating BitShares.exe process leaves database in unstable state and requires restore from backup.

Is there alternate way of searching by asset name and/or browsing available assets?

6
Technical Support / Re: Wallet Not Connected despite trying all the tricks
« on: November 30, 2014, 10:22:32 am »
I recently observed similar behaviour for some time - upgraded from 0.4.16, and found that wallet does not even start syncing.

Deleted everything except "wallets" folder, and after this entered exactly state being discussed here. Wallet was showing 12 connections:

Code: [Select]
>> getinfo

{
  "blockchain_head_block_num": 0,
  "blockchain_head_block_age": null,
  "blockchain_head_block_timestamp": null,
  "blockchain_average_delegate_participation": "0.00 %",
  "blockchain_confirmation_requirement": 202,
  "blockchain_share_supply": "2,499,002,518.57146 BTS",
  "blockchain_blocks_left_in_round": 101,
  "blockchain_next_round_time": null,
  "blockchain_next_round_timestamp": null,
  "blockchain_random_seed": "0000000000000000000000000000000000000000",
  "client_data_dir": "C:/Users/yvg/AppData/Roaming/BitShares",
  "client_version": "v0.4.24",
  "network_num_connections": 12,
  "network_num_connections_max": 200,
  "network_chain_downloader_running": false,
  "network_chain_downloader_blocks_remaining": null,
  "ntp_time": "2014-11-30T09:54:55",
  "ntp_time_error": 0.82485600000000003,
  "wallet_open": true,
  "wallet_unlocked": true,
  "wallet_unlocked_until": "12 days in the future",
  "wallet_unlocked_until_timestamp": "2014-12-11T23:40:32",
  "wallet_last_scanned_block_timestamp": null,
  "wallet_scan_progress": "0.00 %",
  "wallet_block_production_enabled": false,
  "wallet_next_block_production_time": null,
  "wallet_next_block_production_timestamp": null
}

Somehow after [reasonably long] time [tens of minutes] wallet suddenly started syncing. Was it coincident or not, but it was right after I clicked "Overview" (I think it was coincident).

Another thing I currently observe (still syncing) is that "Successfully pushed sync block" count written to p2p.log does not match to one shown in GUI - getinfo shows more or less correct synchronization state, but block count shown in sync status popup in GUI lags really a lot.

CPU load is nearly 100%, and only process using it is BitShares.exe.

Currently I run client on an old Core 2 2.16 GHz machine with 4 Gb RAM (Win7 64-bit), so it can be that either client has some issues when running on slower/older hardware (especially because of some rare thread synchronization issues tend to show up on slow systems and resource starving conditions), or synchronization state visualization inconsistency.

At the moment of writing, "Last block synced" popup shows only about 56000 blocks (and stays in this state for half an hour or so), while getinfo shows 634000 blocks. Execution time of getinfo command is more than 10 seconds.



7
Is there are reason you chose a non-asic-resistant algorithm like SHA* .. and not went for the PTS algo which seems to be pretty asic resistant?

Yep, same question here: selection of SHA512 will leave huge part of CPU miners (individuals that may benefit most from DPOS) out of the game nearly immediately.

I really suggest to reconsider PoW algo to something more centralization-resistant like MMCv2.

Follow @yvg1900 on Twitter to get updates on performance mining software


8
@all: let me know if sparkle should get it's own subboard section on third party DACs…

I personally think it makes sense to have dedicated subboard section for sparkle.

As of tech description from OP, I honestly think that simple hashing PoW is not enough, especially taking into account SHA512, so I agree with FreeTrade on considering some more sophisticated PoW.

As of PoW in general, in some cases PoW is not entirely Proof-Of-Waste - good example is PrimeCoin. And designing good and useful PoW is non-trivial task by itself.

So I personally will follow sparkle development closely, and will support it with mining software when it reaches production/realnet stage.
 

Follow @yvg1900 on Twitter to get updates on performance mining software


9
BitShares PTS / Re: jhProtominer - CPU and collisions/min charts
« on: October 30, 2014, 08:14:39 am »
Missed this thread, probably it is not too late...

Is there still a chance to get output of the miner?

And feel free to PM me if you need urgent answer.

10
BitShares PTS / Re: Mining pool list - Updating
« on: October 15, 2014, 09:22:33 am »
I just revised PTS pool support for yam, and yes, we have only 4 pools left - ypool. 1gh, ptspool and upcpu (yam supports all).

11
General Discussion / Re: "insufficient funds" Help Thread
« on: September 16, 2014, 06:12:36 am »
Same here:

a) Account created by importing keyhotee founder ID (using brain wallet key)
b) PTS and AGS balances imported manually, each private key separately
c) Keyhotee founder ID reward NOT claimed

Code: [Select]
>> blockchain_list_pending_transactions

No pending transactions.

Code: [Select]
>> balance

ACCOUNT                         BALANCE                     
============================================================
yvg1900                         2,586.15334 BTSX      (scaled, definitely more than 2000)

Code: [Select]
>> wallet_transfer 10 BTSX yvg1900 delegate.yvg1900

20010 insufficient_funds: insufficient funds

    {"required":"10.50000 BTSX","available":"0.00000 BTSX"}
    bitshares  wallet.cpp:474 bts::wallet::detail::wallet_impl::withdraw_to_transaction

    {"amount_to_withdraw":{"amount":1050000,"asset_id":0},"from_account_address":"BTSXFBJiZnJVHSteKTPQo3826o2CDFE3NmNZ5","trx":{"expiration":"19700101T000000","delegate_slate_id":null,"operations":[],"signatures":[]},"required_signatures":[]}
    bitshares  wallet.cpp:475 bts::wallet::detail::wallet_impl::withdraw_to_transaction

    {"real_amount_to_transfer":10,"amount_to_transfer_symbol":"BTSX","paying_account_name":"yvg1900","from_account_name":"yvg1900","to_account_name":"delegate.yvg1900","memo_message":""}
    bitshares  wallet.cpp:4065 bts::wallet::wallet::transfer_asset

    {}
    bitshares  common_api_client.cpp:1043 bts::rpc_stubs::common_api_client::wallet_transfer

    {"command":"wallet_transfer"}
    bitshares  cli.cpp:555 bts::cli::detail::cli_impl::execute_command

Code: [Select]
>> wallet_account_register delegate.yvg1900 yvg1900

20010 insufficient_funds: insufficient funds

    {"required":"0.50000 BTSX","available":"0.00000 BTSX"}
    bitshares  wallet.cpp:474 bts::wallet::detail::wallet_impl::withdraw_to_transaction

    {"amount_to_withdraw":{"amount":50000,"asset_id":0},"from_account_address":"BTSXFBJiZnJVHSteKTPQo3826o2CDFE3NmNZ5","trx":{"expiration":"19700101T000000","delegate_slate_id":null,"operations":[{"type":"register_account_op_type","data":{"name":"delegate.yvg1900","public_data":null,"owner_key":"BTSX7UcvxMxc2NyyneLsf8iimihXWBbAQbwmDRKCjp6LF2pkATXm6F","active_key":"BTSX7UcvxMxc2NyyneLsf8iimihXWBbAQbwmDRKCjp6LF2pkATXm6F","delegate_pay_rate":255,"meta_data":null}}],"signatures":[]},"required_signatures":["BTSXFBJiZnJVHSteKTPQo3826o2CDFE3NmNZ5"]}
    bitshares  wallet.cpp:475 bts::wallet::detail::wallet_impl::withdraw_to_transaction

    {"account_to_register":"delegate.yvg1900","public_data":null,"pay_with_account_name":"yvg1900","delegate_pay_rate":255}
    bitshares  wallet.cpp:4145 bts::wallet::wallet::register_account

    {"account_name":"delegate.yvg1900","data":null}
    bitshares  client.cpp:3205 bts::client::detail::client_impl::wallet_account_register

    {}
    bitshares  common_api_client.cpp:1139 bts::rpc_stubs::common_api_client::wallet_account_register

    {"command":"wallet_account_register"}
    bitshares  cli.cpp:555 bts::cli::detail::cli_impl::execute_command

Any ideas how I can help tracking this issue down?

yvg1900

12
BitShares PTS / Re: 1 tx per block in past 18 hours
« on: May 28, 2014, 07:52:19 am »
Finally a block included transactions...

this pool is good: https://coinplorer.com/PTS/Addresses/PrrtrqsqSi1nVpBwer46WaY4x9kr1Cw9fA
this pool is bad:   https://coinplorer.com/PTS/Addresses/PpXRMhz5dDHtFYpbDTpiAMJaVarMUJURT6

Though the "bad" pool is excluding even its own transactions. Any idea who owns what? I emailed ypool and but can't find contact info for beeeeer.org


The problem is with the ypool miners which are all derived from https://github.com/jh000/jhProtominer.git
Specifically, if the miners are still running without these 3 fixes (which is likely for the older optimized forks)

Code: [Select]
commit bc32c370ecdf93d3d21b14029694b99c2ea9ae56
Author: JH <[email protected]>
Date:   Sat Nov 23 18:31:16 2013 +0100

    Better transaction handling

commit 2bc39593dad391353a68adb5bfe6b950da268800
Author: JH <[email protected]>
Date:   Wed Nov 20 02:43:05 2013 +0100

    Interrupt on new work
   
    The miner now stops processing the current work when a new block
    appears.

commit 151634efd03d3e07fda5d701e0da337ef5b98aef
Author: JH <[email protected]>
Date:   Tue Nov 19 00:53:37 2013 +0100

    Critical transaction fix
   
    Fixed a little bug that made it impossible for the xpt pool server to
    generate valid blocks that contain non-coinbase transactions.


Ooops, I think bitder is right. http://ptspool.com/ provided the link to an old jhProtominer build, which didn't include the critical transaction fix. I think yvg1900 can contact ptspool owner to update the link and urge miners to update as well.

ptspool provides a link to file store managed by me, so miners there shall be up to date. It is absolutely pointless to use jhProtominer, because of yam has MUCH better CPU mining performance, and I do not support optimized jhProtominer builds for a long time - all code moved to yam.

As far as I can recall, jhProtominer M7h version located at the link DOES include fix. I think the last buggy one was M7c. I definitely removed all buggy versions long before we agreed that ypool will explicitly block them (miners send miner version to the pool).

I will double-check what was in M7h build, but chances that it does not include fix are extremely low - fix was delivered on Nov 19, 2013, and M7h (last in jhProtominer lime) came out on Dec 07, 2013.

13
BitShares PTS / Re: 1 tx per block in past 18 hours
« on: May 28, 2014, 07:41:17 am »
Finally a block included transactions...

this pool is good: https://coinplorer.com/PTS/Addresses/PrrtrqsqSi1nVpBwer46WaY4x9kr1Cw9fA
this pool is bad:   https://coinplorer.com/PTS/Addresses/PpXRMhz5dDHtFYpbDTpiAMJaVarMUJURT6

Though the "bad" pool is excluding even its own transactions. Any idea who owns what? I emailed ypool and but can't find contact info for beeeeer.org

The problem is with the ypool miners which are all derived from https://github.com/jh000/jhProtominer.git
Specifically, if the miners are still running without these 3 fixes (which is likely for the older optimized forks)

Code: [Select]
commit bc32c370ecdf93d3d21b14029694b99c2ea9ae56
Author: JH <[email protected]>
Date:   Sat Nov 23 18:31:16 2013 +0100

    Better transaction handling

commit 2bc39593dad391353a68adb5bfe6b950da268800
Author: JH <[email protected]>
Date:   Wed Nov 20 02:43:05 2013 +0100

    Interrupt on new work
   
    The miner now stops processing the current work when a new block
    appears.

commit 151634efd03d3e07fda5d701e0da337ef5b98aef
Author: JH <[email protected]>
Date:   Tue Nov 19 00:53:37 2013 +0100

    Critical transaction fix
   
    Fixed a little bug that made it impossible for the xpt pool server to
    generate valid blocks that contain non-coinbase transactions.


NOT all miners derived from mentioned codebase. yam miner developed from scratch and uses minor part of protocol specific code developed by ypool owner jh00. That code DOES include fix (in fact, was first one to include fix). Versions without fix are explicitly blocked by ypool.

14
MemoryCoin / Re: New YAM version release
« on: May 01, 2014, 03:24:23 pm »
yvg1900
what's new in release q and release r??

You can check release news at https://twitter.com/yvg1900 - it has info on all releases, as well as public answers to some user questions as they come.

15
I replied in another thread. Your CPU supports AVX, but does not support AES-NI. AES-NI needed for both GRS and MMC, but for MMC you can explicilty turn it on or off, while for GRS there is no such possibility. It would be really great if you also check readme.txt and other documentation files provided with a miner - they all contain a lot of very useful information.

Thanks.

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