Nostr notes by

📅 Original date posted:2015-03-16 📝 Original message:The ...

2023-06-07T15:32:00Z

In reply to nevent1q…lgg6
_________________________

📅 Original date posted:2015-03-16
📝 Original message:The problem of pseudo-nodes will come over and over. The cat and mouse
chase is just beginning.
It has been discussed some times that the easiest solution world be to
request some kind of resource consumption on each peer to be allowed to
connect to other peers.
Gmaxwell proposed Proof of Storage here:
https://bitcointalk.org/index.php?topic=310323.msg3332919#msg3332919

I proposed a (what I think) is better protocol for Proof of Storage that
I call "Proof of Local storage" here
https://bitslog.wordpress.com/2014/11/03/proof-of-local-blockchain-storage/
. It's better because it does not need the storage of additional data,
but more importantly, it allows you to prove full copy of the blockchain
is being maintained by the peer.
This is specially important now that Bitnodes is trying a full-node
incentive program that may be easily cheated
(http://qntra.net/2015/02/pseudonode-proxy-fools-bitcoin-full-node-incentive-program/)

Proof of local storage allows a node to prove another peer that he is
storing a LOCAL copy of a PUBLIC file, such as the blockchain. So the
peer need not waste more resources (well, just some resources to
encode/decode the block-chain).
The main idea is to use what I called asymmetric-time-encoding.
Basically you encode the block-chain in a way that it takes 100 more
times to write it than to read it. Since the block-chain is an
append-only (write-only) file, this fit good for our needs. For instance
(and as a simplification), choosing a global 1024-bit prime, then
splitting the block-chain in 1024-bit blocks, and encrypting each block
using Polihg-Hellman (modexp) with decryption exponent 3. Then
encryption is at least 100 times slower than decryption. Before PH
encryption each node must xor each block with a pseudo-random mask
derived from the public IP and the block index. So block encryption
could be:
BlockEncryptIndex(i) = E(IP+i,block(i))^inv(3) (mod p),

where inv(3) is 3^-1 mod (p-1). E() could be a fast tweaked encryption
routine (tweak = index), but we only need the PRNG properties of E() and
that E() does share algebraic properties with P.H..

Two protocols can be performed to prove local possession:
1. (prover and verifier pay a small cost) The verifier sends a seed to
derive some n random indexes, and the prover must respond with the hash
of the decrypted blocks within a certain time bound. Suppose that
decryption of n blocks take 100 msec (+-100 msec of network jitter).
Then an attacker must have a computer 50 faster to be able to
consistently cheat. The last 50 blocks should not be part of the list to
allow nodes to catch-up and encrypt the blocks in background.

2. (prover pay a high cost, verified pays negligible cost). The verifier
chooses a seed n, and then pre-computes the encrypted blocks derived
from the seed using the prover's IP. Then the verifier sends the seed,
and the prover must respond with the hash of the encrypted blocks within
a certain time bound. The proved does not require to do any PH
decryption, just take the encrypted blocks for indexes derived from the
seed, hash them and send the hash back to the verifier. The verifier
validates the time bound and the hash.

Both protocols can me made available by the client, under different
states. For instance, new nodes are only allowed to request protocol 2
(and so they get an initial assurance their are connecting to
full-nodes). After a first-time mutual authentication, they are allowed
to periodically perform protocol 1. Also new nodes may be allowed to
perform protocol 1 with a small index set, and increase the index set
over time, to get higher confidence.

The important difference between this protocol and classical remote
software attestation protocols, is that the time gap between a good peer
and a malicious peer can be made arbitrarily high, picking a larger p.
Maybe there is even another crypto primitive which is more asymmetric
than exponent 3 decryption (the LUC or NTRU cryptosystem?).

In GMaxwell proposal each peer builds a table for each other peer. In my
proposal, each peer builds a single table (the encrypted blockchain), so
it could be still possible to establish a thousands of connections to
the network from a single peer. Nevertheless, the attacker's IP will be
easily detected (he cannot hide under a thousands different IPs). It's
also possible to restrict the challenge-response to a portion of the
block-chain, the portion offset being derived from the hash of both IP
addresses and one random numbers provided by each peer. Suppose each
connection has a C-R space equivalent to 1% of the block-chain. Then
having 100 connections and responding to C-R on each connection means
storing approximate 1 copy of the block-chain (there may be overlaps,
which would need to be stored twice) , while having 1K connections would
require storing 10 copies of the blockchain.

Best regards,
Sergio

📅 Original date posted:2014-12-09 📝 Original message:Is ...

2023-06-07T15:27:44Z

In reply to nevent1q…ef7u
_________________________

📅 Original date posted:2014-12-09
📝 Original message:Is that the full terminology or are there more acronyms?
Is this documented somewhere?

Best regards,
Sergio.

📅 Original date posted:2014-10-01 📝 Original message:I like ...

2023-06-07T15:26:04Z

In reply to nevent1q…ytkj
_________________________

📅 Original date posted:2014-10-01
📝 Original message:I like the proposal.

I suggest that applications and nodes should only broadcast transactions
having OP_CHECKLOCKTIMEVERIFY a few blocks after the timeout value.
If a node broadcasts a TX having OP_CHECKLOCKTIMEVERIFY and nLockTime is
equal to the current height and equal to the timeout value, but that
peer is one block behind in the blockchain, the transaction will be
rejected by the peer and the source will be banned.

Another option will be not to ban peers sending transactions failing to
verify OP_CHECKLOCKTIMEVERIFY , but I don't like this.

Still another option would be that the sender checks periodically the
height of it's peers (using the version command) in order to be sure to
send the transaction having OP_CHECKLOCKTIMEVERIFY only to the peers
that are up to date with the blockchain.

Regards,
Sergio.

📅 Original date posted:2014-04-24 📝 Original message:On ...

2023-06-07T15:19:47Z

In reply to nevent1q…0zsm
_________________________

📅 Original date posted:2014-04-24
📝 Original message:On 23/04/2014 05:51 p.m., Mike Hearn wrote:
> On Wed, Apr 23, 2014 at 10:44 PM, Adam Ritter <aritter at gmail.com
> <mailto:aritter at gmail.com>> wrote:
>
> Isn't a faster blockchain for transactions (maybe as a sidechain)
> solving the problem? If there would be a safe way for
> 0-confirmation transactions, the Bitcoin blockchain wouldn't even
> be needed.
>
>
> The 10 minute average comes from a desire to balance wasted work due
> to natural chain splits with latency. With a very fast block interval
> you end up with lots of forks and things take longer to converge,
> also, it can make attacks easier because an attacker is building on
> his own blocks so he doesn't suffer propagation delays and the
> attendant splits.
>
> It's not clear you can just make a faster block chain. 10 minutes is
> somewhat arbitrary, it could be 5 minutes and the system would still
> work, but it probably can't be 5 seconds.
5 seconds block interval is possible. I've simulate it with great
success and I encourage anyone to repeat or check my simulations.

There are a very few protocol modifications that are required to allow 5
seconds block, and most of them have already been discussed in the forums.
For more information you can check my post:
http://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/
Also NimbleCoin is a new alt-coin that uses 5-sec block intervals,
allows 100 tps and .... it's based on BitcoinJ (NimbleCoinJ now). So not
only it is possible, but it was coded by Mike itself.
Important note: the 5-sec block interval method probably requires a
block reward forever. It doesn't work well if there is no block reward
at all.

>
> Unfortunately for best physical-world usability you really need very
> fast payments. A few seconds is competitive with modern credit cards.
Another solution to achieve <5 secs block intervals is this:
http://bitslog.wordpress.com/2014/03/20/mincen-a-new-protocol-to-achieve-instant-payments/

So the problem with 0-confirmations is solely of Bitcoin and other
alt-coins, new alt-coins may achieve instant transactions and no not
have to rely on 0-confirmations.

Best regards,
Sergio.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140424/516c9e13/attachment.html>;