Bitcoin Forum
October 22, 2018, 12:37:42 AM *
News: Make sure you are not using versions of Bitcoin Core other than 0.17.0 [Torrent], 0.16.3, 0.15.2, or 0.14.3. More info.
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 ... 545 »
161  Bitcoin / Development & Technical Discussion / Re: Address from signature. on: June 06, 2018, 06:11:59 AM
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.
162  Bitcoin / Development & Technical Discussion / Re: Need some clarification on usage of the nonce in version message on: June 05, 2018, 04:27:51 AM
But in the version message I also have to specify my address (addr_from), so how do I do that if I don't know it?
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 if they don't know, and some set it to that even if they do know their external IP address.

Ok in principle I get that. But to me that does not make terribly much sense because the probability that any two nodes create the same nonce AND try to connect to each other is exceedingly small.
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.

So for that case I could just connect to another peer. Is that a fair statement?
Yes, you could just connect to another peer.
163  Bitcoin / Bitcoin Discussion / Re: Microsoft buying GitHub for 7.5 billion, Good or it's Death? on: June 05, 2018, 04:21:06 AM
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.
164  Bitcoin / Development & Technical Discussion / Re: Why do some people believe that only the nodes miners run matter? on: June 05, 2018, 04:08:54 AM
Craig Wright[1] had documented that a new block propagates within roughly 1 second to something on the order of ~98% of the hashrate. But the 1000s of nodes in the remaining ~2% of the hashrate can see significant delays. Mining nodes prioritize their connectivity to nodes which generate block solutions, because being late on mining a new block solution costs money.

Thus non-mining nodes are essentially ignored by the consensus system of Nakamoto proof-of-work. That is why user activated fork is nonsense. The only way the non-mining users can overrule the miners is to change the proof-of-work hash of the system (which is centralization because voting and politics is centralized manipulation).

Your non-mining full node can enable you to objectively validate transactions (which is not possible in ANY proof-of-stake systems), but can't have any appreciable impact on the consensus.

[1] Yeah I know he makes mistakes and is irritating, but a few of his points are correct.
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.
165  Bitcoin / Development & Technical Discussion / Re: ECDSA signatures: why not force the reuse for r for spends from the same address on: June 03, 2018, 04:38:53 PM
It ought to be possible to verify and disallow unique r values for spends from the same address.
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.
166  Bitcoin / Development & Technical Discussion / Re: Okamoto Beats Schnorr on: June 03, 2018, 05:34:16 AM
The MuSig paper has been updated to address the security flaw. See
167  Bitcoin / Development & Technical Discussion / Re: Need some clarification on usage of the nonce in version message on: June 03, 2018, 05:30:39 AM
I need some clarification. First, why do I need a nonce to detect a connection to myself, do I not just see that from the IP address?
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.

Second, why do I need to create a new nonce for EVERY version message? Can I not just always use the same nonce since this would still allow me to detect a connection to myself.
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.

My questions may not be the brightest from time to time, maybe just like the one above. But I do not think this is a reason to ban people just as you did with my prior account (schnuber2). You just banned me for no other reason than asking a legit question dude. I feel quite offended by this.

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.
168  Bitcoin / Development & Technical Discussion / Re: TX_FEE Question - Miners / Stakers on: June 01, 2018, 06:31:46 PM
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.
169  Bitcoin / Development & Technical Discussion / Re: Access Trezor using C# on: June 01, 2018, 06:30:31 PM
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#.
170  Bitcoin / Development & Technical Discussion / Re: On Segwit not being backwards compatible question on: May 31, 2018, 10:47:31 PM
Technically, it was the miners. By my recollection, there were not many BIP148 nodes at the time -- no surprise since it was rolled out on such a hasty timeline. BIP91 was activated by miners, and it was hashpower -- not users -- who meaningfully rejected non-conforming blocks.
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.

I believe this distinction is worth noting for posterity. The next time you guys plan on activating a UASF on such a rushed timeline, it may not work out so well.
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
171  Bitcoin / Development & Technical Discussion / Re: On Segwit not being backwards compatible question on: May 31, 2018, 09:56:19 PM
bitcoin CORE, on august 1st  rejected any blocks that were not signaling for segwit.
basically bitcoin core rejected all legacy blocks.. thus bitcoin core did actually split AWAY from the past.
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.
172  Other / Off-topic / Re: Not sure where to ask this question so here goes. on: May 30, 2018, 09:08:02 PM
So basically every website have a different certificates depend whatever certificates they have to authenticate?
and for example the image below is verified by DigiCert INC and bitcointalk forum is verified by COMODO CA Limited Am I right?

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 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.
173  Other / Off-topic / Re: Not sure where to ask this question so here goes. on: May 29, 2018, 10:09:52 PM
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.
174  Bitcoin / Development & Technical Discussion / Re: DagCoin: a cryptocurrency without blocks on: May 29, 2018, 10:07:08 PM
Since people have taken to spamming this topic with nonsense, this thread will be locked.
175  Bitcoin / Development & Technical Discussion / Re: When send to own wallet's address, listtransactions send, receive both printed? on: May 29, 2018, 02:45:38 AM
Yes, this is normal.
176  Bitcoin / Development & Technical Discussion / Re: CHECKSEQUENCEVERIFY After x time of last transaction on: May 29, 2018, 01:26:35 AM
Thatís a shame.
Do you know of any way where i can have a multi-sig address which will allow one of the signers to use only their single key after a set amount of time after each transaction/update on the address?

I want to have an address that requires 2 people to sign for outgoing transactions. But if after 30 days nothing has been done with the address at all a single user can sign a transaction. But if there is ever anything such as an incoming or outgoing transaction the 30 days is reset.
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.
177  Bitcoin / Development & Technical Discussion / Re: CHECKSEQUENCEVERIFY After x time of last transaction on: May 28, 2018, 04:46:36 PM
I could make it so not just 30 days, but 30 days from last transaction.
No, you cannot.
178  Bitcoin / Development & Technical Discussion / Re: Help Me Recover My Bitcoins. on: May 28, 2018, 04:55:32 AM
Well... this falls into the "unlikely" category then I guess... unless both Electrum and Ian Coleman's Mnemonic tool are not validating BIP39 seeds properly...
.. Well ok then. Electrum does validate BIP 39 seeds properly, and, AFAIK actually follows the BIP 39 spec to the word.

In other news... the OP has told me that they are using a Trezor T... apparently the "T" defaults to using a 12 word seed (unlike the Trezor One), hence my confusion about 12 vs. 24 word seeds. OP has also mentioned that they had not used Electrum prior to trying to fix this issue. Unfortunately, this puts us back at square one. Undecided
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?
179  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.0 Released on: May 28, 2018, 03:40:38 AM
I have just installed bitcoind 0.16 in Linux. How can I get the seed of the HD wallet ?

I dont have nor want bitcoin-qt, only bitcoin-cli
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).
180  Bitcoin / Development & Technical Discussion / Re: Help Me Recover My Bitcoins. on: May 27, 2018, 07:50:28 PM

Well that's the really curious thing... this 12 word seed shows up as "valid" according to BIP39 wallets??!? Huh So this combination of words is apparently a valid BIP39 seed... AND a valid Electrum SegWit seed... Shocked
Is this really possible? Huh
Both formats use different schemes to calculate the checksum, is it possible for there to be anintersection between both?
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.
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 ... 545 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!