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
General Discussion / [Ann] Testnet release 3.2.0
« on: June 23, 2019, 03:22:22 pm »

Core Team has tagged a new testnet release:

Preliminary release notes can be seen here:

Mainnet release is planned for 2019-07-05.

General Discussion / Request for shareholder opinion
« on: August 23, 2017, 03:41:05 pm »
Do we need shareholder approval for these bugfixes?

Can we decide on that question? Not just specifically for the PRs in the OP, but generally.

Beyond Bitcoin [closed] / Followup to yesterday's hangout
« on: July 15, 2017, 09:01:36 am »
Like I promised, I posted an example about margin calls on steemit:


Market-pegged assets, aka MPA, aka SmartCoins, can suffer a "black swan" event. A black swan occurs when the least collateralized short position has insufficient collateral to buy back the borrowed SmartCoins at the current feed price. What happens then is that the MPA is tagged with a "settlement price", defined as the collateral ratio of the least collateralized short. All short positions are closed automatically, by collecting sufficient collateral into a settlement pool and paying out the remainder to the short's owners. MPA holders can use the forced settlement operation to receive their share from the settlement pool in exchange for their MPAs.

MPAs that have suffered a black swan are effectively dead. They can still be transferred or traded, but they can no longer be shorted. Eventually, all significant holders wlll have settled their positions, and some dust will remain scattered all over the place, where the value of the dust position is lower than the fees required to get rid of it.

The same is true for Prediction Markets. Prediction Markets don't suffer black swans, but at some point the prediction will be resolved in the same way that an MPA resolves a black swan - i. e. a settlement price is defined, short positions are closed, and holders can settle their positions individually. After that, the Prediction Market is effectively dead.

The most recent example of a black swan is GRIDCOIN, and I think it has left a bad impression on its issuer, and serves as a bad example for possible future candidates:

That's unfortunate & quite a short lived experiment in BitShares by the Gridcoin community then. [...] I hope black swan handling/recovery functionality is added into BitShares in the future, time to look into other DEXs.

I also believe that the one-shot property is one of the major reasons why prediction markets haven't gained traction yet.


I'd like to find a minimally invasive way to revive assets after a global settlement or black swan event. Since we currently don't have a designated dev team, this will have to be done as a community effort. Community support is also required because we need to implement and accept a hardfork for this.

I'm looking for a "minimally invasive" solution because
* I want to avoid breaking things, obviously.
* I hope a small change can be done without the usual hassle with worker proposals. I'd volunteer to implement changes, but I will need help testing.

Starting point

Reviving MPAs / PMs consists of two basic steps, IMO:

1. Resolve all open positions
2. Reset the asset object in the database to a usable state

I believe the second step is safe to do after the first has been completed.
* For an MPA, it is sufficient to remove the settlement price. Once it has been removed, price feeds can be published again, and with sufficient price feeds, shorting becomes possible.
* PMs should be reset into a state that requires issuer action to re-enable shorting, possibly by setting some flags at the time the settlement price is removed.
Both can be done within a maintenance interval at little computational cost.

The first step, however, looks much trickier to me. For example, I'm not clear about what are "open positions":
* holders
* market orders (sell *and* buy)
* shorts that use the to-be-revived asset as collateral (?)
* fee pool
* anything else?

For each type of "open position", we need a way to close it. Suggestions:
* Resolve holders by allowing the issuer to invoke forced settlement if the asset has a settlement_price.
* Resolve market orders by allowing the issuer to cancel orders if one of the assets has a settlement_price.
* Ignore the fee pool - it belongs to the issuer anyway.
* For shorts I don't see a solution, but that should be a rare case. I hope.
* Anything else?

By allowing the issuer to take action we avoid overly complex computations. The fees should be paid by the issuer. We might want to offer a reduced settlement fee in that case, since protecting shorters is not necessary at this point.


Edit: crossposted on steem:

General Discussion / Edinarcoin?
« on: August 27, 2016, 10:00:04 am »
Does anyone know who's behind that? Seems to be a BitShares clone or at least Graphene-based.

IMO it's not a good sign that it wasn't announced here...

Openledger / Steem wallet down?
« on: July 30, 2016, 02:56:50 pm »

yesterday I transferred 400 OPEN.STEEM to openledger-wallet. I haven't received any in my steem account. Is everything working as intended?

[member=11]dannotestein[/member] ?

Edit: resolved

Technical Support / Additional feature(s)
« on: February 13, 2016, 02:22:24 pm »

before I start the formal process of writing BSIPs I'd like to get feedback on an idea. Actually it's more like one and a half ideas.

My starting point was that I'd like to have a way to attach generic information to an account in the form of key/value pairs. Examples would be contact information like email address, URL, PGP-key etc. - specific uses would be up to client software. External representation should be in the form of JSON or BSON, perhaps with an extra datatype for blockchain object references. The latter would make it possible to add a list of "friend" accounts, for example. All of this could be implemented mostly by extending existing data structures (account_object and account_update_operation) with optional add-ons. Since this permanently consumes node resources, more weight should be put on per-kb fees for related operations.

Now that we have defined a generic data structure, the next logical step is to allow storing arbitrary data objects in the blockchain. In addition to the data itself (again, key/value pairs like above), such a data object would require metadata like permissions (owner + active keys) and an expiration time. Fees should be calculated per-kb and per-time, and the expiration time of existing object could be extended by paying additional fees.

I think these generic interfaces could be used by a lot of blockchain-related businesses. Opinions?

Stakeholder Proposals / [Witness] cyrano
« on: October 29, 2015, 09:19:17 pm »
BitShares Witness Proposal - cyrano

My name is Peter Conrad, and I propose to run a BitShares witness.

Previous experience

I have followed the BitShares project since the early days of ProtoShares, back in November 2013. Since March 2015 I've been elected as a worker delegate in in the old (pre-2.0) BitShares blockchain. See my old proposal and some details on my technical background.

I have participated as a witness in the beta runs of the Graphene network. My witness node was up and producing blocks in BitShares-2.0 a few hours after launch. This directly proves my first-hand experience in running a witness. During the first two weeks of BitShares-2.0 my witness has signed more than 13,000 blocks, missing only 46 - more than 99.5% reliability.

Technical details

The witness node is running on a dedicated server in eastern Germany. The machine has 16G RAM and a mostly idle CPU - there's plenty of room for higher TX loads. The data center has high-speed fiber-optic links to interconnection points all over europe, resulting in an average latency of 300ms to my 30 (as of 2015-10-27) co-witnesses.

Please vote!

If you find that convincing, please vote for witness cyrano!

General Discussion / Description of EMunie consensus protocol
« on: August 23, 2015, 06:30:19 pm »

TL;DR: Transactions carry meta-information that assigns trust to signing nodes. In case of conflicting transactions, nodes select the transaction signed by the signers with highest collective trust. Sybil attacks are countered with fees.

Sounds like a system that combines elements from TAPOS + DPOS with an unlimited number of signers.

Deutsch (German) / Vortragsankündigung
« on: August 18, 2015, 08:40:21 pm »
P2P-Labs ist eine relativ junge Initiative, deren Mitglieder aus den unterschiedlichsten Fachgebieten gemeinsam das Ziel verfolgen, Blockchain-Technologien im Allgemeinen zu fördern und zu verbreiten. Ende September hält P2P-Labs als Auftakt einer Vortragsreihe einen Vortrag zum Thema "Bitcoin & Blockchain-Technologie - Sicherheit und Praktikabilität im Zahlungsverkehr". Interessierte sind herzlich eingeladen.

Weitere Themen und Termine stehen noch nicht fest, voraussichtlich werde ich aber auch einen Vortrag zum Thema BitShares, DPOS und BitAssets beitragen.

Technical Support / Collateral stuck after manual cover?!
« on: February 14, 2015, 05:20:32 pm »

I shorted some BTC and a little later I covered to open short. I have done this before, and the usual result is that the collateral is credited back to my wallet. This time it wasn't.

in the CLI I did

wallet_market_submit_short trader1.pmc 5417.97264 BTS 0.12 BTC 0.0000326456222794

in block 1787741, the short was filled one block later, and another 17 blocks after that I found the open cover with


and covered manually with

wallet_market_cover trader1.pmc 0.09825190 BTC 3f94c69c59022edde4fe2e001a63e49d169c7b80

Here's an excerpt of wallet_account_transaction_history:

Code: [Select]
2015-02-14T13:41:52 1787741   trader1.pmc         SHORT-b0958dff      5,417.97264 BTS         short BTC @ 0.12% APR                       2,710.68559 BTS         0.10000 BTS         e7d8565a
|2015-02-14T13:42:10 1787742   SHORT-b0958dff      MARGIN-b0958dff     5,417.97264 BTS         add collateral                              2.60000 BTS             0.00000 BTS         VIRTUAL |
|                              MARKET              MARGIN-b0958dff     3,009.65008 BTS         add collateral                              2.60000 BTS                                         |
|                              MARGIN-b0958dff     MARKET              0.09825190 BTC          short proceeds @ 0.0000326456222794 BTC ... 0.00713279 BTC                                      |
 2015-02-14T13:44:52 1787759   trader1.pmc         MARGIN-b0958dff     0.09825190 BTC          payoff debt                                 0.00611434 BTC          0.10000 BTS         25e0507e

The owner address of that short/cover is BTSLtHYNmAj3spkDezjyZRMNMPxDpFKeNtqd. wallet_account_order_list doesn't show any open orders with that owner, so I suppose it was fully covered. But my collateral wasn't returned.

Any ideas? Any hints on how/where to find information about market transactions?


Stakeholder Proposals / Developer delegate: dev-pc.bitcube
« on: February 03, 2015, 10:41:35 pm »

tl;dr: I'm a professional software developer with 15+ years of experience and I'd like to work on the client and take some load off the core team. Please vote for me:
Code: [Select]
wallet_approve_delegate dev-pc.bitcube true.

Delegate proposal website:

BitShares Delegate Proposal

My name is Peter Conrad and I propose to create a delegate for funding my work. Please support my proposal and vote for me:
Code: [Select]
wallet_approve_delegate dev-pc.bitcube true
A. What I have to offer

I'm a freelance software developer and I would like to offer my expertise to the BitShares DAC. Read up on my professional background if you like. As you can see ;-) I'm not a GUI type. My preference is backend programming, network interfaces and console stuff.

I have done most of the backend work for porting PTS to PTS-DPOS. PTS-DPOS is basically a fork from BitShares-, so I'm already familiar with the BitShares codebase.

I see my activities mainly in these areas (in no particular order, priorities will be worked out together with the core devs on a case-by-case basis):

1. Infrastructure

For PTS I have implemented a dynamic list of seed nodes published via DNS. Porting this to BitShares should be simple. I will create and maintain such a list for BitShares (and DevShares) and publish it in the DNS. These DNS names can then be added to the static list of seed nodes built into the client. Every time the client is started, it will fetch a fresh list of seed nodes from DNS and use these. (Once set up, the list is updated automatically and requires hardly any manual maintenance.)

To my surprise, the current client does not work with IPv6. This is a no-go for a brand new networking application, IMO. I will work on porting the networking code to IPv6.

I will continue to provide my Linux packages of BTS (and DVS) for the current set of distributions (CentOS, Fedora, openSUSE), free of charge - I would do that anyway. I can work for pay on adding support for Debian, RHEL, Ubuntu and ArchLinux.

2. External APIs

The BitShares code already contains a very elegant mechanism for defining and generating the external RPC API (also used by the GUI wallet). The same mechanism also generates the command line interface.

The next logical step is to use this mechanism for generating a common API for external applications. I'm thinking of a BitShares-Java API, a Perl module, C library etc., similar to what Xeroc has already started for Python.

In addition to generating the plain method calls, the parameter types and return types should be formalized as well.

3. Code Quality

A delicate subject. This is not about bashing other people's coding style. It is also not about throwing everything away and starting from scratch (only better this time). Nevertheless, objective metrics on code quality exist, and application on the BitShares codebase suggests that there is room for improvement.

What is code quality and why is it important?

Clean code is simple in the sense that it is easy to read and easy to understand. It is highly modular and well-structured.

When code is easy to read it is also easier to see bugs. This leads to a better product.

Code that is easy to understand makes it easier for new developers to join the team, reducing the time (and cost!) to get them up to speed.

Well-structured code is also easier to maintain, reducing the time (and cost) to find and fix bugs.

Modular code facilitates adding new features to an existing program. It is easier (and cheaper) to add a new module than to fiddle with many details all over the codebase.

Modular code also facilitates code reuse. Reuse reduces the overall code size, which leads to more simplicity, fewer bugs and lower maintenance cost.

How to get there?

  •     Educate others. Not with long monotonous lectures, but by setting examples. By generating interest, explaining and giving pointers.
  •     Introduce tools. I plan to select tools and metrics for evaluating code quality to highlight problem areas and measure improvement over time.
  •     Apply the boy scout principle: Always leave the code cleaner than you found it.

4. Grunt work

There are currently (2015-01-31) 130 open issues in the main github repo. Some of these are more than 7 months old. This is not a sign of lazyness (there are more than a thousand closed issues), it's a sign of an overworked dev team. I can take up some of these issues, taking load off the core team.

In a similar way, I can investigate issues posted by forum users that never even make it into a github ticket.

B. Suggested mode of operation

1. Pricing

I can offer to work for the BitShares DAC for €55.00/hour including all expenses. (This is less than my usual rate, and more than 20% less than the average.) I will adapt the amount of work I'm doing to the exchange rate of BTS/EUR.

I will not charge for

  •     time spent on the forum,
  •     work that is immediately applicable to PTS-DPOS (the codebases have diverged and merging changes is a real PITA anyway),
  •     things I would have done anyway (like maintaining my linux packages, see above).

2. Delegate Operation

I suggest that a 3rd party runs a 100% delegate on my behalf. This should be either an individual living outside the EU, or a business located outside Germany. This serves two purposes:

  •     It is a tax optimization - in this setup I don't have to charge VAT.
  •     It is an insurance to the DAC - the 3rd party can check that I'm actually working for my money, and withhold/burn the funds if I don't.

The 3rd party will have to make their identity (name and address) known to me, so I can send them a proper bill (for example on a monthly basis). These bills (excluding the 3rd party's identity) plus a more detailed report will be published here for you, the shareholders, to check.

The 3rd party should agree on a fixed price for their own service in this setup, which will also be paid from the delegate proceeds. Any remaining funds below a threshold (for example two weeks of delegate payment) will be carried over to the next month, the rest (above the threshold) will be burned.

The first two weeks of pay will be taken as compensation for the registration fee.

3. Delegate Operator

Cube has agreed to run the delegate for me. He's a long time member of our community and has been running very reliable PTS-DPOS delegates for a while now.

I am a IT consultant cum project manager by profession. I started as a developer and a system admin before moving on to a sys analyst, senior analyst and then the project manager role. My IT profession and experiences are over 20 years. I am one of the team members responsible for the release of PTS DPOS. I detailed my interest in crypto here.

- Cube

Cube will charge USD 135.00 per month for his services. This includes hosting, server maintenance and bookkeeping. At the current rate, USD 135.00 is roughly 10% of the total delegate earnings.

4. Vote for me!

Code: [Select]
wallet_approve_delegate dev-pc.bitcube true
Thank you very much!

General Discussion / WTF?! shutting down!
« on: January 27, 2015, 08:36:43 pm »
From their site:

Important Announcement!

Due to very low volume and lack of good userbase, Crypto-Trade has decided to shutdown permanently due to inability to cover its expenditures on rented servers , staff salary and site promotion. All the users are requested to withdraw their funds within 48 hours.The site will continue to process pending withdrawals till our private wallet is empty. The site will go offline on 29th January 6:00 UTC.

I was able to withdraw a few DOGE, FTC, XPM and DVC. Withdrawals for BTC, BTS, EUR and USD seem to be stuck - maybe it's already too late. :-(

Pages: [1] 2