Re: [bitcoin-dev] Compressed Bitcoin Transactions
Hi Peter, Currently, if we’re given a lock time that is non zero, we drop the 16 most significant bits and grind through until we have a valid signature. Therefore I am hesitant to add more fields to grind through, because it can get out of hand in decompression time really quickly. That said our ideal use case for transaction compression is small high security transactions, I doubt they will need a lock time in most cases. Perhaps we should drop grinding the lock time in favor of grinding the block height. Either way assuming both parties agree on the block height(which is a must right now) having a single block height for the transaction might save us several bytes. I’m working on adding an ideal transaction spec to the doc right now. Thanks!- Tom. On Tue, Sep 5, 2023 at 12:00 PM, Peter Todd via bitcoin-dev <[bitcoin-dev@lists.linuxfoundation.org](mailto:On Tue, Sep 5, 2023 at 12:00 PM, Peter Todd via bitcoin-dev < wrote: > On Fri, Sep 01, 2023 at 01:56:18PM +, Andrew Poelstra via bitcoin-dev > wrote: >> We can swag what the space savings would be: there are 122MM utxos right >> now, which is a bit under 2^27. So assuming a uniform distribution of >> prefixes we'd need to specify 28 bits to identify a UTXO. To contrast, >> to identify a blockheight we need 20 bits and then maybe 12 more bits to >> specify a TXO within a block. Plus whatever varint overhead we have. >> (I've been working on this project but busy with family stuff and don't >> remember exactly where we landed on the varints for this. I think we >> agreed that there was room for improvement but didn't want to hold up >> posting the rest of the concept because of it.) > > Since most transactions spend txouts that are similar in height to each other, > you could save further bits by specifying a reference height and then encoding > the exact txout with a delta. > > If you're sending multiple txins or multiple transactions in a single packet, > you could achieve this by starting the packet with the reference block height. > > If your application tends to send just a single transaction, you could use a > reference height that is a function of the current time. Since sender and > receiver might not agree on the exact time, you could try slightly difference > reference heights via bruteforcing until the transaction signatures validate. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Compressed Bitcoin Transactions
On Fri, Sep 01, 2023 at 01:56:18PM +, Andrew Poelstra via bitcoin-dev wrote: > We can swag what the space savings would be: there are 122MM utxos right > now, which is a bit under 2^27. So assuming a uniform distribution of > prefixes we'd need to specify 28 bits to identify a UTXO. To contrast, > to identify a blockheight we need 20 bits and then maybe 12 more bits to > specify a TXO within a block. Plus whatever varint overhead we have. > (I've been working on this project but busy with family stuff and don't > remember exactly where we landed on the varints for this. I think we > agreed that there was room for improvement but didn't want to hold up > posting the rest of the concept because of it.) Since most transactions spend txouts that are similar in height to each other, you could save further bits by specifying a reference height and then encoding the exact txout with a delta. If you're sending multiple txins or multiple transactions in a single packet, you could achieve this by starting the packet with the reference block height. If your application tends to send just a single transaction, you could use a reference height that is a function of the current time. Since sender and receiver might not agree on the exact time, you could try slightly difference reference heights via bruteforcing until the transaction signatures validate. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Concern about "Inscriptions"
On Sun, Sep 03, 2023 at 06:01:02PM +0200, vjudeu via bitcoin-dev wrote: > > Given the current concerns with blockchain size increases due to > > inscriptions, and now that the lightning network is starting to gain more > > traction, perhaps people are now more willing to consider a smaller > > blocksize in favor of pushing more activity to lightning? > > People will not agree to shrink the maximum block size. However, if you want > to kill inscriptions, there is another approach, that could be used to force > them into second layers: it is called cut-through, and was described in this > topic: https://bitcointalk.org/index.php?topic=281848.0 > > Then, if you have "Alice -> Bob -> ... -> Zack" transaction chain, and for > example some inscriptions were created in "Alice -> Bob" transaction, then > cut-through could remove those inscriptions, while leaving the payment > unaffected, because the proper amount of coins will be received by Zack, as > it should be. You are incorrect: cut-through transactions will not meaningfully affect inscriptions. While it is true that with fancy cryptography we can prove the Alice -> ... -> Zack chain, that does not change the fact that Alice -> Bob -> Zack was mined in the blockchain, and those transactions exist. Anyone running a full archival node will still have those transactions, and can provide them (and all their inscription data) to anyone who needs it. This is not unlike how in Bitcoin right now many people run pruned nodes that do not have any archival inscription data. Them running those nodes does not prevent others from running full archival nodes that do make that data available. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
