Alan Reiner [ARCHIVE] on Nostr: 📅 Original date posted:2011-12-18 🗒️ Summary of this message: Headers-only ...
📅 Original date posted:2011-12-18
🗒️ Summary of this message: Headers-only clients can still maintain the same level of security as full nodes by basing verification decisions on hash comparisons. Blockchain pruning is critical for scalability and decentralization.
📝 Original message:The whole point of having headers built at a constant size and
generation rate is to minimize the amount of data needed to "understand"
of the blockchain while simultaneously maximizing integrity/security in
the presence of untrusted nodes. Barring the 50%-attack, you only need
a couple honest nodes out of 50 to stay safe (as long as you're waiting
for your 6 confirmations). In fact, I would argue that a full node
(Satoshi client), has the same level of security as a headers-only
client... because they both base *all* their verification decisions on
computations that end with comparing hashes to the longest-chain headers.
In the case that an attacker figures out how to isolate your node
entirely and start feeing you poisoned blocks, then you are vulnerable
with any kind of node, full or lightweight. I don't see where the
reduced security is.
The only issue I see is that a truly light-weight, headers-only node
will be having to download an entire block to get one transaction it
needs. This would be significantly alleviated if nodes can start
requesting merkle-trees directly, even without merkle-branch-pruning.
If a node can ask for a tx and the tx-hash-list of the block that
incorporated that tx, he can easily verify his tx against his
no-need-to-trust-anyone headers, and doesn't have to download MBs for
every one.
As for blockchain pruning... I think it's absolutely critical to find a
way to do this, /for all nodes/. I am swayed by Dan Kaminsky's
scalability warnings, and my instinct tells me that leaving full
verification to a select few deep-pockets nodes in the future opens up
all sorts of centralization/power-corporation issues that is contrary to
the Bitcoin concept. It is in everyone's best interest to make it as
easy as possible for /anyone/ to act as a full node (if possible). As
such, I believe that the current system of minimizing TxOut size is the
right one. TxIns take up 0 bytes space in the long-run when taking into
account any blockchain pruning/snapshot idea (except for nLocktime/seq
transactions where the TxIn might have to be saved).
-Alan
On 12/18/2011 12:09 PM, theymos wrote:
> On Sat, Dec 17, 2011, at 05:27 PM, Jordan Mack wrote:
>> I don't like the idea of a header only client, unless this is just an
>> interim action until the full block chain is downloaded in the
>> background. Development of these types of clients is probably
>> inevitable, but I believe that this breaks the most fundamental
>> aspects of Bitcoin's security model. If a client has only headers, it
>> cannot do full verification, and it is trusting the data from random
>> anonymous peers.
> A headers-only client is much better than trusting anyone, since an
> attacker needs>50% of the network's computational power to trick
> such clients.
>
> For everyone to keep being a full node, hardware costs would need to
> constantly go down enough for all nodes to be able to handle enough
> transactions to meet demand. If hardware doesn't become cheap enough
> quickly enough, either some people would be unable to handle being full
> nodes, or the max block size wouldn't rise enough to meet demand and
> transaction fees would become noncompetitive.
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live! Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111218/e262a49a/attachment.html>;
🗒️ Summary of this message: Headers-only clients can still maintain the same level of security as full nodes by basing verification decisions on hash comparisons. Blockchain pruning is critical for scalability and decentralization.
📝 Original message:The whole point of having headers built at a constant size and
generation rate is to minimize the amount of data needed to "understand"
of the blockchain while simultaneously maximizing integrity/security in
the presence of untrusted nodes. Barring the 50%-attack, you only need
a couple honest nodes out of 50 to stay safe (as long as you're waiting
for your 6 confirmations). In fact, I would argue that a full node
(Satoshi client), has the same level of security as a headers-only
client... because they both base *all* their verification decisions on
computations that end with comparing hashes to the longest-chain headers.
In the case that an attacker figures out how to isolate your node
entirely and start feeing you poisoned blocks, then you are vulnerable
with any kind of node, full or lightweight. I don't see where the
reduced security is.
The only issue I see is that a truly light-weight, headers-only node
will be having to download an entire block to get one transaction it
needs. This would be significantly alleviated if nodes can start
requesting merkle-trees directly, even without merkle-branch-pruning.
If a node can ask for a tx and the tx-hash-list of the block that
incorporated that tx, he can easily verify his tx against his
no-need-to-trust-anyone headers, and doesn't have to download MBs for
every one.
As for blockchain pruning... I think it's absolutely critical to find a
way to do this, /for all nodes/. I am swayed by Dan Kaminsky's
scalability warnings, and my instinct tells me that leaving full
verification to a select few deep-pockets nodes in the future opens up
all sorts of centralization/power-corporation issues that is contrary to
the Bitcoin concept. It is in everyone's best interest to make it as
easy as possible for /anyone/ to act as a full node (if possible). As
such, I believe that the current system of minimizing TxOut size is the
right one. TxIns take up 0 bytes space in the long-run when taking into
account any blockchain pruning/snapshot idea (except for nLocktime/seq
transactions where the TxIn might have to be saved).
-Alan
On 12/18/2011 12:09 PM, theymos wrote:
> On Sat, Dec 17, 2011, at 05:27 PM, Jordan Mack wrote:
>> I don't like the idea of a header only client, unless this is just an
>> interim action until the full block chain is downloaded in the
>> background. Development of these types of clients is probably
>> inevitable, but I believe that this breaks the most fundamental
>> aspects of Bitcoin's security model. If a client has only headers, it
>> cannot do full verification, and it is trusting the data from random
>> anonymous peers.
> A headers-only client is much better than trusting anyone, since an
> attacker needs>50% of the network's computational power to trick
> such clients.
>
> For everyone to keep being a full node, hardware costs would need to
> constantly go down enough for all nodes to be able to handle enough
> transactions to meet demand. If hardware doesn't become cheap enough
> quickly enough, either some people would be unable to handle being full
> nodes, or the max block size wouldn't rise enough to meet demand and
> transaction fees would become noncompetitive.
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live! Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111218/e262a49a/attachment.html>;