* [bitcoin-dev] Scaling Bitcoin conference micro-report @ 2015-09-16 21:32 Jeff Garzik 2015-09-16 21:51 ` Matt Corallo 0 siblings, 1 reply; 46+ messages in thread From: Jeff Garzik @ 2015-09-16 21:32 UTC (permalink / raw) To: Bitcoin development mailing list [-- Attachment #1: Type: text/plain, Size: 2070 bytes --] During Scaling Bitcoin, Bitcoin Core committers and notable contributors got together and chatted about where a "greatest common denominator" type consensus might be. The following is a without-attribution (Chatham House) summary. This is my own personal summary of the chat; any errors are my own; this is _not_ a consensus statement or anything formal. - Background (pre-conference, was on public IRC): "net-utxo", calculating transaction size within block by applying a delta to transaction size based on the amount of data added, or removed, from the UTXO set. Fee is then evaluated after the delta is applied. This aligns user incentives with UTXO resource usage/cost. Original idea by gmaxwell (and others??). - Many interested or at least willing to accept a "short term bump", a hard fork to modify block size limit regime to be cost-based via "net-utxo" rather than a simple static hard limit. 2-4-8 and 17%/year were debated and seemed "in range" with what might work as a short term bump - net after applying the new cost metric. - Hard fork method: Leaning towards "if (timestamp > X)" flag day hard fork Y months in the future. Set high bit in version, resulting in a negative number, to more cleanly fork away. "miner advisement" - miners, as they've done recently, signal non-binding (Bitcoin Core does not examine the value) engineering readiness for a hard fork via coinbase moniker. Some fork cancellation method is useful, if unsuccessful after Z time elapses. - As discussed publicly elsewhere, other forks may be signaled via setting a bit in version, and then triggering a fork'ing change once a threshold is reached. Chat participants are invited to reply to this message with their own corrections and comments and summary in their view. For the wider community, take this as one of many "inputs" described at Scaling Bitcoin. Over the next few months developers and the community should evaluate everything discussed and work towards some concrete proposal(s) that are implemented, tested and simulated in December in Hong Kong. [-- Attachment #2: Type: text/html, Size: 2724 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-16 21:32 [bitcoin-dev] Scaling Bitcoin conference micro-report Jeff Garzik @ 2015-09-16 21:51 ` Matt Corallo 2015-09-18 5:55 ` Mark Friedenbach 0 siblings, 1 reply; 46+ messages in thread From: Matt Corallo @ 2015-09-16 21:51 UTC (permalink / raw) To: Jeff Garzik, Bitcoin development mailing list I only have one "correction", included inline. On 09/16/15 21:32, Jeff Garzik via bitcoin-dev wrote: > > During Scaling Bitcoin, Bitcoin Core committers and notable contributors > got together and chatted about where a "greatest common denominator" > type consensus might be. The following is a without-attribution > (Chatham House) summary. This is my own personal summary of the chat; > any errors are my own; this is _not_ a consensus statement or anything > formal. > > - Background (pre-conference, was on public IRC): "net-utxo", > calculating transaction size within block by applying a delta to > transaction size based on the amount of data added, or removed, from the > UTXO set. Fee is then evaluated after the delta is applied. This > aligns user incentives with UTXO resource usage/cost. Original idea by > gmaxwell (and others??). > > - Many interested or at least willing to accept a "short term bump", a > hard fork to modify block size limit regime to be cost-based via > "net-utxo" rather than a simple static hard limit. 2-4-8 and 17%/year > were debated and seemed "in range" with what might work as a short term > bump - net after applying the new cost metric. I would be careful to point out that hard numbers were deliberately NOT discussed. Though some general things were thrown out, they were not extensively discussed nor agreed to. I personally think 2-4 is "in range", though 8 maybe not so much. Of course it depends on exactly how the non-blocksize limit accounting/adjusting is done. Still, the "greatest common denominator" agreement did not seem to be agreeing to an increase which continues over time, but which instead limits itself to a set, smooth increase for X time and then requires a second hardfork if there is agreement on a need for more blocksize at that point. > - Hard fork method: Leaning towards "if (timestamp > X)" flag day hard > fork Y months in the future. Set high bit in version, resulting in a > negative number, to more cleanly fork away. "miner advisement" - > miners, as they've done recently, signal non-binding (Bitcoin Core does > not examine the value) engineering readiness for a hard fork via > coinbase moniker. Some fork cancellation method is useful, if > unsuccessful after Z time elapses. > > - As discussed publicly elsewhere, other forks may be signaled via > setting a bit in version, and then triggering a fork'ing change once a > threshold is reached. > > Chat participants are invited to reply to this message with their own > corrections and comments and summary in their view. > > For the wider community, take this as one of many "inputs" described at > Scaling Bitcoin. Over the next few months developers and the community > should evaluate everything discussed and work towards some concrete > proposal(s) that are implemented, tested and simulated in December in > Hong Kong. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-16 21:51 ` Matt Corallo @ 2015-09-18 5:55 ` Mark Friedenbach 2015-09-18 17:10 ` Dave Scotese ` (2 more replies) 0 siblings, 3 replies; 46+ messages in thread From: Mark Friedenbach @ 2015-09-18 5:55 UTC (permalink / raw) To: Matt Corallo; +Cc: Bitcoin development mailing list [-- Attachment #1: Type: text/plain, Size: 3480 bytes --] Correction of a correction, in-line: On Wed, Sep 16, 2015 at 5:51 PM, Matt Corallo via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > - Many interested or at least willing to accept a "short term bump", a > > hard fork to modify block size limit regime to be cost-based via > > "net-utxo" rather than a simple static hard limit. 2-4-8 and 17%/year > > were debated and seemed "in range" with what might work as a short term > > bump - net after applying the new cost metric. > > I would be careful to point out that hard numbers were deliberately NOT > discussed. Though some general things were thrown out, they were not > extensively discussed nor agreed to. I personally think 2-4 is "in > range", though 8 maybe not so much. Of course it depends on exactly how > the non-blocksize limit accounting/adjusting is done. > > Still, the "greatest common denominator" agreement did not seem to be > agreeing to an increase which continues over time, but which instead > limits itself to a set, smooth increase for X time and then requires a > second hardfork if there is agreement on a need for more blocksize at > that point. > Perhaps it is accurate to say that there wasn't consensus at all except that (1) we think we can work together on resolving this impasse (yay!), and (2) it is conceivable that changing from block size to some other metric might provide the basis for a compromise on near-term numbers. As an example, I do not think the net-UTXO metric provides any benefit with respect to scalability, and in some ways makes the situation worse (even though it helpfully solves an unrelated problem of spammy dust outputs). But there are other possible metrics and I maintain hope that data will show the benefit of another metric or other metrics combined with net-UTXO in a way that will allow us to reach consensus. As a further example, I also am quite concerned about 2-4-8MB with either block size or net-UTXO as the base metric. As you say, it depends on how the non-blocksize limit accounting/adjusting is done... But if a metric were chosen that addressed my concerns (worst case propagation and validation time), then I could be in favor of an initial bump that allowed a larger number of typical transactions in a block. But where I really need to disagree is on the requirement for a 2nd hard fork. I will go on record as being definitively against this. While being conservative with respect to exponentials, I would very much like to make sure that there is a long-term growth curve as part of any proposal. I am willing to accept a hard-fork if the adopted plan is too conservative, but I do not want to be kicking the can down the road to a scheduled 2nd hard fork that absolutely must occur. That, I feel, could be a more dangerous outcome than an exponential that outlasts conservative historical trends. I commend Jeff for writing a Chatham-rules summary of the outcome of some hallway conversations that occurred. On the whole I think his summary does represent the majority view of the opinions expressed by core developers at the workshop. I will caution though that on nearly every issue there were those expressed disagreement but did not fight the issue, and those who said nothing and left unpolled opinions. Nevertheless this summary is informative as it feeds forwards into the design of proposals that will be made prior to the Hong Kong workshop in December, in order that they have a higher likelihood of success. [-- Attachment #2: Type: text/html, Size: 4080 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-18 5:55 ` Mark Friedenbach @ 2015-09-18 17:10 ` Dave Scotese 2015-09-18 17:28 ` Eric Lombrozo 2015-09-18 20:06 ` Matt Corallo 2015-09-18 22:15 ` [bitcoin-dev] Improving Blocksize Communication Through Markets Paul Sztorc 2 siblings, 1 reply; 46+ messages in thread From: Dave Scotese @ 2015-09-18 17:10 UTC (permalink / raw) To: Mark Friedenbach; +Cc: Bitcoin development mailing list [-- Attachment #1: Type: text/plain, Size: 5329 bytes --] "But if a metric were chosen that addressed my concerns (worst case propagation and validation time), then I could be in favor of an initial bump that allowed a larger number of typical transactions in a block." +1. A ratio is much more valuable than a simple metric. It seems clearly difficult to identify a reasonable limit to block size, but the ratio between any one of several possible metrics and bytes in a block would work well and may already have a very good reasonable expected range. I like BTCDaysDestroyed (BTCDD) best. If it might be time consuming to compute, then it need only be computed for all blocks less than or equal in size to the average size of the largest 200 or so blocks in the previous difficulty period. To exceed that limit, a miner would have to ensure that the block has enough BTCDD per byte. "Enough" could be hardcoded in each release, or if it's simple enough, use the ratio as computed over all the blocks in the previous difficulty period as the lower limit. notplato On Thu, Sep 17, 2015 at 10:55 PM, Mark Friedenbach via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Correction of a correction, in-line: > > On Wed, Sep 16, 2015 at 5:51 PM, Matt Corallo via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> > - Many interested or at least willing to accept a "short term bump", a >> > hard fork to modify block size limit regime to be cost-based via >> > "net-utxo" rather than a simple static hard limit. 2-4-8 and 17%/year >> > were debated and seemed "in range" with what might work as a short term >> > bump - net after applying the new cost metric. >> >> I would be careful to point out that hard numbers were deliberately NOT >> discussed. Though some general things were thrown out, they were not >> extensively discussed nor agreed to. I personally think 2-4 is "in >> range", though 8 maybe not so much. Of course it depends on exactly how >> the non-blocksize limit accounting/adjusting is done. >> >> Still, the "greatest common denominator" agreement did not seem to be >> agreeing to an increase which continues over time, but which instead >> limits itself to a set, smooth increase for X time and then requires a >> second hardfork if there is agreement on a need for more blocksize at >> that point. >> > > Perhaps it is accurate to say that there wasn't consensus at all except > that (1) we think we can work together on resolving this impasse (yay!), > and (2) it is conceivable that changing from block size to some other > metric might provide the basis for a compromise on near-term numbers. > > As an example, I do not think the net-UTXO metric provides any benefit > with respect to scalability, and in some ways makes the situation worse > (even though it helpfully solves an unrelated problem of spammy dust > outputs). But there are other possible metrics and I maintain hope that > data will show the benefit of another metric or other metrics combined with > net-UTXO in a way that will allow us to reach consensus. > > As a further example, I also am quite concerned about 2-4-8MB with either > block size or net-UTXO as the base metric. As you say, it depends on how > the non-blocksize limit accounting/adjusting is done... But if a metric > were chosen that addressed my concerns (worst case propagation and > validation time), then I could be in favor of an initial bump that allowed > a larger number of typical transactions in a block. > > But where I really need to disagree is on the requirement for a 2nd hard > fork. I will go on record as being definitively against this. While being > conservative with respect to exponentials, I would very much like to make > sure that there is a long-term growth curve as part of any proposal. I am > willing to accept a hard-fork if the adopted plan is too conservative, but > I do not want to be kicking the can down the road to a scheduled 2nd hard > fork that absolutely must occur. That, I feel, could be a more dangerous > outcome than an exponential that outlasts conservative historical trends. > > I commend Jeff for writing a Chatham-rules summary of the outcome of some > hallway conversations that occurred. On the whole I think his summary does > represent the majority view of the opinions expressed by core developers at > the workshop. I will caution though that on nearly every issue there were > those expressed disagreement but did not fight the issue, and those who > said nothing and left unpolled opinions. Nevertheless this summary is > informative as it feeds forwards into the design of proposals that will be > made prior to the Hong Kong workshop in December, in order that they have a > higher likelihood of success. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > -- I like to provide some work at no charge to prove my value. Do you need a techie? I own Litmocracy <http://www.litmocracy.com> and Meme Racing <http://www.memeracing.net> (in alpha). I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which now accepts Bitcoin. I also code for The Dollar Vigilante <http://dollarvigilante.com/>. "He ought to find it more profitable to play by the rules" - Satoshi Nakamoto [-- Attachment #2: Type: text/html, Size: 6605 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-18 17:10 ` Dave Scotese @ 2015-09-18 17:28 ` Eric Lombrozo 0 siblings, 0 replies; 46+ messages in thread From: Eric Lombrozo @ 2015-09-18 17:28 UTC (permalink / raw) To: Dave Scotese, Dave Scotese via bitcoin-dev, Mark Friedenbach Cc: Bitcoin development mailing list [-- Attachment #1: Type: text/plain, Size: 6320 bytes --] To be quite frank, I'm a little disappointed we've fallen back on arguing over numbers pulled out of a hat rather than discussing far more fundamental issues such as the dev process generally, consensus building, and our basic understanding of what Bitcoin really is, its strengths and weaknesses, where it shows most promise, and communicating a more unified vision to the industry and the public. On September 18, 2015 10:10:08 AM PDT, Dave Scotese via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: >"But if a metric were chosen that addressed my concerns (worst case >propagation and validation time), then I could be in favor of an >initial >bump that allowed a larger number of typical transactions in a block." > >+1. A ratio is much more valuable than a simple metric. It seems >clearly >difficult to identify a reasonable limit to block size, but the ratio >between any one of several possible metrics and bytes in a block would >work >well and may already have a very good reasonable expected range. > >I like BTCDaysDestroyed (BTCDD) best. If it might be time consuming to >compute, then it need only be computed for all blocks less than or >equal in >size to the average size of the largest 200 or so blocks in the >previous >difficulty period. To exceed that limit, a miner would have to ensure >that >the block has enough BTCDD per byte. "Enough" could be hardcoded in >each >release, or if it's simple enough, use the ratio as computed over all >the >blocks in the previous difficulty period as the lower limit. > >notplato > >On Thu, Sep 17, 2015 at 10:55 PM, Mark Friedenbach via bitcoin-dev < >bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Correction of a correction, in-line: >> >> On Wed, Sep 16, 2015 at 5:51 PM, Matt Corallo via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> > - Many interested or at least willing to accept a "short term >bump", a >>> > hard fork to modify block size limit regime to be cost-based via >>> > "net-utxo" rather than a simple static hard limit. 2-4-8 and >17%/year >>> > were debated and seemed "in range" with what might work as a short >term >>> > bump - net after applying the new cost metric. >>> >>> I would be careful to point out that hard numbers were deliberately >NOT >>> discussed. Though some general things were thrown out, they were not >>> extensively discussed nor agreed to. I personally think 2-4 is "in >>> range", though 8 maybe not so much. Of course it depends on exactly >how >>> the non-blocksize limit accounting/adjusting is done. >>> >>> Still, the "greatest common denominator" agreement did not seem to >be >>> agreeing to an increase which continues over time, but which instead >>> limits itself to a set, smooth increase for X time and then requires >a >>> second hardfork if there is agreement on a need for more blocksize >at >>> that point. >>> >> >> Perhaps it is accurate to say that there wasn't consensus at all >except >> that (1) we think we can work together on resolving this impasse >(yay!), >> and (2) it is conceivable that changing from block size to some other >> metric might provide the basis for a compromise on near-term numbers. >> >> As an example, I do not think the net-UTXO metric provides any >benefit >> with respect to scalability, and in some ways makes the situation >worse >> (even though it helpfully solves an unrelated problem of spammy dust >> outputs). But there are other possible metrics and I maintain hope >that >> data will show the benefit of another metric or other metrics >combined with >> net-UTXO in a way that will allow us to reach consensus. >> >> As a further example, I also am quite concerned about 2-4-8MB with >either >> block size or net-UTXO as the base metric. As you say, it depends on >how >> the non-blocksize limit accounting/adjusting is done... But if a >metric >> were chosen that addressed my concerns (worst case propagation and >> validation time), then I could be in favor of an initial bump that >allowed >> a larger number of typical transactions in a block. >> >> But where I really need to disagree is on the requirement for a 2nd >hard >> fork. I will go on record as being definitively against this. While >being >> conservative with respect to exponentials, I would very much like to >make >> sure that there is a long-term growth curve as part of any proposal. >I am >> willing to accept a hard-fork if the adopted plan is too >conservative, but >> I do not want to be kicking the can down the road to a scheduled 2nd >hard >> fork that absolutely must occur. That, I feel, could be a more >dangerous >> outcome than an exponential that outlasts conservative historical >trends. >> >> I commend Jeff for writing a Chatham-rules summary of the outcome of >some >> hallway conversations that occurred. On the whole I think his summary >does >> represent the majority view of the opinions expressed by core >developers at >> the workshop. I will caution though that on nearly every issue there >were >> those expressed disagreement but did not fight the issue, and those >who >> said nothing and left unpolled opinions. Nevertheless this summary is >> informative as it feeds forwards into the design of proposals that >will be >> made prior to the Hong Kong workshop in December, in order that they >have a >> higher likelihood of success. >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > >-- >I like to provide some work at no charge to prove my value. Do you need >a >techie? >I own Litmocracy <http://www.litmocracy.com> and Meme Racing ><http://www.memeracing.net> (in alpha). >I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> >which >now accepts Bitcoin. >I also code for The Dollar Vigilante <http://dollarvigilante.com/>. >"He ought to find it more profitable to play by the rules" - Satoshi >Nakamoto > > >------------------------------------------------------------------------ > >_______________________________________________ >bitcoin-dev mailing list >bitcoin-dev@lists.linuxfoundation.org >https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- Sent from my Android device with K-9 Mail. Please excuse my brevity. [-- Attachment #2: Type: text/html, Size: 6869 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-18 5:55 ` Mark Friedenbach 2015-09-18 17:10 ` Dave Scotese @ 2015-09-18 20:06 ` Matt Corallo 2015-09-18 22:33 ` Mike Hearn 2015-09-19 1:47 ` Peter Todd 2015-09-18 22:15 ` [bitcoin-dev] Improving Blocksize Communication Through Markets Paul Sztorc 2 siblings, 2 replies; 46+ messages in thread From: Matt Corallo @ 2015-09-18 20:06 UTC (permalink / raw) To: Mark Friedenbach; +Cc: Bitcoin development mailing list I did not intend to imply that there was agreement on a desire to schedule a second hardfork. My wording may have been a bit too loose. Instead, I believe there was much agreement that doing a short-term hardfork now, with many agreeing that a second would hopefully be entirely unnecessary/impossible, while others thought that a second would be necessary and would have to happen. While this may set up a similar controversy again in several years, I think everyone agreed that we cannot predict the future and I, personally, think none of us should be committing to a viewpoint for what should be done at that time. Personally, I think it is also critical that there be no messaging that people should rely on or assume there will be a future increase after a short-term bump (which I also do not believe people should be relying on now). Matt On 09/18/15 05:55, Mark Friedenbach wrote: > Correction of a correction, in-line: > > On Wed, Sep 16, 2015 at 5:51 PM, Matt Corallo via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > > > - Many interested or at least willing to accept a "short term bump", a > > hard fork to modify block size limit regime to be cost-based via > > "net-utxo" rather than a simple static hard limit. 2-4-8 and 17%/year > > were debated and seemed "in range" with what might work as a short term > > bump - net after applying the new cost metric. > > I would be careful to point out that hard numbers were deliberately NOT > discussed. Though some general things were thrown out, they were not > extensively discussed nor agreed to. I personally think 2-4 is "in > range", though 8 maybe not so much. Of course it depends on exactly how > the non-blocksize limit accounting/adjusting is done. > > Still, the "greatest common denominator" agreement did not seem to be > agreeing to an increase which continues over time, but which instead > limits itself to a set, smooth increase for X time and then requires a > second hardfork if there is agreement on a need for more blocksize at > that point. > > > Perhaps it is accurate to say that there wasn't consensus at all except > that (1) we think we can work together on resolving this impasse (yay!), > and (2) it is conceivable that changing from block size to some other > metric might provide the basis for a compromise on near-term numbers. > > As an example, I do not think the net-UTXO metric provides any benefit > with respect to scalability, and in some ways makes the situation worse > (even though it helpfully solves an unrelated problem of spammy dust > outputs). But there are other possible metrics and I maintain hope that > data will show the benefit of another metric or other metrics combined > with net-UTXO in a way that will allow us to reach consensus. > > As a further example, I also am quite concerned about 2-4-8MB with > either block size or net-UTXO as the base metric. As you say, it depends > on how the non-blocksize limit accounting/adjusting is done... But if a > metric were chosen that addressed my concerns (worst case propagation > and validation time), then I could be in favor of an initial bump that > allowed a larger number of typical transactions in a block. > > But where I really need to disagree is on the requirement for a 2nd hard > fork. I will go on record as being definitively against this. While > being conservative with respect to exponentials, I would very much like > to make sure that there is a long-term growth curve as part of any > proposal. I am willing to accept a hard-fork if the adopted plan is too > conservative, but I do not want to be kicking the can down the road to a > scheduled 2nd hard fork that absolutely must occur. That, I feel, could > be a more dangerous outcome than an exponential that outlasts > conservative historical trends. > > I commend Jeff for writing a Chatham-rules summary of the outcome of > some hallway conversations that occurred. On the whole I think his > summary does represent the majority view of the opinions expressed by > core developers at the workshop. I will caution though that on nearly > every issue there were those expressed disagreement but did not fight > the issue, and those who said nothing and left unpolled opinions. > Nevertheless this summary is informative as it feeds forwards into the > design of proposals that will be made prior to the Hong Kong workshop in > December, in order that they have a higher likelihood of success. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-18 20:06 ` Matt Corallo @ 2015-09-18 22:33 ` Mike Hearn 2015-09-19 16:03 ` cipher anthem 2015-09-19 1:47 ` Peter Todd 1 sibling, 1 reply; 46+ messages in thread From: Mike Hearn @ 2015-09-18 22:33 UTC (permalink / raw) To: Matt Corallo; +Cc: Bitcoin development mailing list [-- Attachment #1: Type: text/plain, Size: 97 bytes --] Any change that results in this happening all over again in a few years does not have consensus. [-- Attachment #2: Type: text/html, Size: 118 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-18 22:33 ` Mike Hearn @ 2015-09-19 16:03 ` cipher anthem 2015-09-19 20:43 ` Mike Hearn 0 siblings, 1 reply; 46+ messages in thread From: cipher anthem @ 2015-09-19 16:03 UTC (permalink / raw) To: hearn; +Cc: Bitcoin development mailing list [-- Attachment #1: Type: text/html, Size: 1852 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-19 16:03 ` cipher anthem @ 2015-09-19 20:43 ` Mike Hearn 0 siblings, 0 replies; 46+ messages in thread From: Mike Hearn @ 2015-09-19 20:43 UTC (permalink / raw) To: cipher anthem; +Cc: Bitcoin development mailing list [-- Attachment #1: Type: text/plain, Size: 1570 bytes --] > > Let me get this straight. You start this whole debate with a "kick the can > down the road" proposal to increase the block size to 20MB, which obviously > would require another hard fork in the future, but if someone else proposes > a similar "kicka the can" proposal you will outright reject it? > Which part of "in the next few years" was unclear? This seems to be a persistent problem in the block size debates: the assumption that there are only two numbers, zero and infinity. BIP101 tops out at 8 gigabyte blocks, which would represent extremely high transaction rates compared to today. *If* Bitcoin ever became so popular, it would be a long way in the future, and many things could have happened: 1. Bitcoin may have become as irrelevant as the Commodore 64 is. 2. We may have invented upgrades that make Bitcoin 100x more efficient than today. 3. Hardware may have improved so much that it no longer matters. 4. The world may have been devastated by nuclear war and nobody gives a shit about internet currencies anymore, because there is no internet. It's silly to ignore the time dimension in these decisions. Bitcoin will not last forever: even if it becomes very successful it will one day it will be replaced by something better, so it does not have to handle infinite usage. But hey, as you bring it up, I'd have been happy with no upper limit at all. There's nothing magic about 8 gigabytes. I go along with BIP 101 because it is still the only proposal that is both reasonable and implemented, and I'm willing to compromise. [-- Attachment #2: Type: text/html, Size: 2024 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-18 20:06 ` Matt Corallo 2015-09-18 22:33 ` Mike Hearn @ 2015-09-19 1:47 ` Peter Todd 2015-09-19 6:06 ` NxtChg 1 sibling, 1 reply; 46+ messages in thread From: Peter Todd @ 2015-09-19 1:47 UTC (permalink / raw) To: Matt Corallo; +Cc: Bitcoin development mailing list [-- Attachment #1: Type: text/plain, Size: 4314 bytes --] On Fri, Sep 18, 2015 at 08:06:23PM +0000, Matt Corallo via bitcoin-dev wrote: > I did not intend to imply that there was agreement on a desire to > schedule a second hardfork. My wording may have been a bit too loose. > Instead, I believe there was much agreement that doing a short-term > hardfork now, with many agreeing that a second would hopefully be > entirely unnecessary/impossible, while others thought that a second > would be necessary and would have to happen. While this may set up a > similar controversy again in several years, I think everyone agreed that > we cannot predict the future and I, personally, think none of us should > be committing to a viewpoint for what should be done at that time. > > Personally, I think it is also critical that there be no messaging that > people should rely on or assume there will be a future increase after a > short-term bump (which I also do not believe people should be relying on > now). Agreed! We still seem to be in a possition where there is fundemental disagreements about the threat model we should design for, and ultimately, what we want Bitcoin to be. For instance, yesterday I was on a blocksize panel, and Valery Vavilov - CEO of the ASIC manufacturer and miner BitFury - stated that he thought we needed to setup a system of large, high-bandwidth, high-powered, Bitcoin nodes at institutions such as universities and large companies to allow the Bitcoin blocksize to be raised multiple orders of magnitude. (e.g. hundreds of megabytes, or even multiple gigabytes) In discussion with him he seemed to expect that we'd have just a few hundred Bitcoin nodes at most, with SPV being the standard way of using Bitcoin. While to many of us that sounds crazy, if you're threat model assumes Bitcoin is a legal/regulated service provided by a highly trusted mining community it's a reasonable design. Mike Hearn recently posted his threat model, which specifically argues we should assume governments are not a threat. (and Hearn has previously argued that the design of Bitcoin assumes a majority of miners are "honest" rather than merely economically rational) Similarly Gavin Andresen was also on that panel, and stated that he believes the idea that Bitcoin has O(n^2) scaling is wrong, implying he doesn't think a large % of the Bitcoin user base will continue to run fully validating nodes. (note that there are other possibilities he could be referring to here, although again with different security assumptions and/or unproven tech) The main objection I raised during the committer/contributor discussions to the idea of a "short term bump" was messaging. I think it's fair to say that nearly all the support for a small blocksize increase stemmed from the (perceived) need to give Bitcoin users and Bitcoin infrastructure some more time to adapt to a world where the blocksize does not grow sufficiently to meet demand, resulting in higher transaction fees and the practical requirement to use the Bitcoin blockchain more efficiently. (or of course the development of genuinely scalable blockchain technology) With that in mind, it's important that we properly communicate that fact, or as Hearn replied, we'll run into the same problem all over again in a few years, but with even less safety margin in the system. My second objection was one of science. Any bump should be accompanied by some kind of model describing scientifically what we were trying to achieve and where the numbers chosen came from. For instance, Pieter Wuille's BIP103 proposes 17% per year based on a bandwidth growth model, the assumption that bandwidth is the bottleneck we're trying to keep constant, and the design criteria to keep centralization roughly constant. (all else being equal) Sure there's lots of potential flaws in that proposal, but the _message_ that we're basing it on science rather than political "horse-trading" is very important. As for the disagreements, it's quite likely that we can't come to genuine consensus in the fact of those fundemental disagreements about what Bitcoin should be. I don't have any good way to resolve that, and I'm open to suggestions! -- 'peter'[:-1]@petertodd.org 000000000000000000da942d1651d405c157821a3fa55bd0c11cd9b39321e574 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-19 1:47 ` Peter Todd @ 2015-09-19 6:06 ` NxtChg 2015-09-19 6:56 ` Eric Voskuil 0 siblings, 1 reply; 46+ messages in thread From: NxtChg @ 2015-09-19 6:06 UTC (permalink / raw) To: Peter Todd, Matt Corallo; +Cc: Bitcoin development mailing list >While to many of us that sounds crazy, if you're threat model assumes >Bitcoin is a legal/regulated service provided by a highly trusted mining >community it's a reasonable design. There is a large, grey area all the way to "legal/regulated service provided by a highly trusted mining community". Painting the worst looking picture is either a defect in thinking or intentional FUD. > Mike Hearn recently posted his threat model, which specifically argues we > should assume governments are not a threat. There are two ways to fight governments: 1. either you become too big to close, so political repercussions become unacceptable 2. or you become too tiny to hunt, in which case you are much better off with a specialized alt-coin, designed specifically for that purpose. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-19 6:06 ` NxtChg @ 2015-09-19 6:56 ` Eric Voskuil 2015-09-19 7:27 ` NxtChg 0 siblings, 1 reply; 46+ messages in thread From: Eric Voskuil @ 2015-09-19 6:56 UTC (permalink / raw) To: NxtChg, Peter Todd, Matt Corallo Cc: Bitcoin development mailing list, Libbitcoin [-- Attachment #1: Type: text/plain, Size: 1893 bytes --] On 09/18/2015 11:06 PM, NxtChg via bitcoin-dev wrote: >> While to many of us that sounds crazy, if you're threat model assumes >> Bitcoin is a legal/regulated service provided by a highly trusted >> mining community it's a reasonable design. > > There is a large, grey area all the way to "legal/regulated service > provided by a highly trusted mining community". Painting the worst > looking picture is either a defect in thinking or intentional FUD. The state is the threat in the Bitcoin threat model. You comments below acknowledge it. The assumption of hostile state actors is the only rational starting point. That which is regulated (and regulatable) in Bitcoin is the attack surface. While of course there are various degrees of weakness, the reference to "legal/regulated service provided by a highly trusted mining" as the threat is by no means irrational or misdirecting. This threat represents the difference between Bitcoin and Fedcoin. I found Mike's threat model downright disturbing. All benefits of Bitcoin arise from its resistance to this threat. Anyone investor in this space should be paying attention... the apparent benefits of Bitcoin will vaporize with regulation. >> Mike Hearn recently posted his threat model, which specifically >> argues we should assume governments are not a threat. > > There are two ways to fight governments: > > 1. either you become too big to close, so political repercussions > become unacceptable This is extremely naive. At a minimum, getting popular/successful (and regulated) is the formula for regulatory capture. > 2. or you become too tiny to hunt, in which case you are much better > off with a specialized alt-coin, designed specifically for that > purpose. I assume you are referring some marginal and largely irrelevant effort. False dichotomy. [cross-posted to libbitcoin] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-19 6:56 ` Eric Voskuil @ 2015-09-19 7:27 ` NxtChg 2015-09-19 7:39 ` Eric Voskuil 0 siblings, 1 reply; 46+ messages in thread From: NxtChg @ 2015-09-19 7:27 UTC (permalink / raw) To: Eric Voskuil, Peter Todd, Matt Corallo Cc: Bitcoin development mailing list, Libbitcoin >The state is the threat in the Bitcoin threat model. You comments below >acknowledge it. The assumption of hostile state actors is the only >rational starting point. That which is regulated (and regulatable) >in Bitcoin is the attack surface. I think, you just proved my point. If your goal is to shrink the attack surface as much as possible, you are better off being a marginalized alt-coin. >This threat represents the difference between Bitcoin and Fedcoin. _This_ is the false dichotomy. There's a range of coins between DarkCoin and FedCoin. >This is extremely naive. At a minimum, getting popular/successful (and regulated) is the formula for regulatory capture. Let me give you an example. Suppose you are a regular guy, say Peter Todd, and you are faced with 10 policemen in anti-riot gear. You can fight them in two ways: 1. become stronger, so you could provide an adequate response, either by turning into Hulk or by getting another 30-50 Peter Todds. 2. lose some fat, learn a few parkour tricks and move around mostly by night behind dumpsters. The worst you can fare is just being Peter Todd with a backpack and an expensive camera on his neck, wandering around the city in daylight. Your vision of Bitcoin is the most vulnerable to government attacks. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-19 7:27 ` NxtChg @ 2015-09-19 7:39 ` Eric Voskuil 2015-09-19 7:57 ` NxtChg 0 siblings, 1 reply; 46+ messages in thread From: Eric Voskuil @ 2015-09-19 7:39 UTC (permalink / raw) To: NxtChg, Peter Todd, Matt Corallo Cc: Bitcoin development mailing list, Libbitcoin [-- Attachment #1: Type: text/plain, Size: 928 bytes --] On 09/19/2015 12:27 AM, NxtChg wrote: >> This is extremely naive. At a minimum, getting popular/successful (and regulated) is the formula for regulatory capture. > > Let me give you an example. > > Suppose you are a regular guy, say Peter Todd, and you are faced with 10 policemen in anti-riot gear. > > You can fight them in two ways: > > 1. become stronger, so you could provide an adequate response, either by turning into Hulk or by getting another 30-50 Peter Todds. Your vision of censorship resistance is to become such a strong central authority that you can resist it in direct physical confrontation. If you succeed at this, you are the threat. > 2. lose some fat, learn a few parkour tricks and move around mostly by night behind dumpsters. And your alternative is to lurk in dark corners. The inability to see another option is the inability to understand what Satoshi created. e [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-19 7:39 ` Eric Voskuil @ 2015-09-19 7:57 ` NxtChg 2015-09-19 8:52 ` Eric Voskuil 0 siblings, 1 reply; 46+ messages in thread From: NxtChg @ 2015-09-19 7:57 UTC (permalink / raw) To: Eric Voskuil, Peter Todd, Matt Corallo Cc: Bitcoin development mailing list, Libbitcoin >Your vision of censorship resistance is to become such a strong >central authority that you can resist it in direct physical confrontation. >If you succeed at this, you are the threat. My vision is a strong _decentralized_ system, which is: a) too important to close, b) able to provide adequate response to governments, like EFF or Google do. Having a substantial attack surface and, at the same time, not having significant power is the worst fighting strategy. It's the "Peter Todd vs 10 cops" scenario. >The inability to see another option is the inability to understand what Satoshi created. So your closing remark is basically, "you're too stupid to understand"? I'll take it. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-19 7:57 ` NxtChg @ 2015-09-19 8:52 ` Eric Voskuil 2015-09-19 13:32 ` NxtChg 2015-09-19 20:57 ` Mike Hearn 0 siblings, 2 replies; 46+ messages in thread From: Eric Voskuil @ 2015-09-19 8:52 UTC (permalink / raw) To: NxtChg, Peter Todd, Matt Corallo Cc: Bitcoin development mailing list, Libbitcoin [-- Attachment #1: Type: text/plain, Size: 1544 bytes --] On 09/19/2015 12:57 AM, NxtChg wrote:> >> Your vision of censorship resistance is to become such a strong >> central authority that you can resist it in direct physical >> confrontation. If you succeed at this, you are the threat. > > My vision is a strong _decentralized_ system, which is: > > a) too important to close, Your argument is that the state is not a threat to a system designed to deprive the state of seigniorage, because the state will see that system as too important? Bitcoin cannot be both decentralized and reliant on being, "too important to close". If it can be closed there is insufficient decentralization. I was concerned that this was going off topic for a technical forum. However this is the central technical issue of Bitcoin. If one does not understand the threat then one cannot model it or design systems to defend against it. On the other hand, this is unfortunately not new territory, so I'll leave it at this, which is also not news to most of us... > b) able to provide adequate response to governments, like EFF or Google do. "The National Security Agency paid millions of dollars to cover the costs of major internet companies involved in the Prism surveillance program after a court ruled that some of the agency's activities were unconstitutional, according to top-secret material passed to the Guardian. The technology companies, which the NSA says includes Google..." http://www.theguardian.com/world/2013/aug/23/nsa-prism-costs-tech-companies-paid e [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-19 8:52 ` Eric Voskuil @ 2015-09-19 13:32 ` NxtChg 2015-09-19 20:57 ` Mike Hearn 1 sibling, 0 replies; 46+ messages in thread From: NxtChg @ 2015-09-19 13:32 UTC (permalink / raw) To: Eric Voskuil, Peter Todd, Matt Corallo Cc: Bitcoin development mailing list, Libbitcoin >Your argument is that the state is not a threat to a system >designed to deprive the state of seigniorage, because the state will see that >system as too important? Well, if you look at governments from the point of youtube illuminati videos, then, yeah, I guess my position would seem a bit off. But in that case no threat model or small blocks are gonna save you. As history shows, even if you go as deep as Dread Pirate Roberts, you will eventually be caught and prosecuted. So start building SilkRoadCoin, which only works via TOR, has ASIC-resistant algorithm and 10 Kb blocks. Then you might have a tiny chance. Most of us subscribed to a global "electronic cash system" and we intend to continue using Bitcoin for that. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-19 8:52 ` Eric Voskuil 2015-09-19 13:32 ` NxtChg @ 2015-09-19 20:57 ` Mike Hearn 2015-09-19 21:53 ` phm 1 sibling, 1 reply; 46+ messages in thread From: Mike Hearn @ 2015-09-19 20:57 UTC (permalink / raw) To: Eric Voskuil; +Cc: Libbitcoin, Bitcoin development mailing list [-- Attachment #1: Type: text/plain, Size: 2605 bytes --] > > Your argument is that the state is not a threat to a system designed to > deprive the state of seigniorage, because the state will see that system > as too important? > And so we get to one of the hearts of the debate. The axiom upon which you and NxtChg disagree is this: he/she believes governments can crush Bitcoin if they want regardless of how decentralised it is, and you don't. If one believes governments have the power to end Bitcoin no matter what, then the only true protection comes from popularity. Governments find it hard to ban things that are wildly popular with their voters. This is the Uber approach: grow fast, annoy governments, but be popular enough that banning you is politically risky. If you don't believe that governments can end Bitcoin because of decentralisation, then the opposite conclusion is logical: growth can be dangerous because stateless money will be inherently opposed by the state, therefore if growth == less decentralisation, growth increases the risk of state shutdown. I don't think we have to choose between decentralisation and growth actually - computers are just amazingly fast. But that's irrelevant here. The point is, your disagreement is summed up by your statement: > Bitcoin cannot be both decentralized and reliant on being, "too important > to close". If it can be closed there is insufficient decentralization. > I believe this statement is wrong because governments can shut down Bitcoin at any point regardless of its level of decentralisation. This is true because: - Most governments can easily spend enough money to do a 51% attack, especially if they can compel chip fabs to cooperate for free. This attack works regardless of how decentralised Bitcoin is. - Any government can end Bitcoin usage in its territory by jailing anyone who advertises acceptance/trading of bitcoins, or prices in BTC. Because merchants *must* advertise in order to alert customers that trades in BTC are possible, this is an attack which is unsolvable. If ordinary people can find such merchants so can government agents. It may appear that trade cannot be suppressed because merchants can all become anonymous too, a la Silk Road. However, if use of Bitcoin is banned then it becomes impossible to convert coins into local currency as that requires cooperation of banks ..... making it useless for even anonymous merchants. An outlaw currency is useless even to outlaws. Because Bitcoin's existence ultimately relies on government cooperation and acceptance, the best way to ensure its survival is growth. Lots of it. [-- Attachment #2: Type: text/html, Size: 3188 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-19 20:57 ` Mike Hearn @ 2015-09-19 21:53 ` phm 2015-09-20 1:26 ` Dave Scotese ` (2 more replies) 0 siblings, 3 replies; 46+ messages in thread From: phm @ 2015-09-19 21:53 UTC (permalink / raw) To: bitcoin-dev Mike Hearn via bitcoin-dev wrote: > Governments find it hard to ban things that are wildly popular with > their voters. This is the Uber approach: grow fast, annoy governments, > but be popular enough that banning you is politically risky. Governments do not find it hard to ban things that threaten their authority, least of all their authority to control money, and they also do not find it hard to ban things which are popular. I'm sure the millions of people with felony drug charges for the possession of marijuana, a plant, understand this better than you appear to. Also, in the US, despite overwhelming resistance on a broad scale, legislation continues to be presented which would violate the 2nd amendment right to keep and bear arms. Bitcoin does not enjoy nearly the popularity that marijuana and guns do, and likely never may. But even if it did, the government can be relied on to outlaw it once it understands the true extent to which Bitcoin can undermine its ability to control stores of value. A mining network that anyone can contribute to would enable Bitcoin to stay alive in spite of this, much like torrents have enabled people to continue pirating music regardless of how many websites have been taken down. > > If you don't believe that governments can end Bitcoin because of > decentralisation, then the opposite conclusion is logical: growth can > be dangerous because stateless money will be inherently opposed by the > state, therefore if growth == less decentralisation, growth increases > the risk of state shutdown. I think there's a difference between natural growth and the kind of growth that's being proposed by bank-backed start-ups and pro-censorship entities. > > I don't think we have to choose between decentralisation and growth > actually - computers are just amazingly fast. But that's irrelevant here. > > The point is, your disagreement is summed up by your statement: > > > Bitcoin cannot be both decentralized and reliant on being, > "too important to close". If it can be closed there is > insufficient decentralization. > > > I believe this statement is wrong because governments can shut down > Bitcoin at any point regardless of its level of decentralisation. This > is true because: > > * Most governments can easily spend enough money to do a 51% attack, > especially if they can compel chip fabs to cooperate for free. > This attack works regardless of how decentralised Bitcoin is. > > * Any government can end Bitcoin usage in its territory by jailing > anyone who advertises acceptance/trading of bitcoins, or prices in > BTC. Because merchants /must/ advertise in order to alert > customers that trades in BTC are possible, this is an attack which > is unsolvable. If ordinary people can find such merchants so can > government agents. > > It may appear that trade cannot be suppressed because merchants can > all become anonymous too, a la Silk Road. However, if use of Bitcoin > is banned then it becomes impossible to convert coins into local > currency as that requires cooperation of banks ..... making it useless > for even anonymous merchants. An outlaw currency is useless even to > outlaws. A ban on Bitcoin would lead to a rise in p2p markets. The government is an inefficient sinkhole at its very best and it has never successfully eradicated anything. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-19 21:53 ` phm @ 2015-09-20 1:26 ` Dave Scotese 2015-09-20 2:18 ` Milly Bitcoin 2015-09-20 9:18 ` NxtChg 2015-09-20 9:25 ` Mike Hearn 2 siblings, 1 reply; 46+ messages in thread From: Dave Scotese @ 2015-09-20 1:26 UTC (permalink / raw) To: P. H. Madore; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1419 bytes --] phm got most of this, but... On Sat, Sep 19, 2015 at 2:53 PM, phm via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Mike Hearn via bitcoin-dev wrote: > > > > > * Most governments can easily spend enough money to do a 51% attack, > > especially if they can compel chip fabs to cooperate for free. > > This attack works regardless of how decentralised Bitcoin is. > > > > * Any government can end Bitcoin usage in its territory by jailing > > anyone who advertises acceptance/trading of bitcoins, or prices in > > BTC. Because merchants /must/ advertise in order to alert > > customers that trades in BTC are possible, this is an attack which > > is unsolvable. If ordinary people can find such merchants so can > > government agents. > > > Pot is used as money, and they do jail people for it, but it doesn't have the effect to which you refer. It has the opposite effect, partially because it enriches suppliers. The 51% attack is a good point, but they would be taking a huge risk. Ideas don't die, just people. For example, they got Ross Ulbricht, not DPR. Government is the group of people that does things that are not acceptable if anyone else does them, and that is because people cheer for them when they do those things, rather than pointing out that they are not acceptable. The movie "The Deep Web" shows how bitcoin helps to turn this misfortune around. [-- Attachment #2: Type: text/html, Size: 2022 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-20 1:26 ` Dave Scotese @ 2015-09-20 2:18 ` Milly Bitcoin 0 siblings, 0 replies; 46+ messages in thread From: Milly Bitcoin @ 2015-09-20 2:18 UTC (permalink / raw) To: bitcoin-dev > Government is the group of people that does things ... Governments (note the plural) are a collection of entities made up of people that do all sorts of things both good and bad. Attaching your political agenda to Bitcoin with the hopes people will agree with it after using Bitcoin is not a viable plan to promote your agenda nor is it a plan for mass adoption. Russ ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-19 21:53 ` phm 2015-09-20 1:26 ` Dave Scotese @ 2015-09-20 9:18 ` NxtChg 2015-09-20 9:25 ` Mike Hearn 2 siblings, 0 replies; 46+ messages in thread From: NxtChg @ 2015-09-20 9:18 UTC (permalink / raw) To: moonpunter, bitcoin-dev >Bitcoin does not enjoy nearly the popularity that marijuana and guns do, Marijuana is an individual activity. Precisely the problem with Bitcoin you envision, where each one of us could be easily jailed. Guns are quite different: they have NRA and judging by how successful it is at fending _any_ sort of gun control laws, it can very effectively counter-balance the government. If Bitcoin had it's own NBitA, it would be in a much better position to defend itself than a bunch of individual users. >A mining network that anyone can contribute to would enable Bitcoin to stay alive in spite of this Again. Start building an alt-coin with ASIC-resistant algorithm then, it's much more important than the small blocks in your model. And it must also have other features to support your fight: integrated darkcoin-style anonymity, only TOR as the protocol, etc. Trying to use Bitcoin, which is overly-exposed, for this kind of fight is a pretty dumb idea. You won't have the benefits of a small attack surface and you won't have the benefits of strength - the most vulnerable position. Not to mention that many people simply don't share your vision of Bitcoin as a marginalized outlawed coin somewhere in the depths of TOR. Looking at how enthusiastically people in smallblockistan promote the most vulnerable position, I'd say they are all agents of USG. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-19 21:53 ` phm 2015-09-20 1:26 ` Dave Scotese 2015-09-20 9:18 ` NxtChg @ 2015-09-20 9:25 ` Mike Hearn 2015-09-20 15:43 ` Mark Friedenbach 2 siblings, 1 reply; 46+ messages in thread From: Mike Hearn @ 2015-09-20 9:25 UTC (permalink / raw) To: moonpunter; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1562 bytes --] > > Also, in the US, despite overwhelming resistance on a broad scale, > legislation continues to be presented which would violate the 2nd amendment > right to keep and bear arms. And yet the proposed legislation goes nowhere, and the USA continues to stand alone in having the first world's weakest gun control laws. You are just supporting my point with this example. Obama would like to restrict guns, but can't, because they are too popular (in the USA). The comparison to BitTorrent is likewise weak: governments hardly care about piracy. They care enough to pass laws occasionally, but not enough to put serious effort into enforcement. Wake me up when the USA establishes a Copyright Enforcement Administration with the same budget and powers as the DEA. Internet based black markets exist only because governments tolerate them (for now). A ban on Tor, Bitcoin or both would send them back to the pre-2011 state where they were virtually non-existent. Governments tolerate this sort of abuse only because they believe, I think correctly, that Bitcoin can have great benefits for their ordinary voters and for now are willing to let the tech industry experiment. But for that state of affairs to continue, the benefits must actually appear. That requires growth. I think there's a difference between natural growth and the kind of growth > that's being proposed by bank-backed start-ups and pro-censorship entities. > What difference? Are you saying the people who come to Bitcoin because of a startup are somehow less "natural" than other users? [-- Attachment #2: Type: text/html, Size: 2177 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-20 9:25 ` Mike Hearn @ 2015-09-20 15:43 ` Mark Friedenbach 2015-09-20 16:21 ` NxtChg 2015-09-21 10:30 ` Mike Hearn 0 siblings, 2 replies; 46+ messages in thread From: Mark Friedenbach @ 2015-09-20 15:43 UTC (permalink / raw) To: Mike Hearn; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 2096 bytes --] Replying to this specific email only because it is the most recent in my mail client. Does this conversation have to happen on-list? It seems to have wandered incredibly far off-topic. On Sun, Sep 20, 2015 at 5:25 AM, Mike Hearn via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Also, in the US, despite overwhelming resistance on a broad scale, >> legislation continues to be presented which would violate the 2nd amendment >> right to keep and bear arms. > > > And yet the proposed legislation goes nowhere, and the USA continues to > stand alone in having the first world's weakest gun control laws. > > You are just supporting my point with this example. Obama would like to > restrict guns, but can't, because they are too popular (in the USA). > > The comparison to BitTorrent is likewise weak: governments hardly care > about piracy. They care enough to pass laws occasionally, but not enough to > put serious effort into enforcement. Wake me up when the USA establishes a > Copyright Enforcement Administration with the same budget and powers as the > DEA. > > Internet based black markets exist only because governments tolerate them > (for now). A ban on Tor, Bitcoin or both would send them back to the > pre-2011 state where they were virtually non-existent. Governments tolerate > this sort of abuse only because they believe, I think correctly, that > Bitcoin can have great benefits for their ordinary voters and for now are > willing to let the tech industry experiment. > > But for that state of affairs to continue, the benefits must actually > appear. That requires growth. > > I think there's a difference between natural growth and the kind of growth >> that's being proposed by bank-backed start-ups and pro-censorship entities. >> > > What difference? Are you saying the people who come to Bitcoin because of > a startup are somehow less "natural" than other users? > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 3220 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-20 15:43 ` Mark Friedenbach @ 2015-09-20 16:21 ` NxtChg 2015-09-20 16:34 ` Milly Bitcoin 2015-09-21 10:30 ` Mike Hearn 1 sibling, 1 reply; 46+ messages in thread From: NxtChg @ 2015-09-20 16:21 UTC (permalink / raw) To: Mark Friedenbach, Mike Hearn; +Cc: bitcoin-dev >Does this conversation have to happen on-list? It seems to have wandered incredibly far off-topic. How is this off-topic? This a fundamental decision, from which all the other development decisions follow. And apparently it's far from settled, with one part pulling in the direction of HideCoin and the other in the direction of PopCoin. The block limit debate is a direct consequence of this fundamental disagreement. Until this is settled, Bitcoin has no clear direction and developers cannot make effective decisions: it's hard to get anywhere when you don't know where you're going. Even though this disagreement probably won't be resolved on this list, it's helpful to have this discussion for people to understand what the root problem is. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-20 16:21 ` NxtChg @ 2015-09-20 16:34 ` Milly Bitcoin 2015-09-20 20:23 ` Steven Pine 0 siblings, 1 reply; 46+ messages in thread From: Milly Bitcoin @ 2015-09-20 16:34 UTC (permalink / raw) To: bitcoin-dev > Until this is settled, Bitcoin has no clear direction and developers cannot make effective decisions: How exactly do things set "settled" in this environment? People looking at Bitcoin think a small group of developers and miners "control" these decisions. Not sure if "control" is the right word but that is the perception. Russ ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-20 16:34 ` Milly Bitcoin @ 2015-09-20 20:23 ` Steven Pine 2015-09-20 20:54 ` Milly Bitcoin ` (2 more replies) 0 siblings, 3 replies; 46+ messages in thread From: Steven Pine @ 2015-09-20 20:23 UTC (permalink / raw) To: Milly Bitcoin; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1089 bytes --] It's amazing how foolish some people are to continue trusting governments especially in light of recent history: a seemingly endless, Orwellian 'war on terror', multiple regional conflicts often justified by fake evidence, wholesale disregard of law and basic human covenants such as do not torture, ubiquitous and secret global surveillance. Anyone who doesn't consider governments the proper threat model is either a shill or an idiot. On Sep 20, 2015 12:34 PM, "Milly Bitcoin via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > Until this is settled, Bitcoin has no clear direction and developers >> cannot make effective decisions: >> > > How exactly do things set "settled" in this environment? > > People looking at Bitcoin think a small group of developers and miners > "control" these decisions. Not sure if "control" is the right word but > that is the perception. > > Russ > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 1751 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-20 20:23 ` Steven Pine @ 2015-09-20 20:54 ` Milly Bitcoin 2015-09-20 21:33 ` s7r 2015-09-20 21:10 ` NxtChg 2015-09-20 21:16 ` Eric Lombrozo 2 siblings, 1 reply; 46+ messages in thread From: Milly Bitcoin @ 2015-09-20 20:54 UTC (permalink / raw) To: bitcoin-dev Your reply has nothing to do with my comment. It looks like you just go around posting wing nut stuff without regard to what is being discussed. A proper threat model considers all possible threats and looks at the probability of each. Obviously from your comment you have no experience in threat models and limited education in general. Russ On 9/20/2015 4:23 PM, Steven Pine wrote: > It's amazing how foolish some people are to continue trusting > governments especially in light of recent history: a seemingly endless, > Orwellian 'war on terror', multiple regional conflicts often justified > by fake evidence, wholesale disregard of law and basic human covenants > such as do not torture, ubiquitous and secret global surveillance. > > Anyone who doesn't consider governments the proper threat model is > either a shill or an idiot. > > On Sep 20, 2015 12:34 PM, "Milly Bitcoin via bitcoin-dev" > <bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > > Until this is settled, Bitcoin has no clear direction and > developers cannot make effective decisions: > > > How exactly do things set "settled" in this environment? > > People looking at Bitcoin think a small group of developers and > miners "control" these decisions. Not sure if "control" is the > right word but that is the perception. > > Russ > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-20 20:54 ` Milly Bitcoin @ 2015-09-20 21:33 ` s7r 2015-09-20 21:45 ` Eric Lombrozo 0 siblings, 1 reply; 46+ messages in thread From: s7r @ 2015-09-20 21:33 UTC (permalink / raw) To: bitcoin-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Nobody said anything about trusting the governments in the way such as you describe. No matter how much you want to disagree here, Mike Hearn is right on some aspects. He only said that bitcoin needs to have larger user base, more use cases, making it more popular and less likely to be banned by the governments because of political reasons. He did not say "let's trust the governments and centralize bitcoin, give them the possibility to trace/seize/control people's bitcoins, own all the full nodes or hashing power" or anything like this. So, I think he wants to suggest "be smart and Play by the rules, follow your interest". The general threat model for which we want to scale is: larger user base (not necessarily by increasing the blocksize - just increase the transactions per second using the best way from all points of view), more use cases for simple people who only do basic stuff, more popularity but all these without the possibility for some actor to control more than he should (like a government agency). For example, just a summary (among many others): it will always be impossible to freeze anyone's coins, or take them without the party's consent, or make it mandatory to tie bitcoin addresses / wallets to real world identities. If we think governments are the threat, it's bad. This is because they can make bitcoin illegal, and no matter what you or I think, there will _always_ be more people who follow the laws (even the immoral ones) than people who don't. If it's illegal / banned in relevant places/countries/continents, bitcoin will be useless. What good will it be if you can only use it anonymously in a dark-web via Tor, and you can't tell anyone you do it and can't exchange it to fiat or vice versa? Bitcoin has to be legit, have normal use cases and be as popular as possible. Don't think that if tomorrow some government bans bitcoin there will be a revolution supporting freedom and free speech and who had this terrible idea will be jailed forever - this will not happen. What will happen is that users under that jurisdiction will not use bitcoin any more, merchants from there will not accept bitcoin any more and exchangers from there will disappear. If some of them will remain to continue doing it as an outlaw, I assume their number will be insignificant anyway. If we move towards crypto-anarchy where we want to say "f*** the laws, f*** the government, f*** everything", we already lost and this should not be the consensus here under any circumstances. We, a few computer experts on this mail list using bitcoin is not what it will make it strong. What will make it strong is millions of human beings from all social classes and with various occupations using it for whatever boring reason each one might have. +1: An outlaw currency is useless even to outlaws. > On 9/20/2015 4:23 PM, Steven Pine wrote: >> It's amazing how foolish some people are to continue trusting >> governments especially in light of recent history: a seemingly >> endless, Orwellian 'war on terror', multiple regional conflicts >> often justified by fake evidence, wholesale disregard of law and >> basic human covenants such as do not torture, ubiquitous and >> secret global surveillance. >> >> Anyone who doesn't consider governments the proper threat model >> is either a shill or an idiot. >> >> On Sep 20, 2015 12:34 PM, "Milly Bitcoin via bitcoin-dev" >> <bitcoin-dev@lists.linuxfoundation.org >> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: >> >> Until this is settled, Bitcoin has no clear direction and >> developers cannot make effective decisions: >> >> >> How exactly do things set "settled" in this environment? >> >> People looking at Bitcoin think a small group of developers and >> miners "control" these decisions. Not sure if "control" is the >> right word but that is the perception. >> >> Russ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJV/yYyAAoJEIN/pSyBJlsRbagH/1mv0u+xUy2FhYhk07irH9Qd +U/v7xOLfrzz8j7BzcqLAt3Jey0r00oWbLpay4EyhtoOjPFSFwXZ5Cz/2FChbTFO kNFtrQpR9ioRAHslePzhIWl0Zl3qz6a7HzrYGl7hLZVJGmXdAncpGEZLpgjONggb R+dbKipICkRCjuOWZkpULLVUEfTTdy7bkBTR33wVb7QxRhdJNdLtXc9E0xEWPwfy AalDSu/nhg+VLjIW9NUGky8oqk1pqnHS8AkkAt0jLaemdWgLTzt6Ll4+w4GYaLrj Ac2te3HXPwUzyq9xnoae5ESOU7MWzkzvyKQs35c4z03aLz2UxHjEL6o6K50leAw= =43rd -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-20 21:33 ` s7r @ 2015-09-20 21:45 ` Eric Lombrozo 2015-09-20 22:02 ` Milly Bitcoin 2015-09-21 8:48 ` NxtChg 0 siblings, 2 replies; 46+ messages in thread From: Eric Lombrozo @ 2015-09-20 21:45 UTC (permalink / raw) To: s7r, bitcoin-dev ------ Original Message ------ From: "s7r via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> To: bitcoin-dev@lists.linuxfoundation.org Sent: 9/20/2015 2:33:38 PM Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report >The general threat model for which we want to scale is: larger user >base >(not necessarily by increasing the blocksize - just increase the >transactions per second using the best way from all points of view), >more use cases for simple people who only do basic stuff, more >popularity but all these without the possibility for some actor to >control more than he should (like a government agency). Larger user base won't necessarily protect against governments if we still have chokepoints they can go after. Given that as a currency Bitcoin currently represents a negligible portion of the world's economy, even growing the user base by some small factor is at best a token gesture in our fight against governmental threats. If governments successfully take down critical pieces of our network infrastructure, Bitcoin will fail and most people will continue doing business as usual (using fiat currency), most of them never even noticing anything noteworthy happened at all. What we really need to grow is the number of nodes on the network that participate in its basic infrastructure - namely: miners, validators, etc...and the more centralized these activities become, the easier it will be for governments to clamp down. > ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-20 21:45 ` Eric Lombrozo @ 2015-09-20 22:02 ` Milly Bitcoin 2015-09-20 22:21 ` Eric Lombrozo 2015-09-21 8:48 ` NxtChg 1 sibling, 1 reply; 46+ messages in thread From: Milly Bitcoin @ 2015-09-20 22:02 UTC (permalink / raw) To: bitcoin-dev > Larger user base won't necessarily protect against governments if we > still have chokepoints they can go after. Bitcoin will always have chokepoints governments can go after. Hackers already targeted routers to divert mining traffic awhile back. Bitcoin traffic is easily seen and blocked by ISP's. It has already been pointed out that laws against merchants and exchanges cannot be defended against any other way than to have many people use the system. (As a developer you, of course, did not mention the threat of having a tiny number of developers who have significant influence over Bitcoin. It always amazes me the endless discussion over miners centralization and almost zero discussion of developer decentralization.) Increasing the nodes by a factor of 2 or 3 or keeping the block size small to increase the diversity of miners by a few percent will have zero effect if those other government threats were to actually happen. Russ ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-20 22:02 ` Milly Bitcoin @ 2015-09-20 22:21 ` Eric Lombrozo 2015-09-20 22:51 ` Milly Bitcoin 0 siblings, 1 reply; 46+ messages in thread From: Eric Lombrozo @ 2015-09-20 22:21 UTC (permalink / raw) To: Milly Bitcoin, bitcoin-dev ------ Original Message ------ From: "Milly Bitcoin via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> To: bitcoin-dev@lists.linuxfoundation.org Sent: 9/20/2015 3:02:32 PM Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report >>Larger user base won't necessarily protect against governments if we >>still have chokepoints they can go after. > > >Bitcoin will always have chokepoints governments can go after. Hackers >already targeted routers to divert mining traffic awhile back. Bitcoin >traffic is easily seen and blocked by ISP's. It has already been >pointed out that laws against merchants and exchanges cannot be >defended against any other way than to have many people use the system. Almost none of these merchants depend on Bitcoin in any significant way for revenue...and that's likely to remain the case for a good while. Merchants that have chosen to accept Bitcoin are typically using a handful of payment processors, again...chokepoints. And almost none of them are contributing any network resources back to Bitcoin. Exchanges are indeed serious chokepoints. But increasing the number of users will probably have relatively little effect on this unless we also increase the number of exchanges and decentralize the exchanges. If all we had to do is increase the number of users, the same argument could be used to claim that banks would be less susceptible to governmental crackdowns if they just had more account holders. Exchange decentralization is indeed another thing we must work towards - but that's probably beyond the scope of the more pressing issue which is building consensus in Bitcoin development. >(As a developer you, of course, did not mention the threat of having a >tiny number of developers who have significant influence over Bitcoin. >It always amazes me the endless discussion over miners centralization >and almost zero discussion of developer decentralization.) I've pointed out this weakness of Bitcoin *numerous* times. That I failed to mention it here does not mean it hasn't been discussed elsewhere. Some of us have also been actively working towards developing a more modular, layered architecture and better implementations that will afford greater decentralization in software development with less need for critical code reviews, less pushback from downstream developers who must continuously rebase, a better process for building consensus in the community, and simpler app migration. > > >Increasing the nodes by a factor of 2 or 3 or keeping the block size >small to increase the diversity of miners by a few percent will have >zero effect if those other government threats were to actually happen. > We need to increase the basic infrastructure nodes by a factor much larger than 2 or 3...more like 100 or 1000...and it's entirely doable with properly aligned incentives. >Russ > > >_______________________________________________ >bitcoin-dev mailing list >bitcoin-dev@lists.linuxfoundation.org >https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-20 22:21 ` Eric Lombrozo @ 2015-09-20 22:51 ` Milly Bitcoin 2015-09-20 23:11 ` Eric Lombrozo 0 siblings, 1 reply; 46+ messages in thread From: Milly Bitcoin @ 2015-09-20 22:51 UTC (permalink / raw) To: bitcoin-dev >Some of us have also been actively working towards developing > a more modular, layered architecture and better implementations that > will afford greater decentralization in software development with less > need for critical code reviews, less pushback from downstream developers > who must continuously rebase, a better process for building consensus in > the community, and simpler app migration. It sounds more efficient but it is not clear to me that it would change the level of centralization of how the final decisions are made. One threat to Bintcoin involves incentive for companies to hire developers. The only reason is to change (or not change) Bitcoin Core so it is beneficial to their interests. I am not sure anything can be done about that risk but it needs to be understood and considered and not just ignored. > We need to increase the basic infrastructure nodes by a factor much > larger than 2 or 3...more like 100 or 1000...and it's entirely doable > with properly aligned incentives. I assume that would mean fees that hike transaction fees and make Bitcoin more expensive? Russ ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-20 22:51 ` Milly Bitcoin @ 2015-09-20 23:11 ` Eric Lombrozo 2015-09-21 0:11 ` Dave Scotese 0 siblings, 1 reply; 46+ messages in thread From: Eric Lombrozo @ 2015-09-20 23:11 UTC (permalink / raw) To: Milly Bitcoin, bitcoin-dev ------ Original Message ------ From: "Milly Bitcoin via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> To: bitcoin-dev@lists.linuxfoundation.org Sent: 9/20/2015 3:51:36 PM Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report >>Some of us have also been actively working towards developing >>a more modular, layered architecture and better implementations that >>will afford greater decentralization in software development with less >>need for critical code reviews, less pushback from downstream >>developers >>who must continuously rebase, a better process for building consensus >>in >>the community, and simpler app migration. > >It sounds more efficient but it is not clear to me that it would change >the level of centralization of how the final decisions are made. > >One threat to Bintcoin involves incentive for companies to hire >developers. The only reason is to change (or not change) Bitcoin Core >so it is beneficial to their interests. I am not sure anything can be >done about that risk but it needs to be understood and considered and >not just ignored. Core development process and decentralized dev/community consensus building (in particular for consensus-critical changes) is at the top of my priorities as issues right now...and one that I'd love to discuss more in depth...but it probably deserves its own thread. The political angle seems very difficult right now while the systems architecture stuff seems a bit more tractable...and it seems that without architectural changes it will be extremely hard to decentralize development and easily bring large numbers of new developers in. > >>We need to increase the basic infrastructure nodes by a factor much >>larger than 2 or 3...more like 100 or 1000...and it's entirely doable >>with properly aligned incentives. > >I assume that would mean fees that hike transaction fees and make >Bitcoin more expensive? > Not necessarily. Right now we already pay around 3,600 bitcoins a day in inflationary subsidies, very little of which goes to the majority of critical infrastructure nodes and their operators. This is a problem with the current protocol design, one we'll hopefully be able to fix. Having more core infrastructure nodes doesn't need to raise costs per transaction - but it will most likely require abandoning the current approach of having three basic node classes: miners (which tend towards centralized pools), full nodes (which must validate each of everyone's transaction and in return get paid nothing), and thin clients (which essentially amount to parasitic nodes that do not contribute any resources back to the network and must be subsidized). ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-20 23:11 ` Eric Lombrozo @ 2015-09-21 0:11 ` Dave Scotese 2015-09-21 5:04 ` Corey Haddad 0 siblings, 1 reply; 46+ messages in thread From: Dave Scotese @ 2015-09-21 0:11 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1952 bytes --] Mike wrote: ... Obama would like to restrict guns, but can't, because they are too popular (in the USA). ... Governments tolerate this sort of abuse [black markets] only because they believe, I think correctly, that Bitcoin can have great benefits for their ordinary voters and for now are willing to let the tech industry experiment. Those two reasons must be recognized for their differences. What does it mean that something is "too popular" if the ultimate goal of government is "great benefits for their ordinary voters"? It means the government assumes that some things are bad for people even though they are popular. Crystal meth and heroin come to mind. This is a natural concern of all decent parents for their children, and the reason that cultures for millennia have had rites of passage, wherein the child takes on the responsibility of determining for him or her self whether or not a popular thing provides great benefits. That responsibility is the birthright of every human being. Why is there an institution that usurps it? How do the people within that institution benefit from being part of it? Some history to study and answer these questions includes: - The origination of public schooling as motivated by Johann Fichte's public letters to his king in response to Prussia's loss to Napolean at Jena. - Franz Oppenheimer's book, The State, tracing the origination of the idea of a state, or group of people who make up and enforce laws. - Carroll Quigley's history book, Tragedy and Hope. - Larken Rose's book, Kicking the Dragon. - The Republic, by Plato, but only once you understand those other books. - If you want a shortcut, John Taylor Gatto did a five-hour interview which is now titled "The Ultimate History Lesson with John Taylor Gatto." It is heavily sourced by its producer in case anyone wants to verify the information he provides. I'm "notplato" for a reason. notplato [-- Attachment #2: Type: text/html, Size: 2168 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-21 0:11 ` Dave Scotese @ 2015-09-21 5:04 ` Corey Haddad 2015-09-21 11:45 ` Milly Bitcoin 0 siblings, 1 reply; 46+ messages in thread From: Corey Haddad @ 2015-09-21 5:04 UTC (permalink / raw) To: Dave Scotese; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3117 bytes --] If it turns out that the blocksize divide is hinging on differing developer views on the nature of the threat posed by governments, perhaps it would be better to defer to people who specialize in that area. There are plenty of them operating in the Bitcoin space. I am familiar with some of the United States based policy people, such as Jerry Brito, Alex Fowler, Constance Choi, Jim Harper, Patrick Murck, etc.. If they are not sure how to frame their ideas as they relate to this debate, maybe the devs could pose some questions for them to answer. If the bitcoin policy people are not of help, maybe we should turn to some political philosophers or something. The main idea here is that if this is a politics question, please consider you may be outside your area of expertise. On Sun, Sep 20, 2015 at 5:11 PM, Dave Scotese via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Mike wrote: > ... Obama would like to restrict guns, but can't, because they are too > popular (in the USA). > ... Governments tolerate this sort of abuse [black markets] only because > they believe, I think correctly, that Bitcoin can have great benefits for > their ordinary voters and for now are willing to let the tech industry > experiment. > > Those two reasons must be recognized for their differences. What does it > mean that something is "too popular" if the ultimate goal of government is > "great benefits for their ordinary voters"? It means the government > assumes that some things are bad for people even though they are popular. > Crystal meth and heroin come to mind. This is a natural concern of all > decent parents for their children, and the reason that cultures for > millennia have had rites of passage, wherein the child takes on the > responsibility of determining for him or her self whether or not a popular > thing provides great benefits. That responsibility is the birthright of > every human being. Why is there an institution that usurps it? How do the > people within that institution benefit from being part of it? > > Some history to study and answer these questions includes: > > - The origination of public schooling as motivated by Johann Fichte's > public letters to his king in response to Prussia's loss to Napolean at > Jena. > - Franz Oppenheimer's book, The State, tracing the origination of the > idea of a state, or group of people who make up and enforce laws. > - Carroll Quigley's history book, Tragedy and Hope. > - Larken Rose's book, Kicking the Dragon. > - The Republic, by Plato, but only once you understand those other > books. > - If you want a shortcut, John Taylor Gatto did a five-hour interview > which is now titled "The Ultimate History Lesson with John Taylor Gatto." > It is heavily sourced by its producer in case anyone wants to verify the > information he provides. > > I'm "notplato" for a reason. > > notplato > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 3769 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-21 5:04 ` Corey Haddad @ 2015-09-21 11:45 ` Milly Bitcoin 0 siblings, 0 replies; 46+ messages in thread From: Milly Bitcoin @ 2015-09-21 11:45 UTC (permalink / raw) To: bitcoin-dev On 9/21/2015 1:04 AM, Corey Haddad via bitcoin-dev wrote: > If it turns out that the blocksize divide is hinging on differing > developer views on the nature of the threat posed by governments, > perhaps it would be better to defer to people who specialize in that > area. ... ... > The main idea here is that if this is a politics question, please > consider you may be outside your area of expertise. That is a great suggestion. Jerry Brito is the number one guy to go to for this information. You will find that many early Bitcoiners are completely clueless as to the motivations of regulators. However, you still have the problem that some influential developers know Bitcoin but otherwise are completely ignorant. They will go around claiming everyone who discusses regulation is a "statist" and so forth. Some people on this list actually claimed I am "statist" simply by pointing out that governments do both good and bad things and that most people trust and depend on governments to a certain extent. That is simply a fact, it does not support any agenda. Another example are the developers who are going around claiming a stress test is a criminal action against those running nodes. Such a claim brings all kinds of complicated legal questions about the liability of people running nodes. Instead of contacting someone who researched the issue (such as Peter Šurda who ended up posting several sensible replies) the developer posted some hyperbolic article on Reddit which did nothing but promote misinformation. On top of that it makes Bitcoiners look totally ridiculous. One day they claim Bitcoin will collapse all these government institutions and the next day they want those same government institutions to arrest people for overflowing their memory pool. One final issue about the conference ... the developers should not be accepting advertisers engaged in nefarious activities. In particular BicoinTalk was accepted as an advertiser. It is well known that site has promoted fake banks where many users lost money (CoinLeders/Inputs.io), illegal investments schemes where,any people lost funds (BLBSE) and whole host of questionable, illegal, immoral, and unethical activities. Just because the guy who runs the site wrote a block explorer that does not mean the developers should blindly promote a highly questionable web site that damages Bitcoin's reputation. The people running these events need to start acting responsibly. Russ ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-20 21:45 ` Eric Lombrozo 2015-09-20 22:02 ` Milly Bitcoin @ 2015-09-21 8:48 ` NxtChg 1 sibling, 0 replies; 46+ messages in thread From: NxtChg @ 2015-09-21 8:48 UTC (permalink / raw) To: Eric Lombrozo, s7r, bitcoin-dev >Larger user base won't necessarily protect against governments if >we still have chokepoints they can go after. This is the critical confusion about Bitcoin decentralization, which leads to this whole recent mess of shouting at each other. Decentralization is _not_ a way to withstand an attack, if the government "goes after you". Many people got this idea drilled into their heads in the previous years, that Bitcoin is a "movement" to fight governments, and decentralization is its main weapon. They confuse Bitcoin and Anonymous. >What we really need to grow is the number of nodes on the network >that participate in its basic infrastructure - namely: miners, validators, etc... Absolutely. Nobody argues that we shouldn't care about decentralization. But who's gonna pay for all this? What are the incentives? We need Bitcoin to get much more popular for this to happen. ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-20 20:23 ` Steven Pine 2015-09-20 20:54 ` Milly Bitcoin @ 2015-09-20 21:10 ` NxtChg 2015-09-20 21:13 ` Steven Pine 2015-09-20 21:24 ` Milly Bitcoin 2015-09-20 21:16 ` Eric Lombrozo 2 siblings, 2 replies; 46+ messages in thread From: NxtChg @ 2015-09-20 21:10 UTC (permalink / raw) To: Steven Pine; +Cc: bitcoin-dev >Anyone who doesn't consider governments the proper threat model is either a shill or an idiot. You meant to say "threat". This is what threat model is: https://en.wikipedia.org/wiki/Threat_model Nobody here discounts governments as a threat. As to the "proper threat model", you can't construct one since your attacker is essentially unbounded. For example, any large government could easily obtain 51% of hash power and then only accept transactions from "certified services". ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-20 21:10 ` NxtChg @ 2015-09-20 21:13 ` Steven Pine 2015-09-20 21:34 ` Milly Bitcoin 2015-09-20 21:24 ` Milly Bitcoin 1 sibling, 1 reply; 46+ messages in thread From: Steven Pine @ 2015-09-20 21:13 UTC (permalink / raw) To: NxtChg; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 883 bytes --] That's a simple fallacy, historically governments even hegemons, fail, in fact it would be odd to assert that a government will not fail, therefore ascribing godlike and limitless powers to a government is again the view of either a shill or someone untutored in history. On Sun, Sep 20, 2015 at 5:10 PM, NxtChg <nxtchg@hush.com> wrote: > > >Anyone who doesn't consider governments the proper threat model is either > a shill or an idiot. > > You meant to say "threat". This is what threat model is: > https://en.wikipedia.org/wiki/Threat_model > > Nobody here discounts governments as a threat. > > As to the "proper threat model", you can't construct one since your > attacker is essentially unbounded. > > For example, any large government could easily obtain 51% of hash power > and then only accept transactions from "certified services". > > -- Steven Pine (510) 517-7075 [-- Attachment #2: Type: text/html, Size: 1469 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-20 21:13 ` Steven Pine @ 2015-09-20 21:34 ` Milly Bitcoin 0 siblings, 0 replies; 46+ messages in thread From: Milly Bitcoin @ 2015-09-20 21:34 UTC (permalink / raw) To: bitcoin-dev > therefore ascribing godlike and limitless powers to a government is > again the view of either a shill or someone untutored in history. Since nobody ever ascribed "godlike and limitless powers to a government" on this list your comment has no bearing on anything discussed here. I am sure the whole world, except for a few underemployed gamers who discovered Bitcoin, are all untutored in history. As for this thread, the question was how/when is a Bitcoin development issue considered "settled?" Russ ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-20 21:10 ` NxtChg 2015-09-20 21:13 ` Steven Pine @ 2015-09-20 21:24 ` Milly Bitcoin 1 sibling, 0 replies; 46+ messages in thread From: Milly Bitcoin @ 2015-09-20 21:24 UTC (permalink / raw) To: bitcoin-dev Threat models can be developed for things like threats from governments. The idea in developing a model is to put in the context of other possible threats. For example, someone with a few million to burn can easily crash the exchange rate or buy a couple core developers much easier and cheaper than doing a 51% attack. These attacks can be done by governments and non-governments alike. The people who consider threats from government and think everyone associated with Bitcoin is somehow "pure" are irrational cultists who have no business discussing threat models in the first place. Russ On 9/20/2015 5:10 PM, NxtChg via bitcoin-dev wrote: > >> Anyone who doesn't consider governments the proper threat model is either a shill or an idiot. > > You meant to say "threat". This is what threat model is: https://en.wikipedia.org/wiki/Threat_model > > Nobody here discounts governments as a threat. > > As to the "proper threat model", you can't construct one since your attacker is essentially unbounded. > > For example, any large government could easily obtain 51% of hash power and then only accept transactions from "certified services". > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-20 20:23 ` Steven Pine 2015-09-20 20:54 ` Milly Bitcoin 2015-09-20 21:10 ` NxtChg @ 2015-09-20 21:16 ` Eric Lombrozo 2 siblings, 0 replies; 46+ messages in thread From: Eric Lombrozo @ 2015-09-20 21:16 UTC (permalink / raw) To: Steven Pine, Milly Bitcoin; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1603 bytes --] Steven, You make a decent point...but please try to keep the discourse civil. It's already hard enough trying to figure this stuff out without fanning more flames. ------ Original Message ------ From: "Steven Pine via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> To: "Milly Bitcoin" <milly@bitcoins.info> Cc: bitcoin-dev@lists.linuxfoundation.org Sent: 9/20/2015 1:23:28 PM Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report >It's amazing how foolish some people are to continue trusting >governments especially in light of recent history: a seemingly endless, >Orwellian 'war on terror', multiple regional conflicts often justified >by fake evidence, wholesale disregard of law and basic human covenants >such as do not torture, ubiquitous and secret global surveillance. > >Anyone who doesn't consider governments the proper threat model is >either a shill or an idiot. > >On Sep 20, 2015 12:34 PM, "Milly Bitcoin via bitcoin-dev" ><bitcoin-dev@lists.linuxfoundation.org> wrote: >>>Until this is settled, Bitcoin has no clear direction and developers >>>cannot make effective decisions: >> >>How exactly do things set "settled" in this environment? >> >>People looking at Bitcoin think a small group of developers and miners >>"control" these decisions. Not sure if "control" is the right word >>but that is the perception. >> >>Russ >> >> >>_______________________________________________ >>bitcoin-dev mailing list >>bitcoin-dev@lists.linuxfoundation.org >>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 3264 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Scaling Bitcoin conference micro-report 2015-09-20 15:43 ` Mark Friedenbach 2015-09-20 16:21 ` NxtChg @ 2015-09-21 10:30 ` Mike Hearn 1 sibling, 0 replies; 46+ messages in thread From: Mike Hearn @ 2015-09-21 10:30 UTC (permalink / raw) To: Mark Friedenbach; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 581 bytes --] > > Does this conversation have to happen on-list? It seems to have wandered > incredibly far off-topic. > I understand, it does seem off topic. But ..... what was the topic again? All Jeff's mail and the followups seem to say is there was a meeting where some people (unnamed) agreed to do something (unspecified) if the metric used is modified (which doesn't change the fundamental issues). So there isn't really much on-topic to discuss. If/when Wladimir starts a thread, with a BIP, and says "this is how it's gonna be in Bitcoin Core", then there will be things to discuss. [-- Attachment #2: Type: text/html, Size: 882 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* [bitcoin-dev] Improving Blocksize Communication Through Markets 2015-09-18 5:55 ` Mark Friedenbach 2015-09-18 17:10 ` Dave Scotese 2015-09-18 20:06 ` Matt Corallo @ 2015-09-18 22:15 ` Paul Sztorc 2015-09-20 11:41 ` Isidor Zeuner 2 siblings, 1 reply; 46+ messages in thread From: Paul Sztorc @ 2015-09-18 22:15 UTC (permalink / raw) To: Bitcoin development mailing list [-- Attachment #1: Type: text/plain, Size: 1777 bytes --] Dear List, 1. Are you sick of hearing about THE BLOCKSIZE? 2. Do you feel that long-settled blocksize issues are coming up again and again, resulting in duplicated work and communications burnout? 3. Do you feel that, while scalability is important and all, people should just shut up about it already so that you can talk about X Feature that you actually spent your time on? 4. Do you ever stop and think: How much *money* was spent for everyone to travel to Montreal, stay at their hotels, and to rent the conference venue and broadcasting accommodations? Shouldn't there be a way of just *purchasing* the information we wanted more directly? 5. Do you feel that the inherent subjectivity of the conversation encourages “political maneuvers” such as character assassination, reduction of complex issues to minimal (two) unrepresentative “parties”, and harassment / threats of violence (for the “greater good”)? As I presented at the Montreal Conference, there is a way to substantially improve the discussion. Would you believe that Hal Finney himself advocated it just seven short years ago? I happen to know it back-to-front, and the (simple) pieces are already coded into my own more-complex project Truthcoin. You could wait for me to hack the pieces together myself (which might take a long time), or you, a competent/fast C++ developer familiar with Bitcoin and/or Sidechain-Elements, could talk to me for 30 minutes, and (depending on your skill level) bang it out in, probably, one weekend. More details are on the project page ( http://bitcoinblocksize.com/ ), some technical details are in the Github README. I have also created a Slack: https://blocksize-markets.slack.com/messages/general/ Sincerely, Paul [-- Attachment #2: Type: text/html, Size: 3268 bytes --] ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [bitcoin-dev] Improving Blocksize Communication Through Markets 2015-09-18 22:15 ` [bitcoin-dev] Improving Blocksize Communication Through Markets Paul Sztorc @ 2015-09-20 11:41 ` Isidor Zeuner 0 siblings, 0 replies; 46+ messages in thread From: Isidor Zeuner @ 2015-09-20 11:41 UTC (permalink / raw) To: Paul Sztorc via bitcoin-dev Hi there, replies in-line: [...] > 4. Do you ever stop and think: How much *money* was spent for everyone > to travel to Montreal, stay at their hotels, and to rent the conference > venue and broadcasting accommodations? Not to mention that trying to solve a global issue with a conference local to Montreal is a good example for _centralizing_ Bitcoin... [...] > More details are on the project page ( http://bitcoinblocksize.com/ ), > some technical details are in the Github README. > I agree that letting the market decide is the way to go. But I don't understand why we would want to have yet another (side-)chain because of that. The market can already decide at the point where _every_ Bitcoin user starts to discriminate the Bitcoins he accepts between the client versions of the blocks where the Bitcoins come from (and the corresponding BIPs where the version numbers relate to). If a miner decides to follow a particular block size policy against the will of the community, the market could quickly rectify it when the miner realizes that no one accepts the resulting coins anymore, leading to financial loss for the miner. Best regards, Isidor ^ permalink raw reply [flat|nested] 46+ messages in thread
end of thread, other threads:[~2015-09-21 11:45 UTC | newest] Thread overview: 46+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-09-16 21:32 [bitcoin-dev] Scaling Bitcoin conference micro-report Jeff Garzik 2015-09-16 21:51 ` Matt Corallo 2015-09-18 5:55 ` Mark Friedenbach 2015-09-18 17:10 ` Dave Scotese 2015-09-18 17:28 ` Eric Lombrozo 2015-09-18 20:06 ` Matt Corallo 2015-09-18 22:33 ` Mike Hearn 2015-09-19 16:03 ` cipher anthem 2015-09-19 20:43 ` Mike Hearn 2015-09-19 1:47 ` Peter Todd 2015-09-19 6:06 ` NxtChg 2015-09-19 6:56 ` Eric Voskuil 2015-09-19 7:27 ` NxtChg 2015-09-19 7:39 ` Eric Voskuil 2015-09-19 7:57 ` NxtChg 2015-09-19 8:52 ` Eric Voskuil 2015-09-19 13:32 ` NxtChg 2015-09-19 20:57 ` Mike Hearn 2015-09-19 21:53 ` phm 2015-09-20 1:26 ` Dave Scotese 2015-09-20 2:18 ` Milly Bitcoin 2015-09-20 9:18 ` NxtChg 2015-09-20 9:25 ` Mike Hearn 2015-09-20 15:43 ` Mark Friedenbach 2015-09-20 16:21 ` NxtChg 2015-09-20 16:34 ` Milly Bitcoin 2015-09-20 20:23 ` Steven Pine 2015-09-20 20:54 ` Milly Bitcoin 2015-09-20 21:33 ` s7r 2015-09-20 21:45 ` Eric Lombrozo 2015-09-20 22:02 ` Milly Bitcoin 2015-09-20 22:21 ` Eric Lombrozo 2015-09-20 22:51 ` Milly Bitcoin 2015-09-20 23:11 ` Eric Lombrozo 2015-09-21 0:11 ` Dave Scotese 2015-09-21 5:04 ` Corey Haddad 2015-09-21 11:45 ` Milly Bitcoin 2015-09-21 8:48 ` NxtChg 2015-09-20 21:10 ` NxtChg 2015-09-20 21:13 ` Steven Pine 2015-09-20 21:34 ` Milly Bitcoin 2015-09-20 21:24 ` Milly Bitcoin 2015-09-20 21:16 ` Eric Lombrozo 2015-09-21 10:30 ` Mike Hearn 2015-09-18 22:15 ` [bitcoin-dev] Improving Blocksize Communication Through Markets Paul Sztorc 2015-09-20 11:41 ` Isidor Zeuner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox