You cannot run two instances of the node that points to the same blockchain directory at the same time. Bitcoin isn't designed for that.

If you want to only allow one IP to connect to you, the best way is probably to set up your firewall to only allow that IP to have incoming connections via port 8333.

Address is derived from the public key by taking the public key and:
1) Hash it using SHA256 once
2) Hash it using RIPEMD-160
3) Put the version byte at the front
4) SHA256 hash it twice
5) You'll be able to extract the checksum from the first few bytes
6) Insert the SHA256 hash at the end of the RIPEMD160 with version byte and BASE58 encode it.

Every address comes with a checksum. If you accidentally capitalise a character in the address, it'll not be valid.

As long as your 99 random bytes is within the range of acceptable values for an ECDSA private key, it's alright.

Let's take it as 01.
Your ECDSA private key is 01

From there, we'll convert it to an ECDSA public key by multiplying it against the generator point. The number of times the number gets multiplied against the generator point is dependent on the number of your private key which is once.

I thus obtain the ECDSA public key to be 0479BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798483ADA7726A3C 4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8.


After this, I'll do my steps 1 to 6.
1) SHA256 Hash of my ECDSA Public key
50929B74C1A04954B78B4B6035E97A5E078A5A0F28EC96D547BFEE9ACE803AC0
2) RIPEMD160 Hash of the above
91B24BF9F5288532960AC687ABB035127B1D28A5
3) Apprehending the network byte to the front (for P2PKH addresses on Bitcoin mainnet, it is 00)
0091B24BF9F5288532960AC687ABB035127B1D28A5
4) SHA256 the above
79FA926BF4AC874060B244D6E985C694233EED0D5562C0B88CDF37BFBB80B44F
5) SHA256 the above
0074FFE0526D823BE09B39865422A1D6135AFC85AFB0A6863C58E9FE89989170
6) Take the first 4 bytes as our checksum
0074FFE0
7) Apprehend the checksum to the end of the SHA256 hash
0091B24BF9F5288532960AC687ABB035127B1D28A50074FFE0
Use BASE58 encoding
1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm

The address generated is an uncompressed P2PKH address. There are different standards which may (P2PWSH, P2PWKH) or may not utilise ECDSA for a keypair (P2SH).

The signature is contained inside the scriptsig of the transaction. Every wallet that sends a transaction on chain automatically signs the transaction to provide the signature inside the scriptsig. Inside the scriptsig, it contains the signature of the transaction and the public key that is used to signed the transaction. Given the property of ECDSA, you can verify that the signature is signed with a specific private key when you're given the corresponding public key.

With the public key, you can hash it to form a P2PKH/P2PWKH address. From there, you can also validate that the transaction is spending the correct UTXOs that belongs to that specific address.

I know Bitpay used to have a zero confirmation transaction system. They do a risk analysis of your transaction and would require the user to wait if it's too high for the merchant. IIRC, some POS system does this also.
Actually, I find that most of them do not accept transactions with an unconfirmed parent; the risk is too high, RBF enabled or not.
As long as the propagation of a non-RBF transaction is good, then I don't see a huge risk of it encountering this scenario. If it's well propagated, most of the nodes won't accept it anyways, rendering the attack useless. BIP66 helped to fixed this issue largely but I'm not sure how easy is it to execute such an attack right now.

Segwit does help with this attack significantly and that is a point to consider.

That's very neat. It's pretty ideal for my fairly underpowered system. Will use it for one of my nodes in the future. Thanks!

I've set up a node from a PHP script I found on github[1] and a Bitcointalk thread[2] with a little modification of my own. It's quite a simple page that displays the data without the graph. I've tried statoshi again and unfortunately, it was quite unusable for some reason.

My node is here: http://51.159.55.21/ . Uptime might be a bit spotty while I modify it as I go. I'll make my own status page when I have the time to code .


[1] https://github.com/craigwatson/bitcoind-status
[2] https://bitcointalk.org/index.php?topic=916634.0

Segwit is helping. The average size in byte is about 1.4MB right now, which is 40 percent more than previously. It was achieved with a soft fork and not cause any issues.
Optimization is the way to go. If you want Bitcoin to be like a payment processor like Visa, increasing the limit won't help with decentralisation. Segwit worked. Lightning network is working. There are proposals such as MAST(BIP114), Schnorr signature that helps to optimize the individual Bitcoin transactions. I admit that increasing block size could potentially be a viable option but it does have some drawbacks.

---

I won't reply to this thread anymore. Seems like you aren't really into discussing the possible solutions and just dismissing all of them.

For the given dataset, if the data is accurate, then your point is valid. Though its important to note that correlation =/causation.

However, the bigger issue right now is about controlling the fees. To be able to fix fees to a reasonable level, you'll have to increase the network capacity to a fairly large extent, way more than the current capacity (whereby it might not be as viable to host a node). If you don't increase the capacity enough, then there's a risk for the mempool to get stagnant at a fixed max fee rate whereby a price ceiling is implemented to control the fees. Since you can't let miners select the fees, then you're making everyone wait longer which still decreases the utility of crypto.

If you want to control the fees, you'll have to be able to increase the capacity first.

The Bitcoin supply is fixed; there are no plans to increase the supply.

Market cap is fixed and there's no way that people would be supporting an increase of the market cap. Doing so would just dilute the current Bitcoin and increase inflation. The fixed inflation is a core feature of Bitcoin and it is unlikely to change. Even with changing demand, a Bitcoin would be worth more and people can buy a fraction of a Bitcoin instead of the full Bitcoin. If Bitcoin ever gets too expensive, we'll probably be able to do a fork to introduce more denominations.

I'm aware but the installation process is quite long. I did it once and I don't think I need that much statistics. I'm looking for a more simplistic one like Shorena's [1] but I can't seem to find any way to replicate it. But well, if there's no alternatives then I guess I'll be going with statoshi again.

[1] http://188.68.53.44/

I'm thinking of something like statoshi but it isn't really my expertise to design a nice looking site. I'm trying to see if anyone has any better alternatives, or else I'll just make my own. 

I'm trying to set up my own Bitcoin node with another (quite underpowered) dedicated server I just bought. I'm looking for some script to display the statistics of my node (mempool data, traffic etc). Is there any lightweight scripts that does this easily?

List A - E ranochigo

Thanks for the raffle! 

It would make attacking the network less costly since it would take less to generate blocks faster than the rest in the network. However, you have to consider the resources needed for a 51% attack. Rationally, it still wouldn't take place since the amount of hashrate you'll still have to gather is a pretty significant amount. You can't use money to buy that much hashrate. Blocks would be mined at a longer interval until at least the next difficulty adjustment.
The big farms located in the other countries would take over. It's just that China will no longer have the largest concentration of hashrate.

---

---

Crypto mining is probably one of the bigger sources of revenue for some of the provenience and the larger government. Spending billions to attack a crypto and wasting all the ASICs that they have won't do any good and the community will just fork the coin and shift elsewhere. Its just not to their best interest.

79 - ranochigo

Thanks for hosting the raffle!

Given an infinite resources, the value could be fixed such that this doesn't affect Bitcoin's stability. The value can't be fixed to respond to changes in the exchange rate vs fiat but it could only be fixed to a certain Bitcoin amount. It would be hard for the network to reach a consensus about the value of Bitcoin unless there is a central authority (exchange, weighted average of exchanges) to decide this.

Bitcoin's realistic minimum fee is 1 satoshi/byte.

Assuming that you're talking about minimum fees for a transaction to get confirmed within a timeframe, it shouldn't be fixed. Bitcoin's capacity is not infinite and will probably never be. The fees market won't be affected much even if you were to impose such a restriction. The miners can only include that many transactions and not all the transactions above the fee rates would be cleared in the timeframe; the restriction would be pretty useless.

The message does not have to be decrypted because signing a message doesn't encrypt anything. Bitcoin uses ECDSA as a message signing mechanism. The way ECDSA works allows the user to sign a message using their private key and others to use the corresponding public key to validate it. This works the same way as how a signature in a transaction works.

To sign a transaction, the user will utilise their private key to sign a message to produce a string of characters.

When a user validates the message, the script will use the signature and message to calculate the possible public key(s) that could be associated with it. Given the signature and the public key, the script can then validate it with message. If the address given and the message is correct for the given signature and derived public key, the program would confirm it.

If the message corresponds, you can assume that the person signed it with his private key and he has access to it.

You can't. Corrected below. The only way is either:
1. You trust that the hash is accurate and the person isn't lying.
2. You download the entire source code and compile it yourself. If you're not reviewing the code yourself, I find it pretty pointless since you're just blindly downloading and compiling it. Else, you can review and compile Bitcoin Core using this guide[1].




[1] https://github.com/bitcoin/bitcoin/blob/master/doc/build-windows.md

Bitpay used to be able to offer instant exchange to fiat immediately after a transaction and this helped to eliminate that issue. It's true that Bitcoin can lose loads of value in a matter of hours but the same goes the other way. IMO, for most online stores, this may not be that big of an issue. Merchants has to pay the payment processors a cut from their profits either ways. If Bitcoin can provide faster settlement while having lower risk and fees, then it could be worth it.

For physical stores, it's not really favourable.

Armory is not very well maintained and it hasn't actually been improved on much for the past few years.

It doesn't support pruning as it builds its own database using Bitcoin Core's data. Without a full blockchain, Armory cannot function.

Using segwit, an average transaction takes about $1 to get a confirmation within a very reasonable amount of time. If you're willing to do so, $0.50 could bring it to a few hours only. Like I said, there are improvements and there isn't any silver bullet solution without compromises. If anyone does have one, please bring it to the table instead of creating a thread and whining about it.

The miners didn't decide the fees in this case. The mempool is unusually full due to the huge volume and there is a backlog of transactions waiting to be cleared. Profitable or not, the miners couldn't decide on the fee rates. The offset of their loss of earnings comes mainly from the difficulty adjustments.