Quote from: abit on March 15, 2018, 07:50:11 PM

Quote from: CoinHoarder on March 15, 2018, 01:27:13 PM

Quote from: pc on March 09, 2018, 11:42:35 AM
http://docs.bitshares.org/development/namespaces/chain.html#_CPPv2N8graphene5chain16custom_operationE

Ok. Thanks to @abit too.

Almost all of the proposed API calls are unneccesary, and can use the custom transaction types.

The documentation is really bad for this stuff though. Something with the schema for the commands would go a long ways. I saw there was a command that returns the schema for the custom operations, but the command does not seem to work with bitshares-ws NPM module API.


It seems like the following commands may be useful for such an implementation:

custom_operation
custom_evaluator
custom_id_type
custom_object_type

Custom operations usually do nothing other than validating authorities. So there will be no "custom_object" in the core, nor evaluator or custom_id_type. Business logic around it would be "customized" (not in the core consensus).

Ok, so custom_operation can be used for all custom operations.

How can these custom operations be queried and filtered using the API? Or would one need to download all custom operations starting from from the genesis block, and process them client-side?

If the latter, then that is definitely not ideal. Some type of query and filter API call would be handy.

I would suggest Meteor's version of MongoDB-styled syntax since custom operations are aschematic. It is easy to learn and fairly straightforward. Two API calls would cover all use cases: find_custom_operation and find_one_custom_operation. These commands should accept MongoDB-styled queries. These API calls would be very powerful for building decentralized applications on top of Bitshares. https://docs.meteor.com/api/collections.html#Mongo-Collection-find

Quote from: pc on March 09, 2018, 11:42:35 AM
http://docs.bitshares.org/development/namespaces/chain.html#_CPPv2N8graphene5chain16custom_operationE

Ok. Thanks to @abit too.

Almost all of the proposed API calls are unneccesary, and can use the custom transaction types.

The documentation is really bad for this stuff though. Something with the schema for the commands would go a long ways. I saw there was a command that returns the schema for the custom operations, but the command does not seem to work with bitshares-ws NPM module API.


It seems like the following commands may be useful for such an implementation:

custom_operation
custom_evaluator
custom_id_type
custom_object_type

Relevant:

Quote from: CoinHoarder on March 09, 2018, 02:28:42 AM
I've been thinking of how best to implement this, and I think we only need six new API calls to make this a reality. The rest is fairly straightforward GUI work.

The six API calls I am proposing are similar to publish_asset_feed. They are mostly used just to record information permanently in the blockchain in a pre-determined schema. The rest can be done client-side and by leveraging the current implementation of multi-signature accounts.

command (description):
provide_escrow (offer escrow services)
publish_offer (sell/buy a crypto token)
cancel_offer (cancel an offer)
initiate_trade (match an existing offer)
request_arbitration (ping the escrow agent to let them know arbitration is needed)
rate_account (rate the counterparty/escrow agent in a trade)

API Call Schema:
provide_escrow
{
  "meta_type": "p2p_trade",
  "sub_type": "provide_escrow",
  "publisher": String (account ID),
  "escrow": Boolean (true... currently providing escrow OR false... not currently providing escrow)
}

publish_offer
{
  "meta_type": "p2p_trade",
  "sub_type": "publish_offer",
  "offer_id": String (a unique ID... similar to how there are IDs for uias, tokens, etc.),
  "publisher": String (account ID),
  "offer_type": String ("ask"... selling crypto OR "bid"... buying crypto),
  "crypto_id": String (UIA/Smartcoin/Token ID that they want to buy/sell),
  "accepting": Array of Strings (what the user will accept in return ["bitcoin", "cash in the mail", "chase bank deposit"] etc.),
  "price": Integer (Price offered),
  "amount": Integer (Amount offered),
  "terms": String (details including terms for the trade... ID required? Time limit? Restrictions? etc.),
  "escrow_options": Array (array of account IDs that the user is willing to use as Escrow Agents for the trade)
}

cancel_offer:
{
  "meta_type": "p2p_trade",
  "sub_type": "cancel_offer",
  "offer_id": String (a unique ID... similar to how there are IDs for uias, tokens, etc.),
  "publisher": String (account ID),
}

initiate_trade:
{
  "meta_type": "p2p_trade",
  "sub_type": "initiate_trade",
  "offer_id": String (a unique ID... similar to how there are IDs for uias, tokens, etc.),
  "escrow_agent": String (an account ID that has declared themselves as available for escrow using provide_escrow, and that the offer has included in the array of preferred escrow agents: escrow_options)
}

request_arbitration (ping the escrow agent to let them know arbitration is needed)
{
  "meta_type": "p2p_trade",
  "sub_type": "request_arbitration",
  "offer_id": String (the unique ID of the offer... similar to how there are IDs for uias, tokens, etc.)
}

rate_account:
{
  "meta_type": "p2p_trade",
  "sub_type": "rate_account",
  "offer_id": String (the unique offer ID of the escrow agent or counterparty you are rating ... similar to how there are IDs for uias, tokens, etc.),
  "rating": Integer (a rating of your experience with the counterparty or escrow agent... 1 through 4)
}

Almost everything can be done client-side with no need for changes in the protocol since 2 of 3 multisignature accounts are used. The only changes in the protocol I can think of:
1. Initiate trade creates a 2 of 3 multi-signature account with the original offerer, the counterparty initiating the trade, and the chosen escrow agent
2. rate_account should only be able to be done if the user has completed a trade with the escrow agent or counterparty

The schema is not completely thought out. I do not want to spend much time on it without knowing if the idea will be disregarded or not, but you guys get the idea. It can be improved upon if there is interest.

I've been thinking of how best to implement this, and I think we may not need any new API calls to make this a reality. It is fairly straightforward GUI work once the design is finalized.

Most custom operations to make this work are used just to record information permanently on the blockchain in a pre-determined schema. Everything else can be done client-side by leveraging the current implementation of multi-signature accounts.

command (description):
provide_escrow (offer escrow services)
publish_offer (sell/buy a crypto token)
cancel_offer (cancel an offer)
initiate_trade (match an existing offer)
request_arbitration (ping the escrow agent to let them know arbitration is needed)
rate_account (rate the counterparty/escrow agent in a trade)

Schema:
provide_escrow:
{
  "meta_type": "p2p_trade",
  "sub_type": "provide_escrow",
  "publisher": String (account ID),
  "escrow": Boolean (true... currently providing escrow OR false... not currently providing escrow)
}

publish_offer:
{
  "meta_type": "p2p_trade",
  "sub_type": "publish_offer",
  "offer_id": String (a unique ID... similar to how there are IDs for uias, tokens, etc.),
  "publisher": String (account ID),
  "offer_type": String ("ask"... selling crypto OR "bid"... buying crypto),
  "crypto_id": String (UIA/Smartcoin/Token ID that they want to buy/sell),
  "accepting": Array of Strings (what the user will accept in return ["bitcoin", "cash in the mail", "chase bank deposit"] etc.),
  "price": Integer (Price offered),
  "amount": Integer (Amount offered),
  "terms": String (details including terms for the trade... ID required? Time limit? Restrictions? etc.),
  "escrow_options": Array (array of account IDs that the user is willing to use as Escrow Agents for the trade)
}

cancel_offer:
{
  "meta_type": "p2p_trade",
  "sub_type": "cancel_offer",
  "offer_id": String (a unique ID... similar to how there are IDs for uias, tokens, etc.),
  "publisher": String (account ID),
}

initiate_trade:
{
  "meta_type": "p2p_trade",
  "sub_type": "initiate_trade",
  "offer_id": String (a unique ID... similar to how there are IDs for uias, tokens, etc.),
  "escrow_agent": String (an account ID that has declared themselves as available for escrow using provide_escrow, and that the offer has included in the array of preferred escrow agents: escrow_options),
  "publisher": String (account ID)
}

request_arbitration:
{
  "meta_type": "p2p_trade",
  "sub_type": "request_arbitration",
  "offer_id": String (the unique ID of the offer... similar to how there are IDs for uias, tokens, etc.),
  "publisher": String (account ID)
}

rate_account:
{
  "meta_type": "p2p_trade",
  "sub_type": "rate_account",
  "offer_id": String (the unique offer ID of the escrow agent or counterparty you are rating ... similar to how there are IDs for uias, tokens, etc.),
  "rating": Integer (a rating of your experience with the counterparty or escrow agent... 1 through 4),
  "comment": String (a description of your rating)
  "publisher": String (account ID)
}

How it works:

Escrow Agents
Escrow Agents will be used as arbitrators. Anyone can be an Escrow Agent by declaring themselves available for such services using the provide_escrow command. Initially it will likely be trusted community members, but the reputation system allows new users to build reputations as Escrow Agents too.

Publish Offer
Like publishing a listing on LocalBitcoins.com, each offer to buy/sell a token will be published on the blockchain using publish_offer. This will contain all applicable information including which token, escrow agents, price, etc... then one of two things can happen:

The publisher of the offer can cancel it using cancel_offer, or someone can choose to be the counterparty to a trade by using initiate_trade.

Initiate Trade
initiate_trade first creates a 2 of 3 multi-signature account with the original offerer, the counterparty initiating the trade, and the escrow agent the counterparty chose from the list of escrow agents the offerer is willing to use.

Requesting Arbitration or Completing The Trade
If both parties in the trade agree that it was completed successfully, then there is no need for the Escrow Agent to do anything. In this case, a transaction out if the multi-signature account can be proposed. If arbitration is meccessary, then request_arbitration can be used to notify the escrow agent of the neccesity of arbitration.

Establishing Reputations
After trades, users can permanently record their experience with the escrow/counterparty on the blockchain with a simple star rating and description to elaborate. rate_account should only count if the account has completed a trade with the escrow agent or counterparty. The last rate_account should be used, which will allow accounts to update their rating after the fact if problems arise.

Sybil Attack Detterents:
Sybil attacks on the ratings can be solved several ways completelu client-side. By simply giving more weight (or sorting in descending order) to  the amount of BTS the reviewer owns. A web of trust system can also be created where people add other BTS accounts they trust. Obviously, filtering reviews to only show if the accounts have successfully completed a trade.

---------


The schema is not completely thought out. I have not spent much time on it, but you guys get the idea. It can be improved upon if there is interest.

The meta_type property of the schema can be used to filter applicable data from the blockchain, and the sub_type can be used to process (or further filter) them.

Quote from: dexy on February 26, 2018, 09:16:46 PM
Nice idea. But it would be better to choose USD instead of BTS as a backed asset, IMHO.
Because very few people who want to short the Amazon against a volatile BTS.
With the USD as a backed asset this would be more interesting, especially since you chose the main market as AMAZONCOM vs USD.

Good point

Bitbay and OpenBazaar have both implemented marketplace features. It is worth taking a look at their implementations.

Seems pretty straightforward... leverage reputation-based escrow agents with simple 2 of 3 multisig addresses.

I think if you're adding this feature, then you might as well implement a full-on decentralized market for goods, services, or cryptos/fiat.

It will require a minimal amount of extra effort to make a fully featured decentralized marketplace (compared to just adding a marketplace for crypto/fiat transactions).

Quote from: sschiessl on February 17, 2018, 05:36:25 PM
We are still investigating what the cause is there. But one.thing we see its likely not a problem with performance at the backend because the servers were basically bored, even through such heavy "out of sync" periods. It might be an issue with client/server connection management.

The cause needs to be identified, setting up your own node is treating the symptom (but of course us a work around atm)

This needs to be a priority at the moment. Potential users are flowing into the community faster than ever thanks to the Network Effect and first impressions are key.

Quote from: yvv on January 26, 2018, 11:29:51 PM
There are reasons to issue them, but creating an asset is not enough to make it useful. Look at bitBTC. This asset makes a perfect sense, but liquidity ...

The free market has spoken... people have indicated that they prefer an IOU for the real thing (OPEN.BTC or GDEX.BTC) rather than a derivative (bitBTC). I view the cryptocurrency Smart Coins as effectively useless at this point... (other than for a small percentage of the userbase that wants to margin trade with them or stay in a completely decentralized and autonomous environment).

But I think cryptocurrency Smart Coins (bitBTC, bitLTC, etc.) may be different than equities, index funds, or commodities. Due to regulatory issues, there is no easy way for someone to setup IOUs for index funds or equities. Also due to custodial/regulatory issues, there is no way to set up IOUs for commodities either.

I think it can be a good for Bitshares marketing to create a few Index Fund Smart Coins. I think the options should represent a decently diversified portfolio. Something like:

VTSMX - Vanguard Total Stock Market Index Fund Investor Shares
VBMFX - Vanguard Total Bond Market Index Fund Investor Shares
VFINX - Vanguard 500 Index Fund Investor Shares

Plenty of price feeds available for all three of those. They would represent ownership in the S&P 500 (VFINX), Bonds (VBMFX), and also the Stock Market as a whole (VTSMX).

I think this would be really good for marketing and bring more users into Bitshares. No other DEX can say they have such derivatives. Smart Coins are Bitshares' killer feature, but they need to be leveraged properly.

Can I ask you a question? I don't know who better to ask... :'(

I am thinking of building a tradable card game that I am designing/coding already on top of Bitshares using UIAs.

From my Javascript/Node.JS/Meteor.JS web app I will need to only do two things:
1. Verify signed memos created in the Bitshares wallet
2. Check the blockchain to see if a specific account owns a certain UIA

I am thinking I need to use bitsharesjs, but there's not really any documentation that I can find. There is a little bit in the ReadMe, but not much info there.

Is there any chance that you could point me in the right direction to get me started? I have not worked with bitsharesjs before. I guess I need to use the Chain library for #2 and the ECC library for #1?

Thanks  :D

Quote from: abit on January 03, 2018, 02:02:45 PM
New proposal https://cryptofresh.com/p/1.10.7264

Fixed the Annual member fee part, but kept the lowered vesting balance creation fee unchanged in comparison to the previous proposal.

Still not using a dedicated field for collateral bidding (to revive smart coins after a black swan event), so the fee will be same to short position updating.

@pc the reason behind the change is to keep the fee in a "small" range in terms of fiat, which was discussed in 2016 (didn't get time to find the post, sorry)

I approve of this message!

TBH, if it is enacted then I will probably build my project on Bitshares. I have been waiting and hoping for a fee adjustment.

I have been rooting for you guys, but I remain blockchain-neutral and have not decided on which one to build the project on top of.

Since you have a nice DEX and GUI with easily signed memos, I had hoped that would be Bitshares, but it is hard to justify the expensive UIA costs at this time when there are other much cheaper options (as cheap as $10...).

This is speculation, but I think that we are in the midst of a huge crypto bull market... I wouldn't expect all crypto prices, including BTS to come down for a while.

Quote from: yvv on December 30, 2017, 02:28:21 PM

QuoteWhy not have bitLTC or any of the other top 20 tokens?

We have BTWTY which represents top 20 tokens. We also have bitOIL, NASDAQ and a bunch of other tokens pegged to real world asset, but nobody provides price feeds for them. Witnesses should post price feeds and all these tokens will get alive.

+5% +5% +5%

The "we're not ready yet" camp has always annoyed me when it comes to issuing additional Smart Coins. You will never know until they are up and running.

You guys better get to bootstrapping and network effecting this feature on the Bitshares chain before someone else eats your lunch...

I know of at least one chain (Ethereum) that if it implemented a SmartCoin smart contract tomorrow... it could steal Bitshare's thunder easily- like taking candy from a baby.

Asset create‡   -   -   -
   -  3-character symbol   21,197 USD   4,239 USD*   0.026 USD
   -  4-character symbol   5,299 USD   1,060 USD*   0.026 USD
   -  5-character symbol or longer   132 USD   26 USD*   0.026 USD

I have a project I am working on where I will need to create about 25 assets.. a tradable card game: http://www.cryptohun.ch/

$3300 is too much for this when I can spend $250 or less on other blockchains. I know I get $2650 of this back AFTER 90 days if I'm a Lifetime member, but still... it's such a waste of money from a business perspective when I could spend $250 on another chain, and then spend the rest on advertising (or something more beneficial than registration fees at least...).

5+ character assets should be cheaper. I will probably build on another chain like Waves or something else if the Bitshares comittee doesn't change them. I wanted to build on Bitshares though. Heck, even a simple ERC20 token would be much cheaper to make and the cards could be traded through ETH's DEXs.

You get my point though... not a good value proposition from an asset issuer. Especially considering the value I think my project would bring into Bitshares... you guys should be paying me those fees instead.  ;)

Quote from: valtr on December 07, 2017, 07:21:50 AM

Quote from: fav on December 07, 2017, 06:26:36 AM

Quote from: renkcub on December 07, 2017, 01:40:44 AM
Also the lag is bad.. need better nodes?

yes. ask @bitcrab why he sees no value in the infrastructure worker

Lag is bad. "Your active node ot of sync" this message is on my screen every minute(or a few minutes).

This needs to be addressed ASAP. First impressions are key...

I know how to verify it in the GUI.

I am wondering what the CLI command is to verify?

I can't seem to find a list of all the CLI command.

Ideally, I would like to verify them without using the client, so I am wondering how exactly it works.

I think is uses AES-256 encryption, with the public memo key being the encryption key. I am not sure what format the memo key is in by default though, and not sure what format it needs to be converted to.

Encryption is not my area of expertise tbh.

Thanks for any help.

The wallet now has a feature to create a signed message like:

-----BEGIN BITSHARES SIGNED MESSAGE-----
Secretcode
-----BEGIN META-----
account=coinhoarder1
memokey=BTS5VoKnbC9zdFg3XfkayjXC9u6c2YAVc95ZrYQPN1TKU7JT6Hkhh
block=22486470
timestamp=Sat, 09 Dec 2017 01:07:42 GMT
-----BEGIN SIGNATURE-----
2070c5e86c9584a6ef6a6cd13a3e1d0ef5d2a2f2e88899f78e388f9b09004900e87f999ec6c43430908a6087f5f9408fdebb8c3e88e4acf27a060f81d0824b6b8a
-----END BITSHARES SIGNED MESSAGE-----

Can someone give me a nudge in the right direction as to how I would confirm the validity of the signed message?

Any help would be more than welcome, but I will be implementing the solution in Javascript (well... Node.js).

They are AES-256 encrypted???

I am trying to test this to see if Bitshares may be a good place for me to build a game that I am designing.

Thanks!