Kevin Greene [ARCHIVE]

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

Public Key

npub1l3sj8amnurgf3cu3p2hhcaham90khafc4vgsmymqdnn0k3kanulsghwq5p

Profile Code

nprofile1qqs0ccfr7ae7p5ycuwgs4tmuwm7ajhmt75u2kygdjdsxeehmgmwe70cndel6s

Author Public Key

npub1l3sj8amnurgf3cu3p2hhcaham90khafc4vgsmymqdnn0k3kanulsghwq5p

Show more details

Last Notes

2023-06-09 12:43:30

- reply

📅 Original date posted:2015-07-01
📝 Original message:
Interesting. It sounds like Joseph may have a solution already, but as a
thought experiment I'm curious how directory nodes could work with the
lightening network. I guess you would have a set of such authorities that
open payment channels with all known lightening processors (how would they
be discovered?), and have a protocol for periodically moving money back and
forth to verify connectivity. One difference here between Tor and
Lightening is that "verifying connectivity" on the Lightening network is
not as simple as connecting to a Tor node. For example, in the ABCD
example, what if C decides to attack only payments that come from B? It
could be non-malicious if C just had a datacenter fire or something that
took out the keys and tx data associated with their channel with B.
Anyways, if the directory nodes didn't test every possible route through
the network (which has exponential complexity), then I don't think they
could reliably tell you if C is trustworthy or not.
On Wed, Jul 1, 2015 at 9:55 AM, Nick ODell <nickodell at gmail.com> wrote:
> >There is no such central processor though in this case to enforce the
> reputation of lightening nodes.
>
> There's no reason why there couldn't be.
>
> Tor, for example, has nine "directory authorities." They attempt to reach
> nodes in the Tor network, and record whether they're available. Then, they
> vote among themselves to produce a directory consensus, and they all sign
> it. Lightning could use a similar system. Unlike Tor, we don't need to
> require everyone to use the same directory authorities, either.
>
> On Wed, Jul 1, 2015 at 10:53 AM, Nick ODell <nickodell at gmail.com> wrote:
>
>> >There is no such central processor though in this case to enforce the
>> reputation of lightening nodes.
>>
>> There's no reason why there couldn't be.
>>
>> Tor, for example, has nine "directory authorities." They attempt to reach
>> nodes in the Tor network, and record whether they're available. Then, they
>> vote among themselves to produce a directory consensus, and they all sign
>> it. Lightning could use a similar system. Unlike Tor, we don't need to
>> require everyone to use the same directory authority, either.
>>
>> On Wed, Jul 1, 2015 at 10:31 AM, Kevin Greene <kgreenek at gmail.com> wrote:
>>
>>> Blargh. The dumb solution here is to just shrug and say that you have to
>>> trust these processors to be highly available, and never try to do
>>> re-routing. That's pretty much equivalent to what would happen if one of
>>> the banks in the visa network had networking issues for example.
>>>
>>> The big difference here though is that visa will kick you out of the
>>> network if you're a bank that's consistently not meeting their
>>> strict SLA's, and that keeps the network honest. There is no such central
>>> processor though in this case to enforce the reputation of lightening
>>> nodes.
>>>
>>>
>>>
>>> On Monday, June 29, 2015, Stephen Morse <stephencalebmorse at gmail.com>
>>> wrote:
>>>
>>>> Hi Rusty,
>>>>
>>>> On Sat, Jun 27, 2015 at 2:41 AM, Rusty Russell <rusty at rustcorp.com.au>
>>>> wrote:
>>>>
>>>>>
>>>>> Yes, C can just get the preimage from E and collude to steal the funds,
>>>>> which is a nasty failure mode.
>>>>>
>>>>>
>>>> This scenario may even happen non-maliciously, if C has an honest
>>>> outage and attempts to pick up where it left off on each of its channels.
>>>> To fix the non-malicious case, C could get a refund from E (a new signed
>>>> transaction with a lower lock time), if C knows he has been offline for
>>>> longer than B's willingness to wait before re-routing. But this isn't
>>>> perfect, or even good, because E cannot know that C isn't just trying to
>>>> get a refund even though they have taken the payment from B. In fact, C is
>>>> guaranteed the payment from B, since they have the pre-image.
>>>>
>>>>
>>>>> Delaying the entire payment is a poor option; can anyone see a better
>>>>> one?
>>>>>
>>>>
>>>> Like you say, delaying the payment seems like a bad way to go, as then
>>>> the payments wouldn't be quite "Lightning" fast anymore. 99% of the payment
>>>> could be re-routed though. Perhaps the 99% could be re-routed, while A
>>>> waits for C to rejoin. Or if multiple paths are being used to process the
>>>> payment, just redistribute the remaining payments allotted for the broken
>>>> path among the other functioning paths.
>>>>
>>>> The bigger problem here seems to be that the incentives are slightly
>>>> skewed in favor of dishonestly. One can minimize the impact of that
>>>> dishonesty by breaking the payment into smaller chunks and across diverse
>>>> paths, but this comes at the cost of bandwidth and speed. Some sort of a
>>>> rating system could come into play possibly, if nothing can be
>>>> cryptographically worked out.
>>>>
>>>> Best,
>>>> Stephen
>>>>
>>>
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150701/33ad4caa/attachment-0001.html>

2023-06-09 12:43:30

- reply

📅 Original date posted:2015-07-01
📝 Original message:
On Wed, Jul 1, 2015 at 3:35 PM, Nick ODell <nickodell at gmail.com> wrote:
> >(how would they be discovered?)
> Two major ways I can see:
> * Each Lightning node keeps track of peers it has seen, and provides part
> of this list to anyone who asks. Directory authorities run spiders, like
> the one at getaddr.bitnodes.io. This could be overlaid onto the Bitcoin
> protocol by setting one of the service bits when the node is an active
> lightning processor. (getaddr approach)
> * Your node tells all of the directory authorities it knows about itself.
> (Tor approach)
>
>
> >One difference here between Tor and Lightening is that "verifying
> connectivity" on the Lightening network is not as simple as connecting to a
> Tor node.
> I think the two of those are similar. Tor can detect various sorts of
> accidental connectivity issues. For example, if you tell Tor in its config
> file that it has a gigabit connection, and it doesn't, it will figure that
> out by itself. However, the most important kind of intentional misbehavior,
> logging connections, cannot be detected remotely.
>
> Lightning is similar. We can detect when someone's internet connection
> goes down. We can detect (with some plumbing) when their Bitcoin node is
> not synchronized yet. But we can't detect the most important kind of
> intentional misbehavior, stealing money, without actually sending money
> through the network.
>
> (Or someone else trying to send money, and complaining when it doesn't go
> through. That would work better if the sender of the payment had some kind
> of log of signed statements made by the nodes involved, though.)
>
> From a privacy perspective, active scanning (sending money through the
> network yourself) is much easier to secure than passive scanning (acting on
> an audit log of someone whose payments got stolen.)
>
> >For example, in the ABCD example, what if C decides to attack only
> payments that come from B? It could be non-malicious if C just had a
> datacenter fire or something that took out the keys and tx data associated
> with their channel with B.
> It doesn't seem like you can catch everybody who's selectively scamming
> through active scanning. For example, if someone stole one out of every
> million payments, the directories would never notice. Personally, I'd more
> worried about someone trying to defeat active scanning by fingerprinting
> wallet software. (e.g. this wallet software always puts zero in this field,
> or this directory authority always connects from Tor addresses.)
>
> WRT the non-malicious example: It seems like a non-malicious node would
> ask for the channel to be closed ASAP, if it no longer remembered the data
> that would show who owned what. This would still leave the payments that it
> was processing just before the data loss in limbo, though, so that's not a
> cure-all.
>
> >Anyways, if the directory nodes didn't test every possible route through
> the network (which has exponential complexity), then I don't think they
> could reliably tell you if C is trustworthy or not.
> I don't think they need to test every route. In the ABCD example, the only
> nodes that C should know about are B and D. Therefore, the routes EBCD and
> ABCD are equivalent from C's point of view.
>
> That's still superlinear, though.
>
Yeah. Also, how will A know what nodes B is connected to? B could
advertise its connected peers ala BGP AS-Paths.
Speaking of which, how does routing work in the lightening network? Forgive
me if that's already documented somewhere. Is that designed already?
>
> On Wed, Jul 1, 2015 at 12:19 PM, Kevin Greene <kgreenek at gmail.com> wrote:
>
>> Interesting. It sounds like Joseph may have a solution already, but as a
>> thought experiment I'm curious how directory nodes could work with the
>> lightening network. I guess you would have a set of such authorities that
>> open payment channels with all known lightening processors (how would they
>> be discovered?), and have a protocol for periodically moving money back and
>> forth to verify connectivity. One difference here between Tor and
>> Lightening is that "verifying connectivity" on the Lightening network is
>> not as simple as connecting to a Tor node. For example, in the ABCD
>> example, what if C decides to attack only payments that come from B? It
>> could be non-malicious if C just had a datacenter fire or something that
>> took out the keys and tx data associated with their channel with B.
>> Anyways, if the directory nodes didn't test every possible route through
>> the network (which has exponential complexity), then I don't think they
>> could reliably tell you if C is trustworthy or not.
>>
>> On Wed, Jul 1, 2015 at 9:55 AM, Nick ODell <nickodell at gmail.com> wrote:
>>
>>> >There is no such central processor though in this case to enforce the
>>> reputation of lightening nodes.
>>>
>>> There's no reason why there couldn't be.
>>>
>>> Tor, for example, has nine "directory authorities." They attempt to
>>> reach nodes in the Tor network, and record whether they're available. Then,
>>> they vote among themselves to produce a directory consensus, and they all
>>> sign it. Lightning could use a similar system. Unlike Tor, we don't need to
>>> require everyone to use the same directory authorities, either.
>>>
>>> On Wed, Jul 1, 2015 at 10:53 AM, Nick ODell <nickodell at gmail.com> wrote:
>>>
>>>> >There is no such central processor though in this case to enforce the
>>>> reputation of lightening nodes.
>>>>
>>>> There's no reason why there couldn't be.
>>>>
>>>> Tor, for example, has nine "directory authorities." They attempt to
>>>> reach nodes in the Tor network, and record whether they're available. Then,
>>>> they vote among themselves to produce a directory consensus, and they all
>>>> sign it. Lightning could use a similar system. Unlike Tor, we don't need to
>>>> require everyone to use the same directory authority, either.
>>>>
>>>> On Wed, Jul 1, 2015 at 10:31 AM, Kevin Greene <kgreenek at gmail.com>
>>>> wrote:
>>>>
>>>>> Blargh. The dumb solution here is to just shrug and say that you have
>>>>> to trust these processors to be highly available, and never try to do
>>>>> re-routing. That's pretty much equivalent to what would happen if one of
>>>>> the banks in the visa network had networking issues for example.
>>>>>
>>>>> The big difference here though is that visa will kick you out of the
>>>>> network if you're a bank that's consistently not meeting their
>>>>> strict SLA's, and that keeps the network honest. There is no such central
>>>>> processor though in this case to enforce the reputation of lightening
>>>>> nodes.
>>>>>
>>>>>
>>>>>
>>>>> On Monday, June 29, 2015, Stephen Morse <stephencalebmorse at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Rusty,
>>>>>>
>>>>>> On Sat, Jun 27, 2015 at 2:41 AM, Rusty Russell <rusty at rustcorp.com.au
>>>>>> > wrote:
>>>>>>
>>>>>>>
>>>>>>> Yes, C can just get the preimage from E and collude to steal the
>>>>>>> funds,
>>>>>>> which is a nasty failure mode.
>>>>>>>
>>>>>>>
>>>>>> This scenario may even happen non-maliciously, if C has an honest
>>>>>> outage and attempts to pick up where it left off on each of its channels.
>>>>>> To fix the non-malicious case, C could get a refund from E (a new signed
>>>>>> transaction with a lower lock time), if C knows he has been offline for
>>>>>> longer than B's willingness to wait before re-routing. But this isn't
>>>>>> perfect, or even good, because E cannot know that C isn't just trying to
>>>>>> get a refund even though they have taken the payment from B. In fact, C is
>>>>>> guaranteed the payment from B, since they have the pre-image.
>>>>>>
>>>>>>
>>>>>>> Delaying the entire payment is a poor option; can anyone see a better
>>>>>>> one?
>>>>>>>
>>>>>>
>>>>>> Like you say, delaying the payment seems like a bad way to go, as
>>>>>> then the payments wouldn't be quite "Lightning" fast anymore. 99% of the
>>>>>> payment could be re-routed though. Perhaps the 99% could be re-routed,
>>>>>> while A waits for C to rejoin. Or if multiple paths are being used to
>>>>>> process the payment, just redistribute the remaining payments allotted for
>>>>>> the broken path among the other functioning paths.
>>>>>>
>>>>>> The bigger problem here seems to be that the incentives are slightly
>>>>>> skewed in favor of dishonestly. One can minimize the impact of that
>>>>>> dishonesty by breaking the payment into smaller chunks and across diverse
>>>>>> paths, but this comes at the cost of bandwidth and speed. Some sort of a
>>>>>> rating system could come into play possibly, if nothing can be
>>>>>> cryptographically worked out.
>>>>>>
>>>>>> Best,
>>>>>> Stephen
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Lightning-dev mailing list
>>>>> Lightning-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150701/e7a8f1ab/attachment-0001.html>

2023-06-09 12:43:29

- reply

📅 Original date posted:2015-07-01
📝 Original message:
Blargh. The dumb solution here is to just shrug and say that you have to
trust these processors to be highly available, and never try to do
re-routing. That's pretty much equivalent to what would happen if one of
the banks in the visa network had networking issues for example.
The big difference here though is that visa will kick you out of the
network if you're a bank that's consistently not meeting their
strict SLA's, and that keeps the network honest. There is no such central
processor though in this case to enforce the reputation of lightening nodes.
On Monday, June 29, 2015, Stephen Morse <stephencalebmorse at gmail.com> wrote:
> Hi Rusty,
>
> On Sat, Jun 27, 2015 at 2:41 AM, Rusty Russell <rusty at rustcorp.com.au
> <javascript:_e(%7B%7D,'cvml','rusty at rustcorp.com.au');>> wrote:
>
>>
>> Yes, C can just get the preimage from E and collude to steal the funds,
>> which is a nasty failure mode.
>>
>>
> This scenario may even happen non-maliciously, if C has an honest outage
> and attempts to pick up where it left off on each of its channels. To fix
> the non-malicious case, C could get a refund from E (a new signed
> transaction with a lower lock time), if C knows he has been offline for
> longer than B's willingness to wait before re-routing. But this isn't
> perfect, or even good, because E cannot know that C isn't just trying to
> get a refund even though they have taken the payment from B. In fact, C is
> guaranteed the payment from B, since they have the pre-image.
>
>
>> Delaying the entire payment is a poor option; can anyone see a better
>> one?
>>
>
> Like you say, delaying the payment seems like a bad way to go, as then the
> payments wouldn't be quite "Lightning" fast anymore. 99% of the payment
> could be re-routed though. Perhaps the 99% could be re-routed, while A
> waits for C to rejoin. Or if multiple paths are being used to process the
> payment, just redistribute the remaining payments allotted for the broken
> path among the other functioning paths.
>
> The bigger problem here seems to be that the incentives are slightly
> skewed in favor of dishonestly. One can minimize the impact of that
> dishonesty by breaking the payment into smaller chunks and across diverse
> paths, but this comes at the cost of bandwidth and speed. Some sort of a
> rating system could come into play possibly, if nothing can be
> cryptographically worked out.
>
> Best,
> Stephen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150701/9c344b96/attachment.html>

2023-06-07 15:38:06

- reply

📅 Original date posted:2015-06-16
📝 Original message:Just thinking off the top of my head here:
What if SPV wallets were exempt from the fee? Only full nodes would pay
other full nodes when initially sync'ing the blockchain. Then as long as
you keep your full node running for a long period of time, you'll
eventually make back the cost you paid to sync initially. This at least
incentives full node operators to keep their node running for as long as
possible once started.
This still imposes a worse UX on casual users who want full node security,
but don't want to run a server 24/7 (or perhaps simply aren't aware that
they have to). These users will watch their balance wither away each time
they open their wallet, but it would be very difficult to explain to them
why that is happening. It would just be frustrating and confusing.
Also, what happens when a user runs Bitcoin-QT for the first time after
downloading it to try it out? They wouldn't be able to sync the blockchain.
Even if the wallet has a balance, how would the wallet be able to see that
it has UTXO's without the ability to sync with the network for free?
On Mon, Jun 15, 2015 at 8:49 PM, Kevin Greene <kgreenek at gmail.com> wrote:
>
>
> On Mon, Jun 15, 2015 at 8:41 PM, Luke Dashjr <luke at dashjr.org> wrote:
>
>> On Tuesday, June 16, 2015 3:30:44 AM Kevin Greene wrote:
>> > Would SPV wallets have to pay to connect to the network too? From the
>> > user's perspective, it would be somewhat upsetting (and confusing) to
>> see
>> > your balance slowly draining every time you open your wallet app. It
>> would
>> > also tie up outputs every time you open up your wallet. You may go to
>> pay
>> > for something in a coffee shop, only to find that you can't spend your
>> > bitcoin because the wallet had to create a transaction to pay to sync
>> with
>> > the network.
>> >
>> > Also, users of centralized wallet services like Coinbase would not have
>> to
>> > pay that fee; but users of native wallets like breadwallet would have no
>> > such option. This incentivizes users to use centralized wallets.
>> >
>> > So this is kind of imposing a worse user experience on users who want to
>> > use bitcoin the "right" way. That doesn't seem like a good thing to me
>> :/
>>
>> SPV isn't the "right" way either ;)
>>
>
> Hah, fair enough, there is no such thing as the "right" way to do
> anything. But I still think punishing users who use SPV wallets is a
> less-than-ideal way to incentive people to run full nodes. Right now SPV is
> the best way that exists for mobile phones to participate in the network in
> a decentralized way. This proposal makes the user experience for mobile
> wallets a little more confusing and annoying.
>
>
>>
>> If you're running a full node (the real "right way"), you should be able
>> to
>> earn more bitcoins than you pay out.
>>
>> Luke
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/6dfa5428/attachment.html>

2023-06-07 15:38:05

- reply

📅 Original date posted:2015-06-16
📝 Original message:On Mon, Jun 15, 2015 at 8:41 PM, Luke Dashjr <luke at dashjr.org> wrote:
> On Tuesday, June 16, 2015 3:30:44 AM Kevin Greene wrote:
> > Would SPV wallets have to pay to connect to the network too? From the
> > user's perspective, it would be somewhat upsetting (and confusing) to see
> > your balance slowly draining every time you open your wallet app. It
> would
> > also tie up outputs every time you open up your wallet. You may go to pay
> > for something in a coffee shop, only to find that you can't spend your
> > bitcoin because the wallet had to create a transaction to pay to sync
> with
> > the network.
> >
> > Also, users of centralized wallet services like Coinbase would not have
> to
> > pay that fee; but users of native wallets like breadwallet would have no
> > such option. This incentivizes users to use centralized wallets.
> >
> > So this is kind of imposing a worse user experience on users who want to
> > use bitcoin the "right" way. That doesn't seem like a good thing to me :/
>
> SPV isn't the "right" way either ;)
>
Hah, fair enough, there is no such thing as the "right" way to do
anything. But I still think punishing users who use SPV wallets is a
less-than-ideal way to incentive people to run full nodes. Right now SPV is
the best way that exists for mobile phones to participate in the network in
a decentralized way. This proposal makes the user experience for mobile
wallets a little more confusing and annoying.
>
> If you're running a full node (the real "right way"), you should be able to
> earn more bitcoins than you pay out.
>
> Luke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/08c20ffe/attachment.html>

2023-06-07 15:38:05

- reply

📅 Original date posted:2015-06-16
📝 Original message:Would SPV wallets have to pay to connect to the network too? From the
user's perspective, it would be somewhat upsetting (and confusing) to see
your balance slowly draining every time you open your wallet app. It would
also tie up outputs every time you open up your wallet. You may go to pay
for something in a coffee shop, only to find that you can't spend your
bitcoin because the wallet had to create a transaction to pay to sync with
the network.
Also, users of centralized wallet services like Coinbase would not have to
pay that fee; but users of native wallets like breadwallet would have no
such option. This incentivizes users to use centralized wallets.
So this is kind of imposing a worse user experience on users who want to
use bitcoin the "right" way. That doesn't seem like a good thing to me :/
On Mon, Jun 15, 2015 at 1:12 PM, sickpig at gmail.com <sickpig at gmail.com>
wrote:
> Hi Raystonn
>
> On Mon, Jun 15, 2015 at 9:36 PM, Raystonn . <raystonn at hotmail.com> wrote:
> >
> > I am only partially through the content at the below link, and I am very
> impressed. Has Justus Ranvier began work on implementation of the ideas
> contained therein?
>
> I don't know if he or someone else has begun writing code to implement
> what was described in the liked post, but I'm sure he will reply to
> you since he's subscribed to this mailing list.
>
>
> >
> >
> >
> > From: sickpig at gmail.com
> > Sent: Monday, June 15, 2015 12:18 PM
> > To: Raystonn .
> > Cc: Bitcoin Dev
> > Subject: Re: [Bitcoin-development] The Bitcoin Node Market
> >
> >
> > Sorry for top posting and the brevity but I'm typing from my phone
> >
> > You shoud be interested in this post by Justus Ranvier then:
> >
> >
> https://bitcoinism.liberty.me/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/
> >
> > On Jun 15, 2015 8:57 PM, "Raystonn ." <raystonn at hotmail.com> wrote:
> >>
> >> I have been toying with an idea and figured I'd run it by everyone here
> >> before investing further time in it. The goal here is to make it
> >> sustainable, and perhaps profitable, to run full nodes on the Bitcoin
> >> Network in the long term.
> >>
> >> - Nodes can participate in a market wherein they are paid by nodes,
> wallets,
> >> and other services to supply Bitcoin Network data. Payment should be
> based
> >> on the cost imposed on the Node to do the work and send the data, but
> can be
> >> set in any way the node operator desires. It's a free market.
> >> - Nodes that are mostly leeching data from the Bitcoin Network, such as
> >> those that do not receive inbound connections to port 8333, will send
> >> payments to the nodes they connect to, but will likely receive no
> payments
> >> from other nodes, wallets, and other services.
> >> - Nodes that are providing balanced full service to the Bitcoin Network
> will
> >> tend to have a balance of payments coming in and going out with regards
> to
> >> other balanced full service nodes, leaving them revenue neutral there.
> But
> >> they will receive payments from leech nodes, wallets, and other
> services.
> >>
> >> The net effect here is that the cost to run nodes will be shared by
> those
> >> who are using the Bitcoin network but not contributing by running a full
> >> node. A market will develop for fees to connect to the Bitcoin Network
> >> which should help cover the cost of running the Network. It's still
> >> possible to continue offering access to your node for free as there is
> >> nothing forcing you to charge a fee. But this isn't very sustainable
> >> long-run. Market efficiencies should eventually mean nodes take in only
> >> what is required to keep the Network operational.
> >>
> >> Raystonn
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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/20150615/3915b397/attachment.html>

2023-06-07 15:35:35

- reply

📅 Original date posted:2015-05-26
📝 Original message:This is true, but the device doesn't know if the LAN it's on is a safe
network or a hotel wifi, for example. So there would be a tricky UX there.
You'd have to ask the user during set up if this is a trusted LAN or not;
or something like that. That may not be an issue though depending on the
nature of the product. For example, Chromecast doesn't need any security
protections against trolls on the same LAN. I guess it just depends on what
you're planning to build.
On Mon, May 25, 2015 at 9:56 PM, Matt Whitlock <bip at mattwhitlock.name>
wrote:
> Who would be performing a Sybil attack against themselves? We're talking
> about a LAN here. All the nodes would be under the control of the same
> entity. In that case, you actually want them all connecting solely to a
> central hub node on the LAN, and the hub node should connect to "diverse
> and unpredictable" other nodes on the Bitcoin network.
>
>
> On Monday, 25 May 2015, at 9:46 pm, Kevin Greene wrote:
> > This is something you actually don't want. In order to make it as
> difficult
> > as possible for an attacker to perform a sybil attack, you want to
> choose a
> > set of peers that is as diverse, and unpredictable as possible.
> >
> >
> > On Mon, May 25, 2015 at 9:37 PM, Matt Whitlock <bip at mattwhitlock.name>
> > wrote:
> >
> > > This is very simple to do. Just ping the "all nodes" address (ff02::1)
> and
> > > try connecting to TCP port 8333 of each node that responds. Shouldn't
> take
> > > but more than a few milliseconds on any but the most densely populated
> LANs.
> > >
> > >
> > > On Monday, 25 May 2015, at 11:06 pm, Jim Phillips wrote:
> > > > Is there any work being done on using some kind of zero-conf service
> > > > discovery protocol so that lightweight clients can find a full node
> on
> > > the
> > > > same LAN to peer with rather than having to tie up WAN bandwidth?
> > > >
> > > > I envision a future where lightweight devices within a home use SPV
> over
> > > > WiFi to connect with a home server which in turn relays the
> transactions
> > > > they create out to the larger and faster relays on the Internet.
> > > >
> > > > In a situation where there are hundreds or thousands of small SPV
> devices
> > > > in a single home (if 21, Inc. is successful) monitoring the
> blockchain,
> > > > this could result in lower traffic across the slow WAN connection.
> And
> > > > yes, I realize it could potentially take a LOT of these devices
> before
> > > the
> > > > total bandwidth is greater than downloading a full copy of the
> > > blockchain,
> > > > but there's other reasons to host your own full node -- trust being
> one.
> > > >
> > > > --
> > > > *James G. Phillips IV*
> > > > <https://plus.google.com/u/0/113107039501292625391/posts>
> > > > <http://www.linkedin.com/in/ergophobe>
> > > >
> > > > *"Don't bunt. Aim out of the ball park. Aim for the company of
> > > immortals."
> > > > -- David Ogilvy*
> > > >
> > > > *This message was created with 100% recycled electrons. Please think
> > > twice
> > > > before printing.*
> > >
> > >
> > >
> ------------------------------------------------------------------------------
> > > One dashboard for servers and applications across
> Physical-Virtual-Cloud
> > > Widest out-of-the-box monitoring support with 50+ applications
> > > Performance metrics, stats and reports that give you Actionable
> Insights
> > > Deep dive visibility with transaction tracing using APM Insight.
> > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> > > _______________________________________________
> > > 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/20150525/05bd344b/attachment.html>

2023-06-07 15:35:35

- reply

📅 Original date posted:2015-05-26
📝 Original message:This is something you actually don't want. In order to make it as difficult
as possible for an attacker to perform a sybil attack, you want to choose a
set of peers that is as diverse, and unpredictable as possible.
On Mon, May 25, 2015 at 9:37 PM, Matt Whitlock <bip at mattwhitlock.name>
wrote:
> This is very simple to do. Just ping the "all nodes" address (ff02::1) and
> try connecting to TCP port 8333 of each node that responds. Shouldn't take
> but more than a few milliseconds on any but the most densely populated LANs.
>
>
> On Monday, 25 May 2015, at 11:06 pm, Jim Phillips wrote:
> > Is there any work being done on using some kind of zero-conf service
> > discovery protocol so that lightweight clients can find a full node on
> the
> > same LAN to peer with rather than having to tie up WAN bandwidth?
> >
> > I envision a future where lightweight devices within a home use SPV over
> > WiFi to connect with a home server which in turn relays the transactions
> > they create out to the larger and faster relays on the Internet.
> >
> > In a situation where there are hundreds or thousands of small SPV devices
> > in a single home (if 21, Inc. is successful) monitoring the blockchain,
> > this could result in lower traffic across the slow WAN connection. And
> > yes, I realize it could potentially take a LOT of these devices before
> the
> > total bandwidth is greater than downloading a full copy of the
> blockchain,
> > but there's other reasons to host your own full node -- trust being one.
> >
> > --
> > *James G. Phillips IV*
> > <https://plus.google.com/u/0/113107039501292625391/posts>
> > <http://www.linkedin.com/in/ergophobe>
> >
> > *"Don't bunt. Aim out of the ball park. Aim for the company of
> immortals."
> > -- David Ogilvy*
> >
> > *This message was created with 100% recycled electrons. Please think
> twice
> > before printing.*
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> 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/20150525/1324d033/attachment.html>

2023-06-07 15:32:55

- reply

📅 Original date posted:2015-05-04
📝 Original message:I feel compelled to re-share Mike Hearn's counter-argument *against *
replace-by-fee:
https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d
Please carefully consider the effects of replace-by-fee before applying
Peter's patch.
On Sun, May 3, 2015 at 9:36 PM, Peter Todd <pete at petertodd.org> wrote:
> My replace-by-fee patch is now available for the v0.10.1 release:
>
> https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.1
>
> No new features in this version; this is simply a rebase for the Bitcoin
> Core v0.10.1 release. (there weren't even any merge conflicts) As with
> the Bitcoin Core v0.10.1, it's recommended to upgrade.
>
>
> The following text is the copied verbatim from the previous release:
>
> What's replace-by-fee?
> ----------------------
>
> Currently most Bitcoin nodes accept the first transaction they see
> spending an output to the mempool; all later transactions are rejected.
> Replace-by-fee changes this behavior to accept the transaction paying
> the highest fee, both absolutely, and in terms of fee-per-KB. Replaced
> children are also considered - a chain of transactions is only replaced
> if the replacement has a higher fee than the sum of all replaced
> transactions.
>
> Doing this aligns standard node behavior with miner incentives: earn the
> most amount of money per block. It also makes for a more efficient
> transaction fee marketplace, as transactions that are "stuck" due to bad
> fee estimates can be "unstuck" by double-spending them with higher
> paying versions of themselves. With scorched-earth techniques⁵ it gives
> a path to making zeroconf transactions economically secure by relying on
> economic incentives, rather than "honesty" and alturism, in the same way
> Bitcoin mining itself relies on incentives rather than "honesty" and
> alturism.
>
> Finally for miners adopting replace-by-fee avoids the development of an
> ecosystem that relies heavily on large miners punishing smaller ones for
> misbehavior, as seen in Harding's proposal⁶ that miners collectively 51%
> attack miners who include doublespends in their blocks - an unavoidable
> consequence of imperfect p2p networking in a decentralized system - or
> even Hearn's proposal⁷ that a majority of miners be able to vote to
> confiscate the earnings of the minority and redistribute them at will.
>
>
> Installation
> ------------
>
> Once you've compiled the replace-by-fee-v0.10.1 branch just run your
> node normally. With -debug logging enabled, you'll see messages like the
> following in your ~/.bitcoin/debug.log indicating your node is replacing
> transactions with higher-fee paying double-spends:
>
> 2015-02-12 05:45:20 replacing tx
> ca07cc2a5eaf55ab13be7ed7d7526cb9d303086f116127608e455122263f93ea with
> c23973c08d71cdadf3a47bae45566053d364e77d21747ae7a1b66bf1dffe80ea for
> 0.00798 BTC additional fees, -1033 delta bytes
>
> Additionally you can tell if you are connected to other replace-by-fee
> nodes, or Bitcoin XT nodes, by examining the service bits advertised by
> your peers:
>
> $ bitcoin-cli getpeerinfo | grep services | egrep
> '((0000000000000003)|(0000000004000001))'
> "services" : "0000000000000003",
> "services" : "0000000004000001",
> "services" : "0000000004000001",
> "services" : "0000000000000003",
> "services" : "0000000004000001",
> "services" : "0000000004000001",
> "services" : "0000000000000003",
> "services" : "0000000000000003",
>
> Replace-by-fee nodes advertise service bit 26 from the experimental use
> range; Bitcoin XT nodes advertise service bit 1 for their getutxos
> support. The code sets aside a certain number of outgoing and incoming
> slots just for double-spend relaying nodes, so as long as everything is
> working you're node should be connected to like-minded nodes a within 30
> minutes or so of starting up.
>
> If you *don't* want to advertise the fact that you are running a
> replace-by-fee node, just checkout a slightly earlier commit in git; the
> actual mempool changes are separate from the preferential peering
> commits. You can then connect directly to a replace-by-fee node using
> the -addnode command line flag.
>
> 1) https://github.com/bitcoinxt/bitcoinxt
> 2) https://github.com/bitcoin/bitcoin/pull/3883
> 3) https://github.com/bitcoin/bitcoin/pull/3883#issuecomment-45543370
> 4) https://github.com/luke-jr/bitcoin/tree/0.10.x-ljrP
> 5)
> http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg05211.html
> 6)
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06970.html
> 7)
> http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04972.html
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000059a3dd65f0e5ffb8fdf316d6f31921fefcf0ef726120be9
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> 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/20150504/2d3b72a5/attachment.html>

2023-06-07 15:31:44

- reply

📅 Original date posted:2015-03-05
📝 Original message:Bitcoind protects against this by storing the addresses it has learned
about in buckets. The bucket an address is stored in is chosen based on the
IP of the peer that advertised the addr message, and the address in the
addr message itself. The idea is that the bucketing is done in a randomized
way so that no attacker should be able to fill your database with his or
her own nodes.
>From addrman.h
<https://github.com/bitcoin/bitcoin/blob/master/src/addrman.h>:
/** Stochastic address manager
*
* Design goals:
* * Keep the address tables in-memory, and asynchronously dump the entire
to able in peers.dat.
* * Make sure no (localized) attacker can fill the entire table with his
nodes/addresses.
*
* To that end:
* * Addresses are organized into buckets.
* * Address that have not yet been tried go into 256 "new" buckets.
* * Based on the address range (/16 for IPv4) of source of the
information, 32 buckets are selected at random
* * The actual bucket is chosen from one of these, based on the range
the address itself is located.
* * One single address can occur in up to 4 different buckets, to
increase selection chances for addresses that
* are seen frequently. The chance for increasing this multiplicity
decreases exponentially.
* * When adding a new address to a full bucket, a randomly chosen
entry (with a bias favoring less recently seen
* ones) is removed from it first.
* * Addresses of nodes that are known to be accessible go into 64
"tried" buckets.
* * Each address range selects at random 4 of these buckets.
* * The actual bucket is chosen from one of these, based on the full
address.
* * When adding a new good address to a full bucket, a randomly
chosen entry (with a bias favoring less recently
* tried ones) is evicted from it, back to the "new" buckets.
* * Bucket selection is based on cryptographic hashing, using a
randomly-generated 256-bit key, which should not
* be observable by adversaries.
* * Several indexes are kept for high performance. Defining
DEBUG_ADDRMAN will introduce frequent (and expensive)
* consistency checks for the entire data structure.
*/
On Wed, Mar 4, 2015 at 5:40 PM, Thy Shizzle <thashiznets at yahoo.com.au>
wrote:
> Hi, so just a thought as my node relays addresses etc. If I wanted to
> really slow down communication over the P2P network, what's stopping me
> from popping up a heap of dummy nodes that do nothing more than exchange
> version and relay addresses, except I send addr messages with all 1000
> addresses pointing to my useless nodes that never send invs or respond to
> getdata etc so clients connect to my dumb nodes instead of legit ones. I'm
> thinking that if I fill up their address pool with enough addresses to dumb
> nodes and keep them really fresh time wise, it could have a bit of an
> impact especially if all 8 outbound connections are used up by my dumb
> nodes right?
>
> I don't want to do this obviously, I'm just thinking about it as I'm
> building my node, what is there to stop this happening?
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> 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/20150304/536a50fe/attachment.html>

2023-06-07 15:31:44

- reply

📅 Original date posted:2015-03-05
📝 Original message:Also (I am fuzzy on the details for this), Bitcoind will detect when a node
is misbehaving and (I believe) it will blacklist misbehaving nodes for a
period of time so it doesn't continually keep trying to connect to tarpit
nodes, for example.
On Wed, Mar 4, 2015 at 6:13 PM, Kevin Greene <kgreenek at gmail.com> wrote:
> Bitcoind protects against this by storing the addresses it has learned
> about in buckets. The bucket an address is stored in is chosen based on the
> IP of the peer that advertised the addr message, and the address in the
> addr message itself. The idea is that the bucketing is done in a randomized
> way so that no attacker should be able to fill your database with his or
> her own nodes.
>
> From addrman.h
> <https://github.com/bitcoin/bitcoin/blob/master/src/addrman.h>:
>
> /** Stochastic address manager
> *
> * Design goals:
> * * Keep the address tables in-memory, and asynchronously dump the
> entire to able in peers.dat.
> * * Make sure no (localized) attacker can fill the entire table with his
> nodes/addresses.
> *
> * To that end:
> * * Addresses are organized into buckets.
> * * Address that have not yet been tried go into 256 "new" buckets.
> * * Based on the address range (/16 for IPv4) of source of the
> information, 32 buckets are selected at random
> * * The actual bucket is chosen from one of these, based on the
> range the address itself is located.
> * * One single address can occur in up to 4 different buckets, to
> increase selection chances for addresses that
> * are seen frequently. The chance for increasing this multiplicity
> decreases exponentially.
> * * When adding a new address to a full bucket, a randomly chosen
> entry (with a bias favoring less recently seen
> * ones) is removed from it first.
> * * Addresses of nodes that are known to be accessible go into 64
> "tried" buckets.
> * * Each address range selects at random 4 of these buckets.
> * * The actual bucket is chosen from one of these, based on the full
> address.
> * * When adding a new good address to a full bucket, a randomly
> chosen entry (with a bias favoring less recently
> * tried ones) is evicted from it, back to the "new" buckets.
> * * Bucket selection is based on cryptographic hashing, using a
> randomly-generated 256-bit key, which should not
> * be observable by adversaries.
> * * Several indexes are kept for high performance. Defining
> DEBUG_ADDRMAN will introduce frequent (and expensive)
> * consistency checks for the entire data structure.
> */
>
> On Wed, Mar 4, 2015 at 5:40 PM, Thy Shizzle <thashiznets at yahoo.com.au>
> wrote:
>
>> Hi, so just a thought as my node relays addresses etc. If I wanted to
>> really slow down communication over the P2P network, what's stopping me
>> from popping up a heap of dummy nodes that do nothing more than exchange
>> version and relay addresses, except I send addr messages with all 1000
>> addresses pointing to my useless nodes that never send invs or respond to
>> getdata etc so clients connect to my dumb nodes instead of legit ones. I'm
>> thinking that if I fill up their address pool with enough addresses to dumb
>> nodes and keep them really fresh time wise, it could have a bit of an
>> impact especially if all 8 outbound connections are used up by my dumb
>> nodes right?
>>
>> I don't want to do this obviously, I'm just thinking about it as I'm
>> building my node, what is there to stop this happening?
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> 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/20150304/12fbe50e/attachment.html>

2023-06-07 15:20:16

- reply

📅 Original date posted:2014-04-27
📝 Original message:Keep in mind that links don't always come embedded in html. Think of native
mobile apps.
On Sat, Apr 26, 2014 at 10:43 AM, Ross Nicoll <jrn at jrn.me.uk> wrote:
> I'd be very cautious of security implications of embedding files into
> the payment request. Even file formats one would presume safe, such as
> images, have had security issues (i.e.
> https://technet.microsoft.com/library/security/ms11-006 )
>
> Longer term I was wondering about embedding the PaymentRequest into web
> pages directly via the <object> tag, which could eliminate need for
> BIP0072 and potentially improve user interface integration that way.
> Obviously this would require browser plugins, however.
>
> Ross
>
> On 26/04/14 18:36, Mike Hearn wrote:
> >> PaymentRequests are limited to 50,000 bytes. I can't think of a reason
> why
> >> Payment messages would need to be any bigger than that. Submit a pull
> >> request to the existing BIP.
> >>
> > In future it might be nice to have images and things in the payment
> > requests, to make UIs look prettier. But with the current version 50kb
> > should be plenty indeed.
> >
>
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> 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/20140427/8db5235d/attachment.html>

2023-06-07 15:14:13

- reply

📅 Original date posted:2014-03-01
📝 Original message:Another example use-case to back up devrandom's point is using a twitter
handle as the "merchant name". In that example, a 3rd party service hosts
and signs the PaymentRequest, but when someone opens that PaymentRequest in
their wallet, they should know that they are paying the specified twitter
user.
On Sat, Mar 1, 2014 at 12:07 PM, Dev Random <c1.devrandom at niftybox.net>wrote:
> This looks like a good solution of the delegation use case for
> medium/large businesses.
>
> I'm wondering about the small business case. A small business or an
> individual might not have the technical expertise to perform the
> delegation signature. Normally the X509 keys are squirreled away on the
> merchant's web server and are not accessible through ordinary means.
> And actually, the merchant might not even have a standalone web
> presence.
>
> Do you think it makes sense to have another scheme where a merchant can
> be name spaced under the payment processor? This would require just one
> additional field - the merchant identifier. In effect, the PP would
> certify that "PP / merchant-id" generated this invoice directly on the
> PP system.
>
> On Fri, 2014-02-28 at 12:46 +0100, Mike Hearn wrote:
> > Now we're starting to see the first companies deploy BIP70, we're
> > encountering a need for identity delegation. This need was long
> > foreseen by the way: it's not in BIP70 because, well, we had to draw
> > the line for v1 somewhere, and this is an issue that mostly affects
> > payment processors. But I figured I'd start a thread anyway because
> > people keep asking me about it :)
> >
> >
> > Objective
> >
> >
> > Identity delegation means that a payment request can be signed by
> > someone who is not holding the certified private key. The most obvious
> > use case for this is payment processors like BitPay and Coinbase who
> > currently have to sign payment requests as themselves. Other use cases
> > might involve untrusted sales agents who want to be able to accept
> > payment as their employer, but cannot be trusted with a long-term
> > valuable secret, e.g. because they take their phone into areas with
> > high crime rates.
> >
> >
> > The lack of this is ok for v1 but not great, because:
> >
> >
> > 1) It requires the name of the *actual* recipient to be put in the
> > memo field, otherwise you don't have the nice receipt-like properties.
> > The memo field is just plain text though, it doesn't have any
> > exploitable structure.
> >
> >
> > 2) It gives a confusing UI, the user thinks they're paying e.g.
> > Overstock but their wallet UI tells them they're paying Coinbase
> >
> >
> > 3) Whilst these payment processors currently verify merchants so the
> > security risk is low, in future a lighter-weight model or competing
> > sites that allow open signups would give a weak security situation: a
> > hacker who compromised your computer could sign up for some popular
> > payment processor under a false identity (or no identity), and wait
> > until you use your hacked computer to make a payment to someone else
> > using the same payment processor. They could then do an identity swap
> > of the real payment request for one of their own, and your Trezor
> > would still look the same. Avoiding this is a major motivation for the
> > entire system!
> >
> >
> > Also it just looks more professional if the name you see in the wallet
> > UI is correct.
> >
> >
> > Proposed implementation
> >
> >
> > We can fix this with a simple extension:
> >
> >
> > enum KeyType {
> > SECP256K1 = 1
> > }
> >
> >
> > message ExtensionCert {
> > required bytes signature = 1;
> > required bytes public_key = 2;
> > required KeyType key_type = 3;
> > required uint32 expiry_time = 4;
> > optional string memo = 5;
> > }
> >
> >
> > // modification
> > message X509Certificates {
> > repeated bytes certificate = 1;
> > repeated ExtensionCert extended_certs = 2;
> > }
> >
> >
> > message PaymentRequest {
> > // new field
> > optional bytes extended_signature = 6;
> > }
> >
> >
> > This allow us to define a so-called extended certificate, which is
> > conceptually the same as an X.509 certificate except simpler and
> > Bitcoin specific. To create one, you just format a ExtensionCert
> > message with an ECDSA public key from the payment processor (PP), set
> > signature to an empty array and then sign it using your SSL private
> > key. Obviously the resulting (most likely RSA) signature then goes
> > into the signature field of the ExtensionCert. The memo field could
> > optionally indicate the purpose of this cert, like "Delegation to
> > BitPay" but I don't think it'd ever appear in the UI, rather, it
> > should be there for debugging purposes.
> >
> >
> > The new ExtensionCert can then be provided back to the PP who adds it
> > to the X509Certificates message. In the PaymentRequest, there are now
> > two signature fields (this is for backwards compatibility). Because of
> > how the mechanism is designed they should not interfere with each
> > other - old implementations that don't understand the new
> > extended_signature field will drop it during reserialization to set
> > signature to the empty array, and thus signature should not cover that
> > field. On the other hand, extended_signature would cover signature.
> > Thus, for full backwards compatibility, you would:
> >
> >
> > 1) Sign the payment request using the PP's SSL cert, i.e. sign as
> > coinbase.com
> >
> >
> > 2) Then sign again using the PP's delegated ECDSA key, i.e. sign as
> > the merchant
> >
> >
> > The finished protobuf would show up in old clients as signed by
> > coinbase.com and by new clients as signed by overstock.com even though
> > Overstock did not provide their SSL key to coinbase.
> >
> >
> > If you have only an ExtensionCert and not any X.509 cert of your own,
> > then you cannot of course make backwards compatible signatures in this
> > way, and in that case you would miss out the signature field and set
> > the pki_type to a new value: "x509+sha256+excert". Old wallets would
> > see that they don't understand this pki_type and treat the request as
> > unverified.
> >
> >
> > For maximum security the merchant may choose to set very short expiry
> > times (like, a day) and then have a cron job that uploads a new
> > ExtensionCert at the end of each expiry period. This means in the case
> > of PP compromise, the system reseals very fast.
> >
> >
> > Alternatives considered
> >
> >
> > We could always use a new pki_type and not bother with the two
> > signature fields. However, this means old wallets will show payment
> > requests as untrusted during the transition period. Some signing is
> > still better than none, security-wise.
> >
> >
> > We could attempt to fix the above by introducing a use of User-Agent
> > field to the case where a payment request is fetched via HTTP, so the
> > server can customise the PaymentRequest according to the capabilities
> > of the client. However, sometimes payment requests are not fetched via
> > HTTP, for example, they may be attached to an email, sent via an IM
> > network or sent over a Bluetooth socket. Nonetheless this may be a
> > useful thing to consider for future cases where the protocol may not
> > be extended in a backwards compatible manner.
> >
> >
> > We could create the extension cert as an X.509 cert, rather than a
> > custom type. However most CA's set path length constraints on their
> > intermediate certs that forbid this kind of extension (I forgot why,
> > possibly some kind of anti-DoS mitigation). Also re-using X.509 for
> > the extension cert would open up the risk of it being accepted by a
> > bogus SSL stack that didn't check the key usage constraints extension,
> > and that would allow for SSL delegation as well. It seems safer to
> > just use a different format that definitely won't be accepted.
> >
> >
> >
> >
> >
> >
> > Feedback welcome.
> >
> ------------------------------------------------------------------------------
> > Flow-based real-time traffic analytics software. Cisco certified tool.
> > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> > Customize your own dashboards, set traffic alerts and generate reports.
> > Network behavioral analysis & security monitoring. All-in-one tool.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> --
> Miron
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140301/2dd1527c/attachment.html>

2023-06-07 15:13:08

- reply

📅 Original date posted:2014-02-12
📝 Original message:Sending this again and truncating since apparently the message body was too
long.
Thanks for humoring my questions!
>I think reporting such errors to the wallet would make complete sense.
However i am not clear why we would a separate url for that?
Hmm, thinking about this more, adding a simple status_code in
PaymentRequest would be a much easier way to achieve this. However,
continuing to think about this even more, maybe the simple memo field along
with an empty set of outputs is enough already.
In bitcoinj, right now the code will throw a
PaymentRequestException.InvalidOutputs exception if the set of outputs is
empty with a message of "No Outputs". Because of that, there isn't a good
way to tell the difference between a payment request that had no outputs
and a payment request that had some invalid output(s).
*Question to everyone:*
How does bitcoin-qt handle a PaymentRequest with no outputs?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140211/e0972311/attachment.html>

2023-06-07 15:13:07

- reply

📅 Original date posted:2014-02-12
📝 Original message:Thanks for humoring my questions!
>I think reporting such errors to the wallet would make complete sense.
However i am not clear why we would a separate url for that?
Hmm, thinking about this more, adding a simple status_code in
PaymentRequest would be a much easier way to achieve this. However,
continuing to think about this even more, maybe the simple memo field along
with an empty set of outputs is enough already.
In bitcoinj, right now the code will throw a
PaymentRequestException.InvalidOutputs exception if the set of outputs is
empty with a message of "No Outputs". There isn't a good way to tell the
difference between a payment request that had no outputs and a payment
request that had some invalid output(s).
*Question to everyone:*
How does bitcoin-qt handle a PaymentRequest with no outputs?
On Tue, Feb 11, 2014 at 10:01 AM, Stephane Brossier
<stephane at kill-bill.org>wrote:
> Hi Kevin,
>
> On Feb 11, 2014, at 2:00 AM, Kevin Greene <kgreenek at gmail.com> wrote:
>
> Figured I would have a crack at reviewing this since Mike is out for a
> bit. It was great running into you guys at the bitcoin fair in SF! Small
> world :)
>
>
> Indeed! It was great meeting you! It's always nice to meet people in
> person...
>
> I like how simple this is. You just give it an url to fetch the next
> payment request and a date to fetch it.
>
> What should happen if the client tries to fetch the PaymentRequest early
> or late?
>
>
> If the client tries to fetch too early, then the merchant will return a
> PaymentRequest with no output (there is nothing to pay yet). If it fetches
> too late, this is merchant specific. It could be that the service got
> discontinued -- extreme case -- or that there are now multiple
> PaymentRequest pending or that the merchant decided to aggregate those into
> one. In that scenario, it could lead to a case where the amount to pay goes
> beyond the contract and the wallet would refuse to make the recurring
> payment.
>
> Does it become valid after some date and stay valid for some length of
> time?
>
>
> The protocol we sketched does not include (yet) an expiration date. At
> this point the contract is fairly minimal, and we could envision adding
> more parameters such as expiration date. So at this point the behavior
> would be dictated by the merchant.
>
> Also, what should happen if the client tries to consume the same
> PaymentRequest twice (or multiple times) during the same period?
>
>
> The merchant initiates the PaymentRequest and is in charge to make sure
> they match the invoices that the client should pay. On the client side, the
> wallet is responsible to verify that the contract is respected, so if a
> merchant were to issue multiple times the same PaymentRequest, the wallet
> would detect it goes beyond the bonds defined in the contract and would
> refuse to make the additional Payments.
>
> I do not think daily/weekly/monthly is flexible enough. What do you think
> about having a concrete start time and end time when the next
> PaymentRequest will be valid?
>
>
> I agree that daily/weekly/monthly may not be flexible enough. However
> specifying a fixed date may be very tricky because in some cases a monthly
> subscription may start on a 31st of a month, and depending on the month,
> the due date will vary -- could be 30th, 28th, 29th, ... Also note that the
> frequency (daily/weekly/monthly) is not used as a polling interval, but is
> only used to verify the contract is respected.
>
> There are multiple viable options to specify that contract and ideally we
> could/should support multiple schemes; different merchants could use
> different schemes, and the client would decide wether or not he is ready to
> accept the terms that will later be enforced by the wallet. But of course
> all this flexibility goes against simplicity and so this is tradeoff...
>
>
> This also prevents the wallet from having to remember when it last sent a
> payment and getting skewed over time.
>
>
> Today, our current prototype is polling every day -- which is the lowest
> granularity we introduced -- and so there is no risk of getting skewed.
>
>
> When a wallet hits the polling_url to download the next PaymentRequest, it
> seems we need a way to communicate an error code to the wallet, for example
> if the server canceled the contract without the wallet knowing. Perhaps a
> separate polling_status_url, with a corresponding ACK message to indicate
> if the PaymentRequest is available. What do you think of that idea?
>
>
> I think reporting such errors to the wallet would make complete sense.
> However i am not clear why we would a separate url for that?
>
> One high-level comment -- the wallet in this design doesn't have any way
> of knowing when the payments are supposed to end. I feel this is important
> to show to the user before they start their wallet polling infinitely.
>
>
> Subscriptions are non ending by definition, but at any time the client
> (through the wallet) or the merchant can decide to terminate the
> subscriptions -- we did not yet implement cancellation in that prototype
> but we are planning to add it later this week. Think of your Netflix
> subscriptions, this is never ending (evergreen) until you decide to
> terminate it or Netflix does it (abuse, bills not paid,...)
>
> Thanks for taking a look!
>
>
> On Sat, Feb 8, 2014 at 6:48 PM, Stephane Brossier <stephane at kill-bill.org>wrote:
>
>> Mike, Gavin,
>>
>>
>> We started to work on the merchant side to test the integration of our
>> prototype for the recurring payments. We modified the 'Payment Request
>> Generator' from Gavin to include a new check box 'set recurring'. We forked
>> the code and checked in our modification here:
>> https://github.com/killbill/paymentrequest/commit/e530f6ec528266aacfd076d7c3154ad39267c3f3
>>
>> We also found a few issues with the code diff that we sent yesterday for
>> bitcoinj and checked in the bug fixes in our fork-- so the diff sent
>> yesterday is slightly outdated.
>>
>> So at this point we have a working prototype for bitcoinj and we are
>> waiting for your feedbacks. We also started to look at integrating the
>> protocol in Kill Bill to check that what is proposed supports indeed the
>> business cases of a full recurring billing platform.
>>
>> Hope to hear from you guys soon!
>>
>>
>> On Feb 7, 2014, at 6:57 PM, Stephane Brossier <stephane at kill-bill.org>
>> wrote:
>>
>> Mike and all,
>>
>> Pierre and I just committed a prototype implementation of the recurring
>> payment protocol using bitcoinj. You can find the diff on our fork:
>>
>> https://github.com/killbill/bitcoinj/commit/40c657c4191498f12539c60316116aa68af368a7
>>
>> We did not write the server (merchant side), but wanted to have some
>> feedback before going deeper (merchant implementation and tests). We did
>> our best to build it on top of the existing BIP-0070 protocol-- only a few
>> additions in the messages, but no new calls and no new uri scheme. We
>> created a new package 'recurring' where most of the new code lives.
>>
>> At a high level:
>>
>> 1. Creation of the subscription:
>>
>> The initial handshake for creating the subscription is exactly similar to
>> the one for the payment protocol (PaymentRequest is used to provide the
>> contract)
>>
>> 2. Wallet can decide to poll the merchants for its active subscriptions.
>>
>> Here the flow is exactly similar to the payment protocol but the wallet
>> receives a callback to verify the payment matches the contract and should
>> go through.
>>
>> Please give us some feedback whenever you have the chance. In the
>> meantime we will start implementing the merchant side and test the code.
>>
>> Cheers!
>>
>>
>>
>> On Jan 31, 2014, at 10:13 AM, Mike Hearn <mike at plan99.net> wrote:
>>
>> That looks OK at a very high level. Things you probably want to think
>> about:
>>
>> - How to trigger it off the existing payment protocol (no new top
>> level messages or mime types or uri extensions please)
>> - Data structures to define the payment schedule
>> - Do you allow pre-submission of time locked transactions or not?
>>
>> I think as you prototype these things will become clearer. You could try
>> prototyping either in Bitcoin Core (C++) or bitcoinj (java, look at the
>> PaymentSession class).
>>
>>
>>
>> On Wed, Jan 29, 2014 at 3:47 AM, Stephane Brossier <
>> stephane at kill-bill.org> wrote:
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *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...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140211/2b958bf7/attachment.html>

2023-06-07 15:13:05

- reply

📅 Original date posted:2014-02-11
📝 Original message:Figured I would have a crack at reviewing this since Mike is out for a bit.
It was great running into you guys at the bitcoin fair in SF! Small world :)
I like how simple this is. You just give it an url to fetch the next
payment request and a date to fetch it.
What should happen if the client tries to fetch the PaymentRequest early or
late? Does it become valid after some date and stay valid for some length
of time? Also, what should happen if the client tries to consume the same
PaymentRequest twice (or multiple times) during the same period?
I do not think daily/weekly/monthly is flexible enough. What do you think
about having a concrete start time and end time when the next
PaymentRequest will be valid? This also prevents the wallet from having to
remember when it last sent a payment and getting skewed over time.
When a wallet hits the polling_url to download the next PaymentRequest, it
seems we need a way to communicate an error code to the wallet, for example
if the server canceled the contract without the wallet knowing. Perhaps a
separate polling_status_url, with a corresponding ACK message to indicate
if the PaymentRequest is available. What do you think of that idea?
One high-level comment -- the wallet in this design doesn't have any way of
knowing when the payments are supposed to end. I feel this is important to
show to the user before they start their wallet polling infinitely.
On Sat, Feb 8, 2014 at 6:48 PM, Stephane Brossier <stephane at kill-bill.org>wrote:
> Mike, Gavin,
>
>
> We started to work on the merchant side to test the integration of our
> prototype for the recurring payments. We modified the 'Payment Request
> Generator' from Gavin to include a new check box 'set recurring'. We forked
> the code and checked in our modification here:
> https://github.com/killbill/paymentrequest/commit/e530f6ec528266aacfd076d7c3154ad39267c3f3
>
> We also found a few issues with the code diff that we sent yesterday for
> bitcoinj and checked in the bug fixes in our fork-- so the diff sent
> yesterday is slightly outdated.
>
> So at this point we have a working prototype for bitcoinj and we are
> waiting for your feedbacks. We also started to look at integrating the
> protocol in Kill Bill to check that what is proposed supports indeed the
> business cases of a full recurring billing platform.
>
> Hope to hear from you guys soon!
>
>
> On Feb 7, 2014, at 6:57 PM, Stephane Brossier <stephane at kill-bill.org>
> wrote:
>
> Mike and all,
>
> Pierre and I just committed a prototype implementation of the recurring
> payment protocol using bitcoinj. You can find the diff on our fork:
>
> https://github.com/killbill/bitcoinj/commit/40c657c4191498f12539c60316116aa68af368a7
>
> We did not write the server (merchant side), but wanted to have some
> feedback before going deeper (merchant implementation and tests). We did
> our best to build it on top of the existing BIP-0070 protocol-- only a few
> additions in the messages, but no new calls and no new uri scheme. We
> created a new package 'recurring' where most of the new code lives.
>
> At a high level:
>
> 1. Creation of the subscription:
>
> The initial handshake for creating the subscription is exactly similar to
> the one for the payment protocol (PaymentRequest is used to provide the
> contract)
>
> 2. Wallet can decide to poll the merchants for its active subscriptions.
>
> Here the flow is exactly similar to the payment protocol but the wallet
> receives a callback to verify the payment matches the contract and should
> go through.
>
> Please give us some feedback whenever you have the chance. In the meantime
> we will start implementing the merchant side and test the code.
>
> Cheers!
>
>
>
> On Jan 31, 2014, at 10:13 AM, Mike Hearn <mike at plan99.net> wrote:
>
> That looks OK at a very high level. Things you probably want to think
> about:
>
> - How to trigger it off the existing payment protocol (no new top
> level messages or mime types or uri extensions please)
> - Data structures to define the payment schedule
> - Do you allow pre-submission of time locked transactions or not?
>
> I think as you prototype these things will become clearer. You could try
> prototyping either in Bitcoin Core (C++) or bitcoinj (java, look at the
> PaymentSession class).
>
>
>
> On Wed, Jan 29, 2014 at 3:47 AM, Stephane Brossier <stephane at kill-bill.org
> > wrote:
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *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...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140211/6c0620d6/attachment.html>

2023-06-07 15:12:45

- reply

📅 Original date posted:2014-01-28
📝 Original message:+1 to the idea of recurring payment requests.
Perhaps one way to realize this would be to add an optional URL to the
PaymentRequest object where the next PaymentRequest can be fetched and the
date at which the merchant expects the next payment.
On Mon, Jan 27, 2014 at 6:36 PM, Stephane Brossier
<stephane at kill-bill.org>wrote:
> Hi,
>
> [I sent this email 2 days ago prior my registration to the mailing list;
> please forgive me if this is a duplicate]
>
> I would like to propose an extension to the Payment Protocol (bip-0070) to
> address the case of recurring payments in Bitcoin -- new bip or
> modification of bip-0070.
>
> There has been a lot of growth in the last few years in the 'subscription
> economy' with many new companies embracing that model -- online video,
> gaming, groceries, newspapers,... In parallel, Bitcoin is growing into a
> mainstream currency (hence bip-0070), and so the next logical step would be
> to define a protocol to address that need.
>
> We have been working in the past few years on an open-source billing
> platform (http://kill-bill.org/), and recently came with a prototype to
> do recurring billing in Bitcoin (see
> http://thekillbillstory.wordpress.com/2014/01/20/bitcoin-plugin/ and
> http://thekillbillstory.wordpress.com/2014/01/11/coinbase-integration-experiment/
> ).
>
>
> The work flow would look similar to the one from bip-0070. There would
> need to be some additions; the flow could be summarized as follow:
>
> 0. Click: 'Subscribe Now'
> 1. Wallet would get a RecurringPaymentRequestAuth which describes the
> nature of the future recurring payments
> 2. The Customer would get prompted from the wallet to authorize it.
> 3. The wallet would then poll the Merchant server (startup time, and/or
> well defined frequency) and potentially merchant would start issuing a
> PaymentRequest); the role of the wallet is to ensure that PaymentRequest is
> within the bounds of what was accepted by the customer-- amount,
> frequency,.. If it is, then it would make the Payment the same way it works
> for bip-0070
>
> Is that something that the community would be interested in? We could
> provide more details about the protocol we have in mind (messages and
> flow), and also provide an implementation with bitcoinj as a wallet and
> Kill Bill as a merchant server.
>
> Le me know what you think.
>
> Stéphane
>
>
> ------------------------------------------------------------------------------
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140127/f154809e/attachment.html>

2023-06-07 15:12:36

- reply

📅 Original date posted:2014-01-27
📝 Original message:>> Should the wallet broadcast the transaction to the bitcoin network when
it
>> receives an ACK, or always assume that the merchant server will do that?
>
> In my opinion, that should be the primary meaning of receiving an ACK:
> acknowledgement that the receiver takes responsibility for getting the
> transaction confirmed (to the extent possible, of course).
Ok, so if there is no
payment
_url specified in the PaymentRequest, then the wallet is responsible for
broadcasting
the transaction to the bitcoin network
.
Otherwise, the wallet should
rely on the merchant server to broadcast.
On Mon, Jan 27, 2014 at 2:17 PM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
> On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene <kgreenek at gmail.com> wrote:
> > +1 for an error field.
>
> Agree, I think we need a way for client applications to interpret the
> response.
>
> > Should the wallet broadcast the transaction to the bitcoin network when
> it
> > receives an ACK, or always assume that the merchant server will do that?
>
> In my opinion, that should be the primary meaning of receiving an ACK:
> acknowledgement that the receiver takes responsibility for getting the
> transaction confirmed (to the extent possible, of course).
>
> --
> Pieter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140127/a97c0293/attachment.html>

2023-06-07 15:12:35

- reply

📅 Original date posted:2014-01-27
📝 Original message:+1 for an error field.
Should the wallet broadcast the transaction to the bitcoin network when it
receives an ACK, or always assume that the merchant server will do that?
On Mon, Jan 27, 2014 at 7:52 AM, Mike Hearn <mike at plan99.net> wrote:
> At the moment there's no way to distinguish between a failed / rejected
> submission and a successful one beyond the freeform memo field, right? It'd
> be good if we had an error code field as well, perhaps for a future version.
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&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/20140127/96cae56c/attachment.html>