please delete | Bitcointalksearch.org

ABCbits

legendary

Activity: 2870

Merit: 7490

Crypto Swap Exchange

Quote from: SapphireSpire on September 01, 2023, 12:50:27 PM

Quote from: ABCbits on August 31, 2023, 07:50:52 AM

--snip--

It doesn't have to be perfect. It's an estimate that permits a slight degree of inaccuracy.

Then how about these condition.
1. Node which use non-default mempool configuration.
2. Node which intentionally disable mempool?
3. Different full node software which has default different mempool configuration.

Quote from: SapphireSpire on September 01, 2023, 12:50:27 PM

Quote from: ABCbits on August 31, 2023, 07:50:52 AM

--snip--

Compact blocks don't replace full blocks, but they do permit more confirmations per block, so full blocks should be much larger.

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.

SapphireSpire

jr. member

Activity: 49

Merit: 38

Quote from: ABCbits on August 31, 2023, 07:50:52 AM

Quote from: SapphireSpire on August 31, 2023, 06:48:17 AM

Quote from: ABCbits on August 30, 2023, 04:57:46 AM

And how exactly the transaction rate obtain? Based on few last block?

The rate of mempool growth over the last 10 blocks.
New transactions per block - confirmations per block.

That won't work on practice. Don't forget each node usually have slightly different set of transaction on mempool.

It doesn't have to be perfect. It's an estimate that permits a slight degree of inaccuracy.

Quote from: ABCbits on August 31, 2023, 07:50:52 AM

Quote from: SapphireSpire on August 31, 2023, 06:48:17 AM

Quote from: ABCbits on August 30, 2023, 04:57:46 AM

1. How do you get number 30k and 3k?

3k comes from here. https://www.blockchain.com/explorer/charts/n-transactions-per-block

And 30k comes from Math: 1 MB compact block / 32 bytes per TXID = 31,250 TXIDs per compact block

Maybe 30k TXIDs + 1,250 bytes for overhead.

I see. But it's clear you misunderstood Compact Block. Compact Block basically just format used to send block data between nodes. The actual block content remain unchanged.

Compact blocks don't replace full blocks, but they do permit more confirmations per block, so full blocks should be much larger.

ABCbits

legendary

Activity: 2870

Merit: 7490

Crypto Swap Exchange

Quote from: SapphireSpire on August 31, 2023, 06:48:17 AM

Quote from: ABCbits on August 30, 2023, 04:57:46 AM

And how exactly the transaction rate obtain? Based on few last block?

The rate of mempool growth over the last 10 blocks.
New transactions per block - confirmations per block.

That won't work on practice. Don't forget each node usually have slightly different set of transaction on mempool.

Quote from: SapphireSpire on August 31, 2023, 06:48:17 AM

Quote from: ABCbits on August 30, 2023, 04:57:46 AM

1. How do you get number 30k and 3k?

3k comes from here. https://www.blockchain.com/explorer/charts/n-transactions-per-block

And 30k comes from Math: 1 MB compact block / 32 bytes per TXID = 31,250 TXIDs per compact block

Maybe 30k TXIDs + 1,250 bytes for overhead.

I see. But it's clear you misunderstood Compact Block. Compact Block basically just format used to send block data between nodes. The actual block content remain unchanged.

SapphireSpire

jr. member

Activity: 49

Merit: 38

Quote from: ABCbits on August 30, 2023, 04:57:46 AM

And how exactly the transaction rate obtain? Based on few last block?

The rate of mempool growth over the last 10 blocks.
New transactions per block - confirmations per block.

Quote from: ABCbits on August 30, 2023, 04:57:46 AM

1. How do you get number 30k and 3k?

3k comes from here. https://www.blockchain.com/explorer/charts/n-transactions-per-block

And 30k comes from Math: 1 MB compact block / 32 bytes per TXID = 31,250 TXIDs per compact block

Maybe 30k TXIDs + 1,250 bytes for overhead.

ABCbits

legendary

Activity: 2870

Merit: 7490

Crypto Swap Exchange

Quote from: ?? on ??

Quote from: ABCbits on August 29, 2023, 07:05:13 AM

On condition where there aren't many unconfirmed transaction, miner would be unable to meet "minimum required transaction count per block". It would force miner to create many useless transaction (e.g. send coin between their address) which in order to fill the block and also bloat the blockchain.

The TTC scales with the transaction rate. A low transaction rate means a low minimum transaction count per block, so miners never need to fill unused space.

And how exactly the transaction rate obtain? Based on few last block?

Quote from: ?? on ??

Quote from: ABCbits on August 29, 2023, 07:05:13 AM

Compact Block (https://bitcoincore.org/en/2016/06/07/compact-blocks-faq/) already achieve this goal.

Really? It looks like a ton of great work, but the median transaction count per block should be 30k, not 3k. Especially since it's also using shortened TXIDs, which they admit can occasionally collide (create duplicates) and give adversaries the opportunity to substitute legitimate transactions with fakes, which must be mitigated with additional complexity. I'm not sure if it's worth it.

1. How do you get number 30k and 3k? It's not mentioned on link i mentioned or BIP 152. In first place, Compact block have no impact on theoretical transaction per block.
2. Risk of receiving fake/invalid data from another node always exist. But as always, full node software would just ban IP of node which behave maliciously.
3. It's definitely worth it since it's already used by Bitcoin Core and mining pools for several years.

SapphireSpire

jr. member

Activity: 49

Merit: 38

Quote from: NotATether on August 29, 2023, 02:50:27 AM

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.

I can't say it's impossible, but an attack like that is only going to work on the oldest and cheapest legacy hardware that nobody uses.

What should a dynamic block interval be based on other than latency?

Quote from: ABCbits on August 29, 2023, 07:05:13 AM

On condition where there aren't many unconfirmed transaction, miner would be unable to meet "minimum required transaction count per block". It would force miner to create many useless transaction (e.g. send coin between their address) which in order to fill the block and also bloat the blockchain.

The TTC scales with the transaction rate. A low transaction rate means a low minimum transaction count per block, so miners never need to fill unused space.

Quote from: ABCbits on August 29, 2023, 07:05:13 AM

Compact Block (https://bitcoincore.org/en/2016/06/07/compact-blocks-faq/) already achieve this goal.

Really? It looks like a ton of great work, but the median transaction count per block should be 30k, not 3k. Especially since it's also using shortened TXIDs, which they admit can occasionally collide (create duplicates) and give adversaries the opportunity to substitute legitimate transactions with fakes, which must be mitigated with additional complexity. I'm not sure if it's worth it.

ABCbits

legendary

Activity: 2870

Merit: 7490

Crypto Swap Exchange

It looks OP updating his thread/proposal again, so here's my updated thought

Quote from: SapphireSpire on July 31, 2023, 04:12:21 PM

2. Miners determine the minimum required transaction count per block by multiplying the TTP by the block interval.
The shorter the block interval, the fewer transactions per block are required to match the TTP, and vice versa.

On condition where there aren't many unconfirmed transaction, miner would be unable to meet "minimum required transaction count per block". It would force miner to create many useless transaction (e.g. send coin between their address) which in order to fill the block and also bloat the blockchain.

Quote from: SapphireSpire on July 31, 2023, 04:12:21 PM

Minimizing Bandwidth Usage
Block messages don't need to contain full transaction data. They only require header data and a list of the transaction IDs in the block. Bandwidth is greatly reduced, and transaction size becomes irrelevant to the confirmation count per block, which means transaction fees will be huge. Nodes can use the transaction IDs to assemble and validate the full blocks with the transaction data they have in their mempools. If a node is missing any transaction data, they can request it from their peers.

Compact Block (https://bitcoincore.org/en/2016/06/07/compact-blocks-faq/) already achieve this goal.

Quote from: SapphireSpire on August 26, 2023, 08:45:52 PM

Quote from: BlackHatCoiner on August 26, 2023, 12:51:46 PM

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.

Transaction fees are huge with Seghead, so miners have no reason to produce empty blocks, unless the mempool is empty. Sad

I see the need for it though. PoW blockchain networks are under constant assault by adversaries who are working to grow their own counterfeit blockchains in the hope of someday overtaking the genuine blockchains, so genuine blockchains can't afford to stop growing. If a genuine blockchain ever stops growing, it'll give counterfeit blockchains the opportunity to catch up and overtake them, which will cause the network to trust the counterfeit blockchain instead of the genuine one.

Unless that counterfeit block happen to not violate any Bitcoin consensus/protocol rule and have most cumulative work, there's no chance Bitcoin full node/software decide to follow that counterfeit block.

SapphireSpire

jr. member

Activity: 49

Merit: 38

Quote from: BlackHatCoiner on August 26, 2023, 12:51:46 PM

What's the point of having a "target transaction capacity"?

Because all the mechanisms in SegHead depend on it. The TTC scales with the transaction rate, the block interval is constantly adjusting itself to be as short as possible without compromising network stability, both determine the minimum confirmation count per head required to meet the TTC, which determines the minimum head size and bandwidth usage.

Quote from: BlackHatCoiner on August 26, 2023, 12:51:46 PM

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.

Transaction fees are huge with Seghead, so miners have no reason to produce empty blocks, unless the mempool is empty. Sad

I see the need for it though. PoW blockchain networks are under constant assault by adversaries who are working to grow their own counterfeit blockchains in the hope of someday overtaking the genuine blockchains, so genuine blockchains can't afford to stop growing. If a genuine blockchain ever stops growing, it'll give counterfeit blockchains the opportunity to catch up and overtake them, which will cause the network to trust the counterfeit blockchain instead of the genuine one.

Cricktor

hero member

Activity: 714

Merit: 1010

Crypto Swap Exchange

Quote from: ABCbits on September 02, 2023, 04:40:53 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.

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

Quote from: SapphireSpire on July 31, 2023, 04:12:21 PM

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.

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

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?)

Quote from: SapphireSpire on August 26, 2023, 08:45:52 PM

counterfeit blockchains

Define "counterfeit blockchain".

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

Quote from: SapphireSpire on July 31, 2023, 04:12:21 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.

Quote from: SapphireSpire on July 31, 2023, 04:12:21 PM

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.

vjudeu

copper member

Activity: 813

Merit: 1944

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.

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

Quote from: vjudeu on July 31, 2023, 11:14:46 PM

Is it similar to BIP-300 and BIP-301?

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.

vjudeu

copper member

Activity: 813

Merit: 1944

Is it similar to BIP-300 and BIP-301?

SapphireSpire

jr. member

Activity: 49

Merit: 38

nothing to see here Sad

Topic: please delete (Read 355 times)