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

[520Bit]

Maybe I'm missing something at the protocol level, but why can't the suggestion above be implemented? Wouldn't that prevent trolling, since people who place an order will be obligated to fulfil it if matched? Also, what is the problem with having an automatic BTCpay once an order is matched? Shouldn’t XCP be like any other market; i.e. if you place an order you should be obligated to transact if it’s matched.

This would only be a check that is performed at the client that is creating the order.The Bitcoin protocol doesn't allow checking the balance of arbitrary addresses so other nodes won't be able to verify this.

If the check was added to the client:

1) It doesn't stop someone creating the order anyway with either a non-standard version of Counterparty.
2) You could just transfer the BTC away from your address after submitting the order. BTC can't be held in escrow.

By placing a fee_required amount on your trade, you are giving an incentive for the person to follow through with the BTCPAY. If they don't, they have just given a nice miner's fee, which helps BTC anyway.

+1 So I will wait for the OP_RETURN being implemented to solve the fees issue.

OP_RETURN has nothing to do with order fees.

I'm the owner of Poloniex, and I'm trying to figure out how to get XCP on the exchange. I have some questions, as I'm not completely sure how it works yet...

1. Someone sent me 2 XCP for testing. I also got about 0.0001 BTC. I'm guessing this is because XCP is sent over BTC transactions, and you have to send at least a little BTC in order to send XCP. Correct?
2. I tried to send XCP to another address, but it tells me I need 0.0003 BTC. Why this amount? Where does it go? Is the amount adjustable?
3. I can see this being a bit of a problem, keeping track of both BTC and XCP. What if someone sends a deposit of 1000 XCP and then withdraws 1 XCP 1000 times? Would this not drain the BTC balance?

1. That's correct, yes.

2. Yes. Most of that goes back to the sending address in a multi-sig output (which few?! clients right now can spend). The amount is determined by what Bitcoind considers dust multi-sig outputs. When OP_RETURN support gets added to Bitcoind (very soon?!), only the .0001 BTC miners' fee will be required.

3. It is certainly an extra thing to keep track of. So have a minimum withdrawal amount... most exchanges do. Also require a sufficient BTC balance to withdraw.

Got it , I misunderstood the OP_RETURN function. So the 0.0001086+0.0001086 BTC dust size could be spent after OP_RETURN support being implemented. I understand now 0.0002172 BTC totally are not the fees. Like this kind of transactions: https://blockchain.info/tx/7b80040a18c70f279ac32c7032e69c46aff50ee76398df7babf6f9039ed2561d. People can still spend them after OP_RETURN is supported.

Thanks for your clarification, PhantomPhreak.

[PhantomPhreak]

This thread is for protocol discussion. Please don't discuss non-protocol issues here. The bitcoind is the only network interface for counterpartyd (as it should be) and it can't check arbitrary bitcoin balances.

This thread is not only for protocol discussion (see the thread's title).

[PhantomPhreak]

Thanks, PhantomPhreak. One more thing. Bitcoind can generate an arbitrary number of addresses for one wallet. Is XCP aware of this, or is every BTC address a separate XCP wallet?

counterpartyd treats every address in the Bitcoind wallet independently.

[busoni]

When I call balances to counterpartyd, it gives me the output in a visually appealing table, but a form that is a little difficult to parse. Is there another way to get balances? (Or better still, something like list transactions that wouldn't necessitate checking every balance individually?)

[porqupine]

This thread is for protocol discussion. Please don't discuss non-protocol issues here. The bitcoind is the only network interface for counterpartyd (as it should be) and it can't check arbitrary bitcoin balances.

On another note, when a BTC sell order is insolvent for some filled part, I think it should wipe the entire order - this would at least prevent buy-wall trolling.

Using your proposal
I place an order to buy 100 XCP in 100 blocks with 1 BTC,
It matches an alpha-testers order to sell 0.001 XCP for 0.0000001 BTC in 1 block which is possible under the current protocol specification.
I just lost all my fees if your proposal was implemented, boo hoo for me.

Why don't you like our suggestions to prevent buy-walling?
https://forums.counterparty.co/index.php/topic,71.0.html
THIRD SUGGESTION is the most powerful free market style solution, but they really work great when all put together.
FOURTH SUGGESTION is the most urgent for a "quick fix"
But at least we can still trade away our XCP alt-coin style (off-dex) while the DEX protocol is broke. see my sig to buy xcp easily. Even if the DEX has some critical flaws it works great as a 100% proof of stake alt-coin, right?

2. Yes. Most of that goes back to the sending address in a multi-sig output (which few?! clients right now can spend). The amount is determined by what Bitcoind considers dust multi-sig outputs. When OP_RETURN support gets added to Bitcoind (very soon?!), only the .0001 BTC miners' fee will be required.

Right, I think my uncles friends cousins wife's step sister heard about someone who once saw someone spend one of those multisig's. They didn't remember which one of those few clients was used though.

I am not very clear on how the fee required variable for the BTC give is interacting in the code (should it just be the check that the BTC seller is providing at least as much of a Fee as the matched order requires?)

Then why does this look backwards ?
 

Code:

       # Check whether fee conditions are satisfied.
        if tx1['get_asset'] == 'BTC' and tx0['fee_provided'] < tx1['fee_required']: continue
        elif tx1['give_asset'] == 'BTC' and tx1['fee_provided'] < tx0['fee_required']: continue

        # Make sure that that both orders still have funds remaining [to be sold].
        if tx0['give_remaining'] <= 0 or give_remaining <= 0: continue

[PhantomPhreak]

When I call balances to counterpartyd, it gives me the output in a visually appealing table, but a form that is a little difficult to parse. Is there another way to get balances? (Or better still, something like list transactions that wouldn't necessitate checking every balance individually?)

Can you use the API, or do you need something like a CSV table for shell scripting?

[cityglut]

Announcement: We have chosen Matt Young (bitcointalk user "Matt Y") to join the Counterparty team and help with public relations. The position is on a month-to-month basis for the time being.

We have decided to pay for Matt's assistance ourselves, and will be moving funds from the marketing donation address to the "centralized exchange bounty" donation address.

[PhantomPhreak]

This thread is for protocol discussion. Please don't discuss non-protocol issues here. The bitcoind is the only network interface for counterpartyd (as it should be) and it can't check arbitrary bitcoin balances.

On another note, when a BTC sell order is insolvent for some filled part, I think it should wipe the entire order - this would at least prevent buy-wall trolling.

Using your proposal
I place an order to buy 100 XCP in 100 blocks with 1 BTC,
It matches an alpha-testers order to sell 0.001 XCP for 0.0000001 BTC in 1 block which is possible under the current protocol specification.
I just lost all my fees if your proposal was implemented, boo hoo for me.

Why don't you like our suggestions to prevent buy-walling?
https://forums.counterparty.co/index.php/topic,71.0.html
THIRD SUGGESTION is the most powerful free market style solution, but they really work great when all put together.
FOURTH SUGGESTION is the most urgent for a "quick fix"
But at least we can still trade away our XCP alt-coin style (off-dex) while the DEX protocol is broke. see my sig to buy xcp easily. Even if the DEX has some critical flaws it works great as a 100% proof of stake alt-coin, right?

2. Yes. Most of that goes back to the sending address in a multi-sig output (which few?! clients right now can spend). The amount is determined by what Bitcoind considers dust multi-sig outputs. When OP_RETURN support gets added to Bitcoind (very soon?!), only the .0001 BTC miners' fee will be required.

Right, I think my uncles friends cousins wife's step sister heard about someone who once saw someone spend one of those multisig's. They didn't remember which one of those few clients was used though.

I am not very clear on how the fee required variable for the BTC give is interacting in the code (should it just be the check that the BTC seller is providing at least as much of a Fee as the matched order requires?)

Then why does this look backwards ?
 

Code:

       # Check whether fee conditions are satisfied.
        if tx1['get_asset'] == 'BTC' and tx0['fee_provided'] < tx1['fee_required']: continue
        elif tx1['give_asset'] == 'BTC' and tx1['fee_provided'] < tx0['fee_required']: continue

        # Make sure that that both orders still have funds remaining [to be sold].
        if tx0['give_remaining'] <= 0 or give_remaining <= 0: continue

It looks right to me: in the first case, e.g., BTC is going from tx0 to tx1 ('forward in time'), and tx0 provides the fee that tx1 requires.

[DaFockBro]

Who else is down to Counterparty when we hit 0.10 BTC/XCP a couple years from now?

[busoni]

When I call balances to counterpartyd, it gives me the output in a visually appealing table, but a form that is a little difficult to parse. Is there another way to get balances? (Or better still, something like list transactions that wouldn't necessitate checking every balance individually?)

Can you use the API, or do you need something like a CSV table for shell scripting?

I'm looking into the API now. It would just be easier if I could do everything from the command line, because nothing is set up to make API calls.

[520Bit]

Announcement: We have chosen Matt Young (bitcointalk user "Matt Y") to join the Counterparty team and help with public relations. The position is on a month-to-month basis for the time being.

We have decided to pay for Matt's assistance ourselves, and will be moving funds from the marketing donation address to the "centralized exchange bounty" donation address.

Great to hear new member join in the Counterparty team.

P.S: The GUI bounty donation address makes a little laugh  to me, people are sending other useless assets like PEERPAY, NEXT, REALESTATE, LOVE and BITCOIN to the address 12J1YFvsWHDCU5HNAWNLNy1Q9nZo8Q4Xgs. Will these useless assets be used as a part of the bounty?

http://blockscan.com/address.aspx?q=12J1YFvsWHDCU5HNAWNLNy1Q9nZo8Q4Xgs

[porqupine]

It looks right to me: in the first case, e.g., BTC is going from tx0 to tx1 ('forward in time'), and tx0 provides the fee that tx1 requires.

Yes, I see.

Jeremy brought up the issue on the Counterparty forums that (https://forums.counterparty.co/index.php/topic,71.0.html):

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)

What about adding Fee required in the Sort Order Matches term when calculating price?

Code:

        order_matches = sorted(order_matches, key=lambda x: x['tx_index'])                              # Sort by tx index second.
        order_matches = sorted(order_matches, key=lambda x: D(x['get_amount']) / D(x['give_amount']))

This thread is for protocol discussion. Please don't discuss non-protocol issues here. The bitcoind is the only network interface for counterpartyd (as it should be) and it can't check arbitrary bitcoin balances.

On another note, when a BTC sell order is insolvent for some filled part, I think it should wipe the entire order - this would at least prevent buy-wall trolling.

Using your proposal
I place an order to buy 100 XCP in 100 blocks with 1 BTC,
It matches an alpha-testers order to sell 0.001 XCP for 0.0000001 BTC in 1 block which is possible under the current protocol specification.
I just lost all my fees if your proposal was implemented, boo hoo for me.

Why don't you like our suggestions to prevent buy-walling?
https://forums.counterparty.co/index.php/topic,71.0.html
THIRD SUGGESTION is the most powerful free market style solution, but they really work great when all put together.
FOURTH SUGGESTION is the most urgent for a "quick fix"
But at least we can still trade away our XCP alt-coin style (off-dex) while the DEX protocol is broke. see my sig to buy xcp easily. Even if the DEX has some critical flaws it works great as a 100% proof of stake alt-coin, right?

2. Yes. Most of that goes back to the sending address in a multi-sig output (which few?! clients right now can spend). The amount is determined by what Bitcoind considers dust multi-sig outputs. When OP_RETURN support gets added to Bitcoind (very soon?!), only the .0001 BTC miners' fee will be required.

Right, I think my uncles friends cousins wife's step sister heard about someone who once saw someone spend one of those multisig's. They didn't remember which one of those few clients was used though.

So I don't see how the 4th part of the proposal prevents troll buy walling - since the wall will still sink all the orders, only for a shorter time.

The third solution would work - but it seems a) unnecessarily complex b) you're basically going to end up with an exchange with a lot of congruent orders that are not interacting because of different xcp/ btc fee requirements? That's going to be a real pain in the ass for your average user.

[busoni]

Okay, I've got the API set up, and can fetch everyone's balances. This will work just like NXT, with a little complication added by BTC fees.

[520Bit]

Okay, I've got the API set up, and can fetch everyone's balances. This will work just like NXT, with a little complication added by BTC fees.

Good, when will you bump us by adding XCP to your platform? You know XCP is an amazing project, right?

[mtbitcoin]

Hi PhantomPhreak

I am not sure if this is an issue/bug/change with the required-fee option running the latest develop branch

I have put a required fee of 0.0006 BTC (http://blockscan.com/order.aspx?q=3693) in the command line.

however, when the order was parsed the required fee became for 0.000042  and subsequently matched the "troll" order ??  same thing for the next test order http://blockscan.com/tx.aspx?q=3694. Used a 0.001 required fee, but when parsed it was 0.00007 BTC ?

Something looks messed up again... sigh...

Note to self: Need to quit running develop branch

[devphp]

PhantomPhreak,

can a matched order in 'awaiting payment' status be canceled without waiting for payment to be released?



I've also noticed a nuisance bug - Insufficient bitcoins at address, when making an order, 0.0003172 BTC is needed, but there is 0.001 in the wallet.

counterpartyd balances xxxxxxxxxxxxxxxxxx    reports 0.0 BTC.
Shouldn't it be more precise in reporting and calculating balance?

[cityglut]

PhantomPhreak,

can a matched order in 'awaiting payment' status be canceled without waiting for payment to be released?

No.

I've also noticed a nuisance bug - Insufficient bitcoins at address, when making an order, 0.0003172 BTC is needed, but there is 0.001 in the wallet.

counterpartyd balances xxxxxxxxxxxxxxxxxx    reports 0.0 BTC.
Shouldn't it be more precise in reporting and calculating balance?

It isn't a lack of precision, counterpartyd doesn't keep track of BTC balances. You have to keep track of the amount of BTC at each address in your wallet, yourself, as Bitcoin-QT creates new addresses and sends BTC to them without telling you. If you PM me the address you are checking the balance of, I can look it up on blockchain.info.

[IamNotSure]

I've also noticed a nuisance bug - Insufficient bitcoins at address, when making an order, 0.0003172 BTC is needed, but there is 0.001 in the wallet.

counterpartyd balances xxxxxxxxxxxxxxxxxx    reports 0.0 BTC.
Shouldn't it be more precise in reporting and calculating balance?

Try a listunspent on bitcoind and see if your 0.001 is there.

if not, start bitcoind or bitcoin-qt with rescan, for me it solved the problem with newly imported addresses that showed a 0 balance while having enough BTC

[gacrux]

I have put a required fee of 0.0006 BTC (http://blockscan.com/order.aspx?q=3693) in the command line.

however, when the order was parsed the required fee became for 0.000042  

I think --fee_required has been updated in the dev branch to mean "as a percentage of the total order", with a default of 1% (ie. 0.01.) The idea is that you shouldn't need to specify --fee_required, counterpartyd should automatically calculate something appropriate. But if you want to override it, specifying "0.0006" would mean your fee required is 0.06% of the value of your order (ie. very small.)

Example:
If you're ordering, say, 0.02 BTC, and you want the fee to be 0.0001, then you'd set --fee_required=0.005 (ie. half a percent. Because 0.5% of 0.02 BTC == 0.0001.)

This might seem a little weird, but makes very good sense when considered in combination with a new protocol change - proportional matching. For example, there's currently a troll order on the DEX for some absurd amount of XCP, but paying 0.0005 fee. There might be 20 orders on the book that all require 0.0001, and he'll match all of them. With the protocol change, he'd only match the first 0.0005 worth (ie. the first 5 orders) and then his fee would be exhausted and the remainder of his order ineffective. If you had the top sell order on the book, with a 0.002 fee, then he'd only match one quarter of your order and have no effect on anyone else. See?

(Note that I'm not responsible for the implementation (I can't claim to have written a single line of counterpartyd code,) I'm just some guy who thinks it's a good idea and wants to help explain it.)

[led_lcd]

An implementation based on porqupine's suggestion to terminate the troll order which failed to btcpay has been suggested in the dev board.

https://forums.counterparty.co/index.php/topic,69.15.html