Re: [Bitcoin-development] The Bitcoin Node Market
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, sick...@gmail.com sick...@gmail.com wrote: Hi Raystonn On Mon, Jun 15, 2015 at 9:36 PM, Raystonn . rayst...@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: sick...@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 . rayst...@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The Bitcoin Node Market
On Mon, Jun 15, 2015 at 8:41 PM, Luke Dashjr l...@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 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The Bitcoin Node Market
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 kgree...@gmail.com wrote: On Mon, Jun 15, 2015 at 8:41 PM, Luke Dashjr l...@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 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Zero-Conf for Full Node Discovery
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 b...@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Zero-Conf for Full Node Discovery
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 b...@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 b...@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New release of replace-by-fee for Bitcoin Core v0.10.1
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 p...@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 '((0003)|(0401))' services : 0003, services : 0401, services : 0401, services : 0003, services : 0401, services : 0401, services : 0003, services : 0003, 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 059a3dd65f0e5ffb8fdf316d6f31921fefcf0ef726120be9 -- 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
Re: [Bitcoin-development] Useless Address attack?
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 thashizn...@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Useless Address attack?
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 kgree...@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 thashizn...@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BlockPow: A Practical Proposal to prevent mining pools AND reduce payoff variance:
with Bitcoin ASICs as is but it can be made partially compatible with some tweaks: The value b is replaced by a a a subset or an integrity check of the block. Using a subset: First the hashMerkleRoot and hashPrevBlock fields are replaced by the fields: ChildBlock (32 bytes) and ScatteredBlockBytes (32 bytes). ChildBlock is the hash of a message with stores the old hashMerkleRoot and hashPrevBlock. ScatteredBlockBytes is a pseudo-random subset of bytes taken from the block template being mined. The seed for the pseudo-random function that selects the subset is the hashMerkleRoot plus the block time. When a miner scans all the 32bit nonce space, then a new hashMerkleRoot must be created to increase the extra-nonce field or the time must be updated. When this happens, a new subset of pseudo-random 32 block bytes must be collected. If the miner only stores 10% of the block template (e.g. 100 Kbytes instead of 1 Mbyte), then the probability he can build the ScatteredBlockBytes by brute-forcing the seed is 10^-32. If the miner performs 100 GH/sec, then the 32-bit nonce will overflow every 20 msec and the miner could request the ScatteredBlockBytes from the pool admin using a bandwidth of 1 Kbyte/s. A pool hosting 6 PH/sec (such as Eligious, which has 8%) would need to stream more than 60 Mb/s of ScatteredBlockBytes fields. A mining pool having 50% would need to stream 500 Mb/s, which is quite challenging. So miners will download the block normally, and become active part of the network. Using an integrity check: ScatteredBlockBytes is replaced by a field BlockHash defined as H( full-block-with-zero-nonce ). Obviously the header must be at the beginning of the block to force the re-hash. Best regards, Sergio. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development Why do you want to punish pools? -- Kevin -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Lets discuss what to do if SHA256d is actually broken
On 6/3/2014 12:29 AM, xor wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I thought a lot about the worst case scenario of SHA256d being broken in a way which could be abused to A) reduce the work of mining a block by some significant amount B) reduce the work of mining a block to zero, i.e. allow instant mining. Bitcoin needs to be prepared for this as any hash function has a limited lifetime. Usually crypto stuff is not completely broken instantly by new attacks but gradually. For example first the attack difficulty is reduced from 2^128 to 2^100, then 2^64, etc. This would make scenario A more likely. Now while B sounds more dangerous, I think in fact A is: Consider how A would happen in real life: Someone publishes a paper of a theoretical reduction of SHA256d attacks to 2^96 bit. Mathematicians will consider this as a serious attack and create a lot of riot. If no plan is made early enough, as in now, the Bitcoin Core team might then probably want to just do the easiest approach of replacing the hash function after a certain block number, i.e. a hard fork. But what about the Bitcoin miners, those who need to actually accept a change of mining algorithm which renders their hardware which cost MILLIONS completely worthless? Over the years they have gotten used to exponential growth of the Bitcoin networks hashrate, and therefore exponential devaluation of their mining hardware. Even if the attack on SHA256d causes a significant growth of difficulty, the miners will not *believe* that it is an actual attack on SHA256d - - maybe it is just some new large mining operation? They are used to this happening! Why should they believe this and switch to a new hash function which requires completely new hardware and therefore costs them millions? They will just keep mining SHA256d. Thats why this is more dangerous, because changing the hash funciton won't be accepted by the miners even though it is broken. Something smarter needs to be thought of. Now I must admit that I am not good at cryptography at all, but I had the following idea: Use the altcoin concept of having multiple hash functions in a chain. If SHA256d is broken, it is chained with a new hash function. Thereby, people who want to mine the new replacement hash function still will need ASICs which can solve the old SHA proof of work. So existing ASIC owners can amend their code to do SHA256d using the ASIC, and then the second hash function using a general purpose CPU. This would also allow a smooth migration of difficulty - I don't even know how difficulty would react with the naive approach of just replacing SHA with something else: It would probably be an unsolvable problem to define new rules to make it decrease enough so new blocks can actually be mined by the now several orders of magnitude slower CPU-only mining community but still be high enough to be able to deal with the fact that millions of people will try their luck with mining at the release date. While this sounds simple in theory, it might be a lot of work to implement, so you guys might want to take precautions for it soon :) Greetings, xor - A Freenet project developer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBCAAGBQJTjU9DAAoJEMtmZ+8tjWt5pNEP/2460eHu7ujrUSxinJXY7+wF E759/NcpNuakqu4NsS3ndi8lSiVIeixiOWZxPwLYkzC0pgPd5JrK5hdrYewsgreL Ltkh6LKB4YZLYrV3jm62ZPMTzCopYQ1l872xbN3PJQJoXhEp4fKu99++LDzVg9Gk n7rvrk6Iy/nSsZ1IMANpKghbU8/Gtn6ppCJv9rxRE//CZdTso1tTyOXXkEEMTHcV y/iv6CHXtTXPvOgEgciU0oCPq0NOUKdIAOD//ybcKzncOoHSmwr1rZdreCTH6/Ek 9uwq/HaQnseHPrq9qrIkIKrZDlnjKu7Tqw1BlbyBeCrWdJPCeDJg2kyCXgTvIzFD oXwZ6r16tb2QPR4ByyO1lZy9G2Pp26thk12BnadnPYTf1rMvsY15BjfUrCU9ppt/ YpFAZSFlXUGOuOBKUznUeO8U1bXJylcTTnyER/cudOpcKR8Jt9l5tfm5LTHCB6Q2 Tjmvsmd0BzwafLEhHD5FHoTZFNVdXWvEUO/w4I/2UWTS7CacbE1qk0rVpsF/4L1K /oFVnZIUKqsm5mMMb6WTQq+MjP2TF/eAAwm2UtFYmj0FVML9HBNwyiAc5UKwnD4Y Yq3Pl5QfRobwu6pgT3zO7vK+saOl8sePWbU8Skj41OTEDrJM4QIQGAqs1U8xke8+ YnUYiyzreJ8ofHhNBs4/ =dkuk -END PGP SIGNATURE- -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development It is good to start thinking about such things. Let's face it, it could happen. However, short of having bitcoin use another algorithm for encryption, I am not sure much could be done. That's just me. -- Kevin -- Learn Graph Databases - Download FREE O'Reilly Book Graph
Re: [Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072)
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 j...@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On 4/23/2014 12:04 PM, Christophe Biocca wrote: It's not necessary that this coinbase retribution be either profitable or risk-free for this scheme to work. I think we should separate out the different layers of the proposal: 1. Attacking the coinbase instead of orphaning allows for 100 blocks' time for a consensus to be reached, rather than 10 minutes. This allows for human verification/intervention if needed (orphaning decisions would almost always need to be automated, due to the short timeframe). This is a useful insight, and I don't think it's been brought up before. 2. The original specification of how it's done (redistribution, no cost to voting) does seem exploitable. This can be fixed by reducing the incentive (burning instead of redistributing) and/or adding a risk to the orphaning attempts (a vote that fails destroys X bitcoins' worth from each voting block's own coinbase). The incentives can be tailored to mirror those of orphaning a block, to reduce the risk of abuse. Then the only difference from orphaning are 1) More limited rewriting of history (only the coinbase, vs all transactions in the block), and 2) More time to coordinate a response. 3. This proposal may be used for things other than punishing double-spend pools. In fact it might be used to punish miners for doing anything a significant percentage of hashpower dislikes (large OP_RETURNs, large blocks, gambling transactions, transactions banned by a government). But we can make the threshold higher than 51%, so that this doesn't turn into a significant risk (if 75% of hashpower is willing to enforce a rule, we're already likely to see it enforced through orphaning). On Wed, Apr 23, 2014 at 11:38 AM, Alex Mizrahi alex.mizr...@gmail.com wrote: And it still would. Non-collusive miners cast votes based on the outcome of their own attempts to double spend. Individually rational strategy is to vote for coinbase reallocation on every block. Yes, in that case nobody will get reward. It is similar to prisoner's dilemma: equilibrium has worst pay-off. In practice that would mean that simple game-theoretic models are no longer applicable, as they lead to absurd results. I'm using it in the same sense Satoshi used it. Honest miners work to prevent double spends. That's the entire justification for their existence. Miners that are deliberately trying to double spend are worse than useless. Miners work to get rewards. It absolutely doesn't matter whether they are deliberately trying to double-spend or not: they won't be able to double-spend without a collusion. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development This all sounds verry restrictive. Is it possible to do a sweep in order to clean up double spending? Why punish miners for the sake of punishing them? -- Kevin -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Warning message when running wallet in Windows XP (or drop support?)
On 4/16/2014 4:14 AM, Wladimir wrote: Hello, Today I noticed that even my bank is warning people to not do internet banking with Windows XP. If it is no longer secure enough for online banking it's CERTAINLY not secure enough to run a wallet (for a node only it would be ok-ish as they have no keys to protect). Any opinions on what to do here? Just warn and allow the user to continue? Redirect them to a 'Windows XP is dangerous' message on bitcoin.org http://bitcoin.org? (Microsoft uses http://windows.microsoft.com/en-us/windows/end-support-help) The drawback of dropping XP support completely would be that a lot of computers (especially in China and Russia etc) are still running XP, so this could cause the network to lose nodes. If you're maintainer of other wallet software: how are you handling this? Are you going to drop XP support completely? If so, starting from when? Regards, Wladimir -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development I think we should get to the bottom of this. Should we assume that xp is not secure enough? What is this warning? Who is issuing this warning? -- Kevin -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Warning message when running wallet in Windows XP (or drop support?)
On 4/16/2014 11:28 AM, Wladimir wrote: On Wed, Apr 16, 2014 at 5:20 PM, Pieter Wuille pieter.wui...@gmail.com mailto:pieter.wui...@gmail.com wrote: On Wed, Apr 16, 2014 at 5:12 PM, Kevin kevinsisco61...@gmail.com mailto:kevinsisco61...@gmail.com wrote: I think we should get to the bottom of this. Should we assume that xp is not secure enough? Yes. It will quickly grow extremely insecure. People will be actively analyzing patches to post-XP versions to find security problems that are patched there, to see if they can be exploited on XP. Wladimir Should we then add an alert message to wallet installers such as, Such and such will not run on windows xp? -- Kevin -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Warning message when running wallet in Windows XP (or drop support?)
On 4/16/2014 5:10 PM, Laszlo Hanyecz wrote: I think a warning like this is inappropriate. There are many reasons to use an out of date operating system and high level applications like wallets need not concern themselves with the rest of the system. Maybe the wallet can scan your browser cache and tell you to stop visiting somesite.com too? It just sounds like some kind of behavior modification that's being discussed here.. not-so-subtly suggesting that users shell out money for a newer version of the operating system, just to use their bitcoin wallets in a 'blessed' configuration. This actually sounds very similar to what happens with Apple iPhones.. they somehow manage to 'invalidate' the charging cables and accessories with every major software version. One day an accessory is working fine, then after the update users get a behavior modification nag every time they use it, urging them to buy a new one. Along these same lines, might as well put a warning about the registry keys needing to be cleaned, and maybe a 'shock the money' banner[1]. You guys all know how it works with financial software - there are many organizations using decades old software (and hardware) because they know its shortcomings, they've taken care of them in a way that works them, and they don't want to start all over just for the sake of having the newest version. -Laszlo [1] http://www.buzzfeed.com/adobe/obnoxious-banner-ads-that-everyone-remembers On Apr 16, 2014, at 8:42 PM, Roy Badami r...@gnomon.org.uk wrote: On Wed, Apr 16, 2014 at 05:20:41PM +0200, Pieter Wuille wrote: On Wed, Apr 16, 2014 at 5:12 PM, Kevin kevinsisco61...@gmail.com wrote: I think we should get to the bottom of this. Should we assume that xp is not secure enough? Yes. Do we need a similar warning for OS X 10.6? The EOL of that one is *far* less well known than XP (because of Apple's failure to communicate product lifecycles). roy What is this warning? Windows XP is no longer maintained. Don't use such a system for protecting your money. Who is issuing this warning? Microsoft: http://windows.microsoft.com/en-us/windows/end-support-help The suggestion here is to make Bitcoin Core detect when it's running on Windows XP, and warn the user (they are likely unaware of the risks). -- Pieter -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development Okay, so how about an autoupdate function which pulls a work around off the server? Sooner or later, the vulnerabilities must be faced. -- Kevin -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets
On 4/9/2014 11:29 AM, Wladimir wrote: Hello, This is primarily aimed at developers of SPV wallets. The recently reported decrease in number of full nodes could have several reasons, one of them that less people are running Bitcoin Core for the wallet because the other wallets are getting ahead in both features and useability. It's great to see innovation in wallets, but it's worrying that the number of full nodes decreases. It may be that lots of people would support the network by running a full node, but don't want to go through the trouble of installing bitcoin core separately (and get confused because it's a wallet, too). Hence I'd like to explore the idea of adding an option to popular SPV wallets, to spin a bitcoind process in the background. This could be pretty much transparent to the user - it would sync in the background, the wallet could show statistics about the node, but is not dependent on it. In exchange the user would get increased (full node level) security, as the SPV wallet would have a local trusted node. Does this sound like a good idea? Is there any way that Bitcoin Core can help to accomedate this 'embedded' usage? Specific Interfaces, special builds - maybe add a walletless bitcoind build to gitian - bindings, dlls, etc? Wladimir -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development I personally like the ida. Are you talking about a flag that could toggle this in the background mode or recoding for in the background use? -- Kevin -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Okay, time to bring up bitcoin/bitcoin
On 4/2/2014 9:08 AM, Jeff Garzik wrote: At first, this is a poor choice of URL. But it really looks like a phishing attempt that no one should visit. On Tue, Apr 1, 2014 at 4:00 PM, Kevin kevinsisco61...@gmail.com wrote: I've sat on this for some time after starting this. I have forked this from bitcoin core and am working on a secure tax mode for bitcoin. It is written in Autoit. I know I know, scripting language alert! I would like people to look at: http://www.githubb.com/bitcoin/bitcoin Look at it, and let's have an open dialog about it. I want to know the good, the bad, and the ugly! -- Kevin -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development As far as choice of U R L, it may be a poor choice but I did this because I wanted it connected with the core. As far as fishing it certainly is not that! This is a serious project. -- Kevin -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Okay, time to bring up bitcoin/bitcoin
On 4/2/2014 11:13 AM, Laszlo Hanyecz wrote: Maybe this site serves up exploits selectively? I'm guessing most people are getting the 'domain for sale' but whoever is the target probably gets something special? On Apr 2, 2014, at 2:53 PM, Kevin kevinsisco61...@gmail.com wrote: On 4/2/2014 9:08 AM, Jeff Garzik wrote: At first, this is a poor choice of URL. But it really looks like a phishing attempt that no one should visit. On Tue, Apr 1, 2014 at 4:00 PM, Kevin kevinsisco61...@gmail.com wrote: I've sat on this for some time after starting this. I have forked this from bitcoin core and am working on a secure tax mode for bitcoin. It is written in Autoit. I know I know, scripting language alert! I would like people to look at: http://www.githubb.com/bitcoin/bitcoin Look at it, and let's have an open dialog about it. I want to know the good, the bad, and the ugly! -- Kevin -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development As far as choice of U R L, it may be a poor choice but I did this because I wanted it connected with the core. As far as fishing it certainly is not that! This is a serious project. -- Kevin -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development I tell you that this is a serious project for bitcoin. You are free to assume the worst. After all, I did say the good the bad and the ugly would come out of this. I happen to be a big believer in bitcoin and I feel this project holds water. If you disagree, that's fine. -- Kevin -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Okay, time to bring up bitcoin/bitcoin
On 4/2/2014 11:45 AM, Ricardo Filipe wrote: Kevin, the thing is you gave us a bad link... what is the correct URL of your project? 2014-04-02 16:30 GMT+01:00 Kevin kevinsisco61...@gmail.com: On 4/2/2014 11:13 AM, Laszlo Hanyecz wrote: Maybe this site serves up exploits selectively? I'm guessing most people are getting the 'domain for sale' but whoever is the target probably gets something special? On Apr 2, 2014, at 2:53 PM, Kevin kevinsisco61...@gmail.com wrote: On 4/2/2014 9:08 AM, Jeff Garzik wrote: At first, this is a poor choice of URL. But it really looks like a phishing attempt that no one should visit. On Tue, Apr 1, 2014 at 4:00 PM, Kevin kevinsisco61...@gmail.com wrote: I've sat on this for some time after starting this. I have forked this from bitcoin core and am working on a secure tax mode for bitcoin. It is written in Autoit. I know I know, scripting language alert! I would like people to look at: http://www.githubb.com/bitcoin/bitcoin Look at it, and let's have an open dialog about it. I want to know the good, the bad, and the ugly! -- Kevin -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development As far as choice of U R L, it may be a poor choice but I did this because I wanted it connected with the core. As far as fishing it certainly is not that! This is a serious project. -- Kevin -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development I tell you that this is a serious project for bitcoin. You are free to assume the worst. After all, I did say the good the bad and the ugly would come out of this. I happen to be a big believer in bitcoin and I feel this project holds water. If you disagree, that's fine. -- Kevin -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development I understand now why someone thought I was fishing. That link should work just fine...I'm not sure what the problem is as I know I forked correctly. I guess I'll need to register a domain for it an get a page going and link from there. I just haven't gotten around to it but will do that. I'll get going! Just know that I would never set up fishing; that's not my style. -- Kevin -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Okay, time to bring up bitcoin/bitcoin
On 4/2/2014 12:55 PM, Jud wrote: Looks like Kevin was probably trying to point us to his fork for comments: https://github.com/kjsisco/bitcoin/tree/patch-1 -- Jud On Wednesday, April 2, 2014 at 12:45 PM, Laszlo Hanyecz wrote: Maybe he has a fork on the real github.com http://github.com and the link was a mistake. http://news.nurse.com/article/20121203/NY02/112030026#.Uzw5UVy2uw8 I think it's possible that 'Kevin' is for real and maybe he doesn't realize he linked to a phishing site, if it was an accident. If this is the same person, then he's blind, and maybe that's why he wrote 'U R L' instead of the usual 'URL', by using speech to text or some other assistive tech. It might be that he tried to fork github.com/bitcoin/bitcoin http://github.com/bitcoin/bitcoin and just provided the wrong link. But regardless, stay away from the one with two Bs in it. Thanks, Laszlo On Apr 2, 2014, at 3:59 PM, Kevin kevinsisco61...@gmail.com mailto:kevinsisco61...@gmail.com wrote: On 4/2/2014 11:45 AM, Ricardo Filipe wrote: Kevin, the thing is you gave us a bad link... what is the correct URL of your project? 2014-04-02 16:30 GMT+01:00 Kevin kevinsisco61...@gmail.com mailto:kevinsisco61...@gmail.com: On 4/2/2014 11:13 AM, Laszlo Hanyecz wrote: Maybe this site serves up exploits selectively? I'm guessing most people are getting the 'domain for sale' but whoever is the target probably gets something special? On Apr 2, 2014, at 2:53 PM, Kevin kevinsisco61...@gmail.com mailto:kevinsisco61...@gmail.com wrote: On 4/2/2014 9:08 AM, Jeff Garzik wrote: At first, this is a poor choice of URL. But it really looks like a phishing attempt that no one should visit. On Tue, Apr 1, 2014 at 4:00 PM, Kevin kevinsisco61...@gmail.com mailto:kevinsisco61...@gmail.com wrote: I've sat on this for some time after starting this. I have forked this from bitcoin core and am working on a secure tax mode for bitcoin. It is written in Autoit. I know I know, scripting language alert! I would like people to look at: http://www.githubb.com/bitcoin/bitcoin Look at it, and let's have an open dialog about it. I want to know the good, the bad, and the ugly! -- Kevin -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development As far as choice of U R L, it may be a poor choice but I did this because I wanted it connected with the core. As far as fishing it certainly is not that! This is a serious project. -- Kevin -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development I tell you that this is a serious project for bitcoin. You are free to assume the worst. After all, I did say the good the bad and the ugly would come out of this. I happen to be a big believer in bitcoin and I feel this project holds water. If you disagree, that's fine. -- Kevin -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development I understand now why someone thought I was fishing. That link should work just fine...I'm not sure what the problem is as I know I forked correctly. I guess I'll need to register a domain for it an get a page going and link from there. I just haven't gotten around to it but will do that. I'll get going! Just know that I would never set up fishing; that's not my style. -- Kevin -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development I was trying to point you to that. I am embarrassed. -- Kevin -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Okay, time to bring up bitcoin/bitcoin
I've sat on this for some time after starting this. I have forked this from bitcoin core and am working on a secure tax mode for bitcoin. It is written in Autoit. I know I know, scripting language alert! I would like people to look at: http://www.githubb.com/bitcoin/bitcoin Look at it, and let's have an open dialog about it. I want to know the good, the bad, and the ugly! -- Kevin -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys
On 3/5/2014 7:49 AM, Mike Hearn wrote: A new practical technique has been published that can recover secp256k1 private keys after observing OpenSSL calculate as little as 200 signatures: http://eprint.iacr.org/2014/161.pdf This attack is based on the FLUSH+RELOAD technique published last year. It works by observing L3 CPU cache timings and forcing cache line flushes using the clflush opcode. As a result, it is applicable to any x86 environment where an attacker may be able to run on the same hardware i.e. virtualised hosting environments where keys are being reused. I am not currently aware of any efforts to make OpenSSL's secp256k1 implementation completely side channel free in all aspects. Also, unfortunately many people have reimplemented ECDSA themselves and even if OpenSSL gets fixed, the custom implementations probably won't. So, IMHO this is a sign for hot wallet users to start walking (but not running) towards the exits of these shared cloud services: it doesn't feel safe to sign transactions on these platforms, so hot wallets should be managed by dedicated hardware. Of course other parts of the service, like the website, are less sensitive and can still run in the cloud. I doubt the researchers will release their code to do the side channel attack and it's rather complex to reimplement, so this gives some time for mitigation. Unfortunately the huge sums being held in some bitbank style hot wallets mean that attackers are well motivated to pull off even quite complex attacks. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development How can we patch this issue? -- Kevin -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Process for getting a patch aproved?
Hello. How would I submit a patch? Could it be sent through the list as an attachment? -- Kevin -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] New to this list
Hello. I am a developer and I wish to contribute to bitcoin. Where is the best place to start? -- Kevin -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70 extension to allow for identity delegation
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.devran...@niftybox.netwrote:
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
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
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 steph...@kill-bill.orgwrote: Hi Kevin, On Feb 11, 2014, at 2:00 AM, Kevin Greene kgree...@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
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 steph...@kill-bill.orgwrote: 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 steph...@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 m...@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 steph...@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
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=124407151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: PaymentACK semantics
+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 m...@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=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: PaymentACK semantics
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.wui...@gmail.comwrote: On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene kgree...@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 -- 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=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
+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 steph...@kill-bill.orgwrote: 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=123612991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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=123612991iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
