Re: [Bitcoin-development] comments on BIP 100
OK. O() notation normally refers to computational complexity, but ... I still don't get it - the vast majority of users don't run relaying nodes that take part in gossiping. They run web or SPV wallets. And the nodes that do take part don't connect to every other node. It's a little scary, IMO, that the fact that the majority of nodes don't relay and only perform the most rudimtentary level of validation if any is considered an acceptable feature of the protocol. - Eric Lombrozo -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP for Proof of Payment
I did misunderstand that. That changes things significantly. However, having paid is not the same as having had access to the input coins. What about shared wallets or coinjoin? Also, if I understand correctly, there is no commitment to anything you're trying to say about the sender? So once I obtain a proof-of-payment from you about something you paid, I can go claim that it's mine? Why does anyone care who paid? This is like walking into a coffeshop, noticing I don't have money with me, let me friend pay for me, and then have the shop insist that I can't drink it because I'm not the buyer. Track payments, don't try to assign identities to payers. On Jun 15, 2015 11:35 AM, Kalle Rosenbaum ka...@rosenbaum.se wrote: Hi Pieter! It is intended to be a proof that you *have paid* for something. Not that you have the intent to pay for something. You cannot use PoP without a transaction to prove. So, yes, it's just a proof of access to certain coins that you no longer have. Maybe I don't understand you correctly? /Kalle 2015-06-15 11:27 GMT+02:00 Pieter Wuille pieter.wui...@gmail.com: Now that you have removed the outputs, I don't think it's even a intent of payment, but just a proof of access to certain coins. On Jun 15, 2015 11:24 AM, Kalle Rosenbaum ka...@rosenbaum.se wrote: Hi all! I have made the discussed changes and updated my implementation (https://github.com/kallerosenbaum/poppoc) accordingly. These are the changes: * There is now only one output, the pop output, of value 0. * The sequence number of all inputs of the PoP must be set to 0. I chose to set it to 0 for all inputs for simplicity. * The lock_time of the PoP must be set to 4 (max block height lock time). The comments so far has been mainly positive or neutral. Are there any major objections against any of the two proposals? If not, I will ask Gregory Maxwell to assign them BIP numbers. The two BIP proposals can be found at https://github.com/kallerosenbaum/poppoc/wiki/Proof-of-Payment-BIP and https://github.com/kallerosenbaum/poppoc/wiki/btcpop-scheme-BIP. The source for the Proof of Payment BIP proposal is also in-lined below. A number of alternative names have been proposed: * Proof of Potential * Proof of Control * Proof of Signature * Signatory Proof * Popo: Proof of payment origin * Pots: Proof of transaction signer * proof of transaction intent * Declaration of intent * Asset-access-and-action-affirmation, AAaAA, or A5 * VeriBit * CertiBTC * VBit * PayID Given this list, I still think Proof of Payment is the most descriptive to non-technical people. Regards, Kalle # pre BIP: BIP number Title: Proof of Payment Author: Kalle Rosenbaum ka...@rosenbaum.se Status: Draft Type: Standards Track Created: date created on, in ISO 8601 (-mm-dd) format /pre == Abstract == This BIP describes how a wallet can prove to a server that it has the ability to sign a certain transaction. == Motivation == There are several scenarios in which it would be useful to prove that you have paid for something. For example: * A pre-paid hotel room where your PoP functions as a key to the door. * An online video rental service where you pay for a video and watch it on any device. * An ad-sign where you pay in advance for e.g. 2 weeks exclusivity. During this period you can upload new content to the sign whenever you like using PoP. * Log in to a pay site using a PoP. * A parking lot you pay for monthly and the car authenticates itself using PoP. * A lottery where all participants pay to the same address, and the winner is selected among the transactions to that address. You exchange the prize for a PoP for the winning transaction. With Proof of Payment, these use cases can be achieved without any personal information (user name, password, e-mail address, etc) being involved. == Rationale == Desirable properties: # A PoP should be generated on demand. # It should only be usable once to avoid issues due to theft. # It should be able to create a PoP for any payment, regardless of script type (P2SH, P2PKH, etc.). # It should prove that you have enough credentials to unlock all the inputs of the proven transaction. # It should be easy to implement by wallets and servers to ease adoption. Current methods of proving a payment: * In BIP0070, the PaymentRequest together with the transactions fulfilling the request makes some sort of proof. However, it does not meet 1, 2 or 4 and it obviously only meets 3 if the payment is made through BIP0070. Also, there's no standard way to request/provide the proof. If standardized it would probably meet 5. * Signing messages, chosen by the server, with the private keys used to sign the transaction. This could meet 1 and 2 but
Re: [Bitcoin-development] The Bitcoin Node Market
Would SPV wallets have to pay to connect to the network too? The cost to compute and deliver the requested data will be pushed to the users of that node. This is the same way all costs, fees, and taxes of any business are always paid by its customers. The Bitcoin Network will not thrive in a decentralised manner if nodes can only be run on the charity of the wealthy. That said, node operators can set fees to lower impact on SPV wallets if they so desire. Market efficiency will ensure everyone pays only what they cost the Network in the long run. Also, users of centralized wallet services like Coinbase would not have to pay that fee Coinbase would pay to access nodes just like everyone else, to cover the costs they impose on the Network. Those costs would be covered by their customers, as are all costs incurred by any business. On 15 Jun 2015 8:50 pm, Kevin Greene kgree...@gmail.com wrote:On Mon, Jun 15, 2015 at 8:41 PM, Luke Dashjr luke@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 users 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 cant 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 doesnt seem like a good thing to me :/ SPV isnt 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 youre 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
On 2015-06-16 03:49, Kevin Greene wrote: 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. Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who would provide the nodes they would need connect to? The decentralization fairy? There's absolutely no reason that paying for connectivity would be any more confusing or annoying than transaction fees are. If some full nodes in the network started offering paid connection slots, that would just mean that users who checked the pay subscription fee box in their wallet configuration would have an easier time connecting than the users who did't, just like how your transaction might eventually get mined without a fee but paying one makes it faster and more probable. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork
Aaron, My understanding is that Gavin and Mike are proceeding with the XT fork, I hope that understanding is wrong. As for improving the non-consensus code to handle full blocks more gracefully. This is something I'm very interested in, block size increase or not. Perhaps I shouldn't hijack this thread, but maybe there are others who also believe this would ameliorate some of the time pressure for deciding on a block size increase. What is it that you would like to see improved? The fee estimation code that is included for 0.11 will give much more accurate fee estimates, which should allow adding the correct fee to a transaction to see it likely to be confirmed in a reasonable time. For further improvements: - There has recently been attention to overhauling the block creation and mempool limiting code in such a way that actual outstanding queues to be included in a block could also be incorporated in fee estimation. See https://github.com/bitcoin/bitcoin/pull/6281. - CPFP and RBF are candidates for inclusion in core soon, both of which could be integrated into transaction processing to handle the edge cases where a priori fee estimation fails. See https://github.com/bitcoin/bitcoin/pull/1647 and https://github.com/bitcoin/bitcoin/pull/6176 I know there has been much discussion of fee estimation not working for SPV clients, but I believe several independent servers which were serving the estimates from full nodes would go a long way towards allowing that information to be used by SPV clients even if its not a completely decentralized solution. See for example http://core2.bitcoincore.org/smartfee/latest.json On Mon, Jun 15, 2015 at 8:08 PM, Aaron Voisine vois...@gmail.com wrote: Wasn't the XT hard fork proposed as a last resort, should the bitcoin-core maintainers simply refuse to lift the 1Mb limit? No one wants to go that route. An alternate hard-fork proposal like BIP100 that gets consensus, or a modified version of gavin's that ups the limit to 8Mb instead of 20Mb, or hell even some major changes to the non-consunsus code to make it adequately handle the situation when blocks fill up, and allow wallet software to continue working with a send-and-forget use pattern, any of these would be enough to avoid the need for an XT only hard-fork. So far BIP100 is the only one that seems to actually be getting any sort of momentum toward consensus, and it was proposed... 2 days ago? When the XT fork was proposed as a last resort, it was when the opponents were (to my understanding) suggesting we just let blocks fill up, and hopefully things would just work out on their own. Aaron Voisine co-founder and CEO breadwallet.com On Mon, Jun 15, 2015 at 3:56 PM, Brian Hoffman brianchoff...@gmail.com wrote: Who is actually planning to move to Bitcoin-XT if this happens? Just Gavin and Mike? [image: image1.JPG] On Jun 15, 2015, at 6:17 PM, Faiz Khan faizkha...@gmail.com wrote: I'm quite puzzled by the response myself, it doesn't seem to address some of the (more serious) concerns that Adam put out, the most important question that was asked being the one regarding personal ownership of the proposed fork: How do you plan to deal with security incident response for the duration you describe where you will have control while you are deploying the unilateral hard-fork and being in sole maintainership control? I do genuinely hope that whomever (now and future) wishes to fork the protocol reconsider first whether they are truly ready to test/flex their reputation/skills/resources in this way... Intuitively, to me it seems counterproductive, and I don't fully believe it is within a single developer's talents to manage the process start-to-finish (as it is non-trivial to hard-fork successfully, others have rehashed this in other threads)... That being said I think it appropriate if Adam's questions were responded in-line when Mike is feeling up to it. I think that the answers are important for the community to hear when such a drastic change is being espoused. Faiz On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop kanz...@gmail.com wrote: On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn m...@plan99.net wrote: Re: anyone who agrees with noted non-programmers MikeGavin must be non-technical, stupid, uninformed, etc OK, go ahead and show them the error of their ways. Anyone can write blogs. I worry that if this is the level of care you take with reading and (mis)interpreting Adam's messages, that you might not be taking extreme care with evaluating consensus changes, even while tired or sleeping. I encourage you to evaluate both messages and source code more carefully, especially in the world of bitcoin. However, this goes for everyone and not just you. Specifically, when Adam mentioned your conversations with non-technical people, he did not mean Mike has talked with people who have possibly not made pull requests to Bitcoin Core, so therefore Mike is
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] questions about bitcoin-XT code fork non-consensus hard-fork
Thanks Alex, the work you've pointed out is helpful. Limiting mempool size should at least prevent nodes from crashing. When I looked a few days ago I only found a few old PRs that seemed to have fallen by the wayside, so this new one is encouraging. I can respond in the PR comments if it's more appropriate there, but I believe ejecting tx from mempools rather than preemptively refusing them according to standard network wide propagation rules will result in spotty, inconsistent tx propagation, and possibly a large increase in tx re-broadcasts, so if those haven't been addressed they will need to be. It would also be prudent to run some simulations to see what other issues are going to pop-up. We're currently using CPFP already in breadwallet when spending unconfirmed non-change inputs. A small percentage of hashing power is using it, but enough to get a transaction unstuck assuming breadwallet's fee calculation is better than the sender's. The problem with RBF is that there's currently no way to tell if your tx has been picked up by miners or not in order to know if you need to replace it. Miners broadcasting partial block solutions would be helpful in this regard, but only for tx in the currently-being-worked-on block, not for tx that won't be picked up until the block after. If miners were to eject tx that were previously being worked on in favor of higher fee tx, then that causes another set of problems for wallets that thought their tx was going to get in but then it doesn't. The other problem with RBF is that users don't know up front what fee they're actually going to pay which is a big blow to real world usability. Also mobile wallets will have to sign lots of tx up front and rely on a service to replace as necessary. And this is all just on the send side. On the receive side it's much worse since you can't rely on the sender to do the replacing. The real problem seems to be the fact that RBF is an interactive iterative process rather than a send-and-forget one. What you really need is some way to tell up-front, is a transaction going to get mined with a high probability? That problem seems really difficult to solve with fixed-size blocks that are full. If the goal is simply to reduce or limit the growth of the blockchain, then there are much simpler solutions, which is why I've advocated for the blocksize increase, followed by tx selection and propagation rule changes to create fee pressure. Aaron Voisine co-founder and CEO breadwallet.com On Mon, Jun 15, 2015 at 6:17 PM, Alex Morcos mor...@gmail.com wrote: Aaron, My understanding is that Gavin and Mike are proceeding with the XT fork, I hope that understanding is wrong. As for improving the non-consensus code to handle full blocks more gracefully. This is something I'm very interested in, block size increase or not. Perhaps I shouldn't hijack this thread, but maybe there are others who also believe this would ameliorate some of the time pressure for deciding on a block size increase. What is it that you would like to see improved? The fee estimation code that is included for 0.11 will give much more accurate fee estimates, which should allow adding the correct fee to a transaction to see it likely to be confirmed in a reasonable time. For further improvements: - There has recently been attention to overhauling the block creation and mempool limiting code in such a way that actual outstanding queues to be included in a block could also be incorporated in fee estimation. See https://github.com/bitcoin/bitcoin/pull/6281. - CPFP and RBF are candidates for inclusion in core soon, both of which could be integrated into transaction processing to handle the edge cases where a priori fee estimation fails. See https://github.com/bitcoin/bitcoin/pull/1647 and https://github.com/bitcoin/bitcoin/pull/6176 I know there has been much discussion of fee estimation not working for SPV clients, but I believe several independent servers which were serving the estimates from full nodes would go a long way towards allowing that information to be used by SPV clients even if its not a completely decentralized solution. See for example http://core2.bitcoincore.org/smartfee/latest.json On Mon, Jun 15, 2015 at 8:08 PM, Aaron Voisine vois...@gmail.com wrote: Wasn't the XT hard fork proposed as a last resort, should the bitcoin-core maintainers simply refuse to lift the 1Mb limit? No one wants to go that route. An alternate hard-fork proposal like BIP100 that gets consensus, or a modified version of gavin's that ups the limit to 8Mb instead of 20Mb, or hell even some major changes to the non-consunsus code to make it adequately handle the situation when blocks fill up, and allow wallet software to continue working with a send-and-forget use pattern, any of these would be enough to avoid the need for an XT only hard-fork. So far BIP100 is the only one that seems to actually be getting any sort of momentum toward
Re: [Bitcoin-development] The Bitcoin Node Market
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 ;) 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] questions about bitcoin-XT code fork non-consensus hard-fork
On Jun 15, 2015, at 3:54 PM, odinn odinn.cyberguerri...@riseup.net wrote: I also disagree with the notion that everybody's just ok with what Mike and Gavin are doing specifically, this statement by Mike The consensus you seek does exist. All wallet developers (except Lawrence), all the major exchanges, all the major payment processors and many of the major mining pools want to see the limit lifted This is certainly twisting words! We all agree that the limit needs to eventually be lifted - but some of us certainly disagree with the means being used to do so by Mike and Gavin. Most news publications keep the discussion rather shallow and like to keep the controversy pretty black and white - some of us have far more nuanced views! - Eric Lombrozo signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ 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] The Bitcoin Node Market
No,Bitcoin 发自我的 iPhone 在 2015年6月16日，13:28，justusranv...@riseup.net 写道： On 2015-06-16 03:49, Kevin Greene wrote: 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. Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who would provide the nodes they would need connect to? The decentralization fairy? There's absolutely no reason that paying for connectivity would be any more confusing or annoying than transaction fees are. If some full nodes in the network started offering paid connection slots, that would just mean that users who checked the pay subscription fee box in their wallet configuration would have an easier time connecting than the users who did't, just like how your transaction might eventually get mined without a fee but paying one makes it faster and more probable. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinf -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] comments on BIP 100
I think he's more talking about like extension-blocks, however they are actually soft-forkable even (and keep the 21m coins obviously) See See https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07937.html and Tier Nolan tech detail https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07927.html Discussion / claimed properties on https://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/ Adam On 15 June 2015 at 19:53, Raystonn . rayst...@hotmail.com wrote: The solution is to hard-fork and merge-mine. This way, both can live, and mining power is not divided. No, this would essentially be blessing an increase to 42M bitcoins, half on each chain. You could expect a severe market price correction if this were to happen. From: Rebroad (sourceforge) Sent: Monday, June 15, 2015 4:16 AM Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] comments on BIP 100 My understanding of this debate is that there are some people who want to keep Bitcoin at 1MB block limit, and there are some who want to increase it. I for one am curious to see how 1MB limited bitcoin evolves, and I believe we can all have a chance to see this AND hard-fork bitcoin to remove the block size restriction. To remove the 1MB limit required a hard fork. This is not disputed. It's what we do with the original (1MB limit) bitcoin that concerns me (and other's I am sure). What I would like to see is both being allowed to live. Harry Potter and Voldermort! (Except neither are evil!) The solution is to hard-fork and merge-mine. This way, both can live, and mining power is not divided. Dogecoin recently hardforked and this hardfork also involved switching to merge-mining, so it's been done successfully. So, simply, bitcoin as it is doesn't need to actually fork, but instead, at a certain block size, a forked bitcoin with the blocksize lmit removed will start to be merge-mined alongside bitcoin. Miners can be ready for this. Wallets can be ready for this - in fact, for most wallets and merchants they will possibly want to default to the bigger blocksize fork since this caters for more transactions per block. We still don't know how removing the block limit will pan out and what other problems with scalability will arise in the future, so by preserving the original bitcoin, we keep diversity, and people won't feel their investments in bitcoin are being unnecessarily put at risk (as their investments will stay in both the new and the old bitcoin). The bitcoin core developers can implement a patch like the one recently used for dogecoin, to allow the chain to fork at a set point, where at which point, bitcoins will be split into the new and the old. Branding will be an important issue here I think, so that there is as little confusion as possible. I think this is a small price to pay in return for not killing the original bitcoin (even if it's true that Satoshi did intend to remove the 1MB limit at some point). If I'm missing something obvious please let me know. On Mon, Jun 15, 2015 at 1:50 PM, Mike Hearn m...@plan99.net wrote: The fact that using a centralized service is easier isn't a good reason IMHO. It disregards the long-term, and introduces systemic risk. Well sure, that's easy for you to say, but you have a salary :) Other developers may find the incremental benefits of decentralisation low vs adding additional features, for instance, and who is to say they are wrong? But in cases where using a decentralized approach doesn't *add* anything, I cannot reasonably promote it, and that's why I was against getutxos in the P2P protocol. It does add something though! It means, amongst other things, I can switch of all my servers, walk away for good, discard this Mike Hearn pseudonym I invented for Bitcoin and the app will still work :) Surely that is an important part of being decentralised? It also means that as the underlying protocol evolves over time, getutxos can evolve along side it. P2P protocol gets encrypted/authenticated? Great, one more additional bit of security. If one day miners commit to UTXO sets, great, one more additional bit of security. When we start including input values in the signature hash, great ... one more step up in security. Anyway, I didn't really want to reopen this debate. I just point out that third party services are quite happy to provide whatever developers need to build great apps, even if doing so fails to meet some kind of perfect cryptographic ideal. And that's why they're winning devs. Now back to your regularly scheduled block size debates ... -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork
Hi Mike Well thank you for replying openly on this topic, its helpful. I apologise in advance if this gets quite to the point and at times blunt, but transparency is important, and we owe it to the users who see Bitcoin as the start of a new future and the$3b of invested funds and $600m of VC funds invested in companies, we owe it to them that we be open and transparent here. I would really prefer on a personal nor professional basis to be having this conversation period, never mind in public, but Mike - your and Gavin's decision to promote a unilateral hard-fork and code fork are extremely high risk for bitcoin and so there remains little choice. So I apologise again that we have to have this kind of conversation on a technical discussion list. This whole thing is hugely stressful and worrying for developers, companies and investors. I strongly urge that we return to the existing collaborative constructive review process that has been used for the last 4 years which is a consensus by design to prevent one rogue person from inserting a backdoor, or lobbying for a favoured change on behalf of a special interest group, or working for bad actor (without accusing you of any of those - I understand you personally just want to scale bitcoin, but are inclined to knock heads and try to force an issue you see, rather than work collaboratively). For you (and everyone) - Should there be a summit of some kind, that is open attendance, and video recorded so that people who are unable to attend can participate too, so that people can present the technical proposals and risks in an unbiased way? (It is not theoretical question, I may have a sponsor and host - not Blockstream, an independent, its a question for everyone, developers, users, CTOs, CEOs.) So here I come back to more frank questions: Governance The rest of the developers are wise to realise that they do not want exclusive control, to avoid governance centralising into the hands of one person, and this is why they have shared it with a consensus process over the last 4 years. No offence but I dont think you personally are thinking far enough ahead to think you want personal control of this industry. Maybe some factions dont trust your motives, or they dont mind, but feel more assured if a dozen other people are closely reviewing and have collective review authority. - Do you understand that attempting to break this process by unilateral hard-fork is extremely weakening of Bitcoin's change governance model? - Do you understand that change governance is important, and that it is important that there be multiple reviewers and sign-off to avoid someone being blackmailed or influenced by an external party - which could potentially result in massive theft of funds if something were missed? - Secondarily do you understand that even if you succeed in a unilateral fork (and the level of lost coins and market cap and damage to confidence is recoverable), that it sets a precedent that others may try to follow in the future to introduce coercive features that break the assurances of bitcoin, like fungibility reducing features say (topically I hear you once proposed on a private forum the concept of red-lists, other such proposals have been made and quickly abandoned), or ultimately if there is a political process to obtain unpopular changes by unilateral threat, the sky is the limit - rewrite the social contract at that point without consensus, but by calculation that people will value Bitcoin enough that they will follow a lead to avoid risk to the system? Security As you probably know some extremely subtle bugs in Bitcoin have at times slipped past even the most rigorous testings, often with innocuous but unexpected behaviours, but some security issues Some extremely intricate and time-sensitive security defect and incident response happens from time to time which is not necessarily publicly disclosed until after the issue has been rolled out and fixed, which can take some time due to the nature of protocol upgrades, work-arounds, software upgrade via contacting key miners etc. We could take an example of the openSSL bug. - How do you plan to deal with security incident response for the duration you describe where you will have control while you are deploying the unilateral hard-fork and being in sole maintainership control? - Are you a member of the bitcoin security reporting list? On 15 June 2015 at 11:56, Mike Hearn m...@plan99.net wrote: I will review both and mostly delegate to Gavin's good taste around the details, unless there is some very strong disagreement. But that seems unlikely. ... Feedback will be read. There are no NACKS in Bitcoin XT. Patch requests aren't scored in any way. The final decision rests with the maintainer as in ~all open source projects. As you know the people who have written 95% of the code (and reviewed, and tested, and formally proved segments etc) are strenuously advising not to push any consensus
[Bitcoin-development] The Bitcoin Node Market
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
Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity
Recent versions of mailman strip DKIM signatures, rewrite the envelope-from to use an address at the list's domain and set reply-to to the original authors address to resolve the DMARC issue. I'm on several lists that do this and it works just fine. +1 on moving the list. Given the fact that the mails are archived in public, it's not really a huge deal how it takes place. One month sounds reasonable (although I think it could be done on a shorter timescale). I'd setup the new list to allow subscriptions, but keep it moderated to keep discussion from moving until the cut, send lots of warnings and then on the big day unmoderate one and moderate the other. It's a great opportunity to hardfork something in Bitcoin without risk of breakage, losses or entertaining melodrama. : ) --adam ps. I think SF will let project admins download mbox archives of the list, the new admins should be able to import them to keep archive consistency in one place. On Mon, Jun 15, 2015 at 6:13 AM, Mike Hearn m...@plan99.net wrote: Bear in mind the problem that stops Jeff's messages getting through is that mailman 1.0 doesn't know how to handle DKIM properly. Switching to a different mailman provider won't fix that. Does mailman 3.0 even fix this? I found it difficult to tell from their website. There's a big page on the mailman wiki that suggests they fixed it by simply deleting the signatures entirely, which won't work. DMARC policies state that mail *must* be signed and unsigned/incorrectly signed message should be discarded. The user documentation for mailman 3 doesn't seem to exist? The links on the website are docs for 2.1, perhaps they released mailman 3 without refreshing the docs. Google Groups may be controversial but if I recall correctly the main issue was the question of whether you needed a Google account or not. I'm pretty sure you can just send an email to groupname+subscr...@googlegroups.com even if you don't have a Google account. But of course this is a bizarre standard to hold mailing list software to: mailman asks users to create an account for each listserv in order to manage a subscription too! -- ___ 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] BIP for Proof of Payment
Shared wallets were discussed earlier as a feature. If you pay a for dry cleaning with a shared wallet, a different 1-of-N signer can pick up the clothes with no physical transfer of a claim check, by proving the money that paid for the cleaning was his. Many kinds of vouchers can be eliminated, because the money itself can be vouched for, wirelessly, with ECDSA security. A PoP would be much more difficult to forge as a valet claim check, to steal a car. Something like your coffee gift example was also mentioned. The buyer could export the private keys to your (the beneficiary's) wallet after the purchase, by using an 'export gift claim check' function on the spent transaction. Then you pick up the coffee (car, concert seats...) just as if you had paid. Kalle goes to some trouble to describe how merchants need to ensure that they only accept a PoP provided as a response to their challenge. Coinjoin or simulfunding transactions wouldn't be PoP-able (nor should they be) since no one signer has all the private keys. On 6/15/2015 3:00 AM, Pieter Wuille wrote: I did misunderstand that. That changes things significantly. However, having paid is not the same as having had access to the input coins. What about shared wallets or coinjoin? Also, if I understand correctly, there is no commitment to anything you're trying to say about the sender? So once I obtain a proof-of-payment from you about something you paid, I can go claim that it's mine? Why does anyone care who paid? This is like walking into a coffeshop, noticing I don't have money with me, let me friend pay for me, and then have the shop insist that I can't drink it because I'm not the buyer. Track payments, don't try to assign identities to payers. On Jun 15, 2015 11:35 AM, Kalle Rosenbaum ka...@rosenbaum.se mailto:ka...@rosenbaum.se wrote: Hi Pieter! It is intended to be a proof that you *have paid* for something. Not that you have the intent to pay for something. You cannot use PoP without a transaction to prove. So, yes, it's just a proof of access to certain coins that you no longer have. Maybe I don't understand you correctly? /Kalle 2015-06-15 11:27 GMT+02:00 Pieter Wuille pieter.wui...@gmail.com mailto:pieter.wui...@gmail.com: Now that you have removed the outputs, I don't think it's even a intent of payment, but just a proof of access to certain coins. On Jun 15, 2015 11:24 AM, Kalle Rosenbaum ka...@rosenbaum.se mailto:ka...@rosenbaum.se wrote: Hi all! I have made the discussed changes and updated my implementation (https://github.com/kallerosenbaum/poppoc) accordingly. These are the changes: * There is now only one output, the pop output, of value 0. * The sequence number of all inputs of the PoP must be set to 0. I chose to set it to 0 for all inputs for simplicity. * The lock_time of the PoP must be set to 4 (max block height lock time). The comments so far has been mainly positive or neutral. Are there any major objections against any of the two proposals? If not, I will ask Gregory Maxwell to assign them BIP numbers. The two BIP proposals can be found at https://github.com/kallerosenbaum/poppoc/wiki/Proof-of-Payment-BIP and https://github.com/kallerosenbaum/poppoc/wiki/btcpop-scheme-BIP. The source for the Proof of Payment BIP proposal is also in-lined below. A number of alternative names have been proposed: * Proof of Potential * Proof of Control * Proof of Signature * Signatory Proof * Popo: Proof of payment origin * Pots: Proof of transaction signer * proof of transaction intent * Declaration of intent * Asset-access-and-action-affirmation, AAaAA, or A5 * VeriBit * CertiBTC * VBit * PayID Given this list, I still think Proof of Payment is the most descriptive to non-technical people. Regards, Kalle # pre BIP: BIP number Title: Proof of Payment Author: Kalle Rosenbaum ka...@rosenbaum.se mailto:ka...@rosenbaum.se Status: Draft Type: Standards Track Created: date created on, in ISO 8601 (-mm-dd) format /pre == Abstract == This BIP describes how a wallet can prove to a server that it has the ability to sign a certain transaction. == Motivation == There are several scenarios in which it would be useful to prove that you have paid for something. For example: * A pre-paid hotel room where your PoP functions as a key to the door. * An online video rental service where you pay for a video and watch
Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork
I'm quite puzzled by the response myself, it doesn't seem to address some of the (more serious) concerns that Adam put out, the most important question that was asked being the one regarding personal ownership of the proposed fork: How do you plan to deal with security incident response for the duration you describe where you will have control while you are deploying the unilateral hard-fork and being in sole maintainership control? I do genuinely hope that whomever (now and future) wishes to fork the protocol reconsider first whether they are truly ready to test/flex their reputation/skills/resources in this way... Intuitively, to me it seems counterproductive, and I don't fully believe it is within a single developer's talents to manage the process start-to-finish (as it is non-trivial to hard-fork successfully, others have rehashed this in other threads)... That being said I think it appropriate if Adam's questions were responded in-line when Mike is feeling up to it. I think that the answers are important for the community to hear when such a drastic change is being espoused. Faiz On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop kanz...@gmail.com wrote: On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn m...@plan99.net wrote: Re: anyone who agrees with noted non-programmers MikeGavin must be non-technical, stupid, uninformed, etc OK, go ahead and show them the error of their ways. Anyone can write blogs. I worry that if this is the level of care you take with reading and (mis)interpreting Adam's messages, that you might not be taking extreme care with evaluating consensus changes, even while tired or sleeping. I encourage you to evaluate both messages and source code more carefully, especially in the world of bitcoin. However, this goes for everyone and not just you. Specifically, when Adam mentioned your conversations with non-technical people, he did not mean Mike has talked with people who have possibly not made pull requests to Bitcoin Core, so therefore Mike is a non-programmer. Communication is difficult and I can understand that, but we really have to be more careful when evaluating each other's messages; technical miscommunication can be catastrophic in this context. On the topic of whether you are a programmer, I suspect that ever since you built CIA.vc we have all known you're a programmer, Mike. - Bryan http://heybryan.org/ 1 512 203 0507 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- My regards, Faiz Khan 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] questions about bitcoin-XT code fork non-consensus hard-fork
http://xtnodes.com/ From: Brian Hoffman Sent: Monday, June 15, 2015 3:56 PM To: Faiz Khan Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork Who is actually planning to move to Bitcoin-XT if this happens? Just Gavin and Mike? On Jun 15, 2015, at 6:17 PM, Faiz Khan faizkha...@gmail.com wrote: I'm quite puzzled by the response myself, it doesn't seem to address some of the (more serious) concerns that Adam put out, the most important question that was asked being the one regarding personal ownership of the proposed fork: How do you plan to deal with security incident response for the duration you describe where you will have control while you are deploying the unilateral hard-fork and being in sole maintainership control? I do genuinely hope that whomever (now and future) wishes to fork the protocol reconsider first whether they are truly ready to test/flex their reputation/skills/resources in this way... Intuitively, to me it seems counterproductive, and I don't fully believe it is within a single developer's talents to manage the process start-to-finish (as it is non-trivial to hard-fork successfully, others have rehashed this in other threads)... That being said I think it appropriate if Adam's questions were responded in-line when Mike is feeling up to it. I think that the answers are important for the community to hear when such a drastic change is being espoused. Faiz On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop kanz...@gmail.com wrote: On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn m...@plan99.net wrote: Re: anyone who agrees with noted non-programmers MikeGavin must be non-technical, stupid, uninformed, etc OK, go ahead and show them the error of their ways. Anyone can write blogs. I worry that if this is the level of care you take with reading and (mis)interpreting Adam's messages, that you might not be taking extreme care with evaluating consensus changes, even while tired or sleeping. I encourage you to evaluate both messages and source code more carefully, especially in the world of bitcoin. However, this goes for everyone and not just you. Specifically, when Adam mentioned your conversations with non-technical people, he did not mean Mike has talked with people who have possibly not made pull requests to Bitcoin Core, so therefore Mike is a non-programmer. Communication is difficult and I can understand that, but we really have to be more careful when evaluating each other's messages; technical miscommunication can be catastrophic in this context. On the topic of whether you are a programmer, I suspect that ever since you built CIA.vc we have all known you're a programmer, Mike. - Bryan http://heybryan.org/ 1 512 203 0507 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- My regards, Faiz Khan -- ___ 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] questions about bitcoin-XT code fork non-consensus hard-fork
Who is actually planning to move to Bitcoin-XT if this happens? Just Gavin and Mike? On Jun 15, 2015, at 6:17 PM, Faiz Khan faizkha...@gmail.com wrote: I'm quite puzzled by the response myself, it doesn't seem to address some of the (more serious) concerns that Adam put out, the most important question that was asked being the one regarding personal ownership of the proposed fork: How do you plan to deal with security incident response for the duration you describe where you will have control while you are deploying the unilateral hard-fork and being in sole maintainership control? I do genuinely hope that whomever (now and future) wishes to fork the protocol reconsider first whether they are truly ready to test/flex their reputation/skills/resources in this way... Intuitively, to me it seems counterproductive, and I don't fully believe it is within a single developer's talents to manage the process start-to-finish (as it is non-trivial to hard-fork successfully, others have rehashed this in other threads)... That being said I think it appropriate if Adam's questions were responded in-line when Mike is feeling up to it. I think that the answers are important for the community to hear when such a drastic change is being espoused. Faiz On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop kanz...@gmail.com wrote: On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn m...@plan99.net wrote: Re: anyone who agrees with noted non-programmers MikeGavin must be non-technical, stupid, uninformed, etc OK, go ahead and show them the error of their ways. Anyone can write blogs. I worry that if this is the level of care you take with reading and (mis)interpreting Adam's messages, that you might not be taking extreme care with evaluating consensus changes, even while tired or sleeping. I encourage you to evaluate both messages and source code more carefully, especially in the world of bitcoin. However, this goes for everyone and not just you. Specifically, when Adam mentioned your conversations with non-technical people, he did not mean Mike has talked with people who have possibly not made pull requests to Bitcoin Core, so therefore Mike is a non-programmer. Communication is difficult and I can understand that, but we really have to be more careful when evaluating each other's messages; technical miscommunication can be catastrophic in this context. On the topic of whether you are a programmer, I suspect that ever since you built CIA.vc we have all known you're a programmer, Mike. - Bryan http://heybryan.org/ 1 512 203 0507 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- My regards, Faiz Khan -- ___ 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] questions about bitcoin-XT code fork non-consensus hard-fork
Wasn't the XT hard fork proposed as a last resort, should the bitcoin-core maintainers simply refuse to lift the 1Mb limit? No one wants to go that route. An alternate hard-fork proposal like BIP100 that gets consensus, or a modified version of gavin's that ups the limit to 8Mb instead of 20Mb, or hell even some major changes to the non-consunsus code to make it adequately handle the situation when blocks fill up, and allow wallet software to continue working with a send-and-forget use pattern, any of these would be enough to avoid the need for an XT only hard-fork. So far BIP100 is the only one that seems to actually be getting any sort of momentum toward consensus, and it was proposed... 2 days ago? When the XT fork was proposed as a last resort, it was when the opponents were (to my understanding) suggesting we just let blocks fill up, and hopefully things would just work out on their own. Aaron Voisine co-founder and CEO breadwallet.com On Mon, Jun 15, 2015 at 3:56 PM, Brian Hoffman brianchoff...@gmail.com wrote: Who is actually planning to move to Bitcoin-XT if this happens? Just Gavin and Mike? [image: image1.JPG] On Jun 15, 2015, at 6:17 PM, Faiz Khan faizkha...@gmail.com wrote: I'm quite puzzled by the response myself, it doesn't seem to address some of the (more serious) concerns that Adam put out, the most important question that was asked being the one regarding personal ownership of the proposed fork: How do you plan to deal with security incident response for the duration you describe where you will have control while you are deploying the unilateral hard-fork and being in sole maintainership control? I do genuinely hope that whomever (now and future) wishes to fork the protocol reconsider first whether they are truly ready to test/flex their reputation/skills/resources in this way... Intuitively, to me it seems counterproductive, and I don't fully believe it is within a single developer's talents to manage the process start-to-finish (as it is non-trivial to hard-fork successfully, others have rehashed this in other threads)... That being said I think it appropriate if Adam's questions were responded in-line when Mike is feeling up to it. I think that the answers are important for the community to hear when such a drastic change is being espoused. Faiz On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop kanz...@gmail.com wrote: On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn m...@plan99.net wrote: Re: anyone who agrees with noted non-programmers MikeGavin must be non-technical, stupid, uninformed, etc OK, go ahead and show them the error of their ways. Anyone can write blogs. I worry that if this is the level of care you take with reading and (mis)interpreting Adam's messages, that you might not be taking extreme care with evaluating consensus changes, even while tired or sleeping. I encourage you to evaluate both messages and source code more carefully, especially in the world of bitcoin. However, this goes for everyone and not just you. Specifically, when Adam mentioned your conversations with non-technical people, he did not mean Mike has talked with people who have possibly not made pull requests to Bitcoin Core, so therefore Mike is a non-programmer. Communication is difficult and I can understand that, but we really have to be more careful when evaluating each other's messages; technical miscommunication can be catastrophic in this context. On the topic of whether you are a programmer, I suspect that ever since you built CIA.vc we have all known you're a programmer, Mike. - Bryan http://heybryan.org/ 1 512 203 0507 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- My regards, Faiz Khan 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 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
