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

[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.

[JahPowerBit]

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.

I think yes, you are at the mercy of the seller..

[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

From which branch? Try running 'counterpartyd reparse'.

I ran reparse, but it says its not a valid choice.

C:\counterpartyd_build>C:\Python32\python.exe run.py reparse
usage: counterpartyd [-h] [-V] [-v] [--force] [--testnet] [--testcoin]
                     [--unsigned] [--data-dir DATA_DIR]
                     [--database-file DATABASE_FILE]
                     [--config-file CONFIG_FILE] [--log-file LOG_FILE]
                     [--bitcoind-rpc-connect BITCOIND_RPC_CONNECT]
                     [--bitcoind-rpc-port BITCOIND_RPC_PORT]
                     [--bitcoind-rpc-user BITCOIND_RPC_USER]
                     [--bitcoind-rpc-password BITCOIND_RPC_PASSWORD]
                     [--rpc-host RPC_HOST] [--rpc-port RPC_PORT]
                     [--rpc-user RPC_USER] [--rpc-password RPC_PASSWORD]
                     [--zeromq-host ZEROMQ_HOST] [--zeromq-port ZEROMQ_PORT]

                     {server,send,order,btcpay,issuance,broadcast,bet,dividend,b
urn,cancel,address,asset,wallet,market,purge}
                     ...
counterpartyd: error: argument action: invalid choice: 'reparse' (choose from 's
erver', 'send', 'order', 'btcpay', 'issuance', 'broadcast', 'bet', 'dividend', '
burn', 'cancel', 'address', 'asset', 'wallet', 'market', 'purge')


I pulled the latest git using

cd C:\counterpartyd_build
git pull origin master
cd C:\counterpartyd_build\dist\counterpartyd
git pull origin master

[rotalumis]

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.

I think we have the same question...

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.

I think yes, you are at the mercy of the seller..

That would make the examples I saw of trades (not real ones) with expirations of 3 to 5 blocks very tight, no? Especially when you account for the randomness of block generation.

[cryptrol]

I ran reparse, but it says its not a valid choice.

purgue will reparse the counterparty DB.

[PhantomPhreak]

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.

I think we have the same question...

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.

I think yes, you are at the mercy of the seller..

That would make the examples I saw of trades (not real ones) with expirations of 3 to 5 blocks very tight, no? Especially when you account for the randomness of block generation.

You don't want to do a BTCpay right before the order match is set to expire (especially in the future, when blocks are closer to being full).

[Patel]

I ran reparse, but it says its not a valid choice.

purgue will reparse the counterparty DB.

Thank you!  

Thanks Phantom for the fix, the XCP is now showing in the wallet.

[panonym]

I see a few have trouble to grasp the order & btcpay process.
These 2 example might help:

Alice give 50 XCP for 1 BTC, blocktime 100 [XCP put in escrow, timer 1]
Bob give 1 BTC for 50 XCP, blocktime 10 [no BTC put in escrow, timer 2]
Need 1 blocktime to match
Bob will have 9 blocktime to _btcpay with the matching Order ID [timer 3 = new timer]

Alice give 50 XCP for 1 BTC, blocktime 20 [XCP put in escrow only a short time]
Bob give 1 BTC for 50 XCP, blocktime 200 [not BTC put in escrow]
Need 1 blocktime to match
Bob will have 19 blocktime to _btcpay the matching Order ID

I haven't test, but I guess if there is only 1blocktime left for a matching order:
either it pass at the last moment and the exchange is done
or there is a message error that the Order ID has expired.

I hope it helped.
Tired, sorry if I answered aside to something that wasn't asked.

[wizzardTim]

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=3 --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]

Thank you

[rotalumis]

You don't want to do a BTCpay right before the order match is set to expire (especially in the future, when blocks are closer to being full).

Can this be foolproofed somehow before going mainstream? I'd hate to think of all the posts on the forums when people start losing BTC. Maybe the BTCpay operation can accept an order match number as an optional parameter and the escrow time extended if necessary for the amount of that specific order only, provided BTCpay is called before the offer expires. The number of blocks to extend would be based on what the protocol determines is reasonable at the time or could be hardcoded initially.