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.


Topics - pc

Pages: 1 [2]
16
Deutsch (German) / Delegates in D?
« on: January 05, 2015, 01:27:41 pm »
Hi,

hat sich mal jemand schlau gemacht, wie die rechtliche Situation für Delegierte hier in D aussieht?

Die Freigabe der BaFin für das Bitcoin-Mining von 12/2013 bezieht sich m. W. nur auf Bitcoin und davon abgeleitete Währungen. Bei BTS macht der Delegierte aber wesentlich mehr als nur TX in einem Block zusammenzufassen und zu hashen - er betreibt letztlich auch den internen Markt. Insofern könnte ich mir vorstellen, dass die BaFin dazu eine andere Meinung hat als zum klassischen Mining.


17
BitShares PTS / [ANN] PTS snapshot 2014-12-14
« on: December 15, 2014, 12:01:20 am »
For the record: the last block mined and published on the old PoW PTS network is block #81688 with block hash 0000000601e8d786761bc44da1575abe7daaec1b89d743202979c0761490a5c2.

Snapshot data is available at http://ptsags.quisquis.de/pts-2014-12-14.json.gz

We will soon launch the new PTS-DPOS chain.

18
BitShares PTS / [ANN] BitShares-PTS Dry Run #2 launched
« on: December 10, 2014, 07:56:59 pm »
Today dry run #2 of the new PTS client software has started.

We invite all interested parties to participate in the final test of the new network.

* Source code is available at https://github.com/PTS-DPOS/PTS .
* Genesis block uses PTS snapshot from 2014-12-09, scaled to 1 billion PTS.
* Everything else is final, unless we identify showstoppers during this run.

Among other things, we want to specifically test our new feature:

Secure genesis claims

It is now possible to claim genesis balances without importing private keys by means of the new "wallet_import_by_signedmsg" command. A description of the idea can be found here: http://pts.cubeconnex.com/index.php?topic=37.0 and a step-by-step explanation in our wiki: http://pts.cubeconnex.com/wiki/index.php?title=Secure_Asset_Import .

Build and run

Code: [Select]
git clone https://github.com/PTS-DPOS/PTS.git
cd PTS
git checkout dry-run-2
git submodule init
git submodule update
cmake .
make pts_client
programs/client/pts_client

References

Website: http://www.ptscrypto.com/
Forum: http://pts.cubeconnex.com/
GitHub: https://github.com/PTS-DPOS/PTS
Linux packages: http://software.opensuse.org/download.html?project=home%3Ap_conrad%3Abts&package=PTS
Windows download: https://github.com/PTS-DPOS/PTS/releases

Next steps

* Dry run 2 will last until Saturday Dec 13.
* The last block published to the old PTS network before the end of Sunday Dec 14 (GMT) will be used for creating the genesis block of the new chain.
* The new PTS-DPOS chain will be launched in the early hours of Monday Dec 15.

WARNING! It is advisable to withdraw your balances from the exchanges unless you have positive confirmation that they will support the new client!

Edit: Apparently, bter will honour the snapshot: https://bter.com/trade/pts_btc .

19
BitShares PTS / [ANN] BitShares-PTS Dry Run #1 launched
« on: December 03, 2014, 10:10:51 pm »
We are pleased to announce that we have just started dry run #1 of the new PTS client software.

We invite all interested parties to participate in testing the new network.

* Currently only the CLI client is available, GUI will follow soon.
* Specs are as announced previously ( http://pts.cubeconnex.com/index.php?topic=43.0 ), but not necessarily final.
* Source code is available at https://github.com/PTS-DPOS/PTS .
* Genesis block uses PTS snapshot from 2014-12-02, scaled to 1 billion PTS.

Among other things, we want to specifically test our new feature:

Secure genesis claims

It is now possible to claim genesis balances without importing private keys by means of the new "wallet_import_by_signedmsg" command. A description of the idea can be found here: http://pts.cubeconnex.com/index.php?topic=37.0

We are looking for initial delegates!

In order to achieve good decentralization right from the start we hope to find volunteers for running initial delegates from dry run #2 on. Details are described here: http://pts.cubeconnex.com/index.php?topic=48.0 . Please help us make the new network secure and reliable!

Build and run

Code: [Select]
git clone git@github.com:PTS-DPOS/PTS.git
git checkout dry-run-1a
git submodule init
git submodule update
cmake .
make pts_client
programs/client/pts_client

References

Website: http://www.ptscrypto.com/
Forum: http://pts.cubeconnex.com/
GitHub: https://github.com/PTS-DPOS/PTS
Linux packages: http://software.opensuse.org/download.html?project=home%3Ap_conrad%3Abts&package=PTS
Windows download: https://github.com/PTS-DPOS/PTS/releases/download/dry-run-1a/PTS-DryRun1a-v0.0.3-x86.exe

Edit: added windows download link + updated version to dry-run-1a

20
General Discussion / PHISHING WARNING!
« on: November 09, 2014, 02:32:52 pm »
I've seen this twice in the last 30 minutes or so: after clicking on a thread the thread opens and the browser opens an authentication window telling me "To see this message, please confirm your identity".

So be careful everybody.

It happened to me here, for example: https://bitsharestalk.org/index.php?topic=11056.0

Edit: according to the auth window the authentication request stems from http://0x5896d083 - how can I attach a screenshot to this message?

21
General Discussion / Problem with wallet_add_contact_account
« on: September 25, 2014, 01:11:13 pm »
I have two wallets with one account each. One is meant for everyday use and has a registered account name. The other is more or less "cold", its account name is unregistered and I have imported my PTS private keys there.

Yesterday I wanted to transfer funds from my everyday wallet to the "cold" wallet. So I opened the cold wallet, dumped its public keys, then opened the "everyday" wallet and added the unregistered account name with one of its public keys:

Code: [Select]
(wallet closed) >>> open pts
OK
pts (locked) >>> wallet_account_list_public_keys pts.local
[{
    "hex": "035dc3a125cca19787b58b2ba8af5a056a322f62f006f3b440192e7c50704fec6e",
    "native_pubkey": "BTSX7YXcLiSCP4nZg4psBo8R9FscJTytHmXVj2mcLxG1Cv1y7BFrKa",
    "native_address": "BTSXMVZZy1WUMCXxtLimkCGERNpVkfT4YmK59",
    "pts_normal_address": "PazdTWzxRst9aei352AwD6QbdcLAaStcB7",
    "pts_compressed_address": "PqPoCfTNqDjF5Rd2Wavis47JMvCn6Cgx6u",
    "btc_normal_address": "144rKSJpfmw5nNuBhXX645AYPMuLiLtdDB",
    "btc_compressed_address": "1JU24amF57nBH9pB96Gsi2sF7fmxEY4uj5"
  },{
...
  }
]
pts (locked) >>> open pmc
OK
pmc (locked) >>> wallet_add_contact_account pts.local BTSX7YXcLiSCP4nZg4psBo8R9FscJTytHmXVj2mcLxG1Cv1y7BFrKa
Wallet automatically backed up to: /home/peter/.BitSharesX/wallets/.backups/pmc/pmc-20140925T130206-account_add.json
pmc (locked) >>> wallet_account_list_public_keys pts.local
[{
    "hex": "035dc3a125cca19787b58b2ba8af5a056a322f62f006f3b440192e7c50704fec6e",
    "native_pubkey": "BTSX7YXcLiSCP4nZg4psBo8R9FscJTytHmXVj2mcLxG1Cv1y7BFrKa",
    "native_address": "BTSXMVZZy1WUMCXxtLimkCGERNpVkfT4YmK59",
    "pts_normal_address": "PazdTWzxRst9aei352AwD6QbdcLAaStcB7",
    "pts_compressed_address": "PqPoCfTNqDjF5Rd2Wavis47JMvCn6Cgx6u",
    "btc_normal_address": "144rKSJpfmw5nNuBhXX645AYPMuLiLtdDB",
    "btc_compressed_address": "1JU24amF57nBH9pB96Gsi2sF7fmxEY4uj5"
  }
]

The last command verifies that "pts.local" in the "pmc" wallet uses the same keys as in the "pts" wallet.
For testing (luckily), I transferred 1 BTSX from pmc to pts.local:
Code: [Select]
pmc (unlocked) >>> transfer 1 BTSX pmc pts.local test
OK
pmc (unlocked) >>> wallet_account_transaction_history
TIMESTAMP           BLOCK     FROM                TO                  AMOUNT                  MEMO                                        BALANCE                 FEE                 ID     
==============================================================================================================================================================================================
...
2014-09-24T19:19:48 571251    pmc                 pts.local           1.00000 BTSX            test                           xxxx BTSX       0.10000 BTSX        c863a255
However, after opening + unlocking the "pts" wallet again the TX hasn't arrived. Blockchain is in sync. Rescan doesn't help.
What I don't understand is that blockchain_get_transaction shows a deposit to a completely different address:
Code: [Select]
pts (unlocked) >>> blockchain_get_transaction c863a255
{
  "trx": {
...
  "provided_deposits": [[
      "BTSXfPy1KbpGxb3iWw5AU8buTydCZXFA6WPi",{
        "amount": 100000,
        "asset_id": 0
      }
    ]
  ],
...
Any ideas?

22
General Discussion / Software license?
« on: September 08, 2014, 12:21:24 pm »
Hi,

I have started to create linux packages for BitSharesX, which has made me research the BitShares license, and I see a problem there.

The BitSharesX client comes with a LICENSE.md that makes the client public domain. The source tree (excluding submodules for now) however clearly contains files that are not public domain (cotire.cmake is MIT, CrashRpt stuff seems to be BSD).

The web_wallet module is a complete nightmare: it also contains LICENSE.md which states that it is public domain plus code licensed under various licenses (including MIT, Apache, jQuery). In addition, it contains a "licenseagreement.html" that is clearly a non-free license.

The "fc" module used by the command line as well as the qt client does not specify its own license, which makes distribution problematic. Even worse, it contains AGPL-licensed code which means it cannot be published as either public domain or with a non-free license.

Please clarify.

Thanks,
Peter

23
General Discussion / Problems on Ubuntu
« on: August 15, 2014, 10:35:22 am »
Hi,

I managed to build the 0.3.1 client on Ubuntu-14.04 (i586), but it is seriously unstable.
After starting it, it instantly goes to 100% CPU and stays there. The console reports varying connection counts, and the p2p.log shows lots of
Code: [Select]
20140815T093416.678613       th_a on_blockchain_item_i ] sync:     191d0c7973d0bf89568668600c8b5a36d8938028                     node.cpp:1942
According to get_info, the block count stays constant for a long time before it starts to crawl upwards - if it ever gets to that point. Most of the time, it crashes either with an Assertion Failure (attempt to free a mutex while threads are waiting on it) or a segfault. After about a dozen or so attempts I'm now synced up to block #23190. IOW, the client is unusable.

Here's a backtrace of the latest segfault:
Code: [Select]
--- there are now 4 active connections to the p2p network
(wallet closed) >>>
Program received signal SIGSEGV, Segmentation fault.
0x0917fd7a in fc::detail::is_operation_shorter::operator()(fc::detail::rate_limited_operation const*, fc::detail::rate_limited_operation const*) ()
(gdb) bt
#0  0x0917fd7a in fc::detail::is_operation_shorter::operator()(fc::detail::rate_limited_operation const*, fc::detail::rate_limited_operation const*) ()
#1  0x09181663 in void std::__insertion_sort<__gnu_cxx::__normal_iterator<fc::detail::rate_limited_operation**, std::vector<fc::detail::rate_limited_operation*, std::allocator<fc::detail::rate_limited_operation*> > >, fc::detail::is_operation_shorter>(__gnu_cxx::__normal_iterator<fc::detail::rate_limited_operation**, std::vector<fc::detail::rate_limited_operation*, std::allocator<fc::detail::rate_limited_operation*> > >, __gnu_cxx::__normal_iterator<fc::detail::rate_limited_operation**, std::vector<fc::detail::rate_limited_operation*, std::allocator<fc::detail::rate_limited_operation*> > >, fc::detail::is_operation_shorter) ()
#2  0x09180e17 in void std::__final_insertion_sort<__gnu_cxx::__normal_iterator<fc::detail::rate_limited_operation**, std::vector<fc::detail::rate_limited_operation*, std::allocator<fc::detail::rate_limited_operation*> > >, fc::detail::is_operation_shorter>(__gnu_cxx::__normal_iterator<fc::detail::rate_limited_operation**, std::vector<fc::detail::rate_limited_operation*, std::allocator<fc::detail::rate_limited_operation*> > >, __gnu_cxx::__normal_iterator<fc::detail::rate_limited_operation**, std::vector<fc::detail::rate_limited_operation*, std::allocator<fc::detail::rate_limited_operation*> > >, fc::detail::is_operation_shorter)
    ()
#3  0x091803ae in void std::sort<__gnu_cxx::__normal_iterator<fc::detail::rate_limited_operation**, std::vector<fc::detail::rate_limited_operation*, std::allocator<fc::detail::rate_limited_operation*> > >, fc::detail::is_operation_shorter>(__gnu_cxx::__normal_iterator<fc::detail::rate_limited_operation**, std::vector<f---Type <return> to continue, or q <return> to quit---
c::detail::rate_limited_operation*, std::allocator<fc::detail::rate_limited_operation*> > >, __gnu_cxx::__normal_iterator<fc::detail::rate_limited_operation**, std::vector<fc::detail::rate_limited_operation*, std::allocator<fc::detail::rate_limited_operation*> > >, fc::detail::is_operation_shorter) ()
#4  0x0917eef7 in fc::detail::rate_limiting_group_impl::process_pending_operations(fc::time_point&, unsigned int&, std::list<fc::detail::rate_limited_operation*, std::allocator<fc::detail::rate_limited_operation*> >&, std::list<fc::detail::rate_limited_operation*, std::allocator<fc::detail::rate_limited_operation*> >&, unsigned int&, unsigned int&) ()
#5  0x0917eaee in fc::detail::rate_limiting_group_impl::process_pending_writes() ()
#6  0x0917e685 in fc::detail::rate_limiting_group_impl::writesome(boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >&, char const*, unsigned int)::{lambda()#1}::operator()() const ()
#7  0x0917f8f2 in fc::detail::void_functor_run<fc::detail::rate_limiting_group_impl::writesome(boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >&, char const*, unsigned int)::{lambda()#1}>::run(void*, fc::detail::void_functor_run<fc::detail::rate_limiting_group_impl::writesome(boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >&, char const*, unsigned int)::{lambda()#1}>) ()
#8  0x08b0bf37 in fc::task_base::run_impl() ()
---Type <return> to continue, or q <return> to quit---
#9  0x08b0beed in fc::task_base::run() ()
#10 0x08b0472b in fc::thread_d::run_next_task() ()
#11 0x08b04a46 in fc::thread_d::process_tasks() ()
#12 0x08b042bb in fc::thread_d::start_process_tasks(int) ()
#13 0x091c3fa9 in make_fcontext ()

I also managed to build the QT wallet, but tested it only briefly as it doesn't even get to the point of opening a "real" window (other than the splash screen). One strange thing I noticed is that it uses "$HOME/BitShares X" instead of "$HOME/.BitSharesX" like the CLI version.

Edit: here's the assertion failure I was referring to:
Code: [Select]
(wallet closed) >>> bitsharesxd: /home/peter/Work/packages/bitshares/trans/bitsharesx-0.3.1/libraries/fc/src/thread/mutex.cpp:22: fc::mutex::~mutex(): Assertion `!m_blist && "Attempt to free mutex while others are blocking on lock."' failed.

Pages: 1 [2]