That supports my assertion that the "end-game" for bitcoin is not as a transaction currency, but as a reserve currency. Blockchain-based protocols inherently cannot scale to a "useful" world scale (and neither did Satoshi envision it scaling to that extent), but as a decentralized, immutable ledger for transactional settlement -- there is no better. |
|
|
|
you guys are so naive it upsets me. shows how much you don't understand about mining economics
price, determined by some intersection of supply and demand
high difficulty translates into
1) less coins rewarded per miner (greater distribution)
2) necessitates a higher price for them to break even on their investment (greater accumulation)
3) fiat that would've entered the mining space is now likelier to be spent buying bitcoins instead
4) restored equilibrium
and don't tell me that miners will panic or that they get coins for extremely cheap anyways because of mining. almost by definition they are in the long game, and anyways, the mining space is now becoming only viable for manufacturers
at the very least, increasing difficulty is a positive factor upon price to some degree. it might be lagged though
The point is - difficulty follows price. It's hard to justify the converse. |
|
|
|
With two curves with different units on the Y axis, you can make them intersect anywhere. The intersection has no meaning.
Even comparing the shape of the two curves over the same time is fairly meaningless. Difficult is just the output of an equation and doesn't actually represent the change in cost of mining, since there were quite a few developments over time that increased hashrate for the same investment.
Then why have they been mimicking eachother since the beginning of bitcoin?    |
|
|
|
There is a belief in the BitCoin community that a large market cap or widespread adoption and becoming more like gold will magically bring stability to the value of the currency, but there is no data to support this. That's completely false. Yes, there's a century's worth of past stock market trading data to suggest that a larger volume makes for a more stable market. Depends on the metric. Short term volatility has not changed; in fact, I'd probably argue that it has gone up.  What you're looking for is distributions. I'd argue that markets have gotten more Levy-distributed over time (smaller day to day flunctuations, larger extreme flunctuations). This at least partially contributes to the volatility smile, a phenomenon that has started to occur since 1987. Volatility microstructure (at the second-millisecond level) has also changed dramatically particularily in the last few years from HFTs, but that is a topic for another discussion. |
|
|
|
I don't think so, because counterpartyd doesn't recognise unconfirmed transactions. Crossposted from the XCP forums. I'm no bitcoin dev, so I'm not 100% sure, but: --- Well, I'll chime in. Because malleability only affects the txid and not pubkeys (which we use for multisig) nor OP-RETURN (which hasn't even been implemented yet), I don't see how that affectx XCP. You might say it could affect BTCpay, but then again no unconfirmed transactions appear in the DEX anyways, so I don't see that as an issue. |
|
|
|
Oooh, quantitative finance ... haven't seen that in a while. Note my exposure to this is basically internet blog posts and probably some random textbooks, so probably not up to date. But... 1. Is bitcoin actually experiencing less volatility on a percentage basis as adoption goes up? This could be argued both ways - On one hand, 30-day rolling annualized volatility has not shown a decrease; rather the process seems to be cyclical (apologies for the hasty graph and badly labeled data -- this is a btc-e timeseries):  30-day autocorrelation is also not that interpretable:  On the other hand, the magnitude of moves and drawdowns seem to have decreased - thus longer term volatility measures may indicate a decrease. Depends on your measurement. 2. Should lower volatility be a policy goal? On one hand, for bitcoin to be adpoted as a currency, current volatility is clearly unacceptable. But would anti-vol measures ("plunge protection teams", circuit breakers, derivatives) trade short term stability for catastrophic long-term consequences (in other words, would they increase kurtosis)? Haven't done the math, but I suspect bitcoin is even more Levy-distributed (aka not normal distributed) than stocks. Also, due to decentralization, would any anti-vol measures actually be effective? You can't exactly trade stocks the same way you can trade bitcoin. Just my thoughts. |
|
|
|
I have bug report
When I place an order for XCP, the balance of BTC in my wallet becomes unconfirmed. Then I have to reboot (windows 7), restart bitcoind , and counterpartyd, before the BTC is again marked as confirmed, and the order is sent out.
You don't have to reboot your computer, just wait for 1 confirm. The reason is because counterpartyd sweeps the balance of your BTC address, uses some of it to generate data, and then gives you back the rest in change. To nitpick, counterparty takes the smallest unspent coin in your walletaddress, and issues a transaction off of that. Therefore it could be a good idea to keep some unspent outputs (blockchain.info can identify those) in your walletaddress to be able to issue more than one counterparty transaction per block. PS address, not wallet. Another one of the things that bitcoin-qt simply doesn't bother to make clear. |
|
|
|
a few days ago I placed a sell order that was wiped out by this guy http://www.blockscan.com/order.aspx?q=3336assuming that this troll will never pay, I'm not sure what happens in these cases. If the buyer doesn't process a btcpay, what happens to the xcp placed in the orderbook? Am I supposed to just wait or am I supposed to cancel my order (if it's possible)? Wait for your order to expire naturally. Lesson learned: set a shorter expiration time, or use fee_required. Until we get those upcoming "anti-troll" features currently in discussion. |
|
|
|
|
To be honest 24/7 mining is hardly a "typical" use for ordinary computer hardware (I know I'm preaching to the choir, but still). You'd get a similar response if you asked why your LN2-cooled overclocked processor suddenly decided to fry itself.
|
|
|
|
|
Great discussion you guys are having right now. I'm incredibly busy and things just got even busier, so I won't be checking/replying to this thread for a few days. I think you guys can manage. :p
|
|
|
|
Could you require BTC Sell XCP Buy orders to Proof of Burn some very marginal amount of BTC? - it would serve as a deterrent from placing Spam orders.
It's a catch 22 in this case. Because a proof of burn address most likely already has XCP on balance and a XCP escrow would work. Also checking an address for proof of burn should be trivial but over time the effectiveness would diminish as new users flood the system. I think an optional XCP fees escrowed system and an option for sellers to only matched orders with XCP escrowed could work. As biggest fish pointed out its only time that centralized exchanges start popping out and most btc /XCP trades would take place here. The key word here is here is 'optional' escrow. +1. Once we stop caring that a buyer needs XCP to buy XCP there is a lot that's possible. Optional XCP escrow released upon successful BTCPay is another great idea. Where would XCP be without mtbitcoin... I am starting an mtbitcoin fan club. Not to be confused with mtgox. I would say the most immediate change should be a lockin parameter to directly address the inability to get XCP back in a short timeframe from this attack. We can then implement some sort of (optional) XCP escrow system, and then followed by a reputation system in the indeterminate future. To allow new buyers to currently buy XCP, allow single orders to be bought without regard to the escrow requirement. All of these things will of course need to be thoroughly tested. |
|
|
|
If you don't want your orders to sell XCP for BTC to get eaten, then you need to set a higher fee_required. Note that only orders to buy BTC have this issue, and there's no way around it that I can think of. The problem with that, besides the fact that it kind of misses the point, is that Bitcoind cannot look up the balance of an arbitrary address. Surely though since counterparty can issue "lib.exceptions.BalanceError: Insufficient bitcoins at address" errors, that means it's possible to check locally if the person selling BTC actually has that much to sell (just as a sanity check)? I'm not worried about the balance in remote addresses. But that's a client-side check. Anyone can craft their own raw transaction to get around that. EDIT: Although I agree that having this client-side check would at least discourage most people from sweeping the book, as well as unintentionally trying to sell BTC they don't have +1, I think the people who want to try to sweep the order book and the people who know how to craft a raw transaction are pretty mutually exclusive. It's not even a question of crafting a raw transaction, but rather of deleting one line of Python code. Alright, you've made your point and I agree. How about moneypaktrader's suggestion though? A lockin period + the ability to reinstate orders automatically? Also is fee_required / fee_provided deducted at the time of match, or btc payment? If the latter, then that approach is also useless, because someone could simply put an absurdly high fee and not intend to actually pay it. This is kind of similar to the asset name issue we had a while back... |
|
|
|
If you don't want your orders to sell XCP for BTC to get eaten, then you need to set a higher fee_required. Note that only orders to buy BTC have this issue, and there's no way around it that I can think of. The problem with that, besides the fact that it kind of misses the point, is that Bitcoind cannot look up the balance of an arbitrary address. Surely though since counterparty can issue "lib.exceptions.BalanceError: Insufficient bitcoins at address" errors, that means it's possible to check locally if the person selling BTC actually has that much to sell (just as a sanity check)? I'm not worried about the balance in remote addresses. But that's a client-side check. Anyone can craft their own raw transaction to get around that. EDIT: Although I agree that having this client-side check would at least discourage most people from sweeping the book, as well as unintentionally trying to sell BTC they don't have +1, I think the people who want to try to sweep the order book and the people who know how to craft a raw transaction are pretty mutually exclusive. |
|
|
|
If you don't want your orders to sell XCP for BTC to get eaten, then you need to set a higher fee_required. Note that only orders to buy BTC have this issue, and there's no way around it that I can think of. The problem with that, besides the fact that it kind of misses the point, is that Bitcoind cannot look up the balance of an arbitrary address. Surely though since counterparty can issue "lib.exceptions.BalanceError: Insufficient bitcoins at address" errors, that means it's possible to check locally if the person selling BTC actually has that much to sell (just as a sanity check)? I'm not worried about the balance in remote addresses. That doesn't fix "order hogging", but it's a sanity check. |
|
|
|
Where do you get $1 in fees from?
Seller posts order: Cost = 0.0001 BTC
Buyer matches order: Cost = 0.0001 BTC + whatever the fee required to match is
Buyer sends BTCPay: Cost = 0.0001 BTC
Yes. Depending on the type of transaction, a Counterparty transaction should cost between .0001 and .0004 BTC. It should cost 0, the burn was a little strange requiring 0.0001 BTC Transaction fee and it just gets worse now in the system with all these so far unexplained fees Each bitcoin transaction requires a 0.0001 BTC fee paid to the mining network. Perhaps you have been using an online wallet such as Coinbase that pays these fees for you so you don't see them? The 0.0001086 BTC values in XCP transactions are put into a 1 of M Multisig escrow which you are theoretically able to spend. Currently I'm not sure which, if any, wallet clients support spending of Multisig outputs, but if you really wanted to you could craft a raw transaction to spend them today (not recommended) Hopefully counterpartyd will support spending of these outputs natively at some point. Here is more detail: https://bitcointalk.org/index.php?topic=287063.20So basically: 1) No, your 0.0001086 bitcoins are not gone. 2) No client currently offers the ability to spend them. Multisig is still a fairly new idea. One might in the future. |
|
|
|
Where do you get $1 in fees from?
Seller posts order: Cost = 0.0001 BTC
Buyer matches order: Cost = 0.0001 BTC + whatever the fee required to match is
Buyer sends BTCPay: Cost = 0.0001 BTC
Yes. Depending on the type of transaction, a Counterparty transaction should cost between .0001 and .0004 BTC. It should cost 0, the burn was a little strange requiring 0.0001 BTC Transaction fee and it just gets worse now in the system with all these so far unexplained fees The ultimate objective is to transition to OP_RETURN (which works already on testnet) when Bitcoin 0.9 comes around, so this this "dust" no longer remains. |
|
|
|
Oh SHEESH
Tx Source Buy Sell Price Expiration F_Req F_Prov Remarks
3256 1Mf2abNSv7jzwsjgkrf2k3LTMyEw96Us3H 1000 XCP 1.320 BTC 0.00132 BTC/XCP (4713|5000) 0 0.0001 Invalid: cancelled
Don't tell me my cancellation of this order did not work either, and that lost 1.320 BTC!
PhantomPhreak, can you please have a look? Now I REALLY start to get more than a little worried. We're talking about serious money now. Did the cancellation also send my btc into a black hole? Tell me it isn't so...
Those who are investing in a project should do their due diligence. We made no secret about the state of the code; if you read the "Announcement" thread, you would have seen the following disclaimer: The code being released here is of alpha-quality and under heavy development. You should expect to encounter significant bugs when using it. It is even possible that a bug might cause you might lose some money. The Counterparty team will do everything in its power to prevent this from happening, but this technology is very new, and the implementation is not yet well-tested. In particular, we may at some point have to change the Counterparty protocol in a not backwards-compatible way, if such a change is necessary to fix a bad bug or an exploit. As always, don't invest more than you can afford to lose.Nevertheless, we have decided to compensate users for this bug, given its peculiar natures. We are all, however, extremely busy, and so if we don't get back to you right away, rest assured it is not because we are not "sticking to our promise", but because we are, among other things, trying to make sure that fewer serious bugs pop up in the future. Thank you for your patience. I'm also extremely busy with real work (I work in biological research, if you are wondering), but +1 |
|
|
|
Oh SHEESH
Tx Source Buy Sell Price Expiration F_Req F_Prov Remarks
3256 1Mf2abNSv7jzwsjgkrf2k3LTMyEw96Us3H 1000 XCP 1.320 BTC 0.00132 BTC/XCP (4713|5000) 0 0.0001 Invalid: cancelled
Don't tell me my cancellation of this order did not work either, and that lost 1.320 BTC!
PhantomPhreak, can you please have a look? Now I REALLY start to get more than a little worried. We're talking about serious money now. Did the cancellation also send my btc into a black hole? Tell me it isn't so...
Orders that are for XCP for BTC shouldn't reserve any BTC - you use BTCpay for that. Also I obviously don't see 1.32 BTC going out from your account. As for reliability - these are growing pains for any alpha-quality software (as Bitcoin itself was for something like 2 years). The difference is that other devs choose to cover up the issues; the counterparty team tackles them head on. It doesn't help that 99% of coins out there are basically forks of Bitcoin and Litecoin. |
|
|
|
this is a very rare, irreversible bug in the order matching (normally bugs like this are reversible, but not BTCpay
Can you perhaps explain what exactly the issue is? Or is it buried somewhere a couple of pages back in the forum? Sure: https://bitcointalk.org/index.php?topic=395761.msg4957701#msg4957701Basically, the rounding code for master and develop was different, so BTCpays for one did not match the other, and went to the wrong accounts (still Counterparty accounts though). As I understand, such a thing will probably almost never happen in the future again, because BTCpay (the only protocol-level irreversible part of Counterparty, besides proof-of-burn) and the rounding issues have been addressed permanently. Note I said almost never.This event is sort of like Counterparty's version of Bitcoin's infamous blockchain fork. (though since we don't have mining, the analogy is tenuous). [Devs correct me on this]. Fortunately it happened early on, as opposed to when it happened for bitcoin. |
|
|
|
|
Show Posts
