Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread - page 526. (Read 1276928 times)
February 11, 2014, 01:06:09 AM
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.
February 11, 2014, 12:40:19 AM
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):
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.
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?
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.
February 11, 2014, 12:27:33 AM
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.
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
February 10, 2014, 11:55:06 PM
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.
February 10, 2014, 11:53:27 PM
Who else is down to Counterparty when we hit 0.10 BTC/XCP a couple years from now?
February 10, 2014, 11:48:38 PM
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.
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?
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.
February 10, 2014, 11:43:31 PM
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.
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.
February 10, 2014, 11:42:52 PM
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?
February 10, 2014, 11:38:06 PM
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.
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?
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
February 10, 2014, 11:33:27 PM
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?)
February 10, 2014, 10:45:07 PM
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.
February 10, 2014, 10:43:38 PM
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).
February 10, 2014, 09:43:12 PM
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. 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.
February 10, 2014, 09:37:06 PM
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?
February 10, 2014, 09:36:49 PM
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.
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?
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. February 10, 2014, 09:27:32 PM
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.
February 10, 2014, 09:26:40 PM
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. 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.
February 10, 2014, 09:05:56 PM
Cannot wait to see that GUI working on my PC. I think I'd rather use a web based version of course, cause this whole blockchain reindex is insane. I tried 3 times already 
February 10, 2014, 09:03:21 PM
Nevermind. I unlocked my wallet temporarily and all is well.
February 10, 2014, 08:53:19 PM
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.
Jump to: