wsxdrfv (OP)
Jr. Member
Offline
Activity: 413
Merit: 5
|
|
February 15, 2018, 01:51:33 AM |
|
So bitcoin block generation speed is 10 minutes, is this minimum transaction speed?
Then how can faster it?
I find at 'chainparams.cpp', consensus.nPowTargetSpacing = 10 * 60;
So this is 10 minutes, so if I change it to 0.1 * 60, then transaction speed also become 6 seconds?
What else parameters should I change to speed up?
|
|
|
|
Random Seller
Newbie
Offline
Activity: 42
Merit: 0
|
|
February 15, 2018, 02:56:18 AM |
|
So bitcoin block generation speed is 10 minutes, is this minimum transaction speed?
Then how can faster it?
I find at 'chainparams.cpp', consensus.nPowTargetSpacing = 10 * 60;
So this is 10 minutes, so if I change it to 0.1 * 60, then transaction speed also become 6 seconds?
What else parameters should I change to speed up?
That will speed up transactions but you may not have enough time for all the nodes to record the transaction. If you do change it that way you should take a look at the reward amount for each block as decreasing blocktime will increase the supply of bitcoin introduced to the system. To increase transaction speed you may also want to take a look at blocksize.
|
|
|
|
achow101
Moderator
Legendary
Offline
Activity: 3570
Merit: 6927
Just writing some code
|
|
February 15, 2018, 04:27:06 AM |
|
So bitcoin block generation speed is 10 minutes, is this minimum transaction speed?
No, that is the average block time that we want. Then how can faster it?
I find at 'chainparams.cpp', consensus.nPowTargetSpacing = 10 * 60;
So this is 10 minutes, so if I change it to 0.1 * 60, then transaction speed also become 6 seconds?
If by transaction speed you mean confirmation time, then changing that will effect confirmation time because it effects the block time. Note that changing that does not guarantee that blocks will be found every 6 seconds, it only says that the average time in between blocks is 6 seconds. What else parameters should I change to speed up?
You will need to change the maximum proof of work target (which thus decreases the minimum difficulty). The proof of work target is what actually regulates block times.
|
|
|
|
DispatchLabs
Jr. Member
Offline
Activity: 420
Merit: 3
|
|
February 15, 2018, 06:03:57 AM |
|
A directed acylic graph (DAG) could be the answer as the confirmation of the transaction is done within the transaction itself with no blockchain. Plus it is friendlier for the environment. Of course, if the question is confined strictly to bitcoin then a change to DAG would likely never happen.
|
Dispatch Labs is a Distributed Ledger Technology Platform for Dapp Developers that is truly scalable, insanely fast with no transaction fees.
|
|
|
wsxdrfv (OP)
Jr. Member
Offline
Activity: 413
Merit: 5
|
|
February 15, 2018, 07:12:55 AM |
|
So bitcoin block generation speed is 10 minutes, is this minimum transaction speed?
No, that is the average block time that we want. Then how can faster it?
I find at 'chainparams.cpp', consensus.nPowTargetSpacing = 10 * 60;
So this is 10 minutes, so if I change it to 0.1 * 60, then transaction speed also become 6 seconds?
If by transaction speed you mean confirmation time, then changing that will effect confirmation time because it effects the block time. Note that changing that does not guarantee that blocks will be found every 6 seconds, it only says that the average time in between blocks is 6 seconds. What else parameters should I change to speed up?
You will need to change the maximum proof of work target (which thus decreases the minimum difficulty). The proof of work target is what actually regulates block times. Thanks. How to change the maximum proof of work target? for faster transaction time?
|
|
|
|
wsxdrfv (OP)
Jr. Member
Offline
Activity: 413
Merit: 5
|
|
February 15, 2018, 07:14:33 AM |
|
So bitcoin block generation speed is 10 minutes, is this minimum transaction speed?
Then how can faster it?
I find at 'chainparams.cpp', consensus.nPowTargetSpacing = 10 * 60;
So this is 10 minutes, so if I change it to 0.1 * 60, then transaction speed also become 6 seconds?
What else parameters should I change to speed up?
That will speed up transactions but you may not have enough time for all the nodes to record the transaction. If you do change it that way you should take a look at the reward amount for each block as decreasing blocktime will increase the supply of bitcoin introduced to the system. To increase transaction speed you may also want to take a look at blocksize. Thanks. Then how ethereum block generation time is so fast? (15 seconds maybe?) Is there enough time for nodes to record the transaction? And what is proper fastest time to wait all nodes record?
|
|
|
|
Random Seller
Newbie
Offline
Activity: 42
Merit: 0
|
|
February 15, 2018, 07:36:13 AM Last edit: February 15, 2018, 08:02:36 AM by Random Seller |
|
So bitcoin block generation speed is 10 minutes, is this minimum transaction speed?
Then how can faster it?
I find at 'chainparams.cpp', consensus.nPowTargetSpacing = 10 * 60;
So this is 10 minutes, so if I change it to 0.1 * 60, then transaction speed also become 6 seconds?
What else parameters should I change to speed up?
That will speed up transactions but you may not have enough time for all the nodes to record the transaction. If you do change it that way you should take a look at the reward amount for each block as decreasing blocktime will increase the supply of bitcoin introduced to the system. To increase transaction speed you may also want to take a look at blocksize. Thanks. Then how ethereum block generation time is so fast? (15 seconds maybe?) Is there enough time for nodes to record the transaction? And what is proper fastest time to wait all nodes record? Pre Segwit full nodes have a max blocksize of 1MB for bitcoin. In Ethereum the blocksize is variable but currently it’s around 22KB. If the blocksize is small you can afford faster block times. The fastest time, in my opinion is fairly arbitrary. Just put in what works for you. But test the hell out of it before you go live.
|
|
|
|
BTCerm
Newbie
Offline
Activity: 79
Merit: 0
|
|
February 20, 2018, 03:28:05 AM |
|
JUST BE PATIENT Spending more money on a transaction is not always the answer for most people. The best option is often to wait until the transaction is confirmed through normal means. Granted, this may take up a lot of valuable time, but it is also a reliable solution. You can still use the other three options if the transaction is still stuck after 24 hours or longer.
|
|
|
|
wsxdrfv (OP)
Jr. Member
Offline
Activity: 413
Merit: 5
|
|
February 20, 2018, 06:11:58 AM |
|
Thanks. Then how ethereum block generation time is so fast? (15 seconds maybe?) Is there enough time for nodes to record the transaction?
And what is proper fastest time to wait all nodes record?
Pre Segwit full nodes have a max blocksize of 1MB for bitcoin. In Ethereum the blocksize is variable but currently it’s around 22KB. If the blocksize is small you can afford faster block times.
The fastest time, in my opinion is fairly arbitrary. Just put in what works for you. But test the hell out of it before you go live.
Thx. How is blocksize after Segwit? Isn't it good to enlarge the size for store more transaction data? Or it is dynamically adjusted as that time's transaction amount?
|
|
|
|
galaxing
Jr. Member
Offline
Activity: 168
Merit: 1
|
|
February 20, 2018, 08:04:48 AM |
|
So bitcoin block generation speed is 10 minutes, is this minimum transaction speed?
Then how can faster it?
I find at 'chainparams.cpp', consensus.nPowTargetSpacing = 10 * 60;
So this is 10 minutes, so if I change it to 0.1 * 60, then transaction speed also become 6 seconds?
What else parameters should I change to speed up?
Transactions for bitcoin are still uncertain, will be nice and beautiful ,, but if the bitcoin transaction will be faster again ,, really cool.
|
|
|
|
Xynerise
Sr. Member
Offline
Activity: 322
Merit: 363
39twH4PSYgDSzU7sLnRoDfthR6gWYrrPoD
|
|
February 20, 2018, 08:40:00 AM |
|
Thx. How is blocksize after Segwit? With Segwit there is no longer a concept of "block size" instead "block weight" is used instead. https://medium.com/@jimmysong/understanding-segwit-block-size-fd901b87c9d4 Isn't it good to enlarge the size for store more transaction data? Simply enlarging the block size doesn't work; it's just kicking the can down the road. And increasing it to absurd levels Isn't even practicalOr it is dynamically adjusted as that time's transaction amount? A dynamic block size -- a la Monero -- has its own drawbacks. Scaling blockchains while keeping it decentralised is really hard.
|
|
|
|
wsxdrfv (OP)
Jr. Member
Offline
Activity: 413
Merit: 5
|
|
February 20, 2018, 09:20:20 AM |
|
Thx. How is blocksize after Segwit? With Segwit there is no longer a concept of "block size" instead "block weight" is used instead. https://medium.com/@jimmysong/understanding-segwit-block-size-fd901b87c9d4 Isn't it good to enlarge the size for store more transaction data? Simply enlarging the block size doesn't work; it's just kicking the can down the road. And increasing it to absurd levels Isn't even practicalOr it is dynamically adjusted as that time's transaction amount? A dynamic block size -- a la Monero -- has its own drawbacks. Scaling blockchains while keeping it decentralised is really hard. Thanks, so eventually for make alt-coin based on newest litecoin source, what parameters should I change about blocksize(weight), transaction amount per second? Or leave it as-is? I just changed block generation speed parameter only.
|
|
|
|
Colorblind
Member
Offline
Activity: 392
Merit: 41
This text is irrelevant
|
|
February 22, 2018, 05:49:23 AM |
|
So bitcoin block generation speed is 10 minutes, is this minimum transaction speed?
Then how can faster it?
I find at 'chainparams.cpp', consensus.nPowTargetSpacing = 10 * 60;
So this is 10 minutes, so if I change it to 0.1 * 60, then transaction speed also become 6 seconds?
What else parameters should I change to speed up?
The real answer is you you shouldn't speed it up. 10 minutes is an AVERAGE block time, but in theory it can be much faster for 2 weeks if you put in lots and lots of additional hash power into network. However this time is there to make sure network is stable and robust, you shouldn't aim to speed it up. There are plenty of solutions offering instant bitcoin transactions and LN will be instant settlement.
|
|
|
|
wsxdrfv (OP)
Jr. Member
Offline
Activity: 413
Merit: 5
|
|
February 22, 2018, 06:23:03 AM |
|
The real answer is you you shouldn't speed it up.
10 minutes is an AVERAGE block time, but in theory it can be much faster for 2 weeks if you put in lots and lots of additional hash power into network. However this time is there to make sure network is stable and robust, you shouldn't aim to speed it up. There are plenty of solutions offering instant bitcoin transactions and LN will be instant settlement.
How about change 2 weeks to just 1 day? or even 1 hour? Then lots and lots of hash power can't ruin?
|
|
|
|
Xynerise
Sr. Member
Offline
Activity: 322
Merit: 363
39twH4PSYgDSzU7sLnRoDfthR6gWYrrPoD
|
|
February 22, 2018, 06:46:50 AM |
|
The real answer is you you shouldn't speed it up.
10 minutes is an AVERAGE block time, but in theory it can be much faster for 2 weeks if you put in lots and lots of additional hash power into network. However this time is there to make sure network is stable and robust, you shouldn't aim to speed it up. There are plenty of solutions offering instant bitcoin transactions and LN will be instant settlement.
How about change 2 weeks to just 1 day? or even 1 hour? Then lots and lots of hash power can't ruin? The 2 weeks he's talking about is bitcoin's difficulty retarget/adjustment in which the rate of blocks being found increases or decreases based on the average hashrate for the last 2016 blocks (2 weeks) You can change the difficulty period to less than 2016 blocks but depending on how you implement it it can lead to disaster
|
|
|
|
|