Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread - page 559. (Read 1276933 times)

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

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

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.

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.

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

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]

Any clarification on BTCPAY?

From which branch? Try running 'counterpartyd reparse'.

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?

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?

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.

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

Forgot to say its for a send.

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.

I am getting this same error when sending.

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

What does it mean to short and leverage??

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

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

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