Bitcoin Forum
October 16, 2024, 01:22:22 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 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 179 180 181 182 183 184 185 186 ... 661 »
  Print  
Author Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread  (Read 1276558 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.
520Bit
Sr. Member
****
Offline Offline

Activity: 602
Merit: 252



View Profile
February 11, 2014, 02:43:12 AM
 #2701

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 (OP)
Sr. Member
****
Offline Offline

Activity: 476
Merit: 300

Counterparty Chief Scientist and Co-Founder


View Profile
February 11, 2014, 03:43:38 AM
 #2702

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 (OP)
Sr. Member
****
Offline Offline

Activity: 476
Merit: 300

Counterparty Chief Scientist and Co-Founder


View Profile
February 11, 2014, 03:45:07 AM
 #2703

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
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250

Owner of Poloniex


View Profile
February 11, 2014, 04:33:27 AM
 #2704

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

Poloniex.com - Fast crypto exchange with margin trading, advanced charts, and stop-limit orders
porqupine
Full Member
***
Offline Offline

Activity: 214
Merit: 101


View Profile
February 11, 2014, 04:38:06 AM
 #2705

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 (OP)
Sr. Member
****
Offline Offline

Activity: 476
Merit: 300

Counterparty Chief Scientist and Co-Founder


View Profile
February 11, 2014, 04:42:52 AM
 #2706

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
Full Member
***
Offline Offline

Activity: 216
Merit: 100


View Profile
February 11, 2014, 04:43:31 AM
 #2707

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 (OP)
Sr. Member
****
Offline Offline

Activity: 476
Merit: 300

Counterparty Chief Scientist and Co-Founder


View Profile
February 11, 2014, 04:48:38 AM
 #2708

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
Newbie
*
Offline Offline

Activity: 126
Merit: 0


View Profile
February 11, 2014, 04:53:27 AM
 #2709

Who else is down to Counterparty when we hit 0.10 BTC/XCP a couple years from now?
busoni
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250

Owner of Poloniex


View Profile
February 11, 2014, 04:55:06 AM
 #2710

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.

Poloniex.com - Fast crypto exchange with margin trading, advanced charts, and stop-limit orders
520Bit
Sr. Member
****
Offline Offline

Activity: 602
Merit: 252



View Profile
February 11, 2014, 05:27:33 AM
 #2711

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  Wink 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
Full Member
***
Offline Offline

Activity: 214
Merit: 101


View Profile
February 11, 2014, 05:40:19 AM
 #2712


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

Quote
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
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250

Owner of Poloniex


View Profile
February 11, 2014, 06:06:09 AM
 #2713

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.

Poloniex.com - Fast crypto exchange with margin trading, advanced charts, and stop-limit orders
520Bit
Sr. Member
****
Offline Offline

Activity: 602
Merit: 252



View Profile
February 11, 2014, 06:13:57 AM
 #2714

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
Legendary
*
Offline Offline

Activity: 876
Merit: 1000


Etherscan.io


View Profile
February 11, 2014, 08:58:14 AM
Last edit: February 11, 2014, 09:13:11 AM by mtbitcoin
 #2715

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




EtherScan::Ethereum Block Explorer | BlockScan::Coming Soon
devphp
Sr. Member
****
Offline Offline

Activity: 336
Merit: 260


View Profile
February 11, 2014, 09:30:26 AM
 #2716

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
Full Member
***
Offline Offline

Activity: 216
Merit: 100


View Profile
February 11, 2014, 09:34:51 AM
 #2717

PhantomPhreak,

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


No.

Quote

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
Hero Member
*****
Offline Offline

Activity: 672
Merit: 500


View Profile
February 11, 2014, 10:10:17 AM
 #2718


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
Newbie
*
Offline Offline

Activity: 22
Merit: 0


View Profile
February 11, 2014, 10:50:39 AM
Last edit: February 11, 2014, 11:42:36 AM by gacrux
 #2719

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? Smiley

(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
Sr. Member
****
Offline Offline

Activity: 262
Merit: 250


View Profile
February 11, 2014, 11:09:31 AM
 #2720

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
Pages: « 1 ... 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 179 180 181 182 183 184 185 186 ... 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!