* Re: [Bitcoin-development] The Bitcoin Node Market @ 2015-06-16 4:38 Raystonn 0 siblings, 0 replies; 17+ messages in thread From: Raystonn @ 2015-06-16 4:38 UTC (permalink / raw) To: Kevin Greene; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/html, Size: 3446 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bitcoin-development] comments on BIP 100 @ 2015-06-14 21:23 Adam Back 2015-06-14 22:23 ` Mike Hearn 0 siblings, 1 reply; 17+ messages in thread From: Adam Back @ 2015-06-14 21:23 UTC (permalink / raw) To: Bitcoin Dev Hi I made these comments elsewhere, but I think really we should be having these kind of conversations here rather than scattered around. These are about Jeff Garzik's outline draft BIP 100 I guess this is the latest draft: (One good thing about getting off SF would be finally JGarzik's emails actually not getting blocked!). http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf may have changed since the original [1] Over the original proposal: 1. there should be a hard cap, not indefinitely growing. 2. there should be a growth limiter (no more than X%/year) 3. I think the miners should not be given a vote that has no costs to cast, because their interests are not necessarily aligned with users or businesses. I think Greg Maxwell's difficulty adjust [2] is better here for that reason. It puts quadratic cost via higher difficulty for miners to vote to increase block-size, which miners can profitably do if there are transactions with fees available to justify it. There is also the growth limiter as part of Greg's proposal. [3] I think bitcoin will have to involve layering models that uplift security to higher layers, but preserve security assurances, and smart-contracts even, with protocols that improve the algorithmic complexity beyond O(n^2) in users, like lightning, and there are multiple other candidates with useful tradeoffs for various use-cases. One thing that is concerning is that few in industry seem inclined to take any development initiatives or even integrate a library. I suppose eventually that problem would self-correct as new startups would make a more scalable wallet and services that are layer2 aware and eat the lunch of the laggards. But it will be helpful if we expose companies to the back-pressure actually implied by an O(n^2) scaling protocol and don't just immediately increase the block-size to levels that are dangerous for decentralisation security, as an interventionist subsidy to save them having to do basic integration work. Otherwise I think whichever any kind of kick the can some 2-5 years down the road we consider, we risk the whole saga repeating in a few years, when no algorithmic progress has been made and even more protocol inertia has set in. Adam [1] original proposal comments on reddit https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/ [2] flexcap propoal by Greg Maxwell see post by Mark Freidenbach https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07599.html [3] growth limited proposal for flexcap by Greg Maxwell https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07620.html ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] comments on BIP 100 2015-06-14 21:23 [Bitcoin-development] comments on BIP 100 Adam Back @ 2015-06-14 22:23 ` Mike Hearn 2015-06-14 23:58 ` Adam Back 0 siblings, 1 reply; 17+ messages in thread From: Mike Hearn @ 2015-06-14 22:23 UTC (permalink / raw) To: Adam Back; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2351 bytes --] > > One thing that is concerning is that few in industry seem inclined to > take any development initiatives or even integrate a library. Um, you mean except all the people who have built more scalable wallets over the past few years, which is the only reason anyone can even use Bitcoin from their phone? Or maybe you mean initiatives like Lightning .... except StrawPay already developed something similar to the Lightning network (complete with a working GUI wallet) and were ignored by Blockstream as you prefer to write your own from scratch? Sure, people in the industry take development initiatives. That doesn't mean their work will be recognised on this mailing list. > I suppose eventually that problem would self-correct as new startups would > make a more scalable wallet and services that are layer2 aware and eat the > lunch of the laggards. "The laggards" being *everyone* who has already invested in building Bitcoin software so far. Not a great way to frame things. Many of those "laggards" have written orders of magnitude more code than you or Gregory or Jeff, for instance. I still think you guys don't recognise what you are actually asking for here - scrapping virtually the entire existing investment in software, wallets and tools. > But it will be helpful if we expose companies to the back-pressure > actually implied by an O(n^2) scaling protocol and don't just immediately > increase the block-size to levels that are dangerous for decentralisation > security Bitcoin does not have n-squared scaling. I really don't get where this idea comes from. Computational complexity for the entire network is O(nm) where n=transactions and m=fully validating nodes. There is no fixed relationships between those two variables. "Exposing the companies to back-pressure" sounds quite nice and gentle. Let me rephrase it to be equivalent but perhaps more direct: you mean "breaking the current software ecosystem to force people into a new, fictional system that bears little resemblance to the Bitcoin we use today, whether they want that or not". As nothing that has been proposed so far (Lightning, merge mined chains, extension blocks etc) has much chance of actual deployment any time soon, that leaves raising the block size limit as the only possible path left. Which is why there will soon be a fork that does it. [-- Attachment #2: Type: text/html, Size: 3042 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] comments on BIP 100 2015-06-14 22:23 ` Mike Hearn @ 2015-06-14 23:58 ` Adam Back 2015-06-15 9:27 ` Mike Hearn 0 siblings, 1 reply; 17+ messages in thread From: Adam Back @ 2015-06-14 23:58 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev Hi Mike On 15 June 2015 at 00:23, Mike Hearn <mike@plan99•net> wrote: >> One thing that is concerning is that few in industry seem inclined to >> take any development initiatives or even integrate a library. > > Um, you mean except all the people who have built more scalable wallets over > the past few years, which is the only reason anyone can even use Bitcoin > from their phone? No slight intended obviously to people who do write actual client code. That was probably insufficiently specific, let me rephrase: I am referring to the trend that much of the industry is built on web2.0 technology using bitcoin via a library in a web scripting language, often with consensus bugs, and even outsourcing and not even running their own full node, so that the service itself offered to their users isn't even SPV secure to the operator. As well as being heavily based on a third-party custody model that is the root cause of the repeated wallet breaches. Some of these companies have a noted tendency not to upgrade or fix code. So I mean this not to call out specific companies, but in the sense that if we're technologists we should be trying to move the technology forward, not just changing parameters which run into an O(n^2) scaling wall or break decentralisation security. And we shouldnt take the above state of affairs as an immutable reality. It can not persist for bitcoin to reach maturity on scale nor security. > I still think you guys don't recognise what you are actually asking for here > - scrapping virtually the entire existing investment in software, wallets > and tools. As I said I dont think we can expect Bitcoin to scale with no further algorithmic improvements. Algorithmic improvements take code. There is reasonable scope to build in an incrementally deployable way, there's plenty of time for people to code, test and opt-in to things, the sky is not falling. Companies do care about scaling, and can invest in the integration and coding implied to improve their products scalability, they have an economic incentive to do it and there is no scalable and safe way todo it without this work. > Computational complexity for the entire network is O(nm) where > n=transactions and m=fully validating nodes. There is no fixed relationships > between those two variables. I am referring to global bandwidth O(n^2) with n=users, or O(n) per user bandwidth cost to the system, while O(nm) is accurate nodes is an internal system concept. Anyway suffice to say the network does not scale O(1) in per user cost. > "Exposing the companies to back-pressure" sounds quite nice and gentle. Let > me rephrase it to be equivalent but perhaps more direct: you mean "breaking > the current software ecosystem to force people into a new, fictional system > that bears little resemblance to the Bitcoin we use today, whether they want > that or not". > > As nothing that has been proposed so far (Lightning, merge mined chains, > extension blocks etc) has much chance of actual deployment any time soon, > that leaves raising the block size limit as the only possible path left. A hard-fork takes a long period of time to deploy due to the non-upgrade risk, people are working on things in the mean-time. There can be a case for some increase to create some breathing room to work on scaling and decentralising tech, I just mean to say that if we do it in isolation, we're not focussing on the big picture. Adam ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] comments on BIP 100 2015-06-14 23:58 ` Adam Back @ 2015-06-15 9:27 ` Mike Hearn 2015-06-15 10:24 ` Pieter Wuille 0 siblings, 1 reply; 17+ messages in thread From: Mike Hearn @ 2015-06-15 9:27 UTC (permalink / raw) To: Adam Back; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 4206 bytes --] > > That was probably insufficiently specific, let me rephrase: I am > referring to the trend that much of the industry is built on web2.0 > technology using bitcoin via a library in a web scripting language OK, good to hear that. I'm not happy about the use of web technologies in wallets/services either, but the causes of that trend are nothing to do with block chain sizes. It's more because there's a generation of developers who see no alternatives. With projects like Lighthouse, I'm trying to show people that they can blend the good bits of the web with the good bits of more traditional client side development, at a cost they can afford. Unfortunately, as you know, one of the reasons that developers turn to outsourced services is that those services actually like developers and give them the features they need. Whereas any attempt to add protocol features for app/wallet developers to Bitcoin Core becomes controversial due to some perceived or real lack of perfection. I persevered for several months to add a very small "API" I needed for my app to Bitcoin Core, and it was in the end a waste of time. There are no actionable items left for the getutxo patch, regardless, I had to fork Bitcoin to get it out there. It would have been *much* easier to just say, fuck it, I'll use blockchain.info and in fact some in this community told me to do exactly that. But, the approach I chose has been working fine for months now. Compare this experience to companies like chain.com, blockcypher etc - when developers say jump, they say "how high?" So It's unreasonable for the Bitcoin Core developer group to constantly call developers building apps idiots or "non technical" (as I see so often in this block size debate), and then complain that people don't write apps in their preferred way! Just accept that decentralised app dev is already hard, and the way Core is run makes it much harder still. As I said I dont think we can expect Bitcoin to scale with no further > algorithmic improvements. A big part of the debate around this change is showing that this statement is wrong. "Scaling" is not some kind of binary yes/no thing. It's a continuous effort. You write a system that scales a certain amount, and then if you find you need more capacity, you scale it again. Maybe that involves rewriting the existing code or maybe it just means improving what you've got. Or maybe (painful truth coming up) your product is not that compelling, or times change and your users leave, and you discover you never actually need to scale to the giddy heights originally envisioned. A big part of the reason modern web dev is so messed up is that lots of developers starting thinking every app they built needed to be "web scale" from day one. SQL databases? Pah. Doesn't scale. Think big. We gotta no NoSQL sharded key/value store from the start! Otherwise we're just showing lack of confidence in our own product. Then when they used up all their budget solving consistency bugs a relational database would have avoided, they notice their competitors sailing past them on a not-fully-scalable but certainly-scalable-enough architecture that let them focus on features and making users happy. > I am referring to global bandwidth O(n^2) with n=users 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. > There can be a case for some increase to create some breathing room to > work on scaling and decentralising tech, I just mean to say that if we > do it in isolation, we're not focussing on the big picture. Alright - let's agree that we disagree on a few areas, like the relative desirability of alternative non-blockchain designs - but we do seem to agree that there is a case for an increase in the block size limit. That seems like progress. As you agree with that, what sort of schedule and time are you thinking of? (well, by "you" I really mean blockstream because it's taking forever to try and negotiate with every single person individually). [-- Attachment #2: Type: text/html, Size: 5392 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] comments on BIP 100 2015-06-15 9:27 ` Mike Hearn @ 2015-06-15 10:24 ` Pieter Wuille 2015-06-15 10:36 ` Mike Hearn 0 siblings, 1 reply; 17+ messages in thread From: Pieter Wuille @ 2015-06-15 10:24 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1925 bytes --] On Mon, Jun 15, 2015 at 11:27 AM, Mike Hearn <mike@plan99•net> wrote: > I persevered for several months to add a very small "API" I needed for my > app to Bitcoin Core, and it was in the end a waste of time. There are no > actionable items left for the getutxo patch, regardless, I had to fork > Bitcoin to get it out there. It would have been *much* easier to just > say, fuck it, I'll use blockchain.info and in fact some in this community > told me to do exactly that. But, the approach I chose has been working fine > for months now. > Since you keep bringing this up, I'll try to clarify this once again. Since your patch was to enable querying spentness of particular outputs, which is fundamentally unprovable data in Bitcoin as is (even your proposed protocol that verifies scripts with amounts under sighash only proves correctness of the txout data, not its spentness), I indeed don't see why you would want anything else than querying such a service. I wish it were different, but the choice is between querying a central service, or trusting something a random peer on the internet tells you. At least with the central service you can use an authenticated protocol with known keys to detect MITM, and have someone to point to when they lie. Not decentralized you say? Absolutely. But why do we want decentralization in the first place? To remove central points of failure, and to reduce trust. Bitcoin gets away with decentralization because it can validate (to more or lesser extent) the data it received from its identityless peers. If you can't do that, and are just aiming for removing central points of failure, run a bunch of servers yourself, and let others run their own. That sounds remarkably close to what you actually did, actually... Do you want actually trustless querying of spentness in the future? Help working on one of the several TXO commitment ideas to get them implemented. -- Pieter [-- Attachment #2: Type: text/html, Size: 2507 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] comments on BIP 100 2015-06-15 10:24 ` Pieter Wuille @ 2015-06-15 10:36 ` Mike Hearn 2015-06-15 10:40 ` Pieter Wuille 0 siblings, 1 reply; 17+ messages in thread From: Mike Hearn @ 2015-06-15 10:36 UTC (permalink / raw) To: Pieter Wuille; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2452 bytes --] > > Since you keep bringing this up, I'll try to clarify this once again. > I understand the arguments against it. And I think you are agreeing with me - Adam is bemoaning the way developers outsource stuff to third party services, and suggesting it is relevant to the block size debate. And we are saying, no, it's happening because it's easier than doing things in a decentralised way. > If you can't do that, and are just aiming for removing central points of > failure, run a bunch of servers yourself, and let others run their own. > That sounds remarkably close to what you actually did, actually... > Right. There's a deeper issue here. The sort of 'trustless' querying of the UTXO set that was demanded from me is impossible even with commitments, because the answer can change the moment you receive it. All it takes is a new block or new transaction to be broadcast a split second after you download and use the data, and suddenly what you did is incorrect no matter how many proofs you verified! The only way to know this has happened is to be a full node and download all transactions yourself ... and even then, you are trusting your peers to actually relay you all transactions and not a subset. So in the end you can never achieve perfection, only get closer to it. But that situation is *fine* for many use cases, like showing someone a snapshot of their crowdfund in a user interface. We just accept that what we see on the screen may lag behind reality. It happens all the time with all kinds of non-Bitcoin apps. We accept that there may be cases where the answer we get is wrong. The software can nevertheless still be useful. So Lighthouse compromises. It queries multiple peers and cross-references their answers. If their answers don't match it shows an error on the screen and won't show the user any status for their crowdfund at all. This error has never occurred. Maybe one day it will. So the app gets more decentralisation, more robustness, and accepts that the user interface might one day show a wrong answer if the P2P network starts lying (or your internet connection is hacked, but the right fix for that is P2P encryption). Unfortunately this sort of balance-of-risks approach is considered a non-starter in Bitcoin Core. So why would developers even try? The message sent was clear: even if you have an approach you think will work, don't bother. Much easier to just outsource to a trusted service indeed. [-- Attachment #2: Type: text/html, Size: 3189 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] comments on BIP 100 2015-06-15 10:36 ` Mike Hearn @ 2015-06-15 10:40 ` Pieter Wuille 2015-06-15 10:50 ` Mike Hearn 0 siblings, 1 reply; 17+ messages in thread From: Pieter Wuille @ 2015-06-15 10:40 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 790 bytes --] On Mon, Jun 15, 2015 at 12:36 PM, Mike Hearn <mike@plan99•net> wrote: > > Since you keep bringing this up, I'll try to clarify this once again. >> > > I understand the arguments against it. And I think you are agreeing with > me - Adam is bemoaning the way developers outsource stuff to third party > services, and suggesting it is relevant to the block size debate. And we > are saying, no, it's happening because it's easier than doing things in a > decentralised way. > The fact that using a centralized service is easier isn't a good reason IMHO. It disregards the long-term, and introduces systemic risk. 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. -- Pieter [-- Attachment #2: Type: text/html, Size: 1498 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] comments on BIP 100 2015-06-15 10:40 ` Pieter Wuille @ 2015-06-15 10:50 ` Mike Hearn 2015-06-15 11:16 ` Rebroad (sourceforge) 0 siblings, 1 reply; 17+ messages in thread From: Mike Hearn @ 2015-06-15 10:50 UTC (permalink / raw) To: Pieter Wuille; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1510 bytes --] > > 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 ... [-- Attachment #2: Type: text/html, Size: 2164 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] comments on BIP 100 2015-06-15 10:50 ` Mike Hearn @ 2015-06-15 11:16 ` Rebroad (sourceforge) 2015-06-15 17:53 ` Raystonn . 0 siblings, 1 reply; 17+ messages in thread From: Rebroad (sourceforge) @ 2015-06-15 11:16 UTC (permalink / raw) Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 4025 bytes --] 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 <mike@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 > > [-- Attachment #2: Type: text/html, Size: 6124 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] comments on BIP 100 2015-06-15 11:16 ` Rebroad (sourceforge) @ 2015-06-15 17:53 ` Raystonn . 2015-06-15 18:14 ` Adam Back 0 siblings, 1 reply; 17+ messages in thread From: Raystonn . @ 2015-06-15 17:53 UTC (permalink / raw) To: Rebroad (sourceforge); +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 4890 bytes --] > 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 <mike@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 -------------------------------------------------------------------------------- ------------------------------------------------------------------------------ -------------------------------------------------------------------------------- _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists•sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development [-- Attachment #2: Type: text/html, Size: 8033 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] comments on BIP 100 2015-06-15 17:53 ` Raystonn . @ 2015-06-15 18:14 ` Adam Back 2015-06-15 18:57 ` [Bitcoin-development] The Bitcoin Node Market Raystonn . 0 siblings, 1 reply; 17+ messages in thread From: Adam Back @ 2015-06-15 18:14 UTC (permalink / raw) To: Raystonn .; +Cc: Bitcoin Dev 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 . <raystonn@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 <mike@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 >> > > > ________________________________ > ------------------------------------------------------------------------------ > > ________________________________ > _______________________________________________ > 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 > ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bitcoin-development] The Bitcoin Node Market 2015-06-15 18:14 ` Adam Back @ 2015-06-15 18:57 ` Raystonn . 2015-06-15 19:18 ` sickpig 0 siblings, 1 reply; 17+ messages in thread From: Raystonn . @ 2015-06-15 18:57 UTC (permalink / raw) To: Bitcoin Dev 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] The Bitcoin Node Market 2015-06-15 18:57 ` [Bitcoin-development] The Bitcoin Node Market Raystonn . @ 2015-06-15 19:18 ` sickpig 2015-06-15 19:36 ` Raystonn . 0 siblings, 1 reply; 17+ messages in thread From: sickpig @ 2015-06-15 19:18 UTC (permalink / raw) To: Raystonn .; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2298 bytes --] Sorry for top posting and the brevity but I'm typing from my phone You shoud be interested in this post by Justus Ranvier then: https://bitcoinism.liberty.me/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/ On Jun 15, 2015 8:57 PM, "Raystonn ." <raystonn@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 > [-- Attachment #2: Type: text/html, Size: 2992 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] The Bitcoin Node Market 2015-06-15 19:18 ` sickpig @ 2015-06-15 19:36 ` Raystonn . 2015-06-15 20:12 ` sickpig 0 siblings, 1 reply; 17+ messages in thread From: Raystonn . @ 2015-06-15 19:36 UTC (permalink / raw) To: sickpig; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2658 bytes --] 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? From: sickpig@gmail•com Sent: Monday, June 15, 2015 12:18 PM To: Raystonn . Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] The Bitcoin Node Market Sorry for top posting and the brevity but I'm typing from my phone You shoud be interested in this post by Justus Ranvier then: https://bitcoinism.liberty.me/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/ On Jun 15, 2015 8:57 PM, "Raystonn ." <raystonn@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 [-- Attachment #2: Type: text/html, Size: 4372 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] The Bitcoin Node Market 2015-06-15 19:36 ` Raystonn . @ 2015-06-15 20:12 ` sickpig 2015-06-16 3:30 ` Kevin Greene 0 siblings, 1 reply; 17+ messages in thread From: sickpig @ 2015-06-15 20:12 UTC (permalink / raw) To: Raystonn .; +Cc: Bitcoin Dev Hi Raystonn On Mon, Jun 15, 2015 at 9:36 PM, Raystonn . <raystonn@hotmail•com> wrote: > > I am only partially through the content at the below link, and I am very impressed. Has Justus Ranvier began work on implementation of the ideas contained therein? I don't know if he or someone else has begun writing code to implement what was described in the liked post, but I'm sure he will reply to you since he's subscribed to this mailing list. > > > > From: sickpig@gmail•com > Sent: Monday, June 15, 2015 12:18 PM > To: Raystonn . > Cc: Bitcoin Dev > Subject: Re: [Bitcoin-development] The Bitcoin Node Market > > > Sorry for top posting and the brevity but I'm typing from my phone > > You shoud be interested in this post by Justus Ranvier then: > > https://bitcoinism.liberty.me/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/ > > On Jun 15, 2015 8:57 PM, "Raystonn ." <raystonn@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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] The Bitcoin Node Market 2015-06-15 20:12 ` sickpig @ 2015-06-16 3:30 ` Kevin Greene 2015-06-16 3:41 ` Luke Dashjr 0 siblings, 1 reply; 17+ messages in thread From: Kevin Greene @ 2015-06-16 3:30 UTC (permalink / raw) To: sickpig; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 4280 bytes --] Would SPV wallets have to pay to connect to the network too? From the user's perspective, it would be somewhat upsetting (and confusing) to see your balance slowly draining every time you open your wallet app. It would also tie up outputs every time you open up your wallet. You may go to pay for something in a coffee shop, only to find that you can't spend your bitcoin because the wallet had to create a transaction to pay to sync with the network. Also, users of centralized wallet services like Coinbase would not have to pay that fee; but users of native wallets like breadwallet would have no such option. This incentivizes users to use centralized wallets. So this is kind of imposing a worse user experience on users who want to use bitcoin the "right" way. That doesn't seem like a good thing to me :/ On Mon, Jun 15, 2015 at 1:12 PM, sickpig@gmail•com <sickpig@gmail•com> wrote: > Hi Raystonn > > On Mon, Jun 15, 2015 at 9:36 PM, Raystonn . <raystonn@hotmail•com> wrote: > > > > I am only partially through the content at the below link, and I am very > impressed. Has Justus Ranvier began work on implementation of the ideas > contained therein? > > I don't know if he or someone else has begun writing code to implement > what was described in the liked post, but I'm sure he will reply to > you since he's subscribed to this mailing list. > > > > > > > > > > From: sickpig@gmail•com > > Sent: Monday, June 15, 2015 12:18 PM > > To: Raystonn . > > Cc: Bitcoin Dev > > Subject: Re: [Bitcoin-development] The Bitcoin Node Market > > > > > > Sorry for top posting and the brevity but I'm typing from my phone > > > > You shoud be interested in this post by Justus Ranvier then: > > > > > https://bitcoinism.liberty.me/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/ > > > > On Jun 15, 2015 8:57 PM, "Raystonn ." <raystonn@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 > [-- Attachment #2: Type: text/html, Size: 6122 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] The Bitcoin Node Market 2015-06-16 3:30 ` Kevin Greene @ 2015-06-16 3:41 ` Luke Dashjr 2015-06-16 3:49 ` Kevin Greene 0 siblings, 1 reply; 17+ messages in thread From: Luke Dashjr @ 2015-06-16 3:41 UTC (permalink / raw) To: bitcoin-development 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] The Bitcoin Node Market 2015-06-16 3:41 ` Luke Dashjr @ 2015-06-16 3:49 ` Kevin Greene 2015-06-16 4:05 ` Kevin Greene ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Kevin Greene @ 2015-06-16 3:49 UTC (permalink / raw) To: Luke Dashjr; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1628 bytes --] 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 > > 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 > [-- Attachment #2: Type: text/html, Size: 2394 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] The Bitcoin Node Market 2015-06-16 3:49 ` Kevin Greene @ 2015-06-16 4:05 ` Kevin Greene 2015-06-16 4:12 ` Aaron Voisine 2015-06-16 5:28 ` justusranvier 2 siblings, 0 replies; 17+ messages in thread From: Kevin Greene @ 2015-06-16 4:05 UTC (permalink / raw) To: Luke Dashjr; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2881 bytes --] Just thinking off the top of my head here: What if SPV wallets were exempt from the fee? Only full nodes would pay other full nodes when initially sync'ing the blockchain. Then as long as you keep your full node running for a long period of time, you'll eventually make back the cost you paid to sync initially. This at least incentives full node operators to keep their node running for as long as possible once started. This still imposes a worse UX on casual users who want full node security, but don't want to run a server 24/7 (or perhaps simply aren't aware that they have to). These users will watch their balance wither away each time they open their wallet, but it would be very difficult to explain to them why that is happening. It would just be frustrating and confusing. Also, what happens when a user runs Bitcoin-QT for the first time after downloading it to try it out? They wouldn't be able to sync the blockchain. Even if the wallet has a balance, how would the wallet be able to see that it has UTXO's without the ability to sync with the network for free? On Mon, Jun 15, 2015 at 8:49 PM, Kevin Greene <kgreenek@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 >> > 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 >> > > [-- Attachment #2: Type: text/html, Size: 4337 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] The Bitcoin Node Market 2015-06-16 3:49 ` Kevin Greene 2015-06-16 4:05 ` Kevin Greene @ 2015-06-16 4:12 ` Aaron Voisine 2015-06-16 5:28 ` justusranvier 2 siblings, 0 replies; 17+ messages in thread From: Aaron Voisine @ 2015-06-16 4:12 UTC (permalink / raw) To: Kevin Greene; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2452 bytes --] We're planning to run our own full nodes to take load off the volunteer network as breadwallet use increases, and also contribute any SPV serving performance optimizations we can make to bitcoin-core. Just want to let people know we share these concerns and have plans to mitigate any negative impact on the network. Aaron Voisine co-founder and CEO breadwallet.com On Mon, Jun 15, 2015 at 8:49 PM, Kevin Greene <kgreenek@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 >> > 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 > > [-- Attachment #2: Type: text/html, Size: 3829 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] The Bitcoin Node Market 2015-06-16 3:49 ` Kevin Greene 2015-06-16 4:05 ` Kevin Greene 2015-06-16 4:12 ` Aaron Voisine @ 2015-06-16 5:28 ` justusranvier 2015-06-16 5:30 ` Potter QQ 2015-06-16 7:55 ` Aaron Voisine 2 siblings, 2 replies; 17+ messages in thread From: justusranvier @ 2015-06-16 5:28 UTC (permalink / raw) To: Kevin Greene; +Cc: Bitcoin Dev 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] The Bitcoin Node Market 2015-06-16 5:28 ` justusranvier @ 2015-06-16 5:30 ` Potter QQ 2015-06-16 7:55 ` Aaron Voisine 1 sibling, 0 replies; 17+ messages in thread From: Potter QQ @ 2015-06-16 5:30 UTC (permalink / raw) To: justusranvier; +Cc: Bitcoin Dev No,Bitcoin 发自我的 iPhone > 在 2015年6月16日，13:28，justusranvier@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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] The Bitcoin Node Market 2015-06-16 5:28 ` justusranvier 2015-06-16 5:30 ` Potter QQ @ 2015-06-16 7:55 ` Aaron Voisine 2015-06-16 13:32 ` justusranvier 2015-06-16 15:52 ` devrandom 1 sibling, 2 replies; 17+ messages in thread From: Aaron Voisine @ 2015-06-16 7:55 UTC (permalink / raw) To: Justus Ranvier; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1800 bytes --] > Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who > would provide the nodes they would need connect to? The SPV wallet author would if they wanted their wallet to function. Aaron Voisine co-founder and CEO breadwallet.com On Mon, Jun 15, 2015 at 10:28 PM, <justusranvier@riseup•net> wrote: > 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 > [-- Attachment #2: Type: text/html, Size: 2955 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] The Bitcoin Node Market 2015-06-16 7:55 ` Aaron Voisine @ 2015-06-16 13:32 ` justusranvier 2015-06-16 17:04 ` Aaron Voisine 2015-06-16 17:22 ` Aaron Voisine 2015-06-16 15:52 ` devrandom 1 sibling, 2 replies; 17+ messages in thread From: justusranvier @ 2015-06-16 13:32 UTC (permalink / raw) To: Aaron Voisine; +Cc: Bitcoin Dev On 2015-06-16 07:55, Aaron Voisine wrote: >> Suppose a billion mobile phones wanted to run SPV wallets tomorrow. >> Who >> would provide the nodes they would need connect to? > > The SPV wallet author would if they wanted their wallet to function. How will the SPV wallet users pay for this service? With their money, or with their privacy? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] The Bitcoin Node Market 2015-06-16 13:32 ` justusranvier @ 2015-06-16 17:04 ` Aaron Voisine 2015-06-16 17:22 ` Aaron Voisine 1 sibling, 0 replies; 17+ messages in thread From: Aaron Voisine @ 2015-06-16 17:04 UTC (permalink / raw) To: justusranvier; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 631 bytes --] With their money, if they were to take advantage of optional additional financial services, like, as one example, comsumer protection insurance. Aaron On Tuesday, June 16, 2015, <justusranvier@riseup•net> wrote: > On 2015-06-16 07:55, Aaron Voisine wrote: > >> Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who >>> would provide the nodes they would need connect to? >>> >> >> The SPV wallet author would if they wanted their wallet to function. >> > > How will the SPV wallet users pay for this service? With their money, or > with their privacy? > -- Aaron Voisine co-founder and CEO breadwallet.com [-- Attachment #2: Type: text/html, Size: 1232 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] The Bitcoin Node Market 2015-06-16 13:32 ` justusranvier 2015-06-16 17:04 ` Aaron Voisine @ 2015-06-16 17:22 ` Aaron Voisine 1 sibling, 0 replies; 17+ messages in thread From: Aaron Voisine @ 2015-06-16 17:22 UTC (permalink / raw) To: justusranvier; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 745 bytes --] Alternate funding strategy: With 1billion users, mr roger ver is now among the worlds first $trillionaires, and he generously donates to the non-profit organization responsible for both the wildly popular wallet, and his new found largess. On Tuesday, June 16, 2015, justusranvier@riseup•net < justusranvier@riseup•net> wrote: > On 2015-06-16 07:55, Aaron Voisine wrote: > >> Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who >>> would provide the nodes they would need connect to? >>> >> >> The SPV wallet author would if they wanted their wallet to function. >> > > How will the SPV wallet users pay for this service? With their money, or > with their privacy? > -- Aaron Voisine co-founder and CEO breadwallet.com [-- Attachment #2: Type: text/html, Size: 1368 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] The Bitcoin Node Market 2015-06-16 7:55 ` Aaron Voisine 2015-06-16 13:32 ` justusranvier @ 2015-06-16 15:52 ` devrandom 1 sibling, 0 replies; 17+ messages in thread From: devrandom @ 2015-06-16 15:52 UTC (permalink / raw) To: Aaron Voisine, Justus Ranvier; +Cc: Bitcoin Dev On 2015-06-16 12:55 AM, Aaron Voisine wrote: >> Suppose a billion mobile phones wanted to run SPV wallets tomorrow. Who >> would provide the nodes they would need connect to? > > The SPV wallet author would if they wanted their wallet to function. I would also guess that the cost to provide service to SPV wallets is less than $0.01/mo per wallet and in any case less than long-term transaction fees. This can either be taken up by the wallet author or transparently through a payment channel by the user. > > > Aaron Voisine > co-founder and CEO > breadwallet.com <http://breadwallet.com> -- devrandom / Miron ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2015-06-16 17:23 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-06-16 4:38 [Bitcoin-development] The Bitcoin Node Market Raystonn -- strict thread matches above, loose matches on Subject: below -- 2015-06-14 21:23 [Bitcoin-development] comments on BIP 100 Adam Back 2015-06-14 22:23 ` Mike Hearn 2015-06-14 23:58 ` Adam Back 2015-06-15 9:27 ` Mike Hearn 2015-06-15 10:24 ` Pieter Wuille 2015-06-15 10:36 ` Mike Hearn 2015-06-15 10:40 ` Pieter Wuille 2015-06-15 10:50 ` Mike Hearn 2015-06-15 11:16 ` Rebroad (sourceforge) 2015-06-15 17:53 ` Raystonn . 2015-06-15 18:14 ` Adam Back 2015-06-15 18:57 ` [Bitcoin-development] The Bitcoin Node Market Raystonn . 2015-06-15 19:18 ` sickpig 2015-06-15 19:36 ` Raystonn . 2015-06-15 20:12 ` sickpig 2015-06-16 3:30 ` Kevin Greene 2015-06-16 3:41 ` Luke Dashjr 2015-06-16 3:49 ` Kevin Greene 2015-06-16 4:05 ` Kevin Greene 2015-06-16 4:12 ` Aaron Voisine 2015-06-16 5:28 ` justusranvier 2015-06-16 5:30 ` Potter QQ 2015-06-16 7:55 ` Aaron Voisine 2015-06-16 13:32 ` justusranvier 2015-06-16 17:04 ` Aaron Voisine 2015-06-16 17:22 ` Aaron Voisine 2015-06-16 15:52 ` devrandom
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox