[Bitcoin-development] snailmail bitcoin client
Here is a business idea: customers send you a bitcoin transaction printed on paper. You scan the transaction and broadcast it to the network. Your fee could be the greater of some minimum or like 0.01% of the transaction value. The fee could be sent as just another paper transaction, it could even just be cash. You could expand into a snailmail based email or publishing platform. Customers send you a letter. You make the letter available in one or more of the following forms: 1. as a single webpage 2. sent via email to a specified address 3. in a data dump along with all open letters received that day / week / month / year / or decade. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
> > Opinion: if a soft work works, it should be preferred, if for no other > reason than once a hard-fork is planned, the discussion begins about > what else to throw in. To minimize the frequency of hard-forks, the > time for that is when the change being considered actually requires one. I'm not sure why it'd be any different. Soft forks are just as disruptive - everyone who needs a correct node has to upgrade on time. Given that, I guess there will be a desire to roll out several changes at once too, regardless of what happens to older nodes. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)
> > Yes, you're right. I didn't consider that case. But the problem is that > this is not automatic. Currently there is a clear division between > miners how will not take the kickback (irrrational) and miners who will > (rational). This seems to come up a lot. Your definition of rational is a short term rationality only. I can pass up a short term profit in return for more stable longer term profits and be completely rational, by a reasonable definition of the word. I think it's clear by now that if most or even some miners decide to prioritise short term profit over the long term health of the system (i.e. longer term profit), Bitcoin basically doesn't work right. This attack is only one of several such things that can happen. This certainly can be a problem when difficulty is skyrocketing because a mining investment is I guess quite short term anyway, but presumably at some point the mining arms race will end and miners will become more settled in. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
On Tue, Oct 7, 2014 at 6:08 PM, Mike Hearn wrote: >> That is easy to change; I'll submit a pull request. > > > That's certainly a useful improvement. It won't help the existing userbase > though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major release. The next minor release (0.9.4) could have Gavin's change already. I don't think CHECKLOCKTIMEVERIFY will make it into the next major release though. Once headers-first and pruning is merged (which is expected to be a matter of weeks). I'd like to split off the 0.10 branch and give it some time to stabilize with a feature freeze, then do a release before the end of the year. So 0.11, in say 6 months, would be soonest. Wladimir -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
By the way, I really like this proposal. I haven't spent much time thinking about the deeper subtleties and risks associated with it, but I see a lot of opportunities. One just came to mind that I didn't see mentioned in his original proposal: _Non-Interactive Recurring payments__with ID-association_: You want to make N recurring payments of 1 BTC each month to a service. Sign N transactions each of them use a CHECKLOCKTIMEVERIFY block number approximately X months in the future (one for each month). The script allows the customer to move the coins at any time, but after the locktime the merchant/service has signing access. The merchant software will continually watch for and sweep all coins that become available via this mechanism and credit the appropriate customer account. The customer maintains control of the funds until payment time, the merchant can automatically collect it each month without requiring user interaction, and the customer can cancel it just by spending it elsewhere before the locktime. This scheme has an added benefit: both the merchant's address and the user's address is in the script. Given an appropriate scheme for linking addresses to accounts (perhaps sending the service a watch-only BIP32 branch), the service can use the other address in the script to recognize and link that payment to the user's account. This allows you to continue paying and extending your subscription without having to explicitly link each payment to the account. The wallet will simply make sure to use a return address that is in a BIP32 branch that was provided to the service during signup, and the service will automatically extend your subscription every month based on that info when it sweeps payments. Along with everything else that was mentioned by Peter in his original proposal, I see OP_CHECKLOCKTIMEVERIFY as an enabling feature, not just a simple improvement. -Alan On 10/08/2014 06:26 AM, Wladimir wrote: > On Tue, Oct 7, 2014 at 6:08 PM, Mike Hearn wrote: >>> That is easy to change; I'll submit a pull request. >> >> That's certainly a useful improvement. It won't help the existing userbase >> though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major release. > The next minor release (0.9.4) could have Gavin's change already. > > I don't think CHECKLOCKTIMEVERIFY will make it into the next major > release though. Once headers-first and pruning is merged (which is > expected to be a matter of weeks). I'd like to split off the 0.10 > branch and give it some time to stabilize with a feature freeze, then > do a release before the end of the year. > > So 0.11, in say 6 months, would be soonest. > > Wladimir > > -- > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
I think you can do everything with the existing script level nlocktime in some kind of turing completeness sense (maybe); but there is a complexity cost that often you have to resort to extra dependent transaction(s) (and work-around malleability until that is fully fixed) just to get the effect. When I tried building things that need nlocktime I found it quite inconvenient that it was wasnt a function rather than a script property, so I like this proposal. Adam On 9 October 2014 04:13, Alan Reiner wrote: > By the way, I really like this proposal. I haven't spent much time thinking > about the deeper subtleties and risks associated with it, but I see a lot of > opportunities. One just came to mind that I didn't see mentioned in his > original proposal: > > Non-Interactive Recurring payments with ID-association: > You want to make N recurring payments of 1 BTC each month to a service. > Sign N transactions each of them use a CHECKLOCKTIMEVERIFY block number > approximately X months in the future (one for each month). The script > allows the customer to move the coins at any time, but after the locktime > the merchant/service has signing access. The merchant software will > continually watch for and sweep all coins that become available via this > mechanism and credit the appropriate customer account. The customer > maintains control of the funds until payment time, the merchant can > automatically collect it each month without requiring user interaction, and > the customer can cancel it just by spending it elsewhere before the > locktime. > > This scheme has an added benefit: both the merchant's address and the > user's address is in the script. Given an appropriate scheme for linking > addresses to accounts (perhaps sending the service a watch-only BIP32 > branch), the service can use the other address in the script to recognize > and link that payment to the user's account. This allows you to continue > paying and extending your subscription without having to explicitly link > each payment to the account. The wallet will simply make sure to use a > return address that is in a BIP32 branch that was provided to the service > during signup, and the service will automatically extend your subscription > every month based on that info when it sweeps payments. > > Along with everything else that was mentioned by Peter in his original > proposal, I see OP_CHECKLOCKTIMEVERIFY as an enabling feature, not just a > simple improvement. > > -Alan > > > > On 10/08/2014 06:26 AM, Wladimir wrote: > > On Tue, Oct 7, 2014 at 6:08 PM, Mike Hearn wrote: > > That is easy to change; I'll submit a pull request. > > That's certainly a useful improvement. It won't help the existing userbase > though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major release. > > The next minor release (0.9.4) could have Gavin's change already. > > I don't think CHECKLOCKTIMEVERIFY will make it into the next major > release though. Once headers-first and pruning is merged (which is > expected to be a matter of weeks). I'd like to split off the 0.10 > branch and give it some time to stabilize with a feature freeze, then > do a release before the end of the year. > > So 0.11, in say 6 months, would be soonest. > > Wladimir > > -- > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > -- > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
On Thu, Oct 9, 2014 at 6:14 AM, Adam Back wrote: > I think you can do everything with the existing script level nlocktime > in some kind of turing completeness sense (maybe); but there is a > complexity cost that often you have to resort to extra dependent > transaction(s) (and work-around malleability until that is fully > fixed) just to get the effect. Right, ... moreover, even with all the malleability fixes, they only work if you refrain from using certain features (e.g. cannot do an anyone-can-pay) and we cannot be completely sure all accidental vectors for malleability are gone (we've been unable to construct a proof that our strengthening of ECDSA turns it into a strong signature, though it seems likely). Having the locktime control in a scriptPubKey sidesteps all those limitations and simplifies protocols (e.g. not requiring some three step state machine and a bunch of risky validation code to be sure a refund you receive is actually workable). -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
On Thu, Oct 09, 2014 at 06:28:19AM +, Gregory Maxwell wrote: > On Thu, Oct 9, 2014 at 6:14 AM, Adam Back wrote: > > I think you can do everything with the existing script level nlocktime > > in some kind of turing completeness sense (maybe); but there is a > > complexity cost that often you have to resort to extra dependent > > transaction(s) (and work-around malleability until that is fully > > fixed) just to get the effect. > > Right, ... moreover, even with all the malleability fixes, they only > work if you refrain from using certain features (e.g. cannot do an > anyone-can-pay) and we cannot be completely sure all accidental > vectors for malleability are gone (we've been unable to construct a > proof that our strengthening of ECDSA turns it into a strong > signature, though it seems likely). > > Having the locktime control in a scriptPubKey sidesteps all those > limitations and simplifies protocols (e.g. not requiring some three > step state machine and a bunch of risky validation code to be sure a > refund you receive is actually workable). Speaking of, can anyone think of an example of a complex transaction use-case that is affected by malleability which can't be fixed by CHECKLOCKTIMEVERIFY? I'm sure they exist, but I'm scratching my head trying to think of a good example. -- 'peter'[:-1]@petertodd.org 12367d385ad11358a4a1eee86cf8ebe06a76add36dfb4622 signature.asc Description: Digital signature -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
On Thu, Oct 9, 2014 at 6:33 AM, Peter Todd wrote: > Speaking of, can anyone think of an example of a complex transaction > use-case that is affected by malleability which can't be fixed by > CHECKLOCKTIMEVERIFY? I'm sure they exist, but I'm scratching my head > trying to think of a good example. Yea, no problem since we lack covenants. Or a least no problem making an example, maybe you'll find it too contrived since I'm not sure what would motivate it: You and I put 5 btc each into a kickstarter-escrow to pay Alice+some oracle that decides if alice did her job. But if a timeout expires before alice manages to get the sign off the funds must be returned completely to their original payers. Returning them to in two outputs, one to me, one to you is trivial with a pre-signed refund. You could make there be multiple alice outputs or refund, but then you can't guarantee an atomic reversal (e.g. maybe Alice gets half if we race). -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
