* [bitcoin-dev] BIP: Short Term Use Addresses for Scalability @ 2015-07-22 20:15 Jeremy Rubin 2015-07-22 20:34 ` Tier Nolan 0 siblings, 1 reply; 6+ messages in thread From: Jeremy Rubin @ 2015-07-22 20:15 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 201 bytes --] While we're all debating the block size, please review this proposal to modestly increase the number of transactions per block. https://gist.github.com/JeremyRubin/4d17d28d5c681a93fa63 Best, Jeremy [-- Attachment #2: Type: text/html, Size: 415 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] BIP: Short Term Use Addresses for Scalability 2015-07-22 20:15 [bitcoin-dev] BIP: Short Term Use Addresses for Scalability Jeremy Rubin @ 2015-07-22 20:34 ` Tier Nolan 2015-07-22 21:06 ` Gavin Andresen 0 siblings, 1 reply; 6+ messages in thread From: Tier Nolan @ 2015-07-22 20:34 UTC (permalink / raw) Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1326 bytes --] Rather than re-enable OP_LEFT, a NOP could be re-purposed in a soft fork. OP_DUP OP_HASH160 [pubKeyHash[:LEN_PARAM]] [LEN_PARAM] OP_LEFTEQUALVERIFY OP_DROP OP_CHECKSIG A B L OP_LEFTEQUALVERIFY checks if the leftmost L bytes of A and B match. If not, then the script immediately fails. If either array is less than L bytes or if there are fewer than 3 values on the stack, then it also fails. The OP_DROP is needed as the new opcode must count as a NOP for legacy nodes. A change like this would only cause a once-off improvement in efficiency, so it is less likely to be worth the effort. It also requires most clients to be updated to support the new address system. A different BIP could be added for that. An alternative way to add new opcodes is to use a different script engine like with P2SH. On Wed, Jul 22, 2015 at 9:15 PM, Jeremy Rubin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > While we're all debating the block size, please review this proposal to > modestly increase the number of transactions per block. > > https://gist.github.com/JeremyRubin/4d17d28d5c681a93fa63 > > Best, > > Jeremy > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 2184 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] BIP: Short Term Use Addresses for Scalability 2015-07-22 20:34 ` Tier Nolan @ 2015-07-22 21:06 ` Gavin Andresen 2015-07-23 4:05 ` Jeremy Rubin 2015-07-23 4:55 ` jl2012 0 siblings, 2 replies; 6+ messages in thread From: Gavin Andresen @ 2015-07-22 21:06 UTC (permalink / raw) To: Tier Nolan; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 647 bytes --] On Wed, Jul 22, 2015 at 4:34 PM, Tier Nolan via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > It also requires most clients to be updated to support the new address > system. That's the killer: introducing Yet Another Type of Bitcoin Address takes a very long time and requires a lot of people to change their code. At least, that was the lesson learned when we introduced P2SH addresses. I think it's just not worth it for a very modest space savings (10 bytes, when scriptSig+scriptPubKey is about 120 bytes), especially with the extreme decrease in security (going from 2^160 to 2^80 to brute-force). -- -- Gavin Andresen [-- Attachment #2: Type: text/html, Size: 1135 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] BIP: Short Term Use Addresses for Scalability 2015-07-22 21:06 ` Gavin Andresen @ 2015-07-23 4:05 ` Jeremy Rubin 2015-07-23 4:55 ` jl2012 1 sibling, 0 replies; 6+ messages in thread From: Jeremy Rubin @ 2015-07-23 4:05 UTC (permalink / raw) To: Gavin Andresen; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 2332 bytes --] I think the catch here is that under STUA (short term use address) there is a strict incentive, you can reduce the transaction fee for these txns. This also fits with the general model that you pay the miners for security. My belief is that when there is a savings benefit to be had large players will prefer it at a minimum, and users will desire it. Your analysis of saving is inaccurate, it comes to be at or greater than 20 bytes because there is typically 2 UTXOs or more. I get that this is still marginal, but when the margins are tight this is a pretty decent gain. The security decrease is actually less extreme than it seems. This is for multiple reasons: 1) you can select LEN_PARAM when you make the tx to be secure at that time Adding a byte or two gets much more security while still keeping it lean. 2) For a small transaction, the hash power is less rewarding than just working on the blockchain or doing something else 3) These addresses are only for use for short term, not perm storage. As such, if you model the threat it isn't great (I'm using this address for one day, someone grinds it in that time). 4) Because it is a UTXO saving, it reduces memory bloat.t It would be interesting to get a more exact analysis on the time needed to run a brute force as it involves computing a valid keypair and hashing for each attempt. On Thu, Jul 23, 2015 at 5:06 AM, Gavin Andresen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Wed, Jul 22, 2015 at 4:34 PM, Tier Nolan via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> It also requires most clients to be updated to support the new address >> system. > > > That's the killer: introducing Yet Another Type of Bitcoin Address takes a > very long time and requires a lot of people to change their code. At least, > that was the lesson learned when we introduced P2SH addresses. > > I think it's just not worth it for a very modest space savings (10 bytes, > when scriptSig+scriptPubKey is about 120 bytes), especially with the > extreme decrease in security (going from 2^160 to 2^80 to brute-force). > > -- > -- > Gavin Andresen > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 3491 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] BIP: Short Term Use Addresses for Scalability 2015-07-22 21:06 ` Gavin Andresen 2015-07-23 4:05 ` Jeremy Rubin @ 2015-07-23 4:55 ` jl2012 2015-07-23 6:05 ` Jeremy Rubin 1 sibling, 1 reply; 6+ messages in thread From: jl2012 @ 2015-07-23 4:55 UTC (permalink / raw) To: bitcoin-dev Quoting Gavin Andresen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>: > On Wed, Jul 22, 2015 at 4:34 PM, Tier Nolan via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> It also requires most clients to be updated to support the new address >> system. > > > That's the killer: introducing Yet Another Type of Bitcoin Address takes a > very long time and requires a lot of people to change their code. At least, > that was the lesson learned when we introduced P2SH addresses. > > I think it's just not worth it for a very modest space savings (10 bytes, > when scriptSig+scriptPubKey is about 120 bytes), especially with the > extreme decrease in security (going from 2^160 to 2^80 to brute-force). > > -- > -- > Gavin Andresen I think it would only save ~5% with all overhead (value, sequence, locktime, version, etc.) counted A better way is to introduce shorter ECDSA keys, which will save a lot of space for public key and signature. It is safe as long as the output value is much lower than the cost of attack. If this happens, I think it will be part of the OP_MAST which will require a new address type anyway. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] BIP: Short Term Use Addresses for Scalability 2015-07-23 4:55 ` jl2012 @ 2015-07-23 6:05 ` Jeremy Rubin 0 siblings, 0 replies; 6+ messages in thread From: Jeremy Rubin @ 2015-07-23 6:05 UTC (permalink / raw) To: jl2012; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 2074 bytes --] A standard transaction is 225 bytes, leading to a savings of 8.6%. However, that is essentially the minimum saving. For other sizes (eg, 10 outputs) which seem to be pretty frequent savings can be greater. Furthermore, it is important to note that this is a memory saving for the UTXO pool so the reduction there is more (not super familiar with how the UTXO pool is stored, but it should be a better savings than 8.6%). Does anyone have the tools currently to be able to easily run through the chain and analyze the impact of this change on historical data more directly? On Thu, Jul 23, 2015 at 12:55 PM, jl2012 via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Quoting Gavin Andresen via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org>: > > On Wed, Jul 22, 2015 at 4:34 PM, Tier Nolan via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> It also requires most clients to be updated to support the new address >>> system. >>> >> >> >> That's the killer: introducing Yet Another Type of Bitcoin Address takes a >> very long time and requires a lot of people to change their code. At >> least, >> that was the lesson learned when we introduced P2SH addresses. >> >> I think it's just not worth it for a very modest space savings (10 bytes, >> when scriptSig+scriptPubKey is about 120 bytes), especially with the >> extreme decrease in security (going from 2^160 to 2^80 to brute-force). >> >> -- >> -- >> Gavin Andresen >> > > I think it would only save ~5% with all overhead (value, sequence, > locktime, version, etc.) counted > > A better way is to introduce shorter ECDSA keys, which will save a lot of > space for public key and signature. It is safe as long as the output value > is much lower than the cost of attack. > > If this happens, I think it will be part of the OP_MAST which will require > a new address type anyway. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 3228 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-07-23 6:05 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-07-22 20:15 [bitcoin-dev] BIP: Short Term Use Addresses for Scalability Jeremy Rubin 2015-07-22 20:34 ` Tier Nolan 2015-07-22 21:06 ` Gavin Andresen 2015-07-23 4:05 ` Jeremy Rubin 2015-07-23 4:55 ` jl2012 2015-07-23 6:05 ` Jeremy Rubin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox