[removed scamsite url]
What??? The BitcoinSV wiki doesn't look like a scam site to me. Then again I use Firefox with two ad blockers and the no-script addon. Because there are malicious banner ads going around that load scripts that can block and tint your whole desktop and display pop-up messages to scare you into thinking that your OS has been corrupted by malware. Don't click anything because everything will direct you to their phone scammers, probably in India. Any innocent website that loads revolving banner ads from 3rd party ad servers to generate revenue is at risk of loading these malicious ads, making the website itself appear malicious. If you ever see big scary stuff like that, just hit you're ESC key to regain access to your desktop and either close or reload the web page and it will all disappear. 
Topic: please delete (Read 166 times)
[removed scamsite url]
What??? The BitcoinSV wiki doesn't look like a scam site to me. 
By replacing thousands of separate transaction headers and IDs with just one transaction header and ID, I could pack more transactions into my blocks
There are no transaction IDs stored in the block, so you won't save anything there.
What you would potentially save is:
- The 4 byte version number from each transaction
- The 4 byte locktime from each transaction
- The 2 byte witness flag from each transaction
- The in-counter from each transaction (typically 1 btye)
- The out-counter from each transaction (typically 1 byte)
However, given the larger number of inputs and outputs in your "single monolithic transaction", your in-counter and out-counter would almost certainly end up being an extra byte or so each.
Not a huge saving overall, but might allow you to fit an extra few transactions in the block if you could find enough mergeable transactions or could get enough people to re-sign the new transaction.
update: Yes! But this will only work on transactions with inputs signed with a [removed scamsite url]SIGHASH_SINGLE|ANYONECANPAY flag or a SIGHASH_NONE|ANYONECANPAY flag.
This is not practical because when SigHash SINGLE and NONE are used in regular single-sig outputs the user can't really control where their coins are going.In case of NONE they have no control so anyone can steal their coins by sending them to their own keys, and in case of SINGLE they have no control over their change since the chances of someone sending all their coins to a single output is small, they always have a change an you can only decide one output with SINGLE not the other.
Practically these SigHash flags only make sense for multi-sig outputs where at least one signer is responsible to make sure the transaction can not change by signing it with SigHash_ALL flag and others can ignore the "details" (such as the destination of the coins) by signing the tx with other flags.
This is why when you look at the blockchains you don't really see these flags be used anywhere.
The problem is you cannot join small transactions to form a bigger one today if you are not the owner of that coins.
1. You only own the coins in an output of a transaction, not the whole transaction.2. Merging transactions won't spend any outputs.
Well, as others have said, this would require all owners of the inputs inside the megatransaction sign them with their private keys. Even finding a way to contact all the owners via Bitcoin protocol will be a Herculean task because the transactions were not directly broadcasted to you (the miner), but through a series of other nodes.
As you are a miner, you *could* propagate the megatransaction to override the smaller ones, but all bets are off if any of the smaller ones are placed in a block by a rival miner.
Quote
1. You only own the coins in an output of a transaction, not the whole transaction.
If you have some typical transaction with SIGHASH_ALL, you cannot just move signatures from one transaction to another without asking coin owners to make another signature for your joined transaction.Quote
2. Merging transactions won't spend any outputs.
It will spend the same outputs as original transactions, so if you join transactions from your mempool, then it is seen as some double-spending attempt. If you join RBF transactions, then that could be accepted, but you will still need new signatures from all participants.Quote
I don't see how one would do that with the current Bitcoin transactions.
It is possible now, but unsafe, because it works only for inputs where you can move exactly the same input script to some other transaction and it still will be valid. For example, if some coins are locked with "OP_HASH256
What you're looking for is a monoidal structure of a transaction where you could just add two together to form a new joint transaction. This is what Mimblewimble does, but it requires a different transaction model. You'd need to have a noninteractive way to merge transactions.
I don't see how one would do that with the current Bitcoin transactions.
I don't see how one would do that with the current Bitcoin transactions.
Yes, see block 364292 with hash 000000000000000003dd2fdbb484d6d9c349d644d8bbb3cbfa5e67f639a465fe, there is one small coinbase transaction 6dcc37358d08b6adee18deb22f037326b5e659c2030189fbf774344c9fb39152 and one megatransaction bb41a757f405890fb0f5856228e23b715702d714d59bf2b1feb70d8b2b4e3e08. The problem is you cannot join small transactions to form a bigger one today if you are not the owner of that coins. It has to be done by users, if they will create and sign that transaction, then you can mine it.
Quote
If so, I hope it can implemented as an option, like a soft fork.
No fork is needed. Any solo miner or mining pool can do that, such block will be valid, as you can see in the example above. 
nothing to see
Jump to: