Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: SapphireSpire on July 31, 2023, 09:12:21 PM



Title: please delete
Post by: SapphireSpire on July 31, 2023, 09:12:21 PM
nothing to see here  :(


Title: Re: Superscaling Transaction Capacity with a Parallel Hashchain
Post by: vjudeu on August 01, 2023, 04:14:46 AM
Is it similar to BIP-300 (https://github.com/bitcoin/bips/blob/master/bip-0300.mediawiki) and BIP-301 (https://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki)?


Title: Re: Superscaling Transaction Capacity with a Parallel Hashchain
Post by: NotATether on August 01, 2023, 06:30:11 AM
Is it similar to BIP-300 (https://github.com/bitcoin/bips/blob/master/bip-0300.mediawiki) and BIP-301 (https://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki)?

It does not seem similar to them at all because the Drivechain BIPs propose to make an on-chain "deposit" and "withdraw" feature from sidechains, where the confirmations for the withdrawal process at least totaling in more than a hundred thousand. While OP is proposing a singular blockchain running along side the mainnet with a (fixed?) block size limit.


Title: Re: Superscaling Transaction Capacity with a Parallel Hashchain
Post by: vjudeu on August 01, 2023, 02:41:28 PM
Quote
If that's true, then why don't people just propose to increase block size?
Because that would be instantly rejected. Many times people hear "you cannot increase block size", but because they have no idea, how to scale things correctly, they cannot see any other solution, so they end up with "obscured block size increase".

We had 1 MB limit. It was reached.
Now we have 4 MB limit, and guess what, it was reached.
After Ordinals, developers will reject any proposal to increase block size, because that limit will also be reached, no matter how high it would be.

Quote
While OP is proposing a singular blockchain running along side the mainnet with a (fixed?) block size limit.
Quote
a second hashchain that runs in parallel with the blockchain
I cannot find any sentence, where OP would say it would be obligatory to run both chains. In sidechains, you can run mainchain-only, both chains, or even sidechain-only, it depends what type of client you need.

Quote
If i understand your idea correctly, 1 block on hashchain linked to 1 block on current Bitcoin blockchain.
There is a difference between obligatory link, and optional link. I think sidechains should be optionally linked, and also through commitments to make it more private. In case of obligatory link, it would be just de-facto block size increase, in the same way as Segwit commitment is.


Title: Re: "SegHead" Segregated Header
Post by: BlackHatCoiner on August 26, 2023, 05:51:46 PM
A target transaction capacity must keep itself above the transaction rate by regulating both the block interval and the transaction count per block.
What's the point of having a "target transaction capacity"? You went to the technical part, of what it means, or how it's connected to the block interval, but you've skipped the "why" part. But just to catch you out, miners can bypass any "transactions required per block" requirement, as they can just create transactions where they send 0 coins to nowhere.

With a floating block interval, the rate of inflation will be less consistent.
This is extremely important. Most people I know, use bitcoin because the inflation schedule is known. You can tell what the inflation rate will be in 30 years, an invaluable property for money of that kind.


Title: Re: "SegHead" Segregated Header
Post by: BlackHatCoiner on August 27, 2023, 12:02:11 PM
I'm still struggling to see the solution to the problem. So what you're proposing is:
- make the block interval variable.
- make the inflation rate variable.
- separate the blockchain into headchain, bodychain and crownchain (so SPV with extra steps?)

counterfeit blockchains
Define "counterfeit blockchain".


Title: Re: "SegHead" Segregated Header
Post by: NotATether on August 29, 2023, 07:50:27 AM
1. Miners ping their peers to measure latency and adjust the target difficulty to keep the block interval as short as possible without forking.

Network latency should not be involved inside calculating the block difficulty, because that opens up a DDoS attack where the routers in front of the nodes can include an additional time "doing nothing" using flashed firmware, to artificially increase the ping and have an influence in lowering the block difficulty.

Latency should be used for just deciding which peers to connect to.


Title: Re: "SegHead" Segregated Header
Post by: Cricktor on September 03, 2023, 10:28:41 AM
And i said that's not true. Maximum block size remain unchanged at 4 million weight unit and compact block doesn't change how weight size of transaction is calculated.

Exactly this. From my understanding compact block is a way to propagate new blocks with less data needed to transmit and thus likely resulting in speedier propagation with less latency. If the receiving node has all transactions of the new block in its mempool, then it can reconstruct the new block on its own and doesn't need to fetch the whole new block from another node which already has it.