Re: [Bitcoin-development] Bitcoin-development Digest, Vol 32, Issue 57
This will easily create too much data in the block chain. I think it's probably better to trust online wallets to handle complex financial transactions such a debits or credits. If Bitcoin achieves Visa-levels of popularity, that would mean one megabyte of transactions per second (even assuming script isn't used), or ~30 terabytes per year. After a decade the Bitcoin blockchain can only be stored by Amazon or Google or the Web Archive, even assuming Kryder's Law continues. If the Bitcoin blockchain instead becomes cheque clearinghouse style transaction system, many problems involving blockchain growth become negligible. Sure, this is supposed to be a trustless system, but there's a reason why everyone relies on trust in the real world. On Tue, Jan 28, 2014 at 7:13 PM, < bitcoin-development-requ...@lists.sourceforge.net> wrote: > Send Bitcoin-development mailing list submissions to > bitcoin-development@lists.sourceforge.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > or, via email, send a message with subject or body 'help' to > bitcoin-development-requ...@lists.sourceforge.net > > You can reach the person managing the list at > bitcoin-development-ow...@lists.sourceforge.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Bitcoin-development digest..." > > > Today's Topics: > >1. Re: BIP70: PaymentACK semantics (Peter Todd) >2. Re: Extension for BIP-0070 to support recurring payments > (Stephane Brossier) > > > -- > > Message: 1 > Date: Tue, 28 Jan 2014 16:12:18 -0500 > From: Peter Todd > Subject: Re: [Bitcoin-development] BIP70: PaymentACK semantics > To: Mike Hearn > Cc: Andreas Schildbach , Bitcoin Dev > > Message-ID: <20140128211218.GE22059@savin> > Content-Type: text/plain; charset="us-ascii" > > On Tue, Jan 28, 2014 at 06:33:28PM +0100, Mike Hearn wrote: > > In practice this should only be an issue if a payment is submitted and > > fails, which should be rare. Barring internal server errors and screwups > on > > the merchants side, the only reasons for a rejection at submit time would > > be the imperfect fungibility of bitcoins, e.g. you try and pay with a > huge > > dust tx or one that's invalid/too low fee/etc. > > > > So I think we have a bit of time to figure this out. But yes - once you > > broadcast, you probably accept that there might be a more painful path to > > resolve issues if something goes wrong, I guess. Right now BitPay has a > > support system where you can file a ticket if you pay the bitcoins and > they > > don't recognise it or the tx never confirms or whatever. It's grotty > manual > > work but they do it. Not broadcasting unless you "have" to seems like an > > optimisation that can reduce pain without much additional complexity. > > That's the reason you use a model where things happen atomicly: the > funds either can or can't be transferred, so if the merchant screws up > due to a server failure at worst the wallet can always send the > original, signed, payment request and transaction details proving to the > merchant that they agreed. Since the asked for txouts exist in the > blockchain they must either refund the money, or ship the goods. > > Wallet software can handle that kind of worst-case failure by > automatically sending the original payment request back to the merchant. > At worst all customer support has to do is tell the customer "Sorry > about that; we didn't get your payment. Please start your wallet up and > hit the 'resend transaction' button in your wallet and we'll clear that > right up." > > Keep in mind that we're probably going to see fraudsters figuring out > ways to make payment servers fail. This means conversely that a customer > calling up a merchant and saying "Hey! Something didn work but the > wallet says I paid!" is going to be treated more suspiciously. By using > atomic protocols the issue of did or didn't they pay becomes much more > black and white, and failure resistant. That's exactly what we keep > saying Bitcoin offers that PayPal doesn't. > > -- > 'peter'[:-1]@petertodd.org > 85c725a905444d271c56fdee4e4ec7f27bdb2e777c872925 > -- next part -- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 685 bytes > Desc: Digital signature > > -- > > Message: 2 > Date: Tue, 28 Jan 2014 18:47:20 -0800 > From: Stephane Brossier > Subject: Re: [Bitcoin-development] Extension for BIP-0070 to support > recurring payments > To: "bitcoin-development@lists.sourceforge.net" > > Cc: Pierre-Alexandre Meyer , PikaPay > > Message-ID: > Content-Type: text/plain; charset="windows-1252" > > >From what I have seen so far, there seems to be an agreement that
Re: [Bitcoin-development] Bitcoin-development Digest, Vol 31, Issue 41
You just completely ignored my point. I'm not sure who's trying to insult whom, or if you're attempting an argumentum ad hominem. My idea is completely valid. The only way to man in the middle to have such a large percentage of hash power is to either a) attack a pool (which people would notice when their withdrawals go nowhere), b) attack a large number of nodes, which must have enough combined hash power to mine four blocks within three days for people to notice (I think it is unlikely for Bitcoin point of sale nodes to have significant hash power), or c) the attacker himself has 1% of the hash power and is diverting it to conduct a man in the middle attack against one single person (as opposed to a major retailer who has a round the clock IT staff). In order for a large number of nodes to be attacked, it must be by someone who either is a state actor or an ISP, at which point you've already lost. It's really simple math, it require on even the most optimistic estimates a tenth of a percent of the total network hash power to mine 4 blocks within three days with good luck. Or maybe this single person is on vacation, then it would take a hundredth of a percent of the total hash power over two weeks. I think very few people even have a hundredth of a percent of the total hash power, which goes to show how secure the network is, and how little my proposal would weaken network security. I'll concede that difficulty could be reduced only by 80% if only four blocks were mined in 3 days, which would provide sufficient margin against these proposed man in the middle attacks, because block-chain growth would be noticeably reduced. But I repeat myself. Repeatedly. I wish you would understand my points. I'm making a good faith effort to provide an original idea before it's possibly too late. But fine. I have nothing more to add, and it's the holidays. On Tue, Dec 24, 2013 at 2:47 AM, < bitcoin-development-requ...@lists.sourceforge.net> wrote: > An attacker with some small hashpower isolates you (as an individual) > from the network by MITMing your network. You just switch the the > attackers chain as if nothing happened because of the network rule > that defines it as OK. Today, you will see that you're behind and warn > the user. > > Was it really so hard to write a three-sentence paragraph to clarify > the attack instead of insulting people? Still, posting ideas here > without spending time to ensure you understand the Bitcoin network > well is frowned upon. > -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin difficulty sanity check suggestion
Maybe it's because the arguments being presented are nonsensical and irrelevant to the current Bitcoin network topology, composed of a small number of mining pools, not solo miners? Furthermore I think people would realize that their mining pool has gone "off the reservation" so to speak. On Mon, Dec 23, 2013 at 8:05 PM, Allen Piscitello < allen.piscite...@gmail.com> wrote: > Ryan, > > Why do you continue to try to correct people who clearly have put more > thought into this than you? Everyone understood you just fine, you just > seem to have trouble comprehending why your ideas are terrible. > > > On Mon, Dec 23, 2013 at 7:51 PM, Ryan Carboni wrote: > >> I think you misunderstood my statement. If time > 3 days, and after 4 >> blocks have been mined, then difficulty would be reset. >> >> In theory, one would have to isolate roughly one percent of the Bitcoin >> network's hashing power to do so. Which would indicate an attack by a state >> actor as opposed to anything else. Arguably, the safest way to run Bitcoin >> is through a proprietary dial-up network. >> >> >> On Sun, Dec 22, 2013 at 7:22 PM, Mark Friedenbach wrote: >> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> Ryan, these sort of adjustments introduce security risks. If you were >>> isolated from the main chain by a low-hashpower attacker, how would >>> you know? They'd need just three days without you noticing that >>> network block generation has stalled - maybe they wait for a long >>> weekend - then after that the block rate is normal but completely >>> controlled by the attacker (and isolated from mainnet). >>> >>> There are fast acting alternative difficulty adjustment algorithms >>> being explored by some alts, such as the 9-block interval, 144-block >>> window, Parks-McClellan FIR filter used by Freicoin to recover from >>> just such a mining bubble. If it were to happen to bitcoin, there >>> would be sophisticated alternative to turn to, and enough time to make >>> the change. >>> >>> On 12/22/2013 07:10 PM, Ryan Carboni wrote: >>> > I think Bitcoin should have a sanity check: after three days if >>> > only four blocks have been mined, difficulty should be adjusted >>> > downwards. >>> > >>> > This might become important in the near future. I project a >>> > Bitcoin mining bubble. >>> > >>> -BEGIN PGP SIGNATURE- >>> Version: GnuPG v1.4.14 (GNU/Linux) >>> Comment: GPGTools - http://gpgtools.org >>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>> >>> iQIcBAEBAgAGBQJSt6yGAAoJEAdzVfsmodw4SegQAIJAWW0OgSjediSWq+EpkReS >>> qMvC2Y9dmVHtowYLdJVcgwFWbpU8RhA6ApQ1Ks2XF4t0hFCObYDecG6Nl3OIaLfb >>> snz24v8ymdxYXKNtzHHUP0VBgsaoRghIpkbf7JMUXC22sxPoPOXFt5RevLgJHrvc >>> oGFZSIcEcGgwhwZ745CgFZLwaKuSmg5+wFFcrjIihlHKJOl47Z7rzeqnD6mf2Oi3 >>> hDpRuVbuhlGMliYcmhk1E6oV0in2R4Purw1WtoY8C9DxrSP2za7W1oeCkmlFfJZS >>> to6SzRj7nEIl0LFaPGsIdBrRdDHfvu6eP2OecI+GNLEwLY6qE5v5fkh47mcDkrN0 >>> 02PmepoX5PRzBqp4sx8WaFKuRbmTRRr3E4i9PGoyzTckkZzq+zFmb1y5fwOy17hE >>> C+nP+DyuaPzjypjdo6V+/oGzUKtuKPtqcB1vurbm+WBl5C1jWosAXv5pR87mdCUJ >>> +0e14wPra5blV6yBVqX7yx+2heDGymPKfHJ8i76Dtix7XVOJWKVY4OpIxO7YrYv8 >>> IKcIswoKhZdSDOJLcjm4Qp4hrzgCHAHWx6vN71r5r2T6zaJTOvp98GS04Yy7VGAr >>> j38hojcwvJC1ahER3LV/vC0cqO+fxrvY8Q9rW2cUxCnzxzjjG0+Z/gjW8uh73lXN >>> DOTF7jpt0ZmCm7uhG9z7 >>> =5Q2H >>> -END PGP SIGNATURE- >>> >> >> >> >> -- >> Rapidly troubleshoot problems before they affect your business. Most IT >> organizations don't have a clear picture of how application performance >> affects their revenue. With AppDynamics, you get 100% visibility into your >> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics >> Pro! >> >> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk >> ___ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> > -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin difficulty sanity check suggestion
It does take a state-level actor to apparently disconnect *multiple *miners from the rest of the network. How many Bitcoin miners hash an entire percent or more of the Bitcoin network? What you're proposing is an attack at the highest levels of the internet infrastructure. On Mon, Dec 23, 2013 at 6:02 PM, Mark Friedenbach wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Which would leave you entirely in the hands of your dialup provider. > Or the manufacturer of your switch. Or your ISP's backbone provider. > It does not take a state-level actor to do network attacks. > > BTW, what does "difficulty would be reset" mean? There are multiple > ways to interpret that statement. In the most straightforward way, my > objections apply. > > On 12/23/2013 05:51 PM, Ryan Carboni wrote: > > I think you misunderstood my statement. If time > 3 days, and after > > 4 blocks have been mined, then difficulty would be reset. > > > > In theory, one would have to isolate roughly one percent of the > > Bitcoin network's hashing power to do so. Which would indicate an > > attack by a state actor as opposed to anything else. Arguably, the > > safest way to run Bitcoin is through a proprietary dial-up > > network. > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.14 (GNU/Linux) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJSuOs3AAoJEAdzVfsmodw4BwAP/0Ynq/SxNIBFFdL7RaSiE5KM > zNRtlZJCYvmCXgKKtMyO+Ron+YGqY8yg8r0ifb6oqlJCG5t0msExym/CA9CYMV6V > UnVaGaNkFrLSF1q8Dt6X4I9OSeCiBstahQOjPaerUycLTY2W/cKPblhCC0rvXrfI > 3Fz3p6SHbCcNHw89w6ry3QG420+UNroFCpNu+Oa2YfWoZY2p91JLbuiUwXL5KEac > PDskHGsb9q1vyAkCJ6eOp3MJfFP/Dy7mASVwPql/nzf2ceSDtO4dpngo0uNsCwFo > QSWIRdWv4OiJk1OM6fjEj/51mebczgO0ShczRKk9QkX4FEFEqP/ARdbl8bSC4IsT > /3s2HHiYDahEOMiXV5ao3kmBpyUR8p4erRbtwRzdZzOgGL37yxj8VGmY93bkVQNB > zi2n3WCCju0a+gqREyaEFAM8kPIhx9++YNIddwQxK38njUSe2CzqM8t+28ZfseYl > YnQeNFUfcmvzhxTXxgyoCuGF5HbFRTn/AallkYSPxYtxGq4WuLN36BS3cTv8wCLz > sYTyuxWxjZ7CS8fx8MWilw72tQf9torwmrWJtjgRLFE3OvQxRjN+ppDV8cfC8UAB > p0CGzBgVaw5yZ5LzCawQVTGWJdzs+ZPlQu8SO53dHhEtRAmdbFa0mMD2FrS/5Ih/ > YcwdP6Xm69HTgzCenu5F > =HtRS > -END PGP SIGNATURE- > -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin difficulty sanity check suggestion
I think you misunderstood my statement. If time > 3 days, and after 4 blocks have been mined, then difficulty would be reset. In theory, one would have to isolate roughly one percent of the Bitcoin network's hashing power to do so. Which would indicate an attack by a state actor as opposed to anything else. Arguably, the safest way to run Bitcoin is through a proprietary dial-up network. On Sun, Dec 22, 2013 at 7:22 PM, Mark Friedenbach wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Ryan, these sort of adjustments introduce security risks. If you were > isolated from the main chain by a low-hashpower attacker, how would > you know? They'd need just three days without you noticing that > network block generation has stalled - maybe they wait for a long > weekend - then after that the block rate is normal but completely > controlled by the attacker (and isolated from mainnet). > > There are fast acting alternative difficulty adjustment algorithms > being explored by some alts, such as the 9-block interval, 144-block > window, Parks-McClellan FIR filter used by Freicoin to recover from > just such a mining bubble. If it were to happen to bitcoin, there > would be sophisticated alternative to turn to, and enough time to make > the change. > > On 12/22/2013 07:10 PM, Ryan Carboni wrote: > > I think Bitcoin should have a sanity check: after three days if > > only four blocks have been mined, difficulty should be adjusted > > downwards. > > > > This might become important in the near future. I project a > > Bitcoin mining bubble. > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.14 (GNU/Linux) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJSt6yGAAoJEAdzVfsmodw4SegQAIJAWW0OgSjediSWq+EpkReS > qMvC2Y9dmVHtowYLdJVcgwFWbpU8RhA6ApQ1Ks2XF4t0hFCObYDecG6Nl3OIaLfb > snz24v8ymdxYXKNtzHHUP0VBgsaoRghIpkbf7JMUXC22sxPoPOXFt5RevLgJHrvc > oGFZSIcEcGgwhwZ745CgFZLwaKuSmg5+wFFcrjIihlHKJOl47Z7rzeqnD6mf2Oi3 > hDpRuVbuhlGMliYcmhk1E6oV0in2R4Purw1WtoY8C9DxrSP2za7W1oeCkmlFfJZS > to6SzRj7nEIl0LFaPGsIdBrRdDHfvu6eP2OecI+GNLEwLY6qE5v5fkh47mcDkrN0 > 02PmepoX5PRzBqp4sx8WaFKuRbmTRRr3E4i9PGoyzTckkZzq+zFmb1y5fwOy17hE > C+nP+DyuaPzjypjdo6V+/oGzUKtuKPtqcB1vurbm+WBl5C1jWosAXv5pR87mdCUJ > +0e14wPra5blV6yBVqX7yx+2heDGymPKfHJ8i76Dtix7XVOJWKVY4OpIxO7YrYv8 > IKcIswoKhZdSDOJLcjm4Qp4hrzgCHAHWx6vN71r5r2T6zaJTOvp98GS04Yy7VGAr > j38hojcwvJC1ahER3LV/vC0cqO+fxrvY8Q9rW2cUxCnzxzjjG0+Z/gjW8uh73lXN > DOTF7jpt0ZmCm7uhG9z7 > =5Q2H > -END PGP SIGNATURE- > -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bitcoin difficulty sanity check suggestion
I think Bitcoin should have a sanity check: after three days if only four blocks have been mined, difficulty should be adjusted downwards. This might become important in the near future. I project a Bitcoin mining bubble. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin-development Digest, Vol 31, Issue 25
> > I believe that if there ever becomes a consensus that Bitcoin?s inflation > parameters were a show-stopper for the Bitcoin economy, that the power to > correct it lies with merchants, who would vote for changing the rules. I > believe they would do this not by changing Bitcoin, but by accepting, in > parallel, a brand new alt coin that reflects the consensus as to how the > inflation should be. I believe such an alt coin would have its genesis at > around the time that consensus moved toward accepting inflation, rather > than adopting the seignorage of some other alt coin out there today. > Agreed Mike. The economic parameters of Bitcoin are fixed in stone forever. Adding a monetary authority to Bitcoin is impossible and undesirable because the implicit contract of Bitcoin is that there would finally be a currency in which no one could mess around with. It would betray all prior holders. But these are ideas everyone is free to experiment with in new altcoins. If the lack of inflation in Bitcoin ever becomes a problem in day-to-day usage, such a parallel chain could become the de-facto cryptocurrency for spending. Or just maybe fiat already works well enough there... Wladimir -- -- How do you propose to use Bitcoin on a week-long vacation or for life in general, when it's value constantly swings up and down? Or for the average person's paycheck to swing up and down in value every week? Awfully hard to budget. There is also a catch-22, no altcoin can gain acceptance because the infrastructure for Bitcoin already exists, but without infrastructure, no altcoin can gain acceptance. Furthermore, the average merchant or consumer lacks the idealism or knowledge to bring about such changes in Bitcoin. It's a lofty idea that the average person will bring about such change when they don't bring about such change already in their own lives. It is ironic considering that there's no Bitcoin "chamber of commerce," just a few programmers in a development mailing list who direct the future of Bitcoin, and thus these merchants you speak of have little to no voice what so ever, with a few exceptions of merchants who do subscribe to this mailing list. What I am proposing makes sound economic sense. It is the only way to fix the speculation crisis. Just ask an economist. And the economic parameters of bitcoin are not fixed in stone. If there needs to be a change, it will be messy but it could happen. Besides, using Austrian precepts of inflation blurs the fact that deflation will still be possible under my proposal. Although amusingly enough Austrian-defined inflation is still occurring within Bitcoin, in fact faster then desired since blocks are being processed every seven minutes now as opposed to ten, and it's quite likely when 28nm ASIC miners are released that blocks will be processed every five minutes before the difficulty is adjusted again. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Monetary Authority for Bitcoin
You're just closed minded. On Mon, Dec 9, 2013 at 3:10 PM, Jeff Garzik wrote: > On Mon, Dec 9, 2013 at 7:23 PM, Ryan Carboni wrote: > > It is not a violation of the trust of those holding the currency. Many > > people bought Bitcoin in the hopes that it's value in the relation of > other > > currencies will increase, not because there's a fixed money supply. The > > majority of people using Bitcoin as a currency in exchange for real goods > > are using the exchanges. > > Your proposal has been met with widespread laughter. Were I not ill > with the flu, mockery would ensue as well. > > -- > Jeff Garzik > Bitcoin core developer and open source evangelist > BitPay, Inc. https://bitpay.com/ > -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Monetary Authority for Bitcoin
Bitcoin is made of many parts, yes, but not all parts were developed simultaneously. On Mon, Dec 9, 2013 at 2:06 PM, Gavin Andresen wrote: > On Tue, Dec 10, 2013 at 8:01 AM, Ryan Carboni wrote: > >> The exchanges that are kept track of could be hard coded into Bitcoin or >> the miner could choose, how this works is not something I'm personally >> focused on. >> >> > That is like saying "We need a way to travel around the world quickly. > There will be an anti-gravity technology; how this works is not something > I'm personally focused on." > > Or, in other words, you are ignoring exactly the sticky, difficult problem > that would have to be solved for your proposal to have any chance of > working. > > -- > -- > Gavin Andresen > -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Monetary Authority for Bitcoin
It is not a violation of the trust of those holding the currency. Many people bought Bitcoin in the hopes that it's value in the relation of other currencies will increase, not because there's a fixed money supply. The majority of people using Bitcoin as a currency in exchange for real goods are using the exchanges. My proposal will still allow for 4.9% semi-weekly variations in the price of Bitcoin, allowing for it to appreciate 11,800% per year. On Mon, Dec 9, 2013 at 2:11 PM, Andrew Poelstra wrote: > On Mon, Dec 09, 2013 at 02:01:07PM -0800, Ryan Carboni wrote: > > This is no doubt probably a very controversial Bitcoin Improvement > Proposal > > and is also a very rough draft of one. > > > > Ryan, you can stop there already because any change to the inflation > formula (supposing such a thing is even possible, which it's not) > would be a violation of the trust of those holding the currency, who > obtained it while believing that its inflation algorithm would not > change. > > -- > Andrew Poelstra > Email: apoelstra at wpsoftware.net > Web: http://www.wpsoftware.net/andrew > > "If they had taught a class on how to be the kind of citizen Dick Cheney > worries about, I would have finished high school." --Edward Snowden > > -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Monetary Authority for Bitcoin
This is no doubt probably a very controversial Bitcoin Improvement Proposal and is also a very rough draft of one. Bitcoin lacks a Central Bank. This is good and bad. A central bank benefits those with political connections. But Bitcoin lacks price stability, this generates menu costs, and incentivizes speculation. I propose the creation of a monetary authority for Bitcoin that sets block reward to a new mathematical formula. The velocity of the Bitcoins that are in circulation likely approaches 100,000x per year as compared to 1x - 4x for the USD. This in itself is not bad. But given that only 10% to 20% of Bitcoins are circulating, this means that the price of Bitcoin is decided largely through speculation. In fact the price of a Bitcoin is irrelevant to those who use Bitcoins as a currency because it appears the majority of coins being used are immediately being sold and repurchased in the exchanges for the sole purpose of buying goods. Unless Bitcoins can be used to purchase intermediate goods and have a closed economic ecosystem, Bitcoin will be too vulnerable to speculation and would not be a viable currency. But the development of a closed economic ecosystem is stymied by the uncertainty of Bitcoin prices and speculation. Fortunately the infrastructure for transacting Bitcoin has long been established, with many major exchanges. Nearly all major exchanges announce recent prices. At the point when a block is generated, the miner will also add the exchange price of bitcoin between various other currencies and crypto-currencies to the blockchain. The exchanges that are kept track of could be hard coded into Bitcoin or the miner could choose, how this works is not something I'm personally focused on. With every new block, the miner will compare the cumulative percentage change in the exchange price of Bitcoin over the previous 432 blocks. The standard deviation of the percentage change in exchange rates will be calculated. Outliers will be excluded, this is so that in case x-currency suffers from hyperinflation, the x-currency will be ignored. It is extremely unlikely for all the world’s currencies to be suffering from hyperinflation caused by monetary expansion as opposed to a supply shock. Every 432 blocks the block reward will be reevaluated. For every 5% increase in the geometric mean of Bitcoin exchange rates in relation to the world’s currencies would increase the block reward by 3%. A 5% decrease in the geometric mean of Bitcoin exchange rates will decrease the block reward by 3%. Changes in the exchange rates of less than 5% will not alter the block reward. The minimum block reward will be one Bitcoin. Why is this better then the current system? Very simple, we are still dependent on banks. Currently Bitcoin is poised to replace Visa and Paypal, not the Federal Reserve. Bitcoin will be less efficient then Visa and Paypal because it takes times to transfer money out of exchanges to one's bank account and vice versa. In order for Bitcoin to replace the US dollar, it needs to not be a more complex version of a debit card. It needs to have a closed economic ecosystem, where all transactions are done in Bitcoin (Consumer > Merchant > Wholesaler > Factory), and the only people who use the exchanges are merchants who need to and those who wish to gamble on Bitcoin. In order for Bitcoin to have widespread acceptance, it needs price stability. My proposal won't peg the Bitcoin to any one currency, but it would reduce month to month variability in relation to a basket of currencies and discourage views that it's speculative. Look at the current system, it's not healthy and it's not a currency. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development