* [bitcoin-dev] Thoughts on Forks, Scalability, and other Bitcoin inconveniences. [not found] ` <CABr1YTfEEXoQJ4SUtrUki9_WetWbGV7TEB+3usJGQqu-P55kSA@mail.gmail.com> @ 2015-07-05 18:50 ` Eric Lombrozo 2015-07-05 19:55 ` Eric Lombrozo 2015-07-05 20:33 ` Justus Ranvier 0 siblings, 2 replies; 6+ messages in thread From: Eric Lombrozo @ 2015-07-05 18:50 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1683 bytes --] Blockchain validation has become too expensive to properly secure the network as per our original security model. The level of validation required to comply with our security model has become completely impractical for most use cases. Block space is still cheap only because of block reward subsidy (which decreases exponentially with time). The economics are already completely jacked - larger blocks will only worsen this disparity. The only practical way for the network to function at present (and what has essentially ended up happening, if often tacitly) is by introducing trust, in validators, miners, relayers, explorer websites, online wallets, etc...which in and of itself wouldn't be the end of the world were it not for the fact that the raison d'etre of bitcoin is trustlessness - and the security model is very much based on this idea. Because of this, there's been a tendency to deny that bitcoin cannot presently scale without trust. This is horrible because our entire security model has gone out the window...and has been replaced with something that isn't specified at all! We don't really know the boundaries of our model, as the fork a couple of days ago demonstrated. Right now we're basically trusting a few devs and some mining pool operators that until now have been willing to cooperate for the benefit of the network. It is dangerous to assume this will continue perpetually. Even assuming the best intentions, an incident might occur that this cooperation cannot easily repair. We need to either solve the validation cost/bottleneck issue...or we need to construct a new security model that takes these trust assumptions into account. - Eric Lombrozo [-- Attachment #2: Type: text/html, Size: 1793 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Thoughts on Forks, Scalability, and other Bitcoin inconveniences. 2015-07-05 18:50 ` [bitcoin-dev] Thoughts on Forks, Scalability, and other Bitcoin inconveniences Eric Lombrozo @ 2015-07-05 19:55 ` Eric Lombrozo 2015-07-05 20:33 ` Justus Ranvier 1 sibling, 0 replies; 6+ messages in thread From: Eric Lombrozo @ 2015-07-05 19:55 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 2166 bytes --] I should clarify that by "most use cases" I'm not envisioning a bunch of cryptogeeks [us, or at least myself and a few of us] happily buying up hard disks, waiting hours, days, weeks to spawn up new full nodes. I'm envisioning a world where every person has access to this technology and finds it practical, convenient, and safe ti use. - Eric Lombrozo On Jul 5, 2015 11:50 AM, "Eric Lombrozo" <elombrozo@gmail•com> wrote: > Blockchain validation has become too expensive to properly secure the > network as per our original security model. The level of validation > required to comply with our security model has become completely > impractical for most use cases. Block space is still cheap only because of > block reward subsidy (which decreases exponentially with time). The > economics are already completely jacked - larger blocks will only worsen > this disparity. > > The only practical way for the network to function at present (and what > has essentially ended up happening, if often tacitly) is by introducing > trust, in validators, miners, relayers, explorer websites, online wallets, > etc...which in and of itself wouldn't be the end of the world were it not > for the fact that the raison d'etre of bitcoin is trustlessness - and the > security model is very much based on this idea. Because of this, there's > been a tendency to deny that bitcoin cannot presently scale without trust. > This is horrible because our entire security model has gone out the > window...and has been replaced with something that isn't specified at all! > > We don't really know the boundaries of our model, as the fork a couple of > days ago demonstrated. Right now we're basically trusting a few devs and > some mining pool operators that until now have been willing to cooperate > for the benefit of the network. It is dangerous to assume this will > continue perpetually. Even assuming the best intentions, an incident might > occur that this cooperation cannot easily repair. > > We need to either solve the validation cost/bottleneck issue...or we need > to construct a new security model that takes these trust assumptions into > account. > > - Eric Lombrozo > [-- Attachment #2: Type: text/html, Size: 2497 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Thoughts on Forks, Scalability, and other Bitcoin inconveniences. 2015-07-05 18:50 ` [bitcoin-dev] Thoughts on Forks, Scalability, and other Bitcoin inconveniences Eric Lombrozo 2015-07-05 19:55 ` Eric Lombrozo @ 2015-07-05 20:33 ` Justus Ranvier 2015-07-05 20:53 ` Eric Lombrozo 1 sibling, 1 reply; 6+ messages in thread From: Justus Ranvier @ 2015-07-05 20:33 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1.1: Type: text/plain, Size: 2060 bytes --] On 07/05/2015 01:50 PM, Eric Lombrozo wrote: > The only practical way for the network to function at present (and what has > essentially ended up happening, if often tacitly) is by introducing trust, > in validators, miners, relayers, explorer websites, online wallets, > etc...which in and of itself wouldn't be the end of the world were it not > for the fact that the raison d'etre of bitcoin is trustlessness - and the > security model is very much based on this idea. Because of this, there's > been a tendency to deny that bitcoin cannot presently scale without trust. > This is horrible because our entire security model has gone out the > window...and has been replaced with something that isn't specified at all! When I read this, I get the impression that you (and possibly many others) never actually understood the Bitcoin security model in the first place. Bitcoin is a digital cash system that prevents double spending without using a trusted third party. More specifically, successful double spending in Bitcoin requires an attacker to pay a proof of work cost that exceeds the cumulative proof of work paid by all non-attackers since the original spend. The security model holds for any user who has access to the complete blockchain, and currently does not hold for all users who do not. An attacker can double spend without paying the full PoW cost the security model requires if users do not have a full copy of the blockchain which which to verify the attacker's blocks. That's a problem, but it's not an unfixable problem. The reason an attacker can fool SPV clients into accepting invalid blocks is because there exists no mechanism via which honest nodes can prove the invalidity of blocks. Implement that mechanism, and the security of SPV clients will far more closely resemble the security of full nodes. -- Justus Ranvier Open Bitcoin Privacy Project http://www.openbitcoinprivacyproject.org/ justus@openbitcoinprivacyproject•org E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623 [-- Attachment #1.2: 0xEAD9E623.asc --] [-- Type: application/pgp-keys, Size: 18667 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Thoughts on Forks, Scalability, and other Bitcoin inconveniences. 2015-07-05 20:33 ` Justus Ranvier @ 2015-07-05 20:53 ` Eric Lombrozo 2015-07-05 21:05 ` Justus Ranvier 0 siblings, 1 reply; 6+ messages in thread From: Eric Lombrozo @ 2015-07-05 20:53 UTC (permalink / raw) To: Justus Ranvier; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 3003 bytes --] Perhaps I didn't write that so well if I gave that impression. Perhaps taking a look at some of my work in this space would make you think otherwise. (yes, I've implemented an entire SPV stack from scratch...look it up.) But all patronizing aside, your claim that "the reason an attacker can fool SPV clients into accepting invalid blocks is because there exists no mechanism via which honest nodes can prove the invalidity of blocks" is exactly to the point...and building such a mechanism would address the first of the two options I give: make it cheap to securely validate or take trust into account. - Eric Lombrozo On Jul 5, 2015 1:34 PM, "Justus Ranvier" < justus@openbitcoinprivacyproject•org> wrote: > On 07/05/2015 01:50 PM, Eric Lombrozo wrote: > > The only practical way for the network to function at present (and what > has > > essentially ended up happening, if often tacitly) is by introducing > trust, > > in validators, miners, relayers, explorer websites, online wallets, > > etc...which in and of itself wouldn't be the end of the world were it not > > for the fact that the raison d'etre of bitcoin is trustlessness - and the > > security model is very much based on this idea. Because of this, there's > > been a tendency to deny that bitcoin cannot presently scale without > trust. > > This is horrible because our entire security model has gone out the > > window...and has been replaced with something that isn't specified at > all! > > When I read this, I get the impression that you (and possibly many > others) never actually understood the Bitcoin security model in the > first place. > > Bitcoin is a digital cash system that prevents double spending without > using a trusted third party. > > More specifically, successful double spending in Bitcoin requires an > attacker to pay a proof of work cost that exceeds the cumulative proof > of work paid by all non-attackers since the original spend. > > The security model holds for any user who has access to the complete > blockchain, and currently does not hold for all users who do not. An > attacker can double spend without paying the full PoW cost the security > model requires if users do not have a full copy of the blockchain which > which to verify the attacker's blocks. > > That's a problem, but it's not an unfixable problem. > > The reason an attacker can fool SPV clients into accepting invalid > blocks is because there exists no mechanism via which honest nodes can > prove the invalidity of blocks. > > Implement that mechanism, and the security of SPV clients will far more > closely resemble the security of full nodes. > > > -- > Justus Ranvier > Open Bitcoin Privacy Project > http://www.openbitcoinprivacyproject.org/ > justus@openbitcoinprivacyproject•org > E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623 > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 3840 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Thoughts on Forks, Scalability, and other Bitcoin inconveniences. 2015-07-05 20:53 ` Eric Lombrozo @ 2015-07-05 21:05 ` Justus Ranvier 2015-07-05 21:08 ` Eric Lombrozo 0 siblings, 1 reply; 6+ messages in thread From: Justus Ranvier @ 2015-07-05 21:05 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1.1: Type: text/plain, Size: 921 bytes --] On 07/05/2015 03:53 PM, Eric Lombrozo wrote: > Perhaps I didn't write that so well if I gave that impression. Perhaps > taking a look at some of my work in this space would make you think > otherwise. (yes, I've implemented an entire SPV stack from scratch...look > it up.) I get concerned when I hear statement like "the raison d'etre of bitcoin is trustlessness" because it implies that Bitcoin promises infinite security, which has never been the case. I don't think we can meaningfully discuss Bitcoin security issues if every proposal is compared to a straw standard of perfection which is achievable. When everybody expects infinite security then the perfect turns into the enemy of the good (and the achievable). -- Justus Ranvier Open Bitcoin Privacy Project http://www.openbitcoinprivacyproject.org/ justus@openbitcoinprivacyproject•org E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623 [-- Attachment #1.2: 0xEAD9E623.asc --] [-- Type: application/pgp-keys, Size: 18667 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Thoughts on Forks, Scalability, and other Bitcoin inconveniences. 2015-07-05 21:05 ` Justus Ranvier @ 2015-07-05 21:08 ` Eric Lombrozo 0 siblings, 0 replies; 6+ messages in thread From: Eric Lombrozo @ 2015-07-05 21:08 UTC (permalink / raw) To: Justus Ranvier; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1304 bytes --] I was saying that somewhat tongue-in-cheek...sorry that didn't come through in the text. On Jul 5, 2015 2:05 PM, "Justus Ranvier" < justus@openbitcoinprivacyproject•org> wrote: > On 07/05/2015 03:53 PM, Eric Lombrozo wrote: > > Perhaps I didn't write that so well if I gave that impression. Perhaps > > taking a look at some of my work in this space would make you think > > otherwise. (yes, I've implemented an entire SPV stack from scratch...look > > it up.) > > I get concerned when I hear statement like "the raison d'etre of bitcoin > is trustlessness" because it implies that Bitcoin promises infinite > security, which has never been the case. > > I don't think we can meaningfully discuss Bitcoin security issues if > every proposal is compared to a straw standard of perfection which is > achievable. When everybody expects infinite security then the perfect > turns into the enemy of the good (and the achievable). > > -- > Justus Ranvier > Open Bitcoin Privacy Project > http://www.openbitcoinprivacyproject.org/ > justus@openbitcoinprivacyproject•org > E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623 > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 2002 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-07-05 21:08 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CABr1YTf72fdQmTDEHAWVKqvTCLSpJZyiiw4g3ifrY8x5RZ=shQ@mail.gmail.com>
[not found] ` <CABr1YTfwcOQuNyqO57=jdghTnqt56u6pBvK6+dWbED-4OMh+Ug@mail.gmail.com>
[not found] ` <CABr1YTfEEXoQJ4SUtrUki9_WetWbGV7TEB+3usJGQqu-P55kSA@mail.gmail.com>
2015-07-05 18:50 ` [bitcoin-dev] Thoughts on Forks, Scalability, and other Bitcoin inconveniences Eric Lombrozo
2015-07-05 19:55 ` Eric Lombrozo
2015-07-05 20:33 ` Justus Ranvier
2015-07-05 20:53 ` Eric Lombrozo
2015-07-05 21:05 ` Justus Ranvier
2015-07-05 21:08 ` Eric Lombrozo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox