Bitcoin Forum
April 28, 2024, 12:32:00 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 [63] 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 »
1241  Bitcoin / Bitcoin Discussion / Re: TradeHill - Dwolla is being scammed and reversing transactions on: July 27, 2011, 05:13:49 PM
[POLL] Will you reverse your Dwolla transactions?
http://forum.bitcoin.org/index.php?topic=32354.0

If the results of this poll are accurate, there are more reversals coming. If I were running an exchange, I would disconnect my bank account from Dwolla ASAP, changing banks if necessary. Let Dwolla sleep in the bed they made.
1242  Economy / Trading Discussion / [POLL] Will you reverse your Dwolla transactions? on: July 27, 2011, 05:00:21 PM
You learn Dwolla transactions ARE reversible. You call your bank.

You: What's this "Duh-wah-luh" thing in my account history?
Bank: Some kind of payment thing like paypal
You: I didn't authorize that
Bank: They deposited in your account to confirm it was yours
You: I didn't see that. I'VE BEEN HAXORED!!!
Bank: We'll take care of it.

Bank to Dwolla: We'll take that money back.
Dwolla to the exchanges: We'll take that money back.
Exchange to users: Um, everything is fine. Don't look behind the curtain

I haven't done this, nor do I plan to, but I'm wondering, will anyone here admit they have done this or plan to?
1243  Economy / Goods / Re: Selling Minecraft gift codes - just 0.95 BTC on: July 27, 2011, 04:23:22 PM
I just purchased a code from this user. I was able to register successfully.

Seller had great communication.

Thanks!
1244  Alternate cryptocurrencies / Altcoin Discussion / Re: Multicoin, Namecoin, Goldcoin, Silvercoin, OilCoin, 1971coin, backed by bitcoin! on: July 27, 2011, 03:46:36 PM
I know, that's why I'm telling you that you can't.

I yield on this issue. Bitcoins can't be created out of thin air. I've decided this after contemplating a doomsday scenario thought experiment here: http://forum.bitcoin.org/index.php?topic=31645.msg403514#msg403514

Well yes, since they're bitcoin denominated, the price in dollars of the commodity doesn't matter at all.
Since you got inputs from markets to the chain, you could also denominate them in dollars Even in dollars from 1971 or any other reference currency. Miners would have to agree on what PCI to look at.

So what happens if bitcoin prices fall 90%? I don't understand how the dollar-denominated contracts would stay valid without an escrow fund.


It is very simple how it would work, you create another chain with your rules, if you need it, with its own currency.
After proposing to add demurrage to bitcoin (freicoin) I would say that is not easy to convince people when you have to modify the rules of what blocks are acceptable.
I have a second proposal that may be more acceptable by the bitcoin community. If it can't be added to bitcoin or namecoin, middlecoin will be needed.

I agree that something like this might be the way to go, especially if the bitcoin community is lukewarm on the idea of polluting the protocol with my crazy ideas Smiley
1245  Bitcoin / Development & Technical Discussion / Re: [PROPOSAL] The Second Bitcoin Whitepaper on: July 27, 2011, 02:41:24 PM
Here's the alternate scenario:

1) Starting condition: $4M in the escrow fund, $2M from hyperbitcoin holders
2) Whole world: "What?! We can own/trade commodities/currencies with no fees or paperwork??" *Tries to fit trillions of dollars of value into a 21M coin hole*
3) Bitcoin prices: +100000000% (million-fold increase)
4) Protocol: "Hmmm. Escrow fund is a million times larger than the target. Time to distribute some wealth to hyperbitcoin holders."
5) Bitcoin holders: "We're rich!"
6) Hyperbitcoin holders: "We're double-rich"
7) That one guy who didn't have any bitcoin: *Jumps out window*

And finally, the doomsday scenario

1) Starting condition: $4T in the escrow fund, $2T from hyperbitcoin holders
2) Jon Stewart: "Bitcoins suck! The escrow fund will go insolvent!"
3) Whole world: *Tries to sell their bitcoins all at once, and any bitcoin-backed commodities/currencies they own*
4) Protocol: "Um, the escrow fund is 50% low . . . no 60% . . . no 70% . . . oh crap!"
5) Protocol: "Time to steal ALL the hyperbitcoins from the speculators: UBERYOINK!!"
6) Speculators: *Jump out window*
7) Protocol: "Anybody want to buy these hyperbitcoins?"
8 ) New Speculators: "No thanks, we're too skeered!"
9) Protocol: "Fine then. LET THERE BE BITCOINS!" *50M bitcoins appear in the escrow fund*
10) Satoshi: "That's inflation! You've ruined my baby!" *Jumps out window*
11) Bitcoin holders: "We're poor!" *Jump out window*
12) Protocol: "Sorry. I'll destroy some bitcoins if prices go up again. Hopefully we'll get down to the 21M number again.
13) Whole World: "We don't want bitcoins anymore"
14) Bitcoin prices -> $0
15) Protocol: "Let's see, to save the token-holders, I need to create infinity+1 bitcoins in the escrow fund. That does not compu..." *bitcoin implodes*
16) Oilcoin/GoldCoin/USDCoin holders *Jump out window*

Obviously the protocol cannot continue to stabilize prices if nobody wants bitcoins anymore. After reading my own doomsday scenario, I think that creating bitcoins out of thin air would be a very bad idea. I think at step 9 above, the protocol would just have to say: "Sorry token holders, you're screwed. The bitcoin show must go on!"

New doomsday scenario ending:
9) Protocol: "Sorry token-holders, while there are no speculators willing to absorb volatility, you will have to eat the volatility. Your OilCoins/AntiOilcoins GoldCoins/AntiGoldCoins will fluctuate in value with bitcoin prices until enough new speculators enter the ring."
10) Token holders: "Sigh. OK. We knew this was in the cards when we signed up. Maybe if we hold these pegged coins long enough, speculators will buy hyperbitcoins and replenish the escrow fund and we won't have to take a loss."
1246  Bitcoin / Development & Technical Discussion / Re: [PROPOSAL] The Second Bitcoin Whitepaper on: July 27, 2011, 02:25:39 PM
Here's a thought experiment for you:

1) Starting condition: escrow fund contains $4T worth of bitcoins, $2T of that is from hyperbitcoin speculators
2) Satoshi sells 10K bitcoins because he wants to buy Australia, instantly driving down bitcoin prices by 10%
3) Protocol: "Escrow fund is 10% below target. Time to steal some hyperbitcoins from the speculators. YOINK!"
4) Speculators: *Jump out the window*
5) Protocol: "Now I'll sell these hyperbitcoins to new speculators. KA-CHING!"
6) New Speculators: Yay!
7) Ending condition: hyperbitcoin prices down some, escrow fund is back to target value, somebody cleans dead speculators off the pavement, new speculators can get rich when bitcoin prices come back

Now here's the important bit, which I just realized: What happens to bitcoin prices when the protocol sells a bunch of hyperbitcoins which it stole from existing speculators? Let's see, we removed a bunch of bitcoins from circulation and put them in the escrow fund. Less bitcoin supply = higher bitcoin prices.

Did the new bitcoin protocol just self-stabilize the price of bitcoins? Did we just create a bitcoin variant that resists price changes??

I'm not saying that bitcoin prices would be immobile, but that they would be inherently less volatile, because hyperbitcoin holders would be absorbing that volatility.
1247  Bitcoin / Development & Technical Discussion / Re: [PROPOSAL] The Second Bitcoin Whitepaper on: July 27, 2011, 02:13:01 PM
I don't agree with your optimistic assessment of honest exchange rate reporting. You might want to look at my thread on " securing contingent claims" which discusses an alternative mechanism.

What, no link?!

Sigh. OK, I'll search for it. Here it is: http://forum.bitcoin.org/index.php?topic=19130.0
1248  Alternate cryptocurrencies / Altcoin Discussion / Re: Multicoin, Namecoin, Goldcoin, Silvercoin, OilCoin, 1971coin, backed by bitcoin! on: July 27, 2011, 02:10:26 PM
I've read this thread and I still think that your system has the risk of default (and the subsequent collapse).
Since you can't print bitcoins (not even for a while), you can default.

My proposal in the sister thread actually mentions that temporarily printing bitcoins might be an emergency measure added to the protocol: http://forum.bitcoin.org/index.php?topic=31645.0

I don't know what is wrong with the derivatives with bitcoin escrows. You still get what you want, oil-coins.

Bitcoin-denominated derivatives are only slightly useful if bitcoin values are bouncing all over the place. I might be right that oil will rise 5% over the next six months, but my gain is dwarfed by a 50% drop in bitcoin values that I used to escrow my bet. I have to have some kind of bitcoin option strategy to hedge against a drop in bitcoin values, which is getting way too complicated for anyone but an options expert.

If I've understood vector76 properly, you would have an oil-coin versus a derivative short oil and long bitcoin.
The problem I didn't get about fungibility is that any of the parties could redeem the contract at any time.
That problem could be reduced if the system can look for contracts enders on both sides of the bet.
Remember that both sides of the derivative are always solvent (or the contract is automatically redeemed).

I also came to the conclusion that you cannot use bitcoins for the escrow, because maybe you need to transfer bitcoins of it from a user to the other and you don't own the private keys.
You need derivativeCoin.

Everything I have proposed so far requires changes to the existing bitcoin protocol. It might also be possible to engineer something that runs distributed, is backed by bitcoins, but does not need to touch the bitcoin block chain. I would be very interested to hear proposals on how that might work.
1249  Bitcoin / Bitcoin Discussion / Re: TradeHill - Dwolla is being scammed and reversing transactions on: July 27, 2011, 12:57:46 PM
Today on IRC and via email, two other exchanges confirmed they had transactions that 'vanished' and that were 'reversed'. We are waiting for them to make this public.

Any exchange using Dwolla CSVs over the past two months almost certainly has loses to the order of 3 to 9% of their volume.

Adam

This could mean that some exchanges no longer have the funds to cover all their liabilities, and are now operating on a "fractional reserve" model where they just hope everybody won't withdraw their money all at once. Kinda scary.

This is why I try not to leave any more money than I have to on the exchanges. There is nobody looking over their shoulder to make sure they aren't making big loans to themselves, writing off big losses, etc, all while naively intending to pay the money back "someday, with our future profits"
1250  Bitcoin / Press / Re: Bitcoin press hits, notable sources on: July 27, 2011, 12:52:44 PM
Nefario story spreading:

http://www.finextra.com/news/fullstory.aspx?newsitemid=22812
http://thenextweb.com/insider/2011/07/27/developer-relies-on-bitcoin-to-fund-u-s-trip-customs-sends-him-home/
1251  Alternate cryptocurrencies / Altcoin Discussion / Re: Multicoin, Namecoin, Goldcoin, Silvercoin, OilCoin, 1971coin, backed by bitcoin! on: July 27, 2011, 12:48:18 PM
One non-obvious consequence of the rules described in my last post should be noted.

I stated that with falling bitcoin prices, hyperbitcoins are sold to speculators, diluting the existing hyperbitcoins and reducing their leverage.

However, for someone holding bitcoins, the effective leverage achieved by trading them for hyperbitcoins actually increases as prices fall. The system is effectively offering greater and greater leverage in exchange for your bitcoins, while existing hyperbitcoin holders get less and less value and leverage.

It might be desirable to amplify this effect when bitcoin prices are falling rapidly, perhaps actually destroying a small percentage of the hyperbitcoins held by each user to make the deal better for new hypercoin buyers. This would be an even more conservative approach to managing the escrow fund. I believe it might be possible to mathematically guarantee solvency with some high degree of probability.
1252  Alternate cryptocurrencies / Altcoin Discussion / Re: Multicoin, Namecoin, Goldcoin, Silvercoin, OilCoin, 1971coin, backed by bitcoin! on: July 27, 2011, 12:35:17 PM
I see two things mixed together
1. a derivative system to stabilize value while someone else gets leverage, and
2. something akin to a fractional reserve banking system

I'm not sure how one ties into the other or why they must be connected.

Hyperbitcoins are leveraged and it is therefore possible for them to be underwater.  The owner can walk away, presumably losing their initial bitcoin 'collateral' but it is still a default.

If a hyperbitcoin were leveraged 2:1, say if it's effectively one bitcoin plus a derivative that's long bitcoins and short USD, then if bitcoins fall to below half their value, the hyperbitcoin is worth less than zero and the owner can discard it.  I don't see this as particularly unlikely since bitcoins today are less than half their high for the year.

My intention is to have the protocol sell more hyperbitcoins to speculators as bitcoin prices fall, decreasing everyone's leverage by diluting the hyperbitcoins which will also drive down hyperbitcoin prices faster than bitcoin prices (the leverage) and adding bitcoins to the escrow fund. When bitcoin prices rise, hyperbitcoins will be purchased from speculators by the protocol, increasing everyone's leverage and driving up hyperbitcoin prices faster than bitcoin prices (the leverage) using excess bitcoins from the escrow fund. I believe that by having the protocol control the hyperbitcoin supply and resulting leverage, the escrow fund can remain solvent in a sustainable way and prevent default as long as bitcoin remains a viable currency.


Dacoinminster, your idea depends on bitcoin (almost) always going up. That's what I don't like about it. In case of default, you can't print more bitcoins outside the bitcoin network, just IOUs.

vector76, what if we have the derivative contracts inside the chain an also an automated broker that liquidates/covers your position if the reserves get too low?
This way, you eliminate the default risk. If you want your position to exist longer, just put more funds in the escrow.
To make them fungible, the "additional funds" (the difference between the needed funds and the actual funds), should be returned to the seller when the oil-coin is sold. The buyer of the oil-coin can add more funds to the contract within the same transaction to avoid the contract to be liquidated because of a small change in price a block after the transaction is made.

I think it could work, but yes, you would need a counter-party in the derivative for each oil-coin issued. All contracts would be btc (or derivativecoin) denominated.

The network would rely on derivativecoin creation and/or in fees for the contracts creation and trades. The fees can be charged in bitcoins, derivativecoins or both.
There's no need to create another currency for this though. This way we could also see if fees are enough on their own.

I agree that the math is easier when bitcoin prices are going up, but I believe the protocol's control of hyperbitcoin prices and effective leverage also prevents default as described above. A more extreme situation, with panic-selling of both bitcoin and bitcoin-backed pegged-value tokens would require a more extreme response, for which I outline a couple possibilities in the first post of the sister thread: http://forum.bitcoin.org/index.php?topic=31645.0

You are correct that all currencies and commodities tracked would need a real-life counter-party (the escrow fund itself cannot be taking positions that have a net long or short position against oil/gold/Euros/etc). That is the intended function of GoldCoins vs AntiGoldCoins, etc.
1253  Other / Meta / Re: [1 BTC GIVEAWAY] 10 users will get 0.1 BTC for being my shill on this forum on: July 27, 2011, 12:21:25 PM
I count 18 posts on my list for potential pay-outs. This is fun!
1254  Bitcoin / Development & Technical Discussion / Re: [PROPOSAL] The Second Bitcoin Whitepaper on: July 27, 2011, 12:13:56 PM
I don't see how you think this can work.  Why would anyone vote for the correct exchange rate?  Any rational person would vote for the option that pays out the escrow funds to their side of the bet.

Again, the external exchange rate voting does not affect what the escrow funds pay out to whom (that is decided by supply and demand). The external exchange rate ONLY affects the fees on transactions, nudging them towards the external exchange rate.

Also, keep in mind that the only real mechanism for "voting" is to reject a block because it doesn't match the exchange rate you calculated. The vast, vast majority of clients have a strong incentive to get it right. It would take massive collusion to get more than 50% of the computing power to accept a different external exchange rate, and that would only accomplish an annoying change in the fee structure. There are a lot more lucrative things you could do with 51% of bitcoin hashing power.

I am totally confident that the distributed exchange rate would work just fine if implemented correctly. The main disruptive idea here is the transfer of volatility risk from the token holders to the hyperbitcoin holders. That is the scary new thing to me, and while it seems like it would work to me, it is not clear what the exact rules should be, or how it could be tested.
1255  Alternate cryptocurrencies / Altcoin Discussion / Re: Multicoin, Namecoin, Goldcoin, Silvercoin, OilCoin, 1971coin, backed by bitcoin! on: July 27, 2011, 12:12:33 AM
Yes, I agree, holding something with the features of bitcoins but with the value stability of oil would be great.  The problem is that somewhere along the line it requires a contract that's long on oil.  I agree that it is difficult or impossible to hold oil in a digital wallet.  This is precisely the problem.

To tie bitcoins into an oil contract such that it can be redeemed for oil will require an oil contract that can be held and transferred digitally.  Essentially a digital bearer certificate that can be unlocked when the derivative is redeemed... or something like that.  A company or 'bank' could hold reserves and issue digital bearer certificates, and those could be connected to bitcoins through derivatives.

But at that point it would be simpler to just use the digital bearer certificates themselves.

This doesn't mean that the derivative market is infeasible, it only means that the derivatives are subject to default risk.  If the bearer certificates could be used, then they could provide 100% guaranteed "backing" but without them there must be some counterparty who is holding the other side of the contract, and that counterparty could default.

If I trade derivatives through a broker, the broker is on the hook if my liabilities exceed my assets, so the broker will liquidate/cover my position if my reserves get too low.  This sort of system might be required for derivatives to be trustworthy enough to be fungible.  It would be a step in the right direction, and exchanges could provide this sort of service today if they wanted, without any changes to the block chain.

To go fully decentralized and guaranteed only by encryption, default risk is going to be a problem.  And it has two facets, one is the actual default risk, and the other is that it makes the derivatives non-fungible.

In my mind, overcoming the default risk is one of the core challenges of setting up such a system.  Perhaps the derivatives could be restricted to those with limited downside, where you can't lose more than 100% of the investment.  Instead of being short, you essentially own a put (or something like that).  Then these contracts can exist without risk of default and without having to figure out how to somehow connect the underlying asset itself.

It is true that with some futures contracts, you can actually take delivery of the underlying commodity (although people actually doing this is very rare). Almost all futures contracts are cash-settled. There are some futures contracts that are 100% cash settled (no way to actually take delivery of the underlying commodity).

Bitcoin-settled tokens like the ones described here and in the sister post for "the second bitcoin whitepaper" (http://forum.bitcoin.org/index.php?topic=31645.0) would actually have nearly zero risk of default by the counterparty. I believe it would not be possible to default without hacking bitcoin.

The risk I would be worried about, which is spelled out in significant detail in posts in the sister thread linked above, is that bitcoin values will crash, and the escrow fund will not be able to cover the value of all the tokens it has issued.

I believe the protocol can mitigate this risk to near zero (again, see the sister thread for details).



1256  Bitcoin / Development & Technical Discussion / Re: [PROPOSAL] The Second Bitcoin Whitepaper on: July 26, 2011, 11:49:52 PM
I am not sure about that.  Even validating simple bitcoin transactions requires knowing the entire history of the transaction chain that leads up to the transaction in question.  Except that because bitcoin only allows validated transactions into the block chain, and because each transaction completely spends the output of the prior transaction, you really only need to keep track of the most recent transaction in every chain of transactions.

In your proposal it seems that, since the bitcoin miners aren't doing any work at all to validate your data set before including the block, every client is going to have to evaluate every single data set completely in order to have an accurate picture of what transactions going forward from that point are valid and which ones aren't.  It just seems like an incredible multiplication of the amount of work for everyone.

With bitcoin, a client can keep just the block chain headers and from that, it can query to someone with more resources than itself to validate transactions in a light weight manner, and can verify their results based on the small block chain headers that it stores (~4 MB per year, easily sustainable for every bitcoin peer).  How will such a thing be done in your external block chain, which will have both valid and invalid blocks and for which the client will not know, just from bitcoin block headers, which ones were valid and which ones weren't?

I believe it is the same problem that bitcoin already solves. If somebody puts bad data into a block, the next miner running the new software would reject the previous block as if it had never been created. Normal users could wait for N confirmations on anything they care about, just like they do now.
1257  Bitcoin / Development & Technical Discussion / Re: [PROPOSAL] The Second Bitcoin Whitepaper on: July 26, 2011, 11:42:52 PM
Once again you're back to making transactions so hard to verify as to be impractical.  Now everyone who wants to detect whether or not a miner who claimed a transaction fee for a block that included one of your hashes, has to validate your entire secondary database, to determine whether the block is valid.  This is much more expensive than your earlier assertion that all you need "is a slot in the bitcoin block chain for a hash value"

Yes, fees paid to miners for including the new hash would NOT be backwards compatible with older versions of bitcoin. Only people running updated software would recognize that the miner collected the fee.

Anyone running the new software would have to verify that the hash matched the transactions and exchange rates they cared about. Anybody running a miner would have to check all transactions and exchange rates to decide if they need to reject any previous blocks.

I'm not sure to what extent the new protocol could be backwards-compatible with the old protocol. It seems like a lot of it could be backwards compatible, but you run into problems when you have a miner collect a fee that is only recognized by the new clients, then he tries to spend it. There might be no way to get around it except to get everyone switched to the new protocol.
1258  Bitcoin / Development & Technical Discussion / Re: [PROPOSAL] The Second Bitcoin Whitepaper on: July 26, 2011, 11:35:08 PM

But do we need another hash race?  Why compete with bitcoiners for hardware?  You're just driving up costs for everyone.

I definitely don't want to compete with bitcoin hashing in any way. I just want to give miners an incentive to include an extra hash in the blocks they are already generating.
1259  Bitcoin / Development & Technical Discussion / Re: [PROPOSAL] The Second Bitcoin Whitepaper on: July 26, 2011, 11:22:09 PM
In order for the above to work though, our blocks can't have a reward, otherwise people will have incentive to overpower it.  In fact, the block finder should pay the transaction fee to lock the chain to bitcoin.  Then, only those who value the security of the block chain have incentive to mine.

I think we could give the miner a transaction fee that is only valid if the rest of the nodes running the new protocol accept the hash in the block. That would give the miner a good incentive to get the exchange rates right.
1260  Bitcoin / Development & Technical Discussion / Re: [PROPOSAL] The Second Bitcoin Whitepaper on: July 26, 2011, 10:32:04 PM
I sent this to Satoshi. Probably, he's just annoyed by this, but who knows?

From: **************
Date: Tue, Jul 26, 2011 at 3:29 PM
Subject: [PROPOSAL] The Second Bitcoin Whitepaper
To: satoshin@g**.com


Hi Satoshi,
 
I know you've been intentionally distant from your bitcoin project for some time now, but I thought you might be interested in my proposal for what could be included in "the second bitcoin whitepaper", extending your bitcoin protocol: http://forum.bitcoin.org/index.php?topic=31645.0

I don't expect a response, although obviously any response you chose to make would carry a lot of weight. If my proposal somehow becomes reality, I believe you could end up a trillionaire (by USD valuation).

Hope you are doing well and enjoying your bitcoin wealth to the fullest!

-********* (dacoinminster)
Pages: « 1 ... 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 [63] 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!