Ryan Carboni [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-12-09 to 2014-01-29
💬 Posted a total of 11 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:12:48

- reply

📅 Original date posted:2014-01-29
📝 Original message: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-request at lists.sourceforge.net> wrote:
> Send Bitcoin-development mailing list submissions to
> bitcoin-development at 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-request at lists.sourceforge.net
>
> You can reach the person managing the list at
> bitcoin-development-owner at 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 <pete at petertodd.org>
> Subject: Re: [Bitcoin-development] BIP70: PaymentACK semantics
> To: Mike Hearn <mike at plan99.net>
> Cc: Andreas Schildbach <andreas at schildbach.de>, Bitcoin Dev
> <bitcoin-development at lists.sourceforge.net>
> Message-ID: <20140128211218.GE22059 at 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
> 000000000000000085c725a905444d271c56fdee4e4ec7f27bdb2e777c872925
> -------------- 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 <stephane at kill-bill.org>
> Subject: Re: [Bitcoin-development] Extension for BIP-0070 to support
> recurring payments
> To: "bitcoin-development at lists.sourceforge.net"
> <bitcoin-development at lists.sourceforge.net>
> Cc: Pierre-Alexandre Meyer <pierre at kill-bill.org>, PikaPay
> <hello at PikaPay.com>
> Message-ID: <D6BCC0C4-EF22-4DE8-868E-825D19C387E3 at kill-bill.org>
> Content-Type: text/plain; charset="windows-1252"
>
> >From what I have seen so far, there seems to be an agreement that this is
> a nice feature to add. We are pretty new to that community and so we don't
> know exactly what the process is, and in particular how we reach consensus
> via email. I am certainly open to follow 'the way' if there is one, but one
> solution would be to follow Mike's suggestion on providing a (prototype)
> implementation first and then defining/refining the BIP. Odinn also
> suggested a possible retribution for our time through crowd-sourcing which
> I am interested to pursue if that makes sense.
>
>
> We have quite some experience on the subscription side of things and while
> we are growing our knowledge on the Bitcoin technology (and ecosystem at
> large) we would benefit from:
> * some feedbacks on the high level proposal
> * additional requirements we might have missed
>
> So, below is a high level description of what we have in mind. If this
> sounds reasonable, we could start working on an implementation.
>
>
>
> I. Abstract
> ---------------
>
> This describes a protocol to enable recurring payments in bitcoins and can
> be seen as an extension of BIP-0070. The main goal here is to have the
> customer subscribe to a service of some kind (that is, agreeing on the
> terms of that subscription contract), and then have the wallet make
> recurring payments without any intervention from the customer as long as
> the payments match what the customer agreed on paying.
>
> An example of such service would be an online streaming website, to which
> a user pays a fixed recurring monthly fee to access videos (a.k.a.
> resources). Note that there is also usage based billing: for example, the
> user may need to purchase additional access for premium videos (overage
> charges). This type of billing is more complicated and there are many
> variations to it used in the industry (pre-paid, ?). For the sake of
> discussion, we?ll focus on fixed recurring payments only, but we will keep
> usage in mind to make sure the protocol will be able to support it as well.
>
>
> II. Motivation
> ------------------
>
> Subscription based services have been growing in the past few years and so
> the intent it to make it possible for customers to pay in bitcoins.
>
> Bitcoin?s push model presents new advantages for the customer compared to
> traditional payment methods: the user has control over the subscription
> (for example, there is no need to call the merchant to explicitly cancel
> the credit card payments). It also opens the door to subscription
> management tools in wallets (e.g. Hive apps), which would give user an
> overview of what they are paying each month.
>
>
> III. Flow of Operations
> ----------------------------------------
>
>
> Creation of the subscription:
> - - - - - - - - - - - - - - - - - - - - - -
>
> 1. The customer clicks 'subscribe' -> A message is sent to the merchant.
> 2. The merchant sends back a message to the wallet with the details of the
> subscription such as the amount to be paid. In reality, there will be more
> information but for the purpose of the prototype implementation this is
> sufficient.
> 3. The wallet prompts the customer for authorization.
> 4. The customer authorizes (or denies) it.
> 5. The wallet sends the confirmation to the merchant.
> 6. The merchant confirms the subscription was created.
>
> Ongoing payments:
> - - - - - - - - - - - - - - - -
>
> >From that time on and since Bitcoin is a 'push' model, the wallet is
> responsible to poll the merchant for due payments associated with that
> subscription. Note that the merchant could specify hints to the wallet on
> when to poll (specific dates) or not during the registration of the
> subscription.
>
> Note that we can't simply have the wallet push X bitcoins every month: the
> user account on the merchant side may have gotten credits, invoice
> adjustments, etc. since the last invoice, so the amount to pay for a given
> billing period may be lower than the regular amount. It could even be zero
> if the user decides to make a one-time payment to the merchant directly
> using a different wallet. Hence, the wallet needs to get the latest invoice
> balance to make sure how much it should pay. This also opens the door for
> the support of overage charges.
>
>
> Quick note on the implementation on the merchant side: an entitlement
> system is a piece of logic on the merchant side which grants the user
> access to certain resources depending on the account status (unpaid
> invoices, etc.). This goes often hand in hand with a dunning system, which
> progressively restricts access as the user's account is more and more
> overdue. Since wallets can be offline for an extended period of time,
> payments may be missed and lead to an overdue state (e.g. extra fees,
> service degraded). It is the responsibility of the customer to ensure the
> wallet is up often enough for payments to happen.
>
>
> In that recurring phase where the wallet polls the merchant, the wallet is
> responsible to check that payments match the subscription contract; that
> is, the amount, frequency of payments, ? match what the customer agreed on.
> If so, the payment is made without asking for explicit approval from
> customer, and the flow is similar to BIP-0070: The message is sent to the
> merchant, and in parallel, a transaction is sent to the btcnet. The
> merchant sends an ACK to the wallet and of course checks the states of the
> transactions on the btcnet to mark that payment as successful.
>
> Subscription change (optional):
> - - - - - - - - - - - - - - - - - - - - - - - -
>
> Optionally we could implement a change in the ongoing subscription to
> address the upgrade/downgrade scenarios. Of course, we could also simply
> support a cancellation followed by a creation of a new subscription, but
> having that as a one atomic message is probably better. The steps are very
> similar to the initial registration.
>
> 1. The customer clicks 'upgrade', 'downgrade', ? -> A msg is sent to the
> merchant.
> 2. The merchant sends back a msg to the wallet with the detail of the NEW
> subscription.
> 3. The wallet prompts the customer for authorization.
> 4. The customer authorizes (or denies) it.
> 5. The wallet sends the confirmation to the merchant.
> 6. The merchant confirms the change in the subscription.
>
> Cancellation of the subscription:
> - - - - - - - - - - - - - - - - - - - - - - - - -
>
> The cancellation is initiated from the customer:
>
> 1. The customer clicks 'cancel' -> The wallet is informed that it should
> not accept any new payment associated to that subscription.
> 2. The wallet sends a message to the merchant to inform about the
> cancellation.
> 3. The merchant confirms the subscription was cancelled.
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends. Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
>
> ------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> End of Bitcoin-development Digest, Vol 32, Issue 57
> ***************************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140128/44a3671d/attachment.html>

2023-06-07 15:11:06

- reply

📅 Original date posted:2013-12-25
📝 Original message: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-request at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131224/e30ee1d4/attachment.html>

2023-06-07 15:11:05

- reply

📅 Original date posted:2013-12-24
📝 Original message: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 <mark at monetize.io> 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-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131223/19bb077d/attachment.html>

2023-06-07 15:11:03

- reply

📅 Original date posted:2013-12-24
📝 Original message: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.piscitello at 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 <ryan.jc.pc at gmail.com>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 <mark at monetize.io>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 at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131223/6a03de9a/attachment.html>

2023-06-07 15:11:03

- reply

📅 Original date posted:2013-12-23
📝 Original message: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 <mark at monetize.io> 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-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131223/b341eca6/attachment.html>

2023-06-07 15:11:02

- reply

📅 Original date posted:2013-12-23
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131222/bedebd25/attachment.html>

2023-06-07 15:10:41

- reply

📅 Original date posted:2013-12-10
📝 Original message:>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131210/0ed5f68f/attachment.html>

2023-06-07 15:10:41

- reply

2023-06-07 15:10:39

- reply

📅 Original date posted:2013-12-09
📝 Original message:You're just closed minded.
On Mon, Dec 9, 2013 at 3:10 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> On Mon, Dec 9, 2013 at 7:23 PM, Ryan Carboni <ryan.jc.pc at gmail.com> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131209/c3838fb9/attachment.html>

2023-06-07 15:10:38

- reply

📅 Original date posted:2013-12-09
📝 Original message: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 <asp11 at sfu.ca> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131209/21ef75ca/attachment.html>

2023-06-07 15:10:38

- reply

2023-06-07 15:10:37

- reply

📅 Original date posted:2013-12-09
📝 Original message: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 <gavinandresen at gmail.com>wrote:
> On Tue, Dec 10, 2013 at 8:01 AM, Ryan Carboni <ryan.jc.pc at gmail.com>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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131209/cf795cd4/attachment.html>

2023-06-07 15:10:36

- reply

📅 Original date posted:2013-12-09
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131209/07587a31/attachment.html>