From: "Jorge Timón" <jtimon@monetize•io>
To: Christophe Biocca <christophe.biocca@gmail•com>
Cc: "bitcoin-development@lists•sourceforge.net"
<bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Combining big transactions with hash-only blocks to improve tps.
Date: Wed, 22 Jan 2014 23:10:16 +0100 [thread overview]
Message-ID: <CAC1+kJM92PrQR+Pvb=n3Ts_OMFew1N1+5uqYjYKG_+Kwwr0wig@mail.gmail.com> (raw)
In-Reply-To: <CANOOu=8OG5L1F3WPP7-oBj5Lsx_xezG7GMinrK8xXJP43R2XDQ@mail.gmail.com>
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 <christophe.biocca@gmail•com> wrote:
> 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 on it. You
> can get even bigger gains by the miners reusing large chunks of each
> other's merkle trees (which they could if they had similar transaction
> selection policies). Then there's just the headers to broadcast.
>
> Natanael:
> - Most of the block's content is important though, because I don't
> just want to know that the block is valid, I also want to know what
> changes to make to my local copy of the UTXO. So I don't know how much
> space/bandwidth you'd save. You would definitely save on signature
> checking and independent validation, but that's CPU time.
>
> On Wed, Jan 22, 2014 at 4:43 PM, Natanael <natanael.l@gmail•com> wrote:
>> 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 the hashes for the block and it could likely
>> still be done fast enough to handle large amounts of transactions. The
>> computer is likely not going to be the most expensive part anyway by a
>> far margin.
>>
>> zkSNARK = zero-knowledge Succinct Non-interactive ARgument of Knowledge
>>
>> On Wed, Jan 22, 2014 at 10:06 PM, bc <bc@bcdev•net> wrote:
>>> 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. I've
>>> not heard anyone talk about implications of combining these two
>>> techniques. I think that it would both improve network's anonymity, but
>>> also improve tps by a few orders of magnitude.
>>>
>>> I propose two optimizations:
>>> 1. Keep only hashes of transactions included in a block. Transfer all tx
>>> separately.
>>> 2. Use CoinJoin to merge transactions from many users for online
>>> shopping and banking.
>>> 3. Use Jumbo transactions as a fallback for applications where CoinJoin
>>> is inappropriate.
>>>
>>> ==== Keeping only hashes of tx in a block: ====
>>> Currently every bitcoin block includes a copy of all transactions. This
>>> is redundant and unnecessary, since after the transaction gets
>>> transmitted, every node learns about it in seconds.
>>> By keeping only transaction hashes in block, we can keep block
>>> propagation time from increasing.
>>> Assuming a typical tx with one or two inputs and two outputs [typically
>>> 300 bytes], current 1MiB block can contain about [assuming a block every
>>> 10 minutes]:
>>> 1MiB / 300 bytes = 3300tx = 5.5tps
>>>
>>> By keeping only hashes in a block [32 bytes per hash]:
>>> 1MiB / 32 bytes = 31000tx = 50tps
>>>
>>> == Benefits: ==
>>> This method allows to achieve more tps without increasing the block
>>> propagation time, which is critical for mining decentralization.
>>> It removes redundancy, since every tx has to be transmitted only once.
>>> It leads to a more consistent bandwidth utilization [large transactions
>>> are transmitted all the time, while blocks are kept small and easy to
>>> propagate].
>>> Because a block size is a constant, mining fees would not depend on the
>>> size of a transaction. Obviously to limit the network flood, there
>>> should be a transaction size limit.
>>>
>>> == Problems: ==
>>> Selfish miner can keep a subset of transactions only for yourself and
>>> release them only with a new block. This problem can be mitigated by
>>> making nodes verify all transactions before propagating a block. The
>>> incentive will then be to mine only a well-distributed transactions to
>>> lower orphan rate.
>>> The miner can try to sneak up invalid transaction in a block. This
>>> problem is also mitigated by not accepting a block before it gets
>>> verified.
>>>
>>> ==== CoinJoin: ====
>>> If the block size keeps only hashes, a transaction can be much bigger.
>>> Since CoinJoin allows many people to send coins with one transaction,
>>> the effective transaction rate can be increased considerably.
>>>
>>> == Example: ==
>>> Let's assume the transaction size limit of 50KiB. Limit of this size
>>> allows for a CoinJoin transaction between 50KiB / 300b = 170
>>> participants.
>>> So for a block of 1MiB, it would allow for 50tps *
>>> 170effective_transactions/tx = 8500tps.
>>>
>>> == Benefits: ==
>>> There would be an incentive for users to use CoinJoin by default [lower
>>> tx fees per effective transaction], which would greatly increase
>>> anonymity of the network.
>>> Since block size stays the same, block propagation time also stays the
>>> same.
>>> It doesn't require any changes to the protocol. CoinJoin transactions
>>> were always supported in bitcoin.
>>>
>>> == Problems: ==
>>> 1) CoinJoin requires collaboration between many users in real-time. It
>>> means, that transaction must be distributed to every CoinJoin
>>> participant, and every participant has to sign it before it can be
>>> released. Therefore it induces delays, which can take some time.
>>> It wouldn't be an issue with Internet banking or on-line shopping [where
>>> even 10 minutes per transaction is fast enough], however even 20 seconds
>>> can make the system unsuitable for POS payments.
>>> Potential solution: Use bigger CoinJoin user base for online payments
>>> [with smaller fees], and a smaller one for POS payments [with larger
>>> fees].
>>>
>>> 2) Signing a CoinJoin transaction requires to transfer a whole
>>> transaction for a user to sign.
>>> This can sometimes take up to a few minutes on a very slow networks.
>>>
>>> 3) CoinJoin transactions are limited. They are good enough for money
>>> transfer, but for more advanced appliances CoinJoin might be inadequate.
>>>
>>> ==== Jumbo transactons: ====
>>> I propose another tx type as a fallback where CoinJoin is not Combining
>>> big transactions with hash-only blocks to improve tps.applicable. It
>>> would remove the CoinJoin induced delays, while keeping transaction
>>> sizes big.
>>>
>>> Image: http://bcdev.net/data/jubo_transaction_description.png
>>>
>>> Transaction joiner is a service that collects transactions from clients
>>> and publishes them as a Jumbo transaction.
>>> Jumbo pubkey prevents transaction from being modified. It can only be
>>> accepted or rejected by the miner as a whole, which should limit
>>> discrimination.
>>>
>>> == Algorithm: ==
>>> 1) Transaction joiner sends a Jumbo pubkey hash to the client.
>>> 2) Client creates a transaction, includes a Jumbo pubkey hash and signs
>>> it.
>>> 3) Transaction joiner waits until there are enough transactions and
>>> releases a Jumbo transaction to the network.
>>> 4) A miner includes only a hash of a Jumbo transaction in a block, he
>>> cannot cherry-pick individual transactions from the bulk.
>>> 5) The network checks if every transaction inside a Jumbo transaction
>>> includes a Jumbo pubkey hash and if every transaction inside is valid.
>>>
>>> == Benefits: ==
>>> Since the block size stays the same, block propagation time also stay
>>> the same.
>>> There is no need to wait for every participant to sign the transaction.
>>> It's therefore more suitable for POS payments.
>>> No additional network overhead for a thin client compared to a standard
>>> tx.
>>> Backwards compatibility with current transaction system.
>>>
>>> == Problems: ==
>>> 1) Jumbo transactions don't mix coins. Anonymity of the network is not
>>> increased.
>>> 2) There would be an incentive to use this transaction type by default
>>> [compared to CoinJoin].
>>>
>>> Potential solution:
>>> Make Jumbo transaction size limit lower than CoinJoin. That would make
>>> fees for these transactions higher, thus creating an incentive to only
>>> use them when necessary.
>>>
>>> 3) Transaction joiner has to wait for a Jumbo transaction to be big
>>> enough before it gets released.
>>> It's not a big problem. When the network load is low, the fee required
>>> for a tx to be included should be lower, allowing for smaller Jumbo
>>> transactions. When the network load is high, it takes less time to fill
>>> a Jumbo transaction.
>>>
>>> ==== References: ====
>>> Increasing the Network Hashing Power by reducing block propagation time
>>> https://bitcointalk.org/index.php?topic=145066.0
>>>
>>> CoinJoin: Bitcoin privacy for the real world
>>> https://bitcointalk.org/index.php?topic=279249.0
>>>
>>> Bitcoin: A Peer-to-Peer Electronic Cash System
>>> http://bitcoin.org/bitcoin.pdf
>>>
>>> ------------------------------------------------------------------------------
>>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>>> Critical Workloads, Development Environments & Everything In Between.
>>> Get a Quote or Start a Free Trial Today.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists•sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>> ------------------------------------------------------------------------------
>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>> Critical Workloads, Development Environments & Everything In Between.
>> Get a Quote or Start a Free Trial Today.
>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jorge Timón
http://freico.in/
next prev parent reply other threads:[~2014-01-22 22:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-22 21:06 bc
2014-01-22 21:43 ` Natanael
2014-01-22 22:04 ` Christophe Biocca
2014-01-22 22:10 ` Jorge Timón [this message]
2014-01-22 22:20 ` bc
2014-01-22 22:20 ` Christophe Biocca
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAC1+kJM92PrQR+Pvb=n3Ts_OMFew1N1+5uqYjYKG_+Kwwr0wig@mail.gmail.com' \
--to=jtimon@monetize$(echo .)io \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=christophe.biocca@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox