Thomas Guyot-Sionnest [ARCHIVE] on Nostr: 📅 Original date posted:2017-08-27 📝 Original message:How do you trust your ...
📅 Original date posted:2017-08-27
📝 Original message:How do you trust your <1000 block blockchain if you don't
download/validate the whole thing? (I know it should be easy to spot
that by looking at the blocks/tx or comparing to other nodes, but from a
programmatic point of view this is much harder). You can of course
include a checkpoint in the code to tell which recent block is valid
(which is already done afaik), but you still need all blocks from that
checkpoint to validate the chain (not 10!). If you rely on such
checkpoint, why not just include the UTXO's as well so you can start
mid-way based on code trust?
Indeed pruning doesn't allow you to start mid-way yet but there are much
easier solutions to that than what you propose.
--
Thomas
On 26/08/17 06:32 PM, Adam Tamir Shem-Tov wrote:
> Thank you Thomas for your response.
>
> 1) Implement solution is impossible... I have given a solution in part
> II. By adding a Genesis Account which will be the new sender.
>
> 2)Keeping older blocks: Yes as I said 10 older blocks should be kept,
> that should suffice. I am not locked on that number, if you think
> there is a reason to keep more than that, it is open to debate.
>
> 3) Why 1000? To be honest, that number came off the top of my head.
> These are minor details, the concept must first be accepted, then we
> can work on the minor details.
>
> 4)Finally it's not just the addresses and balance you need to save...
> I think the Idea of the Genesis Account, solves this issue.
>
> 5) The problem with node pruning is that it is not standardized, and
> for a new node to enter the network and to verify the data, it needs
> to download all data and prune it by itself. This will drastically
> lower the information needed by the full nodes by getting rid of the
> junk. Currently we are around 140GB, that number is getting bigger
> exponentially, by the number of users and transactions created. It
> could reach a Terrabyte sooner than expected, we need to act now.
>
> On your second email:
> When I say account: I mean private-public key.
> The way bitcoin works, as I understand it, is that the funds are
> verified by showing that they have an origin, this "origin" needs to
> provide a signature, otherwise the transaction won't be accepted.
> If I am proposing to remove all intermediate origins, then the funds
> become untraceable and hence unverifiable. To fix that, a new
> transaction needs to replace old ones. A simplified version: If there
> was a transaction chain A->B->C->D, and I wish to show only A->D, only
> a transaction like that never actually occurred, it would be
> impossible to say that it did without having A's private key, in order
> to sign this transaction. In order to create this transaction, I need
> A's private key. And if I wish this to be publicly implemented I need
> this key to be public, so that any node creating this Exodus Block can
> sign with it. Hence the Genesis Account. And yes, it is not really an
> account.
Published at
2023-06-07 18:05:00Event JSON
{
"id": "9f43f0a39a054612835bcd63cc9441751c7595ec5b53cdc6233724e493cefdc8",
"pubkey": "8e9ded2eb9fca290998203d61b6d50df7ac2f6dcf13d8c484cbdee405f963df7",
"created_at": 1686161100,
"kind": 1,
"tags": [
[
"e",
"f07f4eeb7bae9bdd5e178e11bcb46eb250849acf6d02763b5fe4a3430406605e",
"",
"root"
],
[
"e",
"0b76526aa06d8414cca985028bdcab8ff9340517d5f5391a9dcb966235bbc21c",
"",
"reply"
],
[
"p",
"ddab60ab07cfd499e98f10c97115e429bbf06c4ac228b59c612f057a293ee388"
]
],
"content": "📅 Original date posted:2017-08-27\n📝 Original message:How do you trust your \u003c1000 block blockchain if you don't\ndownload/validate the whole thing? (I know it should be easy to spot\nthat by looking at the blocks/tx or comparing to other nodes, but from a\nprogrammatic point of view this is much harder). You can of course\ninclude a checkpoint in the code to tell which recent block is valid\n(which is already done afaik), but you still need all blocks from that\ncheckpoint to validate the chain (not 10!). If you rely on such\ncheckpoint, why not just include the UTXO's as well so you can start\nmid-way based on code trust?\n\nIndeed pruning doesn't allow you to start mid-way yet but there are much\neasier solutions to that than what you propose.\n\n--\nThomas\n\nOn 26/08/17 06:32 PM, Adam Tamir Shem-Tov wrote:\n\u003e Thank you Thomas for your response.\n\u003e\n\u003e 1) Implement solution is impossible... I have given a solution in part\n\u003e II. By adding a Genesis Account which will be the new sender.\n\u003e\n\u003e 2)Keeping older blocks: Yes as I said 10 older blocks should be kept,\n\u003e that should suffice. I am not locked on that number, if you think\n\u003e there is a reason to keep more than that, it is open to debate.\n\u003e\n\u003e 3) Why 1000? To be honest, that number came off the top of my head.\n\u003e These are minor details, the concept must first be accepted, then we\n\u003e can work on the minor details.\n\u003e\n\u003e 4)Finally it's not just the addresses and balance you need to save... \n\u003e I think the Idea of the Genesis Account, solves this issue.\n\u003e\n\u003e 5) The problem with node pruning is that it is not standardized, and\n\u003e for a new node to enter the network and to verify the data, it needs\n\u003e to download all data and prune it by itself. This will drastically\n\u003e lower the information needed by the full nodes by getting rid of the\n\u003e junk. Currently we are around 140GB, that number is getting bigger\n\u003e exponentially, by the number of users and transactions created. It\n\u003e could reach a Terrabyte sooner than expected, we need to act now.\n\u003e\n\u003e On your second email:\n\u003e When I say account: I mean private-public key.\n\u003e The way bitcoin works, as I understand it, is that the funds are\n\u003e verified by showing that they have an origin, this \"origin\" needs to\n\u003e provide a signature, otherwise the transaction won't be accepted.\n\u003e If I am proposing to remove all intermediate origins, then the funds\n\u003e become untraceable and hence unverifiable. To fix that, a new\n\u003e transaction needs to replace old ones. A simplified version: If there\n\u003e was a transaction chain A-\u003eB-\u003eC-\u003eD, and I wish to show only A-\u003eD, only\n\u003e a transaction like that never actually occurred, it would be\n\u003e impossible to say that it did without having A's private key, in order\n\u003e to sign this transaction. In order to create this transaction, I need\n\u003e A's private key. And if I wish this to be publicly implemented I need\n\u003e this key to be public, so that any node creating this Exodus Block can\n\u003e sign with it. Hence the Genesis Account. And yes, it is not really an\n\u003e account.",
"sig": "682e40b020b1bd5095265d5a3cc18775270f7f7282af4a262c88e75516bddbc4b78f559feb9874acac307eabf73f1177096789fdf5a0f4b60294690ee7a5a5e2"
}