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?

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?

Bump

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.

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.

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?

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!

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?

Thank you very very much achow101. You helped me a lot with your reply

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!

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!

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?

Thanks bud <3

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?

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?

Just remember Java is not the same as JavaScript.

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.

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.