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

Pages: [1] 2 3 4 5 6 7 8 ... 210
General Discussion / Re: Internalizing the Hero
« on: July 15, 2018, 06:26:35 pm »
Just FYI there is a committee proposal to transfer ownership of HERO asset to hero-foundation:

General Discussion / Re: SPRING fund
« on: July 14, 2018, 08:48:06 am »
got a tl;DR in english?
A fund which will operate like the public market operation worker, but some money comes from outside, started the first fundraiser (target 50M-200M BTS).

General Discussion / Re: Internalizing the Hero
« on: July 13, 2018, 08:59:46 pm »
Transferring an asset's ownership to committee-account doesn't mean the committee nor any witness is responsible to maintain it.

General Discussion / SPRING fund
« on: July 13, 2018, 08:57:05 pm »

有个疑问,基金持有的 BTS 是否参与见证人、理事会和 worker 投票?个人自己抵押托盘或者抄底,虽然有爆仓风险,但是可以自主投票的。如果基金的 BTS 来源主要是从大家账户里挤出来,会造成有效投票减少,影响共识。


General Discussion / Re: Cancel a transaction
« on: July 12, 2018, 08:27:03 pm »
No sorry this is the price you have to pay to use a decentralized exchange, you always have to wait for the block to be confirmed first. Although I'm not sure if you can broadcast another message to cancel the transaction from being put in a block before the 3 seconds (1.5 sec average) have passed

One could argue that this feature is not useful or it is unnecessary. But i think there is a way to not pay this price.

If there is a cancel_order_by_transaction_id, then it no longer depends on the order id to cancel (which has at least 3 sec delay), since the transaction id is known to the user before he/she sends the transactions.

The chain could have forks, then the order might have different order id in different fork, canceling an order id might not be applied in the end. Cancel_by_transaction_id could in deed complete the cancel in this situation.

It's technically possible to implement, however, not easy based on current infrastructure.
* It's expensive (read: slow) for nodes to undo just one or a few transactions, if there were a lot of transactions in the queue;
* nodes need to make sure the cancellation is requested by the original signer, that said, the cancellation should also be signed, thus need a new verification process.

About usability, due to the 3s block time, it's likely that success rate of cancellation will be low. The cancellation request need to be transmitted through the p2p network, it need time to reach the next block producer. For slow blockchain like bitcoin, such feature would make much more sense.

About security, if this mechanism is in place, it can be used to spam/attack the network with zero cost.

For me, the gain doesn't worth the efforts/risks. Just my own opinion though.

I'm aware of the unclaimed funds: I don't tend to forget such sums of money, especially when they've appreciated like BTS has since they were allocated. My intent for the usage of the funds remains unchanged from my previous statements about it: I'll draw upon them for work I think especially important to the future of the chain.

... I plan to involve some of our engineers in development work prior to that time (I introduced the guys to the concepts of UIAs, for example, yesterday).

Thanks for the clarification and contributions.

One thing I would like to see now and would be willing to fund for a reasonable price from the allocated funds: an onchain or offchain solution to the bug where the vote counts aren't available for committee members that aren't presently elected. To me this seems like a distinct weakness in the governance system.

There is an github issue for this:, actually I've got an idea about how to fix it just a few days before, although not yet started to code, due to priority. It's also good if someone else can get it fixed. However, IMHO, efforts related to this issue can be covered by the core dev worker if there isn't a dedicated bounty for it.

Back to the topic, 7 million BTS seems a bit too huge in comparison to such small bounties. Now we already have a core dev worker to cover the maintenance job which was intention of this worker. Since we haven't yet decided how to use this fund, given the fact that most workers on chain now are being paid via escrows, I propose that we move the remaining funds of this worker to be controlled by an escrow service (for example BBF) or merge it with the core dev worker, if we still want to use it to fund core development / maintenance. We do want experienced project manager and developers to help and contribute, not only funds. On the other hand, if we're going to use it to fund other things, which would be out of this worker's scope, IMHO it's best to re-vote.

中文(Chinese) / Re: AEX从今天起全面下线bitCNY交易对
« on: July 12, 2018, 04:02:14 pm »
如果有过空头支票的事,那么,我感觉现在各承兑平台推的 CNC 的信用风险很大。

中文(Chinese) / Re: 讨论下 GDEX 的交易挖矿
« on: July 12, 2018, 03:57:06 pm »
交 易 挖 矿 开 始 时 , 参 与 交 易 挖 矿 的 交 易 对 为 :


从刷的角度来说,刷bitcny交易对是非常不合算的,因为bitcny有0.1%的手续费,不参与手续费返还。一笔交易付两笔手续费,只返一半 GDP。

刷 BTS 还行,一笔交易付一笔手续费,全返 GDP。

效率最高是刷 GDEX.ETH / GDEX.BTC 或 GDEX.EOS/GDEX.BTC 对,一笔交易付两笔手续费,全返GDP。

中文(Chinese) / 讨论下 GDEX 的交易挖矿
« on: July 12, 2018, 09:55:08 am »
GDEX 今天开启交易挖矿。白皮书地址

交易挖矿本质相当于 ICO 。

按白皮书来看,预计总发行量 10 亿 GDP ,早鸟价 0.5 CNY,相当于初始估值 5 亿。

第一期释放 1000w GDP,占总量的 1%;按早鸟价计算,相当于 500w CNY,由于是交易费用50%返还,相当于融资 1000w CNY。

gdex 能否公布一下上线至今的运营情况,包括交易量、代管资金量(充值量)、手续费收入、运营支出等等?

中文(Chinese) / Re: AEX从今天起全面下线bitCNY交易对
« on: July 12, 2018, 09:42:12 am »


bitcrab and I have moved remaining funds of this worker to a new multi-sig account: worker63fundholder

It's a 2/3 multi-sig account controlled by bitcrab, jademont and me.

Technical Support / Re: Problem in creating a MPA
« on: July 11, 2018, 06:45:38 pm »
After searching on internet and some experiments, I still couldn't figure out how to create a MPA.

Based on my understanding, the process of issuing an UIA is

* create asset
* issue it to an account

After this, you could transfer it to anyone you want.

While I am a little bit confused in the process of creating a MPA and how to use it.

Below is my current understanding:

* create asset with bitasset option
* publish feed for this asset
* borrow the asset
* sell the asset to complete (?)

I managed to create an MPA in cli_wallet, which could be listed in list_assets

unlocked >>> list_assets YW 1
list_assets YW 1
    "id": "1.3.4",
    "symbol": "YWMPA",
    "precision": 5,
    "issuer": "1.2.17",
    "options": {
      "max_supply": "1000000000000000",
      "market_fee_percent": 0,
      "max_market_fee": "1000000000000000",
      "issuer_permissions": 79,
      "flags": 0,
      "core_exchange_rate": {
        "base": {
          "amount": 10000,
          "asset_id": "1.3.0"
        "quote": {
          "amount": 80000,
          "asset_id": "1.3.4"
      "whitelist_authorities": [],
      "blacklist_authorities": [],
      "whitelist_markets": [],
      "blacklist_markets": [],
      "description": "",
      "extensions": []
    "dynamic_asset_data_id": "2.3.4",
    "bitasset_data_id": "2.4.0"

But I didn't pass the publish feed step. The assertion shows

> Assert Exception: bitasset.feeds.count(o.publisher):

I have no idea about this meaning. Any step I missed? What's is the correct step to create a MPA and do the exchange on bitshares?

`"issuer_permissions": 79` means you can't publish feeds from witnesses.
Check what permission the MPAs on mainnet has.
You can adjust the permissions or set feed producers in GUI, or use update_asset command in CLI.

Just a note, there are 1,196,589 BTS and 204,239 BTS accumulated by workers in this thread, unclaimed.

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