[ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread

[PhantomPhreak]

Question about escrowing funds for CFD bets. How is that currently handled in the protocol?

For example if I have 100,000 XCP and I want to short the Bitstamp BTC/USD price which is currently at $800 and specify leverage 1, how would escrow work if my bet is matched?

I assume the protocol should take out all my funds and hold them, correct? Because even though the chance is remote, there is still a possibility that BTC/USD will move up to $100,800 in the next block and I lose all my money.

Yes, it's all escrowed away immediately.

[1506061655]

1506061655

[1506061655]

1506061655

[1506061655]

1506061655

[1506061655]

1506061655

[rotalumis]

Noob question:

I'm currently reindexing and syncing the blockchain I got from bittorrent, planning to try out Counterparty. I also will be installing an Armory watching-only wallet on this PC for both watching and broadcasting transactions signed offline.

Will I be able to use the same bitcoind and data for both applications, or will the "txindex=1" in bitcoin.conf that I added for Counterparty cause trouble with Armory?

I don't think it should cause any trouble, but you might ask etotheipi just to be sure.

Thanks. Sent him a PM.

[PhantomPhreak]

Important Announcement: I just pushed a series of commits to the develop branch of the GitHub repository which contain a significant number of new features and a fair number of bug fixes:

• Most visibly, all asset names now include a checksum character at the end which will catch at least all single-character replacements and adjacent transpositions (statistically 90% of typos). Previously issued assets will have the character appended to their names automatically. To create a new asset, you need to calculate the checksum yourself with 'counterparty checksum STRING'. This change may not be permanent (in particular we may want to use a longer checksum), so tell me what you think of the feature. Note that the change is not in the protocol itself, but only in counterpartyd's CLI.
• Assets are now accompanied by up to 42 characters of Unicode text which may serve as a short description of the asset (esp. a link to a website with more information and proof it does what it says).
• The command-line syntax has been tweaked so that '--from' becomes '--source' and '--to' becomes '--destination', for consistency.
• Assets are now callable, if they are set to be so upon first issuance. An asset may be able to be 'called back' by its issuer at a fixed price from a particular date.

Also, the bug that Patel reported before, about cancels not recrediting escrowed funds, has been fixed in both master and develop (but the fix is still somewhat untested).

[PhantomPhreak]

Question about escrowing funds for CFD bets. How is that currently handled in the protocol?

For example if I have 100,000 XCP and I want to short the Bitstamp BTC/USD price which is currently at $800 and specify leverage 1, how would escrow work if my bet is matched?

I assume the protocol should take out all my funds and hold them, correct? Because even though the chance is remote, there is still a possibility that BTC/USD will move up to $100,800 in the next block and I lose all my money.

Yes, it's all escrowed away immediately.

Ok great! Continuing with this scenario: let's say I make this bet (short BTC/USD at $800, leverage 1, with 100,000 XCP in my address) and it's included into block X. In block X+1 BTC/USD spikes to $200,000. Then in block X+2 BTC/USD crashes back to $800.

At the end of block X+1 the bet is closed and I lose all my XCP, correct?

Yes. That's the 'forced liquidation' scenario.

[xnova]

So nobody can help me with this?

All prerequisites installed, setup completed successful, this is what I get on running "counterpartyd server"

Code:

C:\counterpartyd_build>echo off
Traceback (most recent call last):
  File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 22, in
 <module>
    from lib import (config, api, zeromq, util, exceptions, bitcoin, blocks)
  File "C:\counterpartyd_build\dist\counterpartyd\lib\zeromq.py", line 14, in <m
odule>
    import zmq
ImportError: No module named zmq

Please see my response at https://forums.counterparty.co/index.php?topic=22.new#new

[halfcab123]

What does it mean to short and leverage??

[Patel]

Also, the bug that Patel reported before, about cancels not recrediting escrowed funds, has been fixed in both master and develop (but the fix is still somewhat untested).

Thank you Phantom,

Do I have to rebuild the database? The wallet still does not show the XCP.

I pulled the latest git's, and ran setup.py

[Patel]

Done it.

unfortunately this error came up:

Code:

C:\counterpartyd_build>C:\counterpartyd_build\run.py burn --from=1CibkcwpBRZAMZU
wv6hXE1eNoZ8Mb38cQg --quantity=0.0029
Confirm? (y/N) y
Traceback (most recent call last):
  File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 585, i
n <module>
    json_print(bitcoin.transmit(unsigned_tx_hex, unsigned=args.unsigned))
  File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 315, in
transmit
    return rpc('sendrawtransaction', [signed_tx_hex])
  File "C:\counterpartyd_build\dist\counterpartyd\lib\bitcoin.py", line 69, in r
pc
    raise exceptions.BitcoindError('{}'.format(response_json['error']))
lib.exceptions.BitcoindError: {'message': 'TX rejected', 'code': -22}

C:\counterpartyd_build>

Code:

'TX rejected', 'code': -22

 TX rejected?

I am getting this same error when sending.

[physalis]

I am getting this same error

When doing what? If I understand all of this correctly, the burn period is over, so running a burn command like in your quoted text should be rejected.

[Patel]

I am getting this same error

When doing what? If I understand all of this correctly, the burn period is over, so running a burn command like in your quoted text should be rejected.

Forgot to say its for a send.

[kdrop22]

We are on Reddit - upvote for visibility.
http://www.reddit.com/r/Bitcoin/comments/1wtz2b/2124_btc_destroyed_in_proofofburn/

[sixteendigits]

The guy selling WEED on the Dex gave me a marketing idea.

Of course you can sell weed on XCP! A Decentralized Silk Road is just a sub-feature of XCP. All you need is a guy with enough trust to issue an asset corresponding to say 1 oz of his product.

The forum would have to exist elsewhere, but transactions could be conducted entirely through XCP. The authorities could shut down the forum, but again there would be no money exchanged there. They sure as hell can't shut down XCP.

Silk Road made up something like 50% of Bitcoin transaction volume at one point.

Technology to support a decentralized virtual black market is live today. We live in the future.

Holy shit, you are right.  I guess I didn't stretch my imagination enough and thought of it more as a protocol merely for exchange of financial assets and virtual goods, but really this can be an exchange for ANYTHING.

I knew I was gonna regret not burning more BTC, this is gonna be huge.

[ddink7]

This is so big that I'm having a hard time wrapping my head around it.

Let's try something simple. How do I exchange XCP for BTC? I put up a trade in counterpartyd, then someone accepts my trade and my XCP go into escrow. The buyer then sends BTC to the address, and counterpartyd verifies that the BTC have arrived and releases my XCP to the buyer? Is that correct?

[ddink7]

This is so big that I'm having a hard time wrapping my head around it.

Let's try something simple. How do I exchange XCP for BTC? I put up a trade in counterpartyd, then someone accepts my trade and my XCP go into escrow. The buyer then sends BTC to the address, and counterpartyd verifies that the BTC have arrived and releases my XCP to the buyer? Is that correct?

I think in order to prevent double-spending your XCP are put into escrow as soon as you put up a trade, not when it gets matched.

Gotcha. But everything else works basically the same way? The buyer doesn't get my XCP until counterpartyd sees the BTC has been sent to the designated address?

[PhantomPhreak]

Also, the bug that Patel reported before, about cancels not recrediting escrowed funds, has been fixed in both master and develop (but the fix is still somewhat untested).

Thank you Phantom,

Do I have to rebuild the database? The wallet still does not show the XCP.

I pulled the latest git's, and ran setup.py

From which branch? Try running 'counterpartyd reparse'.

[wizzardTim]

Any clarification on BTCPAY?

[Patel]

Any clarification on BTCPAY?

Here are some useful commands

cd C:\counterpartyd_build
C:\Python32\python.exe run.py server


C:\Python32\python.exe run.py send --from=1xx --quantity=xx --asset=XCP --to=1xx

C:\Python32\python.exe run.py order --from=1xx --get-quantity=xx --get-asset=XCP --give-quantity=xx --give-asset=BTC --expiration=10 --fee_required=.001


C:\Python32\python.exe run.py btcpay --order-match-id=[enter tx hashes of both orders, combined]

C:\Python32\python.exe run.py cancel --offer-hash=[enter tx hash here]

[panonym]

Hi everyone
Over 30 pages to catch up after a few days of break, such communication
Things appear to go well.

I didn't test _cancel yet. Good to know the funds return have been fixed.
Glad to hear the GUI is becoming more concret.
By 15feb will we see an alpha version? or is it the beginning of a dedicated bounty raising?

GUI is great, but personally it's not what I'm waiting the most for.
As it still require the full Bitcoin blockain synced with txindex=1 & the XCP DB, for any trading use.
Which therefore might not speed up demand as much as some hope, 'coz install&gateway still are not that friendly for newbie.

I saw that 6 BTC where traded on Google Doc for 600 XCP, that's a nice start. 0.01BTC/XCP = 100XCP/BTC
Personally I think to wait 0.02BTC/XCP = 50XCP/BTC, and even then 'might only sell a little.

It's great that GUI, usage, doc and everything is improving. You're all doing an amazing job.
But strictly on a monetary point of view: we need a easier trading gateway.

Both the DEX & Google Doc have some disadvantage.
Don't get me wrong, I love the decentralized exchange.
(That may be the main feature that made me wish to burn that much)
But centralized exchange have for advantage to be easy & therefore allow massing buyer incoming.

I was thinking about a middle-way solution.
No idea if that is technically possible to make in a safe way, but here is a draft:

- early adopter & experimented ones can broadcast _{sell order} of XCP4BTC on the DEX.
- dev need to create/add an alternative OrderID (a partial/sell one, different from a match one)  
- then outsider can easily trade their BTC for XCP (or assets) by using blockchain.info
  simply by checking on blockscan.com for existing valid ext-sell-OrderID
  BTC seller have to be very careful while adding a specific message along their transaction
  counterypartyd would check the communication
  When a BTC transaction with the specific data is detected (multi-sig ? something similar to what _btcpay output write),
  the XCP in hold would be released/transferred to the XCPbuyer/BTCseller-pubkey

Over a few weeks with cooperation from different community member we could reach a semi-centralized exchange.
50% centralized with decentralized core.

---

In any case, the XCP seller would still have to use the DEX.
Just like now: need two order matching, then a _btcpay from the BTCseller
Or the solution proposed upper.
The sole downside I see is the work it ask.
- the XCPcoredev must make modification to XCPd to allow XCP&Asset release/exchange without the internal _btcpay.
  [Is it do-able?]
- Blockscan webmaster will also have stuff to do, but with the advantage that - mtbitcoin - you will not have to manage the security trouble/responsibility that come with a regular exchange or online wallet.
   Just listing the current OrderID(SellID) of valid XCP sell order.
- This solution would serve as secondary gateway.
  Easier & faster that the DEX, but with disadvantage that order are not match "at best" anymore.  
  They are at fixed rate, with fixed XCPseller pubkey-destination,
  where order/sell validity much be checked on blockscan with a slight trust issue toward the WM (& blockchain.info WM)

Despite all these downside, I think this second gateway would bring a huge boost of XCP market value.
Main gateway use should still be considered the main & better one.
But finally people would no longer need solution such as Google Doc (where the trust/scam factor is much worst - and not fast / real time).

Thanks for reading.
All comments appreciated.


edit:
MUCH simpler solution, perhaps...
I don't understand the multisig stuff, or should I write: how it is implemented/transmitted. (2of3 I catch)

What exactly is done when the command _order and _btcpay are sent?
Couldn't that be replicated outside counterpartyd?
If order50XCPfor1BTC generate a text that is linked to a BTC transaction, it should be possible to generate this text manually and then send 0.0001BTC to the right pubkey with the correct data.
Allowing to create a match on the DEX without using XCPd.
Then do the same with _btcpay equivalent.
Result: any XCPbuyer would just have to send 2 BTC transaction, while being careful with the data.
Trustless, secure, decentralized, not much work. Just a tuto for manually get the right data.
(Or a tuto how to send specific multisig transaction with the right data)

Sry for the over-long post, no direct thought broadcasting capacity available at the moment ~.~

[rotalumis]

This is so big that I'm having a hard time wrapping my head around it.

Let's try something simple. How do I exchange XCP for BTC? I put up a trade in counterpartyd, then someone accepts my trade and my XCP go into escrow. The buyer then sends BTC to the address, and counterpartyd verifies that the BTC have arrived and releases my XCP to the buyer? Is that correct?

I think in order to prevent double-spending your XCP are put into escrow as soon as you put up a trade, not when it gets matched.

Gotcha. But everything else works basically the same way? The buyer doesn't get my XCP until counterpartyd sees the BTC has been sent to the designated address?

What happens if the XCP sale offer expires before the BTC arrive? Are you now at the mercy of the seller to return your BTC or choose to honor the trade? If I have understood correctly, Counterparty can only escrow XCP and assets generated inside its system.

[Patel]

This is so big that I'm having a hard time wrapping my head around it.

Let's try something simple. How do I exchange XCP for BTC? I put up a trade in counterpartyd, then someone accepts my trade and my XCP go into escrow. The buyer then sends BTC to the address, and counterpartyd verifies that the BTC have arrived and releases my XCP to the buyer? Is that correct?

I think in order to prevent double-spending your XCP are put into escrow as soon as you put up a trade, not when it gets matched.

Gotcha. But everything else works basically the same way? The buyer doesn't get my XCP until counterpartyd sees the BTC has been sent to the designated address?

What happens if the XCP sale offer expires before the BTC arrive? Are you now at the mercy of the seller to return your BTC or choose to honor the trade? If I have understood correctly, Counterparty can only escrow XCP and assets generated inside its system.

your btc don't leave when you place an order, after an order is matched, then you send the btc. I am not sure if orders will stay matched after expiration though.