Search content
Sort by
Showing 20 of 24 results by nathan_24
Do you think the crypto community could use at least one more exchange site (like gdax, bitstamp, bitfinex, etc), given the fact that current exchange sites are being overloaded way beyond what they would have expected? Or do you think there are already enough, or even, too many?
Re: Post your SegWit questions here - open discussion - big week for Bitcoin!
Does the private key in WIF format tell if the address associated is segwit?
Since the same priv key can generate both segwit and non-segwit addresses, when importing a WIF-encoded priv key, should we ask the user if it is segwit or is that information obtained from the wif-encoded key itself?
Since the same priv key can generate both segwit and non-segwit addresses, when importing a WIF-encoded priv key, should we ask the user if it is segwit or is that information obtained from the wif-encoded key itself?
Re: Why does the testnet difficulty permanently drops to around 1 periodically?
The difficulty will reset to 1 if the time since the last block is more than 20 minutes. There is no stipulation that after a difficulty reset block that the next block must be the normal difficulty; if the next block is more than 20 minutes after the current block, then it can also have a difficulty of 1.
For blocks that are found within 20 minutes of each other, the block's difficulty will be the same as the difficulty of the last block in the difficulty interval whose difficulty was not 1 OR the difficulty of the first block in the difficulty interval. This behavior is defined here: https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp#L32. Because the difficulty look back is clamped to be the first block in the interval, if that block was found more than 20 minutes after the block before it, its difficulty will be 1, and so will all subsequent blocks in the difficulty period. After 2016 blocks, the difficulty adjustment will kick in and bring the difficulty back up.
So the behavior we are observing is that the first block of a difficulty interval (block height % 2016 == 0) is found 20 minutes or more after the previous block, so its difficulty is 1. Then blocks that are mined after it use the difficulty of 1 because that is the difficulty of the first block in the interval.
For blocks that are found within 20 minutes of each other, the block's difficulty will be the same as the difficulty of the last block in the difficulty interval whose difficulty was not 1 OR the difficulty of the first block in the difficulty interval. This behavior is defined here: https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp#L32. Because the difficulty look back is clamped to be the first block in the interval, if that block was found more than 20 minutes after the block before it, its difficulty will be 1, and so will all subsequent blocks in the difficulty period. After 2016 blocks, the difficulty adjustment will kick in and bring the difficulty back up.
So the behavior we are observing is that the first block of a difficulty interval (block height % 2016 == 0) is found 20 minutes or more after the previous block, so its difficulty is 1. Then blocks that are mined after it use the difficulty of 1 because that is the difficulty of the first block in the interval.
As far as I know, the difficulty of a block multiple of 2016 doesn't change if it takes more than 20 minutes to process. Such blocks are the only ones not affected by that rule in the testnet.
The difficulty of such blocks is calculated depending on the difficulty of the block immediately prior to them. If that block took more than 20 minutes, then this block could have the difficulty set to 1 as well, and so would the blocks mined after this one.
I said "could" because, if the previous 2,016 blocks took less than 2 weeks to process, then the difficulty could be slightly greater than 1.
Neither they know if they will be the ones finding the current block.
Hi TryNinja, thanks for your reply!
As I explained in the first post, miners just have to not relay those spammy transactions into the bitcoin network until they mine the block, so that they don't get included in the blockchain by other miner.
When they finally mine a block and broadcast it, that's the first time the network gets to know about those spammy txs, and the miner gets back all the fees that they spent.
[PROBLEM & SOLUTION] Blocks fees to be rewarded to the next block's miner?
Hi!
I was thinking yesterday about an idea that I think could help to solve one specific problem of bitcoin. Let me know what you think!
Users decide what fee they want to spend on a tx depending on how fast they want it to be confirmed. Blocks can hold a limited amount of txs, so, miners always try to include those that paid the most satoshis/byte first. When there is network congestion (more txs being sent that can fit in a block), either you pay higher fees or your txs could take longer than expected to confirm.
The client (software, website wallets, etc) suggests the user a "recommended fee" for their txs, which is calculated, among other things, depending on the fees paid by txs included in the previous blocks.
The problem: Malicious miners could use this to increase the fee users have to pay to send txs. They could create lots of spammy txs with high fees, include them in their own block, and then the network would think you must spend higher fees to get your txs confirmed. Since miners are including those txs in their own blocks (without actually relaying them to the network so that they won't get mined by other miners), they would be receiving the fees of such txs, and it would be cost-less for them.
Due to this, miners could potentially make the fees go higher with no cost for them. They probably do it or they probably don't, we don't know. But I would sleep better at night if I knew they don't do it because they CAN'T, rather than because they are good people and they wouldn't do such thing.
The solution: One easy way to solve this could be if, when a block gets mined, the fees obtained by the block, instead of being claimed by the miner that mined THAT block, they are claimed by the miner that mines the NEXT block.
That way, malicious miners would be no longer interested in including lots of txs paying lots of fees on a block to raise the "recommended fee", because they can't be sure they will be lucky and mine the next block to get the fees they paid back. It would no longer be profitable for them.
Miners would however still be interested in filling in the blocks and including as many transactions as possible, since they could actually be the ones to mine the next block, and if that's the case, they would still want to get the biggest reward possible.
How to implement: I haven't thought this part carefully yet, but I think this could be done in a way that is completely backwards-compatible. All we would need to do is to add a new rule on future versions of the bitcoin client in which they will only validate new blocks if the coinbase tx pays the reward to an specific "anyone-can-spend" output, such as an script that doesn't require any signature to be validated, or just a bitcoin address derived from a private key which is public and hardcoded in the client. That way, miners could add a secondary transaction spending the coins gathered by the previous block (or actually, 100 blocks before, since the coinbase txs needs to mature for some blocks before it is spent).
Thanks for reading! Thoughts?
I was thinking yesterday about an idea that I think could help to solve one specific problem of bitcoin. Let me know what you think!
Users decide what fee they want to spend on a tx depending on how fast they want it to be confirmed. Blocks can hold a limited amount of txs, so, miners always try to include those that paid the most satoshis/byte first. When there is network congestion (more txs being sent that can fit in a block), either you pay higher fees or your txs could take longer than expected to confirm.
The client (software, website wallets, etc) suggests the user a "recommended fee" for their txs, which is calculated, among other things, depending on the fees paid by txs included in the previous blocks.
The problem: Malicious miners could use this to increase the fee users have to pay to send txs. They could create lots of spammy txs with high fees, include them in their own block, and then the network would think you must spend higher fees to get your txs confirmed. Since miners are including those txs in their own blocks (without actually relaying them to the network so that they won't get mined by other miners), they would be receiving the fees of such txs, and it would be cost-less for them.
Due to this, miners could potentially make the fees go higher with no cost for them. They probably do it or they probably don't, we don't know. But I would sleep better at night if I knew they don't do it because they CAN'T, rather than because they are good people and they wouldn't do such thing.
The solution: One easy way to solve this could be if, when a block gets mined, the fees obtained by the block, instead of being claimed by the miner that mined THAT block, they are claimed by the miner that mines the NEXT block.
That way, malicious miners would be no longer interested in including lots of txs paying lots of fees on a block to raise the "recommended fee", because they can't be sure they will be lucky and mine the next block to get the fees they paid back. It would no longer be profitable for them.
Miners would however still be interested in filling in the blocks and including as many transactions as possible, since they could actually be the ones to mine the next block, and if that's the case, they would still want to get the biggest reward possible.
How to implement: I haven't thought this part carefully yet, but I think this could be done in a way that is completely backwards-compatible. All we would need to do is to add a new rule on future versions of the bitcoin client in which they will only validate new blocks if the coinbase tx pays the reward to an specific "anyone-can-spend" output, such as an script that doesn't require any signature to be validated, or just a bitcoin address derived from a private key which is public and hardcoded in the client. That way, miners could add a secondary transaction spending the coins gathered by the previous block (or actually, 100 blocks before, since the coinbase txs needs to mature for some blocks before it is spent).
Thanks for reading! Thoughts?
You say that difficulty can't go lower than that because of the algorithm, but it is much lower in the testnet, for example.
Is there a hard-coded minimum difficulty then?
Testnet does have a minimum difficulty of 1 though it is not equivalent to the difficulty on the mainnet. Is there a hard-coded minimum difficulty then?
Yes, the lowest possible target is hardcoded into the client.[1]
[1] https://github.com/bitcoin/bitcoin/blob/1b046603b30ebfab6199a2f92015d507b248b590/src/pow.cpp#L82
That's it! I could read in the code that the minimum difficulty target is 0x00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff. That is transformed into 486604799 when compressed. Then that's why the difficulty never went lower, even when the blocks were produced slower than 2,016 blocks per 2 weeks.
Thanks!
There's nothing wrong with that. At that time, there were only a few machines (presumably only satoshi's) running to mine Bitcoins.
The network does try to keep the blocks at an interval of 10 minutes. At that time, the difficulty was set at 1 and it is impossible to go lower than that, as per the algorithm that calculates the difficulty.
The network does try to keep the blocks at an interval of 10 minutes. At that time, the difficulty was set at 1 and it is impossible to go lower than that, as per the algorithm that calculates the difficulty.
You say that difficulty can't go lower than that because of the algorithm, but it is much lower in the testnet, for example.
Is there a hard-coded minimum difficulty then?
As far as I know, the difficulty must be re-targeted every 2,016 blocks. It is increased or decreased depending on how long it took to process the previous 2,016 blocks.
Block 0 (genesis) has a timestamp of 1231006505, and block 2,015, has 1233061996. That makes a difference of 2055491 seconds, which is roughly 23-24 days. That is more than 2 weeks (14 days) so, the difficulty should have been decreased a little at block 2,016, but it didn't. It remained exactly at 486604799.
It also didn't change at blocks 4,032, 6,048, 8,064, 10,080... and I haven't checked anymore.
What kind of Dark Magic is behind this anomaly?
Block 0 (genesis) has a timestamp of 1231006505, and block 2,015, has 1233061996. That makes a difference of 2055491 seconds, which is roughly 23-24 days. That is more than 2 weeks (14 days) so, the difficulty should have been decreased a little at block 2,016, but it didn't. It remained exactly at 486604799.
It also didn't change at blocks 4,032, 6,048, 8,064, 10,080... and I haven't checked anymore.
What kind of Dark Magic is behind this anomaly?
Re: Post your SegWit questions here - open discussion - big week for Bitcoin!
Hi! I am reading about segwit and I have several questions about it.
1) I've read that a segwit transaction cannot spend non-segwit utxos. Is this correct? How can you then create your first segwit transaction, if you only have non-segwit utxos? I am sure I am missing something there.
2) Is the new segwit serialization format really backwards compatible? I have been looking at it and I am pretty sure that wallets that do not understand segwit will not be able to recognize a segwit transaction, and thus, they might think that the block is invalid for including non-standard transactions?
3) I also read that there will now be two ways of identifying transactions, the txid (which is the hash of the transaction serialized the old way) and the wtxid (the hash of the transaction serialized as segwit). When signing the transactions, do you also use the old serialization to calculate the hash you need to sign? or do you serialize it as segwit? (in which case, again, old wallets would not be able to verify the signature).
4) If the txid included in the merkle tree is not the wtxid, then, how can you tell if a transaction is segwit or not when it is presented to you using the old serialization?
Thanks a lot in advance!
1) I've read that a segwit transaction cannot spend non-segwit utxos. Is this correct? How can you then create your first segwit transaction, if you only have non-segwit utxos? I am sure I am missing something there.
2) Is the new segwit serialization format really backwards compatible? I have been looking at it and I am pretty sure that wallets that do not understand segwit will not be able to recognize a segwit transaction, and thus, they might think that the block is invalid for including non-standard transactions?
3) I also read that there will now be two ways of identifying transactions, the txid (which is the hash of the transaction serialized the old way) and the wtxid (the hash of the transaction serialized as segwit). When signing the transactions, do you also use the old serialization to calculate the hash you need to sign? or do you serialize it as segwit? (in which case, again, old wallets would not be able to verify the signature).
4) If the txid included in the merkle tree is not the wtxid, then, how can you tell if a transaction is segwit or not when it is presented to you using the old serialization?
Thanks a lot in advance!
Re: Post your SegWit questions here - open discussion - big week for Bitcoin!
Hi! I have several doubts regarding SegWit.
Starting on August 1st, will ALL transactions in the blockchain be in segwit format? Is it a format imposed if you want your transaction included in the blockchain? Or is it optional? Or there is no transaction format change at all and it is just about the way it will be stored in the blockchain by the miners?
Thanks a lot in advance!
Starting on August 1st, will ALL transactions in the blockchain be in segwit format? Is it a format imposed if you want your transaction included in the blockchain? Or is it optional? Or there is no transaction format change at all and it is just about the way it will be stored in the blockchain by the miners?
Thanks a lot in advance!
Will transaction fees drop after Aug 1st? How long will it last?
With blockchain split or not, I am sure the new block structure allowing for more transactions will cause fees to drop, which would be great news, because they have been too high for too long imo.
But in case that happens, you think it will last for long? Will we be able to enjoy small fees like we used to in the good old days for a long period of time?
But in case that happens, you think it will last for long? Will we be able to enjoy small fees like we used to in the good old days for a long period of time?
The timestamp of the block 57060 is lower than the median of the prev 11 blocks
⭐ Merited by ABCbits (1)
I was reading the developer reference and I found this:
It's nice to have that rule in the protocol because otherwise miners could set any timestamp in the past. But I don't understand how is it possible that the block 57060 doesn't follow that rule. As you can see, it has a timestamp of more than one hour before the previous block. That shouldn't be a problem if the timestamp was still greater or equal the median of the previous eleven, but it turns out it is not.
The median of the blocks [57049-57059] is 1274556410.5454545, and thats +797 seconds ahead of the timestamp of the block 57060.
How is this possible?
Quote
The block time is a Unix epoch time when the miner started hashing the header (according to the miner). Must be greater than or equal to the median time of the previous 11 blocks. Full nodes will not accept blocks with headers more than two hours in the future according to their clock.
It's nice to have that rule in the protocol because otherwise miners could set any timestamp in the past. But I don't understand how is it possible that the block 57060 doesn't follow that rule. As you can see, it has a timestamp of more than one hour before the previous block. That shouldn't be a problem if the timestamp was still greater or equal the median of the previous eleven, but it turns out it is not.
The median of the blocks [57049-57059] is 1274556410.5454545, and thats +797 seconds ahead of the timestamp of the block 57060.
How is this possible?
Code:
Height Timestamp
57049 1274553925
57050 1274554547
57051 1274554591
57052 1274554864
57053 1274555612
57054 1274555564
57055 1274556515
57056 1274557815
57057 1274558735
57058 1274558865
57059 1274559483
57060 1274555613
57049 1274553925
57050 1274554547
57051 1274554591
57052 1274554864
57053 1274555612
57054 1274555564
57055 1274556515
57056 1274557815
57057 1274558735
57058 1274558865
57059 1274559483
57060 1274555613
Hi!
I am working on an idea for an alt-coin that could ideally be used forever without its blockchain size constatly growing...
I think I had an idea for this alt-coin and I would love to know if it could work or not, and why.
This alt-coin is designed in a way that you only need to know the last X (lets say 2,016) blocks in order to know all you need to check your balance, send bitcoins, and do everything, and those blocks are not necessarily bigger than the blocks of bitcoin. That way we can keep pruning old blocks and keep only the last 2,016 blocks.
There is a problem to that: in order to be able to verify those 2,016 blocks you can get from the network, you need to keep at least the headers of all previous blocks to the first one, or if not, when given two valid chains by the network, you wouldn't know which one belongs to the valid blockchain.
My idea of solving that issue is the following:
Bitcoin calculates the blocks difficulty every 2,016 blocks. It increases the difficulty if the previous 2,015 blocks have been created very fast, and decreases it if they have been created too slow, in order to mantain a difficulty that causes the blocks to be created every 10 minutes.
My alt-coin would instead, every 2,016 blocks, calculate the new difficulty based on how far or how close the miner's clock is to the timestamp this block should have -> If the block 0 had a date of 1 Jan 0:00, then the block 1 was expected to have a date of 1 Jan 0:10, block 2 at 1 Jan 0:20, and so on. This way, we should be able to calculate the height of the blockchain right now by only checking our local time.
In this alt-coin, the blockchain would be pruned every 2,016 blocks, exactly at the block where a new difficulty is calculated. When you first connect to the network, you connect to some peers, and request them the last part of the blockchain, and they will reply you with the 2,016 blocks (and some more that where created recently and haven't yet reached 2,016). If any of them responds you with a chain that is too far in the past, or too far in the future, you drop it as invalid. If you are given more than one 2,016-chains of the same height, both apparently valid, you don't need to keep all the blockchain headers in order to check which one is valid and which one has been forged parallel to the valid blockchain, you just choose the one that has the highest bits value.
I guess this should work, as long as more than the 50% of the network CPU is owned by good people.
What do you think?
I am working on an idea for an alt-coin that could ideally be used forever without its blockchain size constatly growing...
I think I had an idea for this alt-coin and I would love to know if it could work or not, and why.
This alt-coin is designed in a way that you only need to know the last X (lets say 2,016) blocks in order to know all you need to check your balance, send bitcoins, and do everything, and those blocks are not necessarily bigger than the blocks of bitcoin. That way we can keep pruning old blocks and keep only the last 2,016 blocks.
There is a problem to that: in order to be able to verify those 2,016 blocks you can get from the network, you need to keep at least the headers of all previous blocks to the first one, or if not, when given two valid chains by the network, you wouldn't know which one belongs to the valid blockchain.
My idea of solving that issue is the following:
Bitcoin calculates the blocks difficulty every 2,016 blocks. It increases the difficulty if the previous 2,015 blocks have been created very fast, and decreases it if they have been created too slow, in order to mantain a difficulty that causes the blocks to be created every 10 minutes.
My alt-coin would instead, every 2,016 blocks, calculate the new difficulty based on how far or how close the miner's clock is to the timestamp this block should have -> If the block 0 had a date of 1 Jan 0:00, then the block 1 was expected to have a date of 1 Jan 0:10, block 2 at 1 Jan 0:20, and so on. This way, we should be able to calculate the height of the blockchain right now by only checking our local time.
In this alt-coin, the blockchain would be pruned every 2,016 blocks, exactly at the block where a new difficulty is calculated. When you first connect to the network, you connect to some peers, and request them the last part of the blockchain, and they will reply you with the 2,016 blocks (and some more that where created recently and haven't yet reached 2,016). If any of them responds you with a chain that is too far in the past, or too far in the future, you drop it as invalid. If you are given more than one 2,016-chains of the same height, both apparently valid, you don't need to keep all the blockchain headers in order to check which one is valid and which one has been forged parallel to the valid blockchain, you just choose the one that has the highest bits value.
I guess this should work, as long as more than the 50% of the network CPU is owned by good people.
What do you think?
You're gonna have to design it (HTML, CSS, and if you want dynamic elements that don't require refreshing the page, Java.) Then you'll need to have an organized back end db and likely use PHP for that, in addition to JSON-RPC calls to Local Bitcoind.
Let me know how it goes.
Let me know how it goes.
Just remember Java is not the same as JavaScript.
Quote
I tried to search if the OP_RETURN was no longer accepted by the network, but in fact it is. But I have read that it first allowed 80 bytes of information, and then they lowered it to 40 bytes... Who knows what they might do to my new best friend OP_RETURN in the future...
No, it was 80 bytes (I think never deployed though), then lowered to 40 bytes, then now it is back to 80 bytes.
The 0.12 version will allow multiple push in the OP_RETURN, but the limit will still be 80 bytes for all data (more precisely 83 bytes for the OP_RETURN script)
OP_RETURN is relatively safe, I don't think devs will break anything here since it does not cost anything on the UTXO set and is prunable.
If you want a reason not to use OP_RETURN, it would be if the fee rate rise so much than the added value of using OP_RETURN for your case is not worth the price of the added bytes in your transaction.
Thank you very much for your reply. I didn't know the limit was raised to 80 bytes again.
I will definitely keep using OP_RETURN for my application, unless someone comes up with a reason to not do it.
You can still use OP_RETURN. I highly doubt that it will be dropped. Try pushing it through other pushtx options like blockcypher or blocktrail's. You can also try pushing the transaction through your own full node, that should work. Blockchain.info is just being stupid as usual.
Hey thanks for the reply. Let me invite you to a cofee https://blockexplorer.com/tx/aa02fd76ad9004df566722d4f68a276def329c5f59ac25ca40fca718036f2227
If anyone else can provide any information on why I should not use OP_RETURN, I will award it.
I strongly prefer to pay somebody now rather than pay the consecuences in the future
I think you should learn how to make any simple website first, and then go for bigger things.
Anyawys, for the website design, you will need to learn HTML, CSS and Javascript.
After you have designed a beautiful website, you can use PHP as the server-side programming language, which will take care of managing users data.
You can have a bitcoin node running on the server, and set its options to allow RCP requests. That way PHP can communicate with the bitcoin node, and ask it anything about the blockchain. Search how to do this on google.
But remember there is no copy-paste-and-change-the-name free template on the internet for this. You will have to program it all by yourself.
Here is a way to start with the php-bitcoin communication part: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list
Good luck.
Anyawys, for the website design, you will need to learn HTML, CSS and Javascript.
After you have designed a beautiful website, you can use PHP as the server-side programming language, which will take care of managing users data.
You can have a bitcoin node running on the server, and set its options to allow RCP requests. That way PHP can communicate with the bitcoin node, and ask it anything about the blockchain. Search how to do this on google.
But remember there is no copy-paste-and-change-the-name free template on the internet for this. You will have to program it all by yourself.
Here is a way to start with the php-bitcoin communication part: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list
Good luck.