Transactions are already sitting in everyone's (or nearly everyone's)
mempools (because they get broadcast to get to a miner in the first
place). If you don't have it (because you just connected to the
network after stopping for a bit) you can just call getdata against
your peers to get a copy.
No
Jorge Timón:
The node would need to first verify a block before mining on top of it.
Basically a receiver would ask a sender for missing transactions if he
doesn't know them already before propagating or mining the block.
Christophe Biocca:
You're right, my idea doesn't offer any real advantage o
Maybe I'm missing something.
How do miners validate blocks if they only receive the hashes of the
transactions?
Will they mine on top of a block when they don't know if it's valid?
On 1/22/14, Christophe Biocca wrote:
> Comments:
>
> bc:
> - Ultimately, this helps with block propagation latency,
Comments:
bc:
- Ultimately, this helps with block propagation latency, but not with
the bandwidth constraints themselves, because all transactions do need
to be broadcast.
- Most of the benefits of your approach can be obtained simply by
prebroadcasting the entire merkle tree while you're working
Couldn't we also use the type of zkSNARK's that Zerocoin adopted to
prove that the hash-only blocks only have valid transactions in it,
since they are small and quite efficient to verify? The trouble is
that they're still inefficient to generate, but given powerful enough
computers that compiles th
Pdf version:
http://bcdev.net/data/bitcoin_big_tx_with_coin_join.pdf
== Combining big transactions with hash-only blocks to improve tps. ==
Abstract:
I've heard people talk about including only hashes in a block to speed
up the network and also about using CoinJoin to improve privacy.
6 matches
Mail list logo
