The point of the stake your address thread is to post your address, not just a message and a signature. You should see addresses in there, not just messages and signatures.

But even with just a message and signature, you can still get an address, it just may not be the correct one.

Signature verification requires three items: the signature, a message, and a public key. Typically you pass all three into a verification algorithm which tells you whether the signature is true or false. However, with just the signature and the message, you can get a public key which is valid for the message and signature. You can then compute the address for that public key.

Keep in mind that any signature and message combination can be used to produce a public key. That does not mean that the private key for that public key is the one that actually produced the signature or that the message is the message that was actually signed. Part of signature verification is to also provide the public key to prove that the owner of the private key for that public key signed the message, not just that the message and signature are both valid. The public key is an important part of signature verification.

It doesn't have to be correct. You can really set it to any IP address you want, the field is pretty much ignored. Many clients will set it to 127.0.0.1 if they don't know, and some set it to that even if they do know their external IP address.

I don't think it is as small as you think it is. The field is a 32 bit integer. By the birthday paradox, you would only need 65536 nodes before it is likely that two of those nodes happen to generate the same nonce. While this is still fairly small, it is trivial to make this a non-issue by randomly generating a random value. Sure you can take a shortcut and no one would really care, but for the benefit of the network, we want to reduce these chances to as close to 0 as possible. We want the best possible and your idea is not the best possible.

Yes, you could just connect to another peer.

If you think that Microsoft is trying to control GIthub for cryptocurrencies, then you are delusional. Cryptocurrencies are not the only things on GitHub and probably not at all what Microsoft cares about when they bought Github.

The reason for the acquisition is almost definitely for business reasons. First of all, Microsoft is a huge user of GIthub with tons of repositories. There were probably some features that Microsoft wanted that Github was unable to implement. By acquiring Github, Microsoft can make those features happen themselves. Furthermore, GIthub itself probably would like to have more financial and infrastructure support. Both of those things Microsoft can provide by utilizing its own cloud services and the fact that Microsoft has a lot of money. Github is largely free to use but the infrastructure to support all of the services that they offered is most certainly not free.

Another thing to note is that Github has recently had issues with properly serving Pull Requests (sometimes they would fail to load). This may be indicative of infrastructure problems that they were having. With the Microsoft acquisition, those problems may go away as they will have more financial support and more infrastructure to use.

I honestly don't think that the acquisition is all the doom and gloom that everyone makes it out to be. I don't think that Microsoft acquired Github to kill it, that wouldn't make sense given their large usage of Github.

The time to propagate blocks is completely unrelated to this. How does taking more time for a block to reach a non-mining node matter? If that non-mining node rejects the block, and if enough non-mining nodes reject the block, then the miners are still on a fork that is not being used so their coins are effectively worthless. The block propagation time is completely irrelevant; the point is not to prevent mining nodes from seeing those blocks, rather it is so that miners who are using a different blockchain from the rest of the network (which occurs regardless of block propagation times) are mining useless coins. Block propagation time has nothing to do with consensus.

No, it isn't. Bitcoin does not use an accounts model where an address is an account. It uses a UTXO model where each UTXO is independent of every other UTXO. Furthermore, addresses do not exist on the protocol level, so to do this, we would have to maintain a script index, but not all scripts map to an address anyways. Additionally, there are more than just the single pubkey addresses, you can have complex scripts for an address (P2SH) which greatly complicates things because those scripts can have pubkeys that are reused in other scripts. And then all nodes need to maintain a script index which requires significantly more computational power and a lot more disk space.

The MuSig paper has been updated to address the security flaw. See https://twitter.com/pwuille/status/998314349969031170

No, a node does not necessarily know his external IP address. Your computer typically does not know its external IP address unless someone tells you it. This is especially the case if your computer is behind a NAT (usually setup by a router), which it typically is.

A random nonce allows you to avoid having the same nonce generated by someone else. If you happen to use the same nonce as someone else, you would not be able to connect to them as both nodes would think the connection was to themselves and drop it. Even with a randomly generated fixed nonce at the beginning of a session, the two nodes would never be able to connect with each other. With random nonces for every message, even if the nonces collide, the connection can be tried again and a new nonce will be used which is unlikely to collide.

Please do not post meta topics in non-meta forums. Also note that if you were banned on one account, you cannot return with another account to post; that is considered ban evasion and is a bannable offense.

No, that is not the code that calculates fees. It is for calculating a fee given a fee rate which is only used for creating transactions, not receiving transactions.

You would have to use the low level API directly. The high level libraries abstract this away, but without the high level library, you have to use the low level API. Or you can write some translation interface between Python and C#.

We have absolutely no idea whether BIP 91 was actually being enforced. There were zero non-conforming blocks found following BIP 91's activation. I highly suspect that BIP 91 was not actually being enforced by the majority of the hashpower or by users, they were simply signalling BIP 91 and following its consensus rules with threat of being kicked off of the network for not conforming being enough to get miners to follow the consensus rules. In the past with other soft forks, miners have actually signaled for a soft fork without actually enforcing its consensus rules post-activation; they were simply setting the correct version number. It just so happens that in most cases, miners did not create invalid blocks following the fork.

The UASF really was not rushed. It happened with months of notice and a lot of users were joining in on it. Obviously Bitcoin Core did not release anything related to the UASF

This is completely and absolutely false. Bitcoin Core at no point in time implemented BIP 148 or BIP 91 nor was there any release of Bitcoin Core which supported BIPs 148 or 91. All attempts to implement BIP 148 and BIP 91 into Bitcoin Core were never merged. There was no release of Bitcoin Core that contained any support for BIPs 148 or 91. All clients that did support it were software forks of Bitcoin Core and created by primarily (i.e. mostly) by individuals unrelated to Bitcoin Core (as in they have not contributed to Bitcoin Core before). While some Bitcoin Core developers did partake in the alternative implementations for BIPs 148 and 91, this does not mean that Bitcoin Core supported it nor does it mean that Bitcoin Core rejected non-segwit signalling blocks on August 1st as Bitcoin Core itself did not have code for that.

I am not sure what you mean by "have to authenticate" or "verified by".

A HTTPS certificate is issued by a Certificate Authority (CA). CAs include Comodo, DigiCert, Let's Encrypt, etc. The certificate for Bitcointalk.org is issued by Comodo. For a CA to issue a certificate, they need to verify some information. The most basic verification is domain verification where the issuer asks the requester to prove that they control the domain the certificate will be issued for. This proof is usually by putting a specific string generated by the CA at a particular path on the website. The other kind of verification is Extended Validation which is what this topic is about. Extended Validation also verifies the identity of the requester and the certificate includes this identity.

Every website should have its own HTTPS certificate. If certificates are shared between sites, then there is risk for security issues.

Those are the indicators for Extended Validation HTTPS certificates. Such certificates are tied to an actual legal entity and the certificate issuer has to verify that the legal entity is actually requesting the certificate before the certificate is issued.

Since people have taken to spamming this topic with nonsense, this thread will be locked.

Yes, this is normal.

That is impossible to do. Bitcoin does not work that way. First of all, Bitcoin does not actually use addresses or accounts on the technical level. It is just UTXOs, and UTXOs have a script that is generated from an address. A UTXO is not aware of any other UTXO and finding other UTXOs that have the same script (i.e. the same address) is computationally expensive.

No, you cannot.

.. Well ok then. Electrum does validate BIP 39 seeds properly, and, AFAIK actually follows the BIP 39 spec to the word.

The seed is likely a BIP 39 seed then.

So this is what we know:

• 12 word BIP 39 seed
• BIP 49 derivation path is default (m/49'/0'/0')
• Came from a Trezor T
• OP used Trezor web interface

Did OP use any other accounts besides the default account?

I'll take a look through the Trezor code and docs to see if there is any unexpected behavior like generating with different purposes or coins or whatever.

One last thing. Litecoin's P2SH addresses used to also start with a 3. So for segwit, a Litecoin address looks identical to a Bitcoin address. Is it possible that the key was generated on the Litecoin derivation path somehow?

Use the dumpwallet RPC command. Do bitcoin-cli dumpwallet <filename> where <filename> is the name of the file you want the wallet data to be written to. Open up that file as a regular text file. At the top of it will be something that has the master private key (an xprv). Somewhere in the file will be a private key with the hdkeypath listed as "m". That is the seed. Note that the seed is not a phrase; Bitcoin Core does not use mnemonics (which are often misnamed as seeds).

It's possible, but it's also rather unlikely.

BIP 39 wallets are not supposed to just accept any seed. Rather they are supposed to warn you if a seed is invalid. However some wallets may not be implemented in this way and may not actually be checking the validity of a seed before using it. I suspect that is actually what is happening here.