Bitcoin Forum
November 09, 2024, 08:14:07 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 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 179 180 181 182 183 184 185 ... 661 »
  Print  
Author Topic: [ANN][XCP] Counterparty - Pioneering Peer-to-Peer Finance - Official Thread  (Read 1276763 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.
MoneypakTrader.com
Sr. Member
****
Offline Offline

Activity: 472
Merit: 250


Never spend your money before you have it.


View Profile
February 10, 2014, 10:48:24 PM
 #2681

There has been some disagreement between stakeholders and developers on the future of the counterparty protocol and distributed exchange system. This is currently helping investors who still want to get into XCP by buying at fairly low rates from stakeholders who are unsatisfied with the current direction (see my review thread for details on buying XCP for 0.005 BTC each, link in sig).
It has just now become more clear as to the cause of the disagreement.

The main DISAGREEMENT is on the NATURE OF THE CURRENT PROBLEM with the DEX system.
While we believe the current fees required to use the XCP network are excessive and inefficient - totalling ~$1 or 0.001 BTC for a single matched trade to complete with much of the expense being sent to unspendable locations (multi-sig is currently unspendable despite that rumor of spendability which was debunked in this thread). Our perspective is that MORE fees going to miners or being "burned" are NOT acceptable changes, while allowing asset orders to request and receive fees for the privilege of locking that order for a time they agree to is more fair and acceptable.

How it currently works:
1 A) People with XCP can place an offer to sell a specific amount of XCP at a specific XCP/BTC rate to last until a specific expiration. They may only cancel unmatched orders prior to the expiration. This costs about 30 cents (USD) currently whereas a direct XCP send costs about 20 cents.

1 B)People with bitcoins can place requests to buy XCP at a specific rate until a specific expiration. They may cancel or refuse to pay. This costs about 30 cents.

2 A) If there is overlap of the two above listings, those orders are matched regardless of order size (0.000001 XCP order may be matched with a 1 BTC order) and regardless of expiration time (XCP order expiring in 2 blocks may match with a BTC order expiring in 100 blocks). This creates an order match, (in this case perhaps for 0.00001 BTC for 0.0000005 XCP or 1 BTC for 200 XCP expiring in 2 blocks) matching happens regardless of whether the xcp/btc seller want to match a minimum quantity, maximum time to pay, etc.
For example, if a btc offer is placed around 6PM lasting for the next 25 hours (150 blocks) and wants to sell 5 btc for 1000 XCP and will come back the next day around 4PM to review orders and pay for those that match. They might be matched numerous times with short expiration XCP orders of (maybe 10 blocks or even 20 blocks, since they are not intending to view the matches until closer to their expiration time) over the next day but NONE of them show or might have very short expiration time when they are reviewing the matches. Further, they CAN'T specify minimum matches, so several dust matches are present which they must parse the database to view since the CLI doesn't show which match is for what trade. Frustrated at these failures of the protocol, they might abandon using the DEX around 7PM on that day and go to the thread in this forum to trade for XCP the same way every other alt-coin is traded if they don't abandon the idea of XCP altogether (due to the failure of XCP protocol to do it's intended purpose).

2 B) Assuming there are some XCP orders that matched with sufficient time for the BTC order to review them and pay, the BTC order involved in the match (requesting XCP or other asset) then has an option to send BTC (BTCpay command) to complete the match/s and receive XCP. NOTE: They will lose their btc for no benefit if the transaction occurs after the expiration of the match.

Based on how the protocol currently works, these MOST SIGNIFICANT CURRENT PROBLEMS are as follows:
1) EXCESSIVE FEES REQUIRED FOR USING THE DEX (whereas the devs are contemplating MORE fees).
2) LACK OF CUSTOMIZATION FOR ORDERS IN REGARDS TO TIME TO BTCPAY AND MINIMUM MATCH AMOUNTS.
Specifically: PEOPLE PLACING ORDERS INVOLVING BTC CANNOT SPECIFY:
A) The duration of time allowed for BTCpay.
B) Minimum match amounts.
3) Asset for BTC orders receive no compensation for order matches that do not BTCpay within the timeframe. Also, they receive no compensation difference for an order requiring payment in 5 blocks and no compensation for an option to buy their XCP in 1000 blocks expiration time.

A solutions to these problems is being worked out in this thread:
- https://forums.counterparty.co/index.php/topic,71.0.html
But since the dev's don't agree to the above problems, of course they won't implement solutions to them. . .

Solutions in short to the above defined problems are:
1) Don't force people to pay fees as default, let the market decide.
2) Allow customizing orders in regards to matching, particularly for matches after the first match to a btc order (see thread discussion) -
3) Allow XCP orders to get compensated for the expiration/payment timeframe they offer: This would be paid by the BTC seller for the privilege of multiple matches/options to buy. NOTE: due to already excessive fees and the potential for a highly clogged book from numerous fee amounts as we see now, the FIRST match should be included for the price of getting your BTC Sale request included in the blockchain. This will allow clearing of orders around the trading range for the cost of the transaction fees (already too high). The DEX system already is usable for small amounts, it's just numerous matches per BTC order that needs some option to prevent continuing the matching.

As long as the developers are misguided in identifying/solving the problems, we will be divesting of XCP.
Buy XCP at 0.005BTC each! link in sig

What the dev's have to say about the problems/fees being burned to miners:
^^^^^ EXCELLENT REVIEW OF CURRENT PROBLEM AN IMMEDIATE FIX WITH A LINK TO WELL THOUGHT OUT LONG TERM FIXES THAT ENSURE VIABILITY OF THE ORDER BOOK / DEX SYSTEM.
Please take a look at my suggestion [...]
I'm advocating much higher fees [...] in proportion to the size of the order matched.
I agree, you advocate burning more per transaction. . .

The BTCpay mechanism isn't intended to be an "option" for people to have the luxuary of locking in a price and deciding later whether to exercise it. It has worked that way so far only by an unfortunate accident in the protocol design - one that can be corrected.
I'm calling BS on that, it's absolutely necessary for the BTC offer to know exactly when they are willing and able to pay, thus they MUST be able to set a time that they are able to pay for their order request and forcing all trades to be done in an arbitrary timeframe (10 blocks) would SUCK, what if I want to btcpay in 150 blocks (expiration of my btc offer) and there's an xcp offer on the books that is looking for the same?
Give us more options, don't take them away. . .

Quote from: PhantomPhreak
https://forums.counterparty.co/index.php/topic,69.msg388.html#msg388
Re: DEX anti-trolling proposal
« Reply #19 on: Today at 08:02:29 am »
Take a look at this commit [...] which now has all order fees specified as a percentage of the BTC to be transacted, and defaults to 1%.
Great, now you want BTC orders to pay 1% in miner fees, wow, we're definitely not on the same page. . .

We are selling XCP at 0.005 BTC each until 30 BTC worth has been exchanged or 7 days, whichever comes sooner.

I hope dev's become enlightened on these problems and solutions we have described:
https://forums.counterparty.co/index.php/topic,71.0.html

MoneypakTrader.com
Sr. Member
****
Offline Offline

Activity: 472
Merit: 250


Never spend your money before you have it.


View Profile
February 10, 2014, 10:51:31 PM
 #2682

BTW: doesn't this mean that XCP cannot sell below 0.09 BTC until that 55480.18704735 BTC order either expires or is matched?

No, it doesn't. If there are two bids at .005 and .006, then a new ask at .004 will match the bid at .005 first. (This is a weird and perhaps surprising, and I'm not sure that it shouldn't be changed. Prices should converge either way, however.)

Of course, even if that weren't the case, one could also trade with a higher fee_required (which is what everyone should have been doing all along).

I disagree with your interpretation of how the match protocol works:
Order: sell 0.00001818 XCP at 0.0017 BTC/XCP in 8000 blocks, with a provided fee of 5e-05 BTC and a required fee of 0.0 BTC (f8ff1b5e75436cc61c20476684d431e5f3890ea1c080b9f683d7f287fa005975)
Order Match: 0.00000181 BTC for 0.0000181 XCP at 0.1000 BTC/XCP (6efab911ef0b392cced9a410f610380783356f3172b6ee724e9c5175e21e8a7df8ff1b5e75436cc 61c20476684d431e5f3890ea1c080b9f683d7f287fa005975)

Notice it didn't match the lower rates that are on the market? (0.0025, 0.004, etc. etc.)

cityglut
Full Member
***
Offline Offline

Activity: 216
Merit: 100


View Profile
February 10, 2014, 11:00:30 PM
 #2683

MoneyPakTrader, you have written a very long response, but one statement you've repeatedly made should be cleared up:



Based on how the protocol currently works, these MOST SIGNIFICANT CURRENT PROBLEMS are as follows:
1) EXCESSIVE FEES REQUIRED FOR USING THE DEX (whereas the devs are contemplating MORE fees).

If the "FEES REQUIRED FOR USING THE DEX" are the costs associated with multi-sig transactions, then you should know, as has been explained repeatedly, that these are not fees, and it is only in the absence of OP_RETURN that multi-sig is implemented; the new fee_required/fee_provided is set to a default of 1%, it is by no means required and it is grossly misleading to keep referring to these as required fees.
MoneypakTrader.com
Sr. Member
****
Offline Offline

Activity: 472
Merit: 250


Never spend your money before you have it.


View Profile
February 10, 2014, 11:05:05 PM
 #2684

Very interesting.  Can you point me in the direction of how to recover my multisig fees?

Please DON'T delay your dinner plans while you wait for that.
Actually, don't expect to have those funds ready for your vacation plans next week either.

But the reason I'm posting is just to reiterate the QUICK FIX to current problems (again):
NEW CODE:
Orders offering btc DO NOT/WILL NOT MATCH WITH asset offers if the asset expiration time left is less than the btc offer expiration time left.
Orders requesting btc DO NOT/WILL NOT MATCH  btc offers if the asset expiration time left is less than the btc offer expiration time left.

BAM, solved until the other suggestions can be implemented to further harden the DEX against more rigorous alpha testing.

MoneyPakTrader, you have written a very long response, but one statement you've repeatedly made should be cleared up:
Based on how the protocol currently works, these MOST SIGNIFICANT CURRENT PROBLEMS are as follows:
1) EXCESSIVE FEES REQUIRED FOR USING THE DEX (whereas the devs are contemplating MORE fees).
If the "FEES REQUIRED FOR USING THE DEX" are the costs associated with multi-sig transactions, then you should know, as has been explained repeatedly, that these are not fees, and it is only in the absence of OP_RETURN that multi-sig is implemented; the new fee_required/fee_provided is set to a default of 1%, it is by no means required and it is grossly misleading to keep referring to these as required fees.
Please explain again how *if* people decide to force BTC orders to burn more coins that will help (A) what problem be solved and (B) not cause more friction to trading? quotes are fine.
How will that not just make an overlapping trading range in the book as currently shows? that's no good, the first match should be free to allow clearing up the book as per our proposals: https://forums.counterparty.co/index.php/topic,71.0.html

JahPowerBit
Sr. Member
****
Offline Offline

Activity: 335
Merit: 255


Counterparty Developer


View Profile
February 10, 2014, 11:07:50 PM
 #2685

I just made a push.
These actions are now available:
send, order, btcpay, cancel, issuance, dividend, callback, broadcast and bet.

https://github.com/JahPowerBit/BoottleXCP

A couple of questions on https://code.google.com/p/chromiumembedded/

Download links to both CEF1 and CEF3 are available. Should I be downloading CEF3?
I am running Windows 8 64 bit, CEF3 windows 64 shows up as experimental. It is OK to use the 64 bit or do you recommend the 32 bit install.

The last (and first) I used CEF was in June 2013 and it was the version: cef_binary_1.1364.1123_macosx
So I can not really advise you on this point.
It is precisely the hard part, making a standalone build with counterpartyd and CEF embedded in. This is the part that will take me more time I think.
cityglut
Full Member
***
Offline Offline

Activity: 216
Merit: 100


View Profile
February 10, 2014, 11:14:05 PM
 #2686

Very interesting.  Can you point me in the direction of how to recover my multisig fees?

Please DON'T delay your dinner plans while you wait for that.
Actually, don't expect to have those funds ready for your vacation plans next week either.

But the reason I'm posting is just to reiterate the QUICK FIX to current problems (again):
NEW CODE:
Orders offering btc DO NOT/WILL NOT MATCH WITH asset offers if the asset expiration time left is less than the btc offer expiration time left.
Orders requesting btc DO NOT/WILL NOT MATCH  btc offers if the asset expiration time left is less than the btc offer expiration time left.

BAM, solved until the other suggestions can be implemented to further harden the DEX against more rigorous alpha testing.

Quote

Please explain again how *if* people decide to force BTC orders to burn more coins that will help? quotes are fine.
How will that not just make an overlapping trading range as is currently shown on the order book? that's no goo, the first match should be free to allow clearing up the book as per our proposals: https://forums.counterparty.co/index.php/topic,71.0.html
Whether you think the current implementation is effective is one thing (and on this matter we have been taking the community's discussions into consideration and will continue to do so), but this is quite different from claiming that we have implemented new required fees, which is false.

To be completely clear, we have implemented zero required fees. Users are, as always, free to choose the fees themselves.
keccak512
Full Member
***
Offline Offline

Activity: 210
Merit: 100


View Profile
February 10, 2014, 11:24:19 PM
 #2687

Nice project.  Well done.
cityglut
Full Member
***
Offline Offline

Activity: 216
Merit: 100


View Profile
February 10, 2014, 11:30:01 PM
 #2688

Very interesting.  Can you point me in the direction of how to recover my multisig fees?

Please DON'T delay your dinner plans while you wait for that.
Actually, don't expect to have those funds ready for your vacation plans next week either.

But the reason I'm posting is just to reiterate the QUICK FIX to current problems (again):
NEW CODE:
Orders offering btc DO NOT/WILL NOT MATCH WITH asset offers if the asset expiration time left is less than the btc offer expiration time left.
Orders requesting btc DO NOT/WILL NOT MATCH  btc offers if the asset expiration time left is less than the btc offer expiration time left.

BAM, solved until the other suggestions can be implemented to further harden the DEX against more rigorous alpha testing.

Quote

Please explain again how *if* people decide to force BTC orders to burn more coins that will help? quotes are fine.
How will that not just make an overlapping trading range as is currently shown on the order book? that's no goo, the first match should be free to allow clearing up the book as per our proposals: https://forums.counterparty.co/index.php/topic,71.0.html
Whether you think the current implementation is effective is one thing (and on this matter we have been taking the community's discussions into consideration and will continue to do so), but this is quite different from claiming that we have implemented new required fees, which is false.

To be completely clear, we have implemented zero required fees. Users are, as always, free to choose the fees themselves.

But defaults are powerful signals for setting the standard. Remember when the Ethereum team asked for $36mm in their IPO (they didn't...that was a cap...but that was the number that everyone used to flame them)

If you really want to make it clear that zero fees are required, make the default fee percentage 0%, not 1%. Let users decide if they want to use the fee system or the XCP escrow system that I eagerly await.

We of course debated what the default fee required should be, and indeed the decision is not once-and-for-all. Nevertheless you just criticized us for implementing new required fees, which we have not done, and hence my clarification.
led_lcd
Sr. Member
****
Offline Offline

Activity: 262
Merit: 250


View Profile
February 10, 2014, 11:37:12 PM
 #2689

BTW: doesn't this mean that XCP cannot sell below 0.09 BTC until that 55480.18704735 BTC order either expires or is matched?

No, it doesn't. If there are two bids at .005 and .006, then a new ask at .004 will match the bid at .005 first. (This is a weird and perhaps surprising, and I'm not sure that it shouldn't be changed. Prices should converge either way, however.)

Of course, even if that weren't the case, one could also trade with a higher fee_required (which is what everyone should have been doing all along).

Counterparty's timing resolution is restricted to a Bitcoin and therefore as a DEX, it offers a different service to trading on centralised exchanges. That's why there is a bounty out there for a centralised exchange. The time for order matching, execution, settlement and liquidity will be different to off blockchain transactions. The market price will reflect these factors between the exchanges.

The market is still in its infancy but I don't see a problem, even with these 'troll' trades that popped up on the DEX. The protocol is pretty clear that the fee_required is a disincentive to put up 'troll' trades and an incentive to follow through with settlement . We should just mentally sort where fee_required is given higher priority.

In some ways, I see Counterparty as a trustless inter-dealer broker which provides liquidity to centralised exchanges (or perhaps gateways) who are on sell side.
led_lcd
Sr. Member
****
Offline Offline

Activity: 262
Merit: 250


View Profile
February 11, 2014, 12:31:44 AM
 #2690

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

Activity: 214
Merit: 101


View Profile
February 11, 2014, 01:04:14 AM
 #2691

But the GUI release could be changed so it checks wallet balance before creating a sell BTC order, as well as an option to auto fill that order when a match has been found.

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

Activity: 364
Merit: 250

Owner of Poloniex


View Profile
February 11, 2014, 01:41:31 AM
 #2692

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?

Poloniex.com - Fast crypto exchange with margin trading, advanced charts, and stop-limit orders
rashley
Newbie
*
Offline Offline

Activity: 10
Merit: 0


View Profile
February 11, 2014, 01:43:26 AM
 #2693

Uh oh...

Tried to cancel an order and got this error;

lib.exceptions.BitcoindError: {'message': 'Private key for address 156FAUbf3Moo54qnUN9NRdNq7KP8KrMXBP is not known', 'code': -4}

That's where my XCP's are and a Bitcoin.

Is there something that counterpartyd could have done? All I've done with it the last few days is buy a little XCP through the DEX. I've done nothing fancy.
520Bit
Sr. Member
****
Offline Offline

Activity: 602
Merit: 252



View Profile
February 11, 2014, 01:53:19 AM
 #2694

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

Activity: 10
Merit: 0


View Profile
February 11, 2014, 02:03:21 AM
 #2695

Nevermind. I unlocked my wallet temporarily and all is well.
halfcab123
Full Member
***
Offline Offline

Activity: 224
Merit: 100

CabTrader v2 | crypto-folio.com


View Profile
February 11, 2014, 02:05:56 AM
 #2696

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 Cry


DayTrade with less exposure to risk, by setting buy and sell spreads with CabTrader v2, buy now @ crypto-folio.com
PhantomPhreak (OP)
Sr. Member
****
Offline Offline

Activity: 476
Merit: 300

Counterparty Chief Scientist and Co-Founder


View Profile
February 11, 2014, 02:26:40 AM
 #2697

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

Activity: 476
Merit: 300

Counterparty Chief Scientist and Co-Founder


View Profile
February 11, 2014, 02:27:32 AM
 #2698

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

Activity: 472
Merit: 250


Never spend your money before you have it.


View Profile
February 11, 2014, 02:36:49 AM
 #2699

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.

busoni
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250

Owner of Poloniex


View Profile
February 11, 2014, 02:37:06 AM
 #2700

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?

Poloniex.com - Fast crypto exchange with margin trading, advanced charts, and stop-limit orders
Pages: « 1 ... 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 179 180 181 182 183 184 185 ... 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!