Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
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? -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] MtGox blames bitcoin
Gregory Maxwell says : "Try paying a consultant if your ego demands that you have a technical expert to entertain your musing with immediate response." I don't know why your resorting to such an adhominem. But I have already said that you were the only one who responded. Your response was correct as is reflected in the conversation on the forums. No doubting that. But it does not address the full scope of the attack where a small pool would intentionally (or out of whatever reason) make the hash invalid for the txs they recieve. So that leaves a whole lot of businesses in the lurch who have relied on txid (albeit wrongly that) for their tracking purposes. Thats all I'm trying to say, without blaming anyone. Hope it makes sense. On Wed, Feb 12, 2014 at 2:19 AM, Gregory Maxwell wrote: > On Tue, Feb 11, 2014 at 12:42 PM, naman naman wrote: > > I was talking about a DOS attack in > > https://bitcointalk.org/index.php?topic=458608.0 (ofcourse only > applicable > > to entitys doing the tracking with txids). > > > > Amazing how I did not get a response from any of the devs (except Greg's > > response > > https://bitcointalk.org/index.php?topic=458608.msg5063789#msg5063789 but > > that too was short and not concerning the attack scenario plausibiity as > I > > replied to him). > > Try paying a consultant if your ego demands that you have a technical > expert to entertain your musing with immediate response. > > My response was absolutely relevant. > > If you reissue a transaction without respending the prior transactions > coins, you will end up double paying. Only spending the inputs in > question can prevent the prior transaction (itself or in other form) > from going through. > > Once you respend the inputs there is no risk of actually losing funds > due to an issue regardless of how you track coins in your higher level > application. > -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] MtGox blames bitcoin
On Tue, Feb 11, 2014 at 12:42 PM, naman naman wrote: > I was talking about a DOS attack in > https://bitcointalk.org/index.php?topic=458608.0 (ofcourse only applicable > to entitys doing the tracking with txids). > > Amazing how I did not get a response from any of the devs (except Greg's > response > https://bitcointalk.org/index.php?topic=458608.msg5063789#msg5063789 but > that too was short and not concerning the attack scenario plausibiity as I > replied to him). Try paying a consultant if your ego demands that you have a technical expert to entertain your musing with immediate response. My response was absolutely relevant. If you reissue a transaction without respending the prior transactions coins, you will end up double paying. Only spending the inputs in question can prevent the prior transaction (itself or in other form) from going through. Once you respend the inputs there is no risk of actually losing funds due to an issue regardless of how you track coins in your higher level application. -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] MtGox blames bitcoin
I was talking about a DOS attack in https://bitcointalk.org/index.php?topic=458608.0 (ofcourse only applicable to entitys doing the tracking with txids). Amazing how I did not get a response from any of the devs (except Greg's response https://bitcointalk.org/index.php?topic=458608.msg5063789#msg5063789 but that too was short and not concerning the attack scenario plausibiity as I replied to him). Today they are apparently at work here https://github.com/bitcoin/bitcoin/pull/3651 Amazing how nobody acknowledges it until later when the attack already happens. The devs need to show some greater level of responsibility. Don't get me wrong - I am not trying to claim credit for the attack scheme described (though I do not know of any other place where this was mentioned earlier as an attack scheme), but I am trying to make the point that people should just be around and at least make others feel that their concerns are being read. Now putting this on some place like reddit will only give the community a bad name. On a lighter note I messaged some of the devs (as my previous mail says) saying the attack should be called "thenoblebot" attack (after my handle, which would inspire me to pursue crypto studies further). It was meant to be a lame joke. But I had no idea how it would start causing so much disruption in the ecosystem. Regards thenoblebot On Tue, Feb 11, 2014 at 2:03 AM, Vocatus Gate wrote: > It's quite simple, really: > > Unique transaction == (Inputs+Outputs+ReceivingAddress) > > Problem solved. Simply don't rely on TxID for tracking. Can we put this > issue to rest and move on? > > > > > On 2014-02-10 12:40 PM, Peter Todd wrote: > > On Tue, Feb 11, 2014 at 01:00:21AM +0530, naman naman wrote: > > Hi guys, > > Please check this threadhttps://bitcointalk.org/index.php?topic=458608.0for a > possible attack > scenario. > > Already mailed Gavin, Mike Hearn and Adam about this : > > See if it makes sense. > > That's basically what appears to have happened with Mt. Gox. > > Preventing the attack is as simple as training your customer service > people to ask the customer if their wallet software shows a payment to a > specific address of a specific amount at some approximate time. Making > exact payment amounts unique - add a few satoshis - is a trivial if > slightly ugly way of making sure payments can be identified uniquely > over the phone. That the procedure at Mt. Gox let front-line customer > service reps manually send funds to customers without a proper > investigation of why the funds didn't arrive was a serious mistake on > their part. > > Ultimately this is more of a social engineering attack than a technical > one, and a good example of why well-thought-out payment protocols are > helpful. Though the BIP70 payment protocol doesn't yet handle busines to > individual, or individual to indivudal, payments a future iteration can > and this kind of problem will be less of an issue. > > Similarly stealth addresses have an inherent per-tx unique identifier, > the derived pubkey, which a UI might be able to take advantage of. > > > > > -- > Androi apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start > now.http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > > > > ___ > Bitcoin-development mailing > listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
Is there any code that does this? I would like to develop a multicoin-qt wallet that runs on two blockchains from one binary, and allows trading using this mechanism between the two chains. On Mon, Feb 10, 2014 at 02:32:47PM -0500, Peter Todd wrote: > On Sun, Feb 09, 2014 at 03:44:34PM -0500, Peter Todd wrote: > > On Sun, Feb 09, 2014 at 01:04:58PM -0500, Peter Todd wrote: > > > Alex Mizrahi recently outlined a mechanism(1) based on SIGHASH_SINGLE > > > that allows colored coins and similar embedded consensus system assets > > > to be securely transferred to another party in exchange for Bitcoins > > > atomically. In summary his p2p 2-step-trade mechanism operates as > > > follows: > > > > I'm told there's probably at least one if not more earlier > > attributions/reinventions for the 2-step-trade protocol using > > SIGHASH_SINGLE. Please reply with them if you have them so we can give > > credit where credit is due. > > Got this: > > Message-ID: <52418eba.3080...@monetize.io> > Date: Tue, 24 Sep 2013 06:08:10 -0700 > From: Mark Friedenbach > Organization: Monetize.io Inc. > To: Meni Rosenfeld > Subject: Re: Freimarkets and investment > > If assets were tagged you could do a very limited form of pre-signed offers: > > in: 10 btc SINGLE|ANYONECANPAY > out: 1 AAA > > These are composable, in that you can append the inputs and outputs of > multiple offers together and result in a valid transaction. However this > is pretty much the limit of what is possible without adding new SIGHASH > modes, and if you're going to hard-fork to add tagging, then you might > as well go the whole distance with explicit hierarchical > sub-transactions as we did with Freimarkets. > > Cheers, > Mark > > On 9/24/13 5:44 AM, Meni Rosenfeld wrote: > > Hi Jorge, > > > > The video was sent to me by Amos Meiri, I think eToro funded its production. > > > > Maybe I don't understand SIGHASH_ANYONECANPAY very well. In the > > transaction, there will be an output of 1 "my stock" to an initially > > unknown address. Can I provide a signature for my input of 1 "my stock" > > that will be valid even with the output details provided later? > > > > In any case, I think that's out of scope for the presentation. > > > > Meni > > > > On 24/09/2013 13:10, Jorge Timón wrote: > >> Yes, it's a nice presentation. > >> I love the video with the chameleons that you link at the end !! > >> > >> As a little sugestion, I think the biggest advantage of tagging is not > >> inflatable assets, it's open binding orders. Even without granular > >> subtransactions as freimarket has, you could sign your input (say, > >> representing 1 "My stock") and only the output you're interested in > >> (say 100 bitstampUSD to myAddress) with SIGHASH_SINGLE | > >> SIGHASH_ANYONECANPAY. > >> > >> Without tagging, you need to know where the inputs come from to check > >> they're really bitstampUSD, because the network won't enforce the "100 > >> bistampUSD" in your output, any uncolored coins filling the btc > >> quantity you wanted to represent those 100 usd will be ok, for miners. > >> > >> Goog luck with the talk, I'm eager to hear it. > >> > >> By the way, Mark, the explanation of the blockchain image sounds a > >> little bit like hashcasttle, no? well, just merged mining every new > >> asset, sounds like jaromil's freecoin too. > >> > >> > >> On 9/24/13, Meni Rosenfeld wrote: > >>> Hi Mark, > >>> > >>> We currently have a more general mathematical framework for the concept of > >>> colored coins - a color is a combination of initial state and a kernel > >>> function that maps input colors to output colors. Order-based coloring is > >>> one such kernel function, tagging is another. As long as you can point at > >>> an > >>> output and say what its color is, we call it a colored coin system. > >>> > >>> The blockchain image is a stand-in for "using a new block chain for each > >>> asset". > >>> > >>> Meni > >>> > >>> On 24/09/2013 00:42, Mark Friedenbach wrote: > > Hi Meni, > > > > I did call Freimarkets "colored coins" in the early days, but the term > > colored coin itself within the community seems to have become > > identified with the specific proposal of assigning value to specific > > satoshis, and running an order based coloring algorithm to determine > > asset flow, e.g. Bitcoin-X. Freimarkets allows issuance of entirely > > new assets and has explicit tagging of outputs, so we decided to avoid > > the phrase "colored coin" so as to keep from confusing people. But as > > an academic, yes you are correct. > > > > You presentation looks great. BTW, what's the first logo for the > > "Alternative token systems" slide? Or is that just a stand-in for the > > block chain? > > > > Mark > > > > On 9/23/13 12:24 PM, Meni Rosenfeld wrote: > >> Hi, > >> > >> As you might know I'm giving a talk about Colored Coins in > >> Amsterdam. > >> > >> My presentation is available at > >> https://bitcoil.co.il/files/Colored Coins.pptx (I'm no
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
Hey guys, I'm on vacation now so won't be able to take a look until I'm back in a couple of weeks but the approach sounds reasonable based on your description. On 8 Feb 2014 08:28, "Stephane Brossier" 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 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 > 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 'subsc
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
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 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 > 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 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 > 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 o
