Bitcoin Forum
March 29, 2024, 08:26:06 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 [128] 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 ... 661 »
  Print  
Author Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread  (Read 1276267 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
mtbitcoin
Legendary
*
Offline Offline

Activity: 876
Merit: 1000


Etherscan.io


View Profile
February 08, 2014, 03:48:33 PM
 #2541

Getting another error now with v 0.4

I am pretty sure it does not exceed 8 decimals

buy 0.12 btc for 20 XCP

---
Traceback (most recent call last):
  File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 515, in <module>
    fee_provided = util.devise(db, args.fee_provided, 'BTC', 'input')
  File "C:\counterpartyd_build\dist\counterpartyd\lib\util.py", line 552, in devise
    raise exceptions.QuantityError('Divisible assets have only eight decimal places of precision.')
lib.exceptions.QuantityError: Divisible assets have only eight decimal places of precision.

EtherScan::Ethereum Block Explorer | BlockScan::Coming Soon
1711700766
Hero Member
*
Offline Offline

Posts: 1711700766

View Profile Personal Message (Offline)

Ignore
1711700766
Reply with quote  #2

1711700766
Report to moderator
1711700766
Hero Member
*
Offline Offline

Posts: 1711700766

View Profile Personal Message (Offline)

Ignore
1711700766
Reply with quote  #2

1711700766
Report to moderator
1711700766
Hero Member
*
Offline Offline

Posts: 1711700766

View Profile Personal Message (Offline)

Ignore
1711700766
Reply with quote  #2

1711700766
Report to moderator
"The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711700766
Hero Member
*
Offline Offline

Posts: 1711700766

View Profile Personal Message (Offline)

Ignore
1711700766
Reply with quote  #2

1711700766
Report to moderator
1711700766
Hero Member
*
Offline Offline

Posts: 1711700766

View Profile Personal Message (Offline)

Ignore
1711700766
Reply with quote  #2

1711700766
Report to moderator
1711700766
Hero Member
*
Offline Offline

Posts: 1711700766

View Profile Personal Message (Offline)

Ignore
1711700766
Reply with quote  #2

1711700766
Report to moderator
rashley
Newbie
*
Offline Offline

Activity: 10
Merit: 0


View Profile
February 08, 2014, 03:55:29 PM
 #2542

I posted a valid order to buy XCP and it was correctly matched. I did counterpartyd market to see orders awaiting BTC payment by me and took the matched order id from there and then executed

counterpartyd btcpay --order-match-id=9ce90757c8f8d9c0c3cffb429d01c737cac39ccfc630d783e8812b468c01e76ce99f02130953b989da98f2d862069d6f6b8b4aa98fc59c457433b96467b8b023

That all went fine, no errors. But the transaction never got confirmed and no XCP has shown up.
 
Did I do something wrong?
Patel
Legendary
*
Offline Offline

Activity: 1324
Merit: 1007



View Profile WWW
February 08, 2014, 03:56:30 PM
 #2543

I posted a valid order to buy XCP and it was correctly matched. I did counterpartyd market to see orders awaiting BTC payment by me and took the matched order id from there and then executed

counterpartyd btcpay --order-match-id=9ce90757c8f8d9c0c3cffb429d01c737cac39ccfc630d783e8812b468c01e76ce99f02130953b989da98f2d862069d6f6b8b4aa98fc59c457433b96467b8b023

That all went fine, no errors. But the transaction never got confirmed and no XCP has shown up.
 
Did I do something wrong?


wait for it to confirm. Most of the time, you won't see the tx's on blockchain.info until it gets confirmed
peled1986
Legendary
*
Offline Offline

Activity: 882
Merit: 1002


View Profile
February 08, 2014, 04:03:29 PM
 #2544

i want to try and sell XCPs using the Distributed exchange.

this is the top buying order: http://blockscan.com/order.aspx?q=3447

so if i want to sell to him 1 XCP i write the following command? :

order --source=15FYGCAaae3jCR4agQWJUoFjsE2qomftSn --get-quantity=0.006 --get-asset=BTC
--give-quantity=1 --give-asset=XCP --expiration=10 --fee_required=0


520Bit
Sr. Member
****
Offline Offline

Activity: 602
Merit: 252



View Profile
February 08, 2014, 04:06:11 PM
 #2545

i want to try and sell XCPs using the Distributed exchange.

this is the top buying order: http://blockscan.com/order.aspx?q=3447

so if i want to sell to him 1 XCP i write the following command? :

order --source=15FYGCAaae3jCR4agQWJUoFjsE2qomftSn --get-quantity=0.006 --get-asset=BTC
--give-quantity=1 --give-asset=XCP --expiration=10 --fee_required=0




If you really want to sell, set the expiration time long enough, say 100 blocks. And the --fee_required=0.0001 is recommended to pay for the miners.
peled1986
Legendary
*
Offline Offline

Activity: 882
Merit: 1002


View Profile
February 08, 2014, 04:12:15 PM
 #2546

how does the protocol know from which address i am paying the XCPs from? thats the source address?
520Bit
Sr. Member
****
Offline Offline

Activity: 602
Merit: 252



View Profile
February 08, 2014, 04:23:17 PM
 #2547

how does the protocol know from which address i am paying the XCPs from? thats the source address?

Exactly, the source address will pay for the XCP if it has sufficient XCP and BTC.
peled1986
Legendary
*
Offline Offline

Activity: 882
Merit: 1002


View Profile
February 08, 2014, 04:31:18 PM
 #2548

i made a sell order for 1 XCP @ 0.006
so should my sell order match this buy order: http://www.blockscan.com/order.aspx?q=3447 immediately once my sell has 1 confirmation?
(sorry for all the questions)
mtbitcoin
Legendary
*
Offline Offline

Activity: 876
Merit: 1000


Etherscan.io


View Profile
February 08, 2014, 04:43:54 PM
 #2549

i made a sell order for 1 XCP @ 0.006
so should my sell order match this buy order: http://www.blockscan.com/order.aspx?q=3447 immediately once my sell has 1 confirmation?
(sorry for all the questions)

I think this is yours http://www.blockscan.com/order_match.aspx?q=3482

You just have to wait for the XCP buyer to issue a btcpay matching your order hash and you're good to go

EtherScan::Ethereum Block Explorer | BlockScan::Coming Soon
peled1986
Legendary
*
Offline Offline

Activity: 882
Merit: 1002


View Profile
February 08, 2014, 04:46:41 PM
 #2550

i made a sell order for 1 XCP @ 0.006
so should my sell order match this buy order: http://www.blockscan.com/order.aspx?q=3447 immediately once my sell has 1 confirmation?
(sorry for all the questions)

I think this is yours http://www.blockscan.com/order_match.aspx?q=3482

nice. the protocol matches with the highest current buy order: http://www.blockscan.com/order.aspx?q=3482
520Bit
Sr. Member
****
Offline Offline

Activity: 602
Merit: 252



View Profile
February 08, 2014, 04:52:05 PM
 #2551

i made a sell order for 1 XCP @ 0.006
so should my sell order match this buy order: http://www.blockscan.com/order.aspx?q=3447 immediately once my sell has 1 confirmation?
(sorry for all the questions)

I think this is yours http://www.blockscan.com/order_match.aspx?q=3482

nice. the protocol matches with the highest current buy order: http://www.blockscan.com/order.aspx?q=3482

Ii should be, that's how the Counterparty protocol works. Happy trading in Counterparty.
peled1986
Legendary
*
Offline Offline

Activity: 882
Merit: 1002


View Profile
February 08, 2014, 04:56:08 PM
 #2552

another small questions:
how can i check which version of counterpartyd is currently installed?
(i am not sure if am running the new V0.3)

and why are the top buy and sell orders not matching immediately?
http://www.blockscan.com/order_book.aspx
mtbitcoin
Legendary
*
Offline Offline

Activity: 876
Merit: 1000


Etherscan.io


View Profile
February 08, 2014, 04:57:33 PM
 #2553

another small questions:
how can i check which version of counterpartyd is currently installed?
(i am not sure if am running the new V0.3)

and why are the top buy and sell orders not matching immediately?
http://www.blockscan.com/order_book.aspx

-V for checking version

I am running the latest develop git .. And I suspect there still might be pending issues due to the rounding/division bugs

EtherScan::Ethereum Block Explorer | BlockScan::Coming Soon
knyhetin
Newbie
*
Offline Offline

Activity: 22
Merit: 0


View Profile
February 08, 2014, 05:20:17 PM
 #2554

a few days ago I placed a sell order that was wiped out by this guy http://www.blockscan.com/order.aspx?q=3336
assuming that this troll will never pay, I'm not sure what happens in these cases.
If the buyer doesn't process a btcpay, what happens to the xcp placed in the orderbook?
Am I supposed to just wait or am I supposed to cancel my order (if it's possible)?
jimhsu
Sr. Member
****
Offline Offline

Activity: 364
Merit: 264


View Profile
February 08, 2014, 10:16:52 PM
 #2555

a few days ago I placed a sell order that was wiped out by this guy http://www.blockscan.com/order.aspx?q=3336
assuming that this troll will never pay, I'm not sure what happens in these cases.
If the buyer doesn't process a btcpay, what happens to the xcp placed in the orderbook?
Am I supposed to just wait or am I supposed to cancel my order (if it's possible)?


Wait for your order to expire naturally.

Lesson learned: set a shorter expiration time, or use fee_required. Until we get those upcoming "anti-troll" features currently in discussion.

Dans les champs de l'observation le hasard ne favorise que les esprits préparé
jimhsu
Sr. Member
****
Offline Offline

Activity: 364
Merit: 264


View Profile
February 08, 2014, 10:19:32 PM
 #2556

I have  bug report
When I place an order for XCP, the balance of BTC in my wallet becomes unconfirmed. Then I have to reboot (windows 7), restart bitcoind , and counterpartyd, before the BTC is again marked as confirmed, and the order is sent out.


You don't have to reboot your computer, just wait for 1 confirm.

The reason is because counterpartyd sweeps the balance of your BTC address, uses some of it to generate data, and then gives you back the rest in change.

To nitpick, counterparty takes the smallest unspent coin in your walletaddress, and issues a transaction off of that. Therefore it could be a good idea to keep some unspent outputs (blockchain.info can identify those) in your walletaddress to be able to issue more than one counterparty transaction per block.

PS address, not wallet. Another one of the things that bitcoin-qt simply doesn't bother to make clear.

Dans les champs de l'observation le hasard ne favorise que les esprits préparé
Patel
Legendary
*
Offline Offline

Activity: 1324
Merit: 1007



View Profile WWW
February 08, 2014, 10:22:33 PM
Last edit: February 09, 2014, 01:35:34 AM by Patel
 #2557

I have  bug report
When I place an order for XCP, the balance of BTC in my wallet becomes unconfirmed. Then I have to reboot (windows 7), restart bitcoind , and counterpartyd, before the BTC is again marked as confirmed, and the order is sent out.


You don't have to reboot your computer, just wait for 1 confirm.

The reason is because counterpartyd sweeps the balance of your BTC address, uses some of it to generate data, and then gives you back the rest in change.

To nitpick, counterparty takes the smallest unspent coin in your walletaddress, and issues a transaction off of that. Therefore it could be a good idea to keep some unspent outputs (blockchain.info can identify those) in your walletaddress to be able to issue more than one counterparty transaction per block.

PS address, not wallet. Another one of the things that bitcoin-qt simply doesn't bother to make clear.

doing something like this:

https://blockchain.info/tx/779936e5278f492e64529824a77f9b4c3ed6718760c97f28f9c44dedecdfe3d6?show_adv=true
rashley
Newbie
*
Offline Offline

Activity: 10
Merit: 0


View Profile
February 09, 2014, 12:35:28 AM
 #2558

I've had a couple transactions go through today, and I still have 5 order id's that show up when I look at counterparty market. I guess they'll just expire but I'd hate for those people to think I'm a troll :-)
PhantomPhreak (OP)
Sr. Member
****
Offline Offline

Activity: 476
Merit: 300

Counterparty Chief Scientist and Co-Founder


View Profile
February 09, 2014, 01:29:12 AM
 #2559

Getting another error now with v 0.4

I am pretty sure it does not exceed 8 decimals

buy 0.12 btc for 20 XCP

---
Traceback (most recent call last):
  File "C:\counterpartyd_build\dist\counterpartyd\counterpartyd.py", line 515, in <module>
    fee_provided = util.devise(db, args.fee_provided, 'BTC', 'input')
  File "C:\counterpartyd_build\dist\counterpartyd\lib\util.py", line 552, in devise
    raise exceptions.QuantityError('Divisible assets have only eight decimal places of precision.')
lib.exceptions.QuantityError: Divisible assets have only eight decimal places of precision.

That problem should be fixed in this commit.
MoneypakTrader.com
Sr. Member
****
Offline Offline

Activity: 472
Merit: 250


Never spend your money before you have it.


View Profile
February 09, 2014, 01:59:31 AM
 #2560

There is some discussion on how to improve the protocol, specifically the critical "free options to buy all offered XCP until they expire with a single BTC order" flaw that one alpha-tester pointed out a few days ago (resulting in a critical order-book-clearing, locking all XCP orders for their full duration).
Here is the proposal some of us support which was cleaned up and more fully described by jeremy to fix that problem and also implement some added functionality to the options system that this protocol uses such as to prevent micro-orders from burdening BTCpay'ers:

https://forums.counterparty.co/index.php/topic,71.msg321.html#msg321
Quote from: jeremy
I'm heavily invested in the XCP system and want to see it succeed and do better.

MoneypakTrader offered some good solutions for fixing a few of the problems the system currently has: https://bitcointalk.org/index.php?topic=395761.msg5009075#msg5009075
Building on those suggestions, I'd advocate the following improvements:

FIRST SUGGESTION:
All orders should include the major version number of the client issuing the order to prevent matching problems that users have experienced. The protocol should not allow matches of different major version and should inform the user if other version numbers are more popular than the one used to suggest upgrading. The new version should show the old version order book and the new version order book to allow placing orders under either systems.
Essentially these are hard forks. Older clients can still make trades with each other, but for added features and trades with new clients, it must be updated.
Again, new clients should have a feature to view and issue orders/commands at older version levels just in case significant users/orders resist the upgrades and the new client user wishes to match older version orders.

SECOND SUGGESTION:
All orders involving BTC should be able to set an optional variable [minimum] (amount of BTC for each valid match), denominated in BTC (for efficiency reasons). Leftover amounts in the order book for less than the [minimum] should be cancelled from the order book and returned to the owner AFTER ALL other fractions of that order are COMPLETELY BTCpayd for.
This works particularly well when combined with the other following improvements.

Reason:
"BTC for XCP" orders require a second "BTCpay" to complete EACH order match made, this wouldn't be an issue except:
1) Significant fees (around 40 cents/0.0004btc) are required for EACH "BTCpay" action make small transactions (<1 XCP) proportionally very expensive (as described by moneypaktrader on bitcointalk around their above linked post time).

Here's a scenario, suppose I want to spend some BTC to buy 50XCP at the best possible DEX rates and the order book looks like this:
XCP for BTC orders:
1 XCP @ 0.0040 (total costs with btcpay = 0.0044 btc/xcp, ignoring the costs to place the btc/xcp orders)
2 XCP @ 0.0041 (total costs with btcpay = 0.0043 btc/xcp, ignoring the costs to place the btc/xcp orders)
1 XCP @ 0.0042 (total costs with btcpay = 0.0046 btc/xcp, ignoring the costs to place the btc/xcp orders)
50 XCP @ 0.00425 (total costs with btcpay = 0.004258 btc/xcp, ignoring the costs to place the btc/xcp orders)

I have an incentive to place a btc for xcp order for enough quantity (or more) to buy at least all the orders through the 50 XCP order but only "btcpay" for the single 50 XCP order match which is the best price for the quantity I want.

When combined with fees per match described below, this feature is almost necessary to avoid excessive fees from numerous matches.

THIRD SUGGESTION:
Because BTC orders get the option to pay or not to complete the order, the orders requesting BTC should be allowed to charge/receive an XCP fee for providing that option. I agree with MPT that this fee should be waived/ignored for the first matched order to prevent clogging the order book with high match fees, the BTC order will be paying sufficient network fees to justify getting a first match without a fee. Also using XCP for this fee will encourage XCP usage and drive demand for XCP by high volume traders.

New Variables needed -
A) Orders requesting BTC have an OPTIONAL variable [fee-charged] (defaults to 0 if not set).
B) Orders offering to pay BTC have an OPTIONAL (XCP) input [fees-provided] (defaults to 0 if not set). This is deducted from the xcp of the BTC address of the BTC offer and escrowed for use until the order completes/expires.
C) Orders offering to pay BTC have an OPTIONAL variable [max-fee] (defaults to total fees-provided balance or 0 if not set).

How it would work -
The first otherwise valid match to a BTC order is matched with no fee deducted from B.
After the first match, B (fees-provided) and C (max-fee) must be greater than or equal to A (fee-charged) or it does not get matched and goes to the next order/match. The remaining balance of B and variable C must still be greater than or equal to each A of each future match (or A must equal 0 if B=0).
Each match after the first gets paid immediately the XCP value agreed and the balance of B is reduced accordingly. Balance of B is refunded to the BTC offer on completion/expiration of the order.

Why? "XCP for BTC" orders must wait until their order expires and currently receive no compensation for giving the option to buy to the "BTC for XCP" order for the duration of their order time. At the same time, the initial order requires some expense to create and that should be conidered enough payment to justify one free match. Also, requiring a fee for the first match would allow high fees and low prices reaulting in a strange looking order book.

FOURTH SUGGESTION:
1) Orders requesting BTC may designate an optional variable [max-time] to btcpay (defaults to remaining expiration time):
Only BTC offering orders with less than or equal to this amount of expiration time remaining are matchable. Matches that aren't paid for in this time are returned to the order book as usual.
DECISION FOR HOW TO IMPLEMENT THIS FEATURE:
EITHER a) the max time will allow extending past the orders expiration time or b) the expiration time remaining must be greater than the max-time or the remaining orders are cancelled. It's not so important which, just must be documented which method is used.

NOTE: BTC offering orders should NOT have a second variable for lock time because they should need to know EXACTLY when they will need to plan to be online to check orders and having such a variable is too random for someone who wants to collect several matches over a few days an then pay them all by their expiration time. i.e. it would make it too unpredictable just like the current system.

FIFTH SUGGESTION:
This is possibly unnecessary with the other features, but some people might want to trade with each other so this would help them:
Allow direct order matching for the cost of the fee-charged described above.
Self explanatory, but could be from just having a new variable --buy-order XXXX and the order will only match against that order number (either matched or not).

SIXTH SUGGESTION:
There should be a variable for order persistence (or not) (should default to yes as currently provided), but some people might want their order to NOT relist after failed purchases.

In regards to other people's suggestion to simply charge more miner fees:
As MPT noted, it is wasteful to simply ask for the BTC for Asset order to burn/spend/waste BTC in miner fees, that is equivalent to asking them to piss away money for no benefit.
In regards to escrow, that does not give anyone value immediately for the immediate loss of use of the Asset. That's why the fee is better. They should be compensated directly for the option if the option is given rather than only compensated in failure to pay.

Pages: « 1 ... 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 [128] 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 ... 661 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!