diff options
| author | Natanael <natanael.l@gmail.com> | 2014-01-22 22:43:44 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-01-22 21:44:12 +0000 |
| commit | b1e99f4a1aa78ed07a05343cc75e002fa3066848 (patch) | |
| tree | e2d7c31deb171871139abd39173755097ad603d4 | |
| parent | b35a3a0b5215e054a692c78bcc47b38afd8795b6 (diff) | |
| download | pi-bitcoindev-b1e99f4a1aa78ed07a05343cc75e002fa3066848.tar.gz pi-bitcoindev-b1e99f4a1aa78ed07a05343cc75e002fa3066848.zip | |
Re: [Bitcoin-development] Combining big transactions with hash-only blocks to improve tps.
| -rw-r--r-- | 06/ee427f0165bbcd5c87e01cb35467c14661b169 | 236 |
1 files changed, 236 insertions, 0 deletions
diff --git a/06/ee427f0165bbcd5c87e01cb35467c14661b169 b/06/ee427f0165bbcd5c87e01cb35467c14661b169 new file mode 100644 index 000000000..98f7a7430 --- /dev/null +++ b/06/ee427f0165bbcd5c87e01cb35467c14661b169 @@ -0,0 +1,236 @@ +Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] + helo=mx.sourceforge.net) + by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <natanael.l@gmail.com>) id 1W65am-0001xT-1G + for bitcoin-development@lists.sourceforge.net; + Wed, 22 Jan 2014 21:44:12 +0000 +Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com + designates 74.125.82.176 as permitted sender) + client-ip=74.125.82.176; envelope-from=natanael.l@gmail.com; + helo=mail-we0-f176.google.com; +Received: from mail-we0-f176.google.com ([74.125.82.176]) + by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1W65ak-0003rL-Gr + for bitcoin-development@lists.sourceforge.net; + Wed, 22 Jan 2014 21:44:11 +0000 +Received: by mail-we0-f176.google.com with SMTP id t61so532404wes.35 + for <bitcoin-development@lists.sourceforge.net>; + Wed, 22 Jan 2014 13:44:04 -0800 (PST) +X-Received: by 10.194.83.9 with SMTP id m9mr743942wjy.39.1390427044362; Wed, + 22 Jan 2014 13:44:04 -0800 (PST) +MIME-Version: 1.0 +Received: by 10.194.54.10 with HTTP; Wed, 22 Jan 2014 13:43:44 -0800 (PST) +In-Reply-To: <52E032BD.4020206@bcdev.net> +References: <52E032BD.4020206@bcdev.net> +From: Natanael <natanael.l@gmail.com> +Date: Wed, 22 Jan 2014 22:43:44 +0100 +Message-ID: <CAAt2M18tyVXh+ZyZ6hF=19JAPjzd9wk+K4_sNXSC6S-baNphWA@mail.gmail.com> +To: bc <bc@bcdev.net> +Content-Type: text/plain; charset=UTF-8 +X-Spam-Score: -1.6 (-) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (natanael.l[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-Headers-End: 1W65ak-0003rL-Gr +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. +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Wed, 22 Jan 2014 21:44:12 -0000 + +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 + + |