I didn't think MasterCoin supported short sales...
It doesn't matter if it's built into the system. I can still borrow the coins outside the system from anybody willing to lend them to me, and then immediately sell them. That's all a short sale is. |
|
|
|
These constraints are artificial. The market is much bigger than your system.
I must be losing my mind after so many posts with bytemaster. This is another post which makes no sense to me. Maybe I just need to be done for the day . . . I'll elaborate: Your response was that your system prevents fully solvent competitors from stepping in and wiping out a currency that has just become insolvent, by the mechanism I described. Namely, where the simple existence of the better positioned competition forces the market price of the currency below its target, and thus forces perpetual buying by the escrow fund until it's emptied. My point is that there will always be competition from outside your constrained system that you must take into account, and as soon as the backing of a currency in your system drops below 100%, then it's automatically at a competitive disadvantage with any freshly created one in an outside system. Now THAT is an interesting point. An escrow fund could continue to operate successfully in a closed system, but given another competing GoldCoin launched by someone else, people might flock to the new one which would start at 100% backing. Of course, over-funded escrow funds would work just fine, but it may be that under-funded ones will immediately face competition. Very interesting. I'll need to think about this. This also provides a profitable avenue for attack: short sell a bunch of insolvent OldCoins, and use a portion of the proceeds from this sale to issue your own solvent NewCoins at a discount. Wait until OldCoin's escrow fund is overrun and OldCoins become worthless, and your short sale is automatically covered for free. |
|
|
|
These constraints are artificial. The market is much bigger than your system.
I must be losing my mind after so many posts with bytemaster. This is another post which makes no sense to me. Maybe I just need to be done for the day . . . I'll elaborate: Your response was that your system prevents fully solvent competitors from stepping in and wiping out a currency that has just become insolvent, by the mechanism I described. Namely, where the simple existence of the better positioned competition forces the market price of the currency below its target, and thus forces perpetual buying by the escrow fund until it's emptied. My point is that there will always be competition from outside your constrained system that you must take into account, and as soon as the backing of a currency in your system drops below 100%, then it's automatically at a competitive disadvantage with any freshly created one in an outside system. |
|
|
|
If the total value of the backing drops below the total nominal value of the issued currency, then why anyone would ever bother to buy this one over a freshly created copy? The latter always begins its life with full backing, and thus has a relative advantage over the former. It seems to me that once this threshold is breached, the old currency will have to sell at a discount to compete with the new one, thus depleting the escrow fund until it's wiped out completely. Notice that the old currency remains technically insolvent no matter how much buying the escrow fund does, and it can never eliminate the advantage that the new currency has over it. Its demise is a certainty at this point.
All GoldCoins are backed by the same escrow fund, to the same degree. GoldCoins are fungible, and there wouldn't be one that was more funded than another. These constraints are artificial. The market is much bigger than your system. |
|
|
|
|
If the total value of the backing drops below the total nominal value of the issued currency, then why anyone would ever bother to buy this one over a freshly created copy? The latter always begins its life with full backing, and thus has a relative advantage over the former. It seems to me that once this threshold is breached, the old currency will have to sell at a discount to compete with the new one, thus depleting the escrow fund until it's wiped out completely. Notice that the old currency remains technically insolvent no matter how much buying the escrow fund does, and it can never eliminate the advantage that the new currency has over it. Its demise is a certainty at this point.
|
|
|
|
I don't believe this is true. A government (or any other entity) cannot maintain a peg indefinitely unless they have a indefinite amount of resources with which to do it (and no, money printing doesn't count  ). Panamá and Hong Kong have their currencies pegged to the USD for decades now, don't they? AFAIK, all cases of failed pegged currencies were in situations where the money issuers also attempted to use money creation to manipulate interest rates (or any other price). As long as it only creates and destroy currency with the goal of keeping a parity price with a foreign currency, I fail to see what's the great danger. It's trivial to create a currency with a perfectly stable peg: just maintain 100% reserves in the same asset you're pegging to. Decrease this reserve ratio, or swap out the reserves for ones whose price has less than a guaranteed perfect correlation with the pegged-to asset going forward, and you increase the risk of being overrun and the peg breaking. The scheme presented here proposes 0% of the reserves be held in the pegged-to asset, and all of them to be held in a new and unnecessary asset with no established liquidity, whose price has no reason to be anything other than completely uncorrelated with that of the pegged-to asset. It strikes me as maximally risky. |
|
|
|
Indeed... "If <politician> dies, I will make public n such that H(n)==0x4a5e1e4baab89f3a32518a88c31bc8"
Did you have to use that example?  Disclaimer: Bitcoin leaks a lot of information, don't do these. |
|
|
|
Yes, more people accept Bitcoin than Litecoin. My points hinge on the idea that cryptocurrencies would be basically all the same in the future, and standardized, and cheap to exchange.
Also, (related to what you mentioned earlier) there must be some kind of force such that if everyone is invested in one currency, they're less likely to switch for fear of losing their value; If the price of Litecoin begins to rise, there is always the fear that the trend could reverse.
I guess I'm trying to wrap my head around the prospect of a future multi-cryptocurrency world.
I'll reemphasize this point: In any realistic economy, real or virtual, there is a demand for at least one good which is used as a "store of value," that is, not used or intended to be used by the owner, but owned simply to transfer purchasing power across time. It doesn't follow that because you have frictionless transfer between two assets, the two assets do an equally good job of transferring purchasing power across time. All else being equal, you use the more liquid one for that. That's why the equilibrium is to converge on a single standard. |
|
|
|
I think this will be the third time I've dropped a quote from this insightful post: In any realistic economy, real or virtual, there is a demand for at least one good which is used as a "store of value," that is, not used or intended to be used by the owner, but owned simply to transfer purchasing power across time. Nonetheless, the owner holds this good and participates in the market for it. If many owners standardize on the same good, they affect the market for this good. We can think of their collective purchasing power as a sort of "energy" that flows into this market. It turns out that the correct collective strategy in this game is for everyone to standardize on the same asset as a store of value, and for this asset to be one of intrinsically limited quantity. If the quantity is not limited, as for example in a manufactured good, a stable pool of savers will not increase its price. If the quantity is limited, as with gold, Bitcoin, etc, the price will increase as savings energy flows in - and, of course, decrease as it flows back out. There is no way to eradicate this effect from anything like a realistic economy. There is always at least one bubble. Ideally, this bubble is stable, and we call it "money." If you try to spread savings energy across all the goods in the economy, it will stay in storable goods and not in un-storable ones. It will flee from manufactured goods and end up in rare collectibles. Finally, it will flee from a broad spectrum of collectible assets and end up in a single standard. Those who are late in fleeing are, by definition, caught in a bubble which pops - and taste the pain. And this one: Bitcoin is an exceptionally pure test of the BTM, because it has no intrinsic utility. It is uncomfortably reminiscent of that apex specimen of the South Sea Bubble, "a company for carrying out an undertaking of great advantage, but nobody to know what it is." One of the problems with the South Sea Bubble - in fact, one of the reasons why South Sea Company stock could not become a new monetary standard - was the inability to define a reason why one security should be the standard, and not another. There are Bitcoin clones, all more or less worthless. Bitcoin is a protocol standard, and everyone in our era knows how protocol standards play: winner takes all. |
|
|
|
Are there plans for a call that returns a tx's merkle branch?
What is the use case? That data falls into the category of "public blockchain data", so it is OK to add that sort of data, if there is a use. Note that the JSON format of a TX outputs its confirmed block-hash, which enables discovery of a TX's merkle branch. No particular use case in mind at the moment; being able to easily prove a given tx was included in a block just feels generally useful to me, and a more targeted call than one that returns the full block is more efficient for both parties. |
|
|
|
|
Are there plans for a call that returns a tx's merkle branch?
|
|
|
|
I'm speaking specifically about confirm count without regard to latency. Under the assumption that orphaning isn't an issue, with a lower mean block time you need to wait less on average for a given level of security. For example, let's say that with either 5 min or 10 min mean time, orphaning isn't an issue. Let's say also that you want a 10%-hashrate attacker to have less than 2% chance of successfully double spending, so you wait for 3 confirms. If 10 min is the time constant, you have to wait 30 mins on average. If it's 5 min, you have to wait 15 mins. This is an advantage of a lower time constant, as suggested by the OP. In the case where an attacker is purchasing his hashing power on-demand, wouldn't halving the block period also halve the cost of any n-block chain reversal, since on average the attacker would need to rent the same fraction q of total hashing power, but for only half the time? |
|
|
|
|
We've got a rabid one here.
|
|
|
|
To the extent that a pooled miner is actively checking forums etc. to listen for claims that their pool is misbehaving, and switching pools in such an event, then I think they are contributing somewhat.
How is the miner checking forums if the internet doesn't work? Well text is a lot easier than streaming video, for example, and I did assume there was enough bandwidth available for SPV to work. There's also word of mouth, telephone, etc. Just a matter of not being lazy about it. Of course this is less than ideal, though. |
|
|
|
Pooled mining is also low bandwidth, so miners might still be able to contribute by connecting to a pool in another country.
Thats not really contributing... I mean, they aren't validating anything. Presumably the same party isolating them could be redirecting their hashpower selfishly or maliciously. To the extent that a pooled miner is actively checking forums etc. to listen for claims that their pool is misbehaving, and switching pools in such an event, then I think they are contributing somewhat. Re: redirecting hashpower, of course a state level actor can always come in guns blazing and take your mining rig if it knows you have it. Certainly no way around that  In general SPV in isolation seems a bit odd except as a short term measure, it means you have to trust people who your communication with is restricted... they may even be the ones restricting you.
Oh for sure. Just arguing that a country here or there isolated from full validation mode isn't the end of the world. Of course Bitcoin needs enough "free" countries acting as the backbone. I mentioned the improved SPV mode as it would reduce the trust required of the backbone. |
|
|
|
|
People in these dire circumstances have found ways to maintain some connectivity to the outside world, just at low bandwidth.
Running in SPV mode (block headers only) is pretty low bandwidth, so keeping this service up might be possible. There are also improvements that can be made to the SPV trust model that would allow an SPV node to reject invalid blocks upon receiving a short fraud proof, so the loss of access in a few countries to most of the transaction data wouldn't pose much of a risk to the people there, or the network as a whole.
Pooled mining is also low bandwidth, so miners might still be able to contribute by connecting to a pool in another country.
|
|
|
|
|
A p2p prediction market would be a pretty cool use case. This could also be used to hedge FX risk of holding bitcoins. I guess it might work something like this:
An oracle publishes the hash of a secret, and the secret as well if a given event occurs before some expiry date.
With this setup, we want anyone (a writer) to be able to construct a tx with a txout (the contract) whose script allows only the buyer of the contract to spend it before the expiry date, and only if he can provide the secret. Furthermore, we want only the writer to be able to spend the txout after the expiry date. I think this only additionally requires the PUSH_BLOCK_DATE opcode that Sergio proposed above. The writer would include a second txout that spends to him the price in bitcoins he's asking for the contract. He would sign inputs that add up to the contract txout plus any tx fee, and the buyer would provide the rest of the inputs required.
It would be nice if trust could be spread across multiple oracles by requring m of n secrets for the buyer to spend the txout. We don't have OP_AND or OP_OR, so I guess we'd need these or maybe a special opcode just for this purpose?
A really nice feature would be if the person buying this contract were able to spend it on the blockchain without requiring a signature from the person writing it. Then we could have trust free (ignoring underlying trust in oracles) secondary markets for these contracts. Could this be done using the transaction persistence you mentioned, Sergio? I guess the condition for the buyer to be able to spend it before the expiry date, but without the secret(s), would be that the tx which spends it has a txout (the replacement contract) of greater or equal value, and with the same script, except with the original buyer's address replaced by the new buyer's.
|
|
|
|
Also, shouldn't this be moved to alt-currencies?
The whole idea here was to present a way for Bitcoin to benefit from new innovations that are too controversial to integrate directly into its block chain, and to neutralize their destabilizing effect. |
|
|
|
1 - e^(-t/T)
Good formula. Let's extend our analysis a bit. Let "x" be transaction rate, i.e. number of transactions per second. And "t0" - average transaction validation time, i.e. block validation time divided by number of transactions in that block, in the first approximation we can assume that "t0" doesn't depend on block size. Than, number of transactions to be validated N = x*T and time required for validation t = x*T*t0 Thus, orphans rate, expressed with theese variables: 1 - e^(-x*t0). We see, in first approximation it doesn't depend on T. Dependacy on T arises from network delays. Ah yes, that's right. I actually deleted that post shortly after posting it because I noticed this for a second, but the brain fart won out in the end and I reposted it without fixing it I should've just written it down explicitly like you did. This formula is a first approximation, where it is assumed that miners rarely end up working on competing chains. As we lower T while keeping x fixed, we can intuitively see that the likelihood of races between miners increases, i.e. higher order terms in the orphan rate become important. As you mentioned, this is due to network delays. It's during these races that hashing power is wasted, so T should be set high enough to keep their frequency low. I'll try and come up with the next order term for the orphan rate. This will be from the cases where another miner finds a block at roughly the same time as our miner, and gets it to some portion of the miners before our miner gets his block to them. I agree, that working on payment channels is important. But may be it would be beneficial for Bitcoin to adopt shorter block times. At least it definitely would eliminate that marketing issue.
Sure it would be "beneficial" to lower it to the "optimal" value, but practically speaking it's probably just cosmetic. If the problem is people misunderstanding the issue, then perhaps educating people is the better solution. |
|
|
|
It seems that block validation time is almost linear in block size, i.e. t = O(blockSize). If we reduce blocktime, blocks will become smaller and validation time will decrease correspondingly. In other words 10 times more frequent blocks are 10 times smaller and require about 10 times less time to validate. Am I missing something?
No, that's pretty much correct, I think. It's also not hard to show that a miner's orphan rate can be written approximately as 1 - e^(-t/T) where T is the block period, and t is time required for the other miners to download and verify the block*. t scales with block size, as you noted, so clearly you can scale block size at the same rate as the block period, and the orphan rate is left invariant. Thus, a system with a low transaction rate can safely get away with a smaller block period, but keep in mind it will at some point have to raise the block period to accommodate a larger transaction rate, in order to avoid wasting too much hashing power on orphans, or screwing up consensus forming. Much better IMHO to just focus on ways of making 0-conf transactions less risky and work on building a network of payment channels* than to try to decrease the block period. It's not like any block period tweaking is going to improve brick and mortar transactions anyway, which need to be done in seconds, not minutes. Although there definitely does appear to be a dumb marketing gimmick aspect to it, which is unfortunate. * More precisely, t is the fractional hashing power-weighted sum of the times required for the other miners to download and verify the block. * https://bitcointalk.org/index.php?topic=244656.0 |
|
|
|
|
Show Posts
