Bitcoin Forum
September 21, 2018, 06:53:13 PM *
News: ♦♦ New info! Bitcoin Core users absolutely must upgrade to previously-announced 0.16.3 [Torrent]. All Bitcoin users should temporarily trust confirmations slightly less. 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 ... 543 »
121  Bitcoin / Development & Technical Discussion / Re: Leaf-Node weakness in Bitcoin Merkle Tree Design on: June 11, 2018, 08:22:24 PM
Protecting against this is fairly trivial. Actually fixing the problem requires a hard fork unfortunately as the entire merkle tree structure needs to be redone.

The cost of exploiting this vulnerability is pretty high. With as much hashrate as Bitmain, there are easier and cheaper attacks that can be performed against SPV wallets that are inherent to how SPV wallets work. I wouldn't be too worried about this.
122  Bitcoin / Development & Technical Discussion / Re: Get hash of oldest stored block (Core pruned mode)? on: June 10, 2018, 07:58:30 PM
getblockchaininfo will tell you the height of the oldest stored complete block. You can then look up its hash using getblockhash.
123  Bitcoin / Development & Technical Discussion / Re: Bitcoin money back. Very useful function. on: June 10, 2018, 07:31:54 AM
This is impossible to do in Bitcoin.

Doing such contracts requires using the Bitcoin scripting language. However the scripting language does not have access to output amounts, nor does it have access to other UTXOs which it would in order to have the correct balance for an address.
124  Bitcoin / Development & Technical Discussion / Re: Adding anti-theft feature to Bitcoin using a new address type on: June 08, 2018, 06:57:30 PM
Your proposal itself requires a fork as it is a change to the consensus rules.

If you want to be taken seriously, then you should post to the bitcoin-dev mailing list and create a BIP



What is the point of this? You are just extending the period of time that something is unconfirmed for. Merchants, when they see coins sent from such addresses, will simply not accept the coins until the 100 confirmation mark because they know that the coins can be double spent anyways. It is just the same security as unconfirmed transactions.
125  Bitcoin / Development & Technical Discussion / Re: The usability of Lightning network on: June 08, 2018, 08:30:19 AM
Of course it is going to change! Once the Lightning Network is actually out of the experimental phase, developers will shift focus towards UI/UX. Currently, they are working on making sure that the various Lightning Network software can actually interact with each other and making sure that all of the technical details work. The most important things for a Lightning Network software is to ensure that the user doesn't lose their funds. UI/UX comes last, after everything that works in the backend is complete.
126  Bitcoin / Development & Technical Discussion / Re: What is RPC attack? on: June 08, 2018, 07:32:04 AM
bitcoind's JSON-RPC interface is used to issue commands to bitcoind to have it do things. Having access to the JSON-RPC interface of a node means that you have a significant amount of control over that node. For example, an attacker can dictate what nodes that node connects to, send coins from the wallet, shut down the node, etc.

The really important thing to note is the control of the wallet. If the wallet has any funds in it and the wallet passphrase is known or not set, anyone who has access to the RPC interface can send commands to the wallet that result in the coins being sent elsewhere. Thus an attacker could potentially steal your coins if the RPC interface is insecure.

To secure the RPC interface, you set a password on it. This password is most securely set by using the rpcauth configuration option. You can generate a correctly formatted rpcauth line by using the script provided here: https://github.com/bitcoin/bitcoin/tree/master/share/rpcauth. That script can also generate a secure password for you to use.

Additionally, you should add rpcallowip=<ip> lines to your config file to limit the IP addresses that are allowed to access the RPC interface of bitcoind.
127  Bitcoin / Development & Technical Discussion / Re: Need some clarification on usage of the nonce in version message on: June 08, 2018, 07:09:12 AM
No, it is a 64 bit integer which obsoletes your point concerning the birthday paradox entirely  Roll Eyes
Oops, forgot about that.

Regardless, my point still stands as the birthday paradox is largely unrelated to the point I was making:
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.

That is the reason for doing this.



Perhaps then, you can explain to me why you think it shouldn't be done this way.
128  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.
129  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 127.0.0.1 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.
130  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.
131  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.
132  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.
133  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 https://twitter.com/pwuille/status/998314349969031170
134  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.

@theymos:
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.
135  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.
136  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#.
137  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
138  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.
139  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 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.
140  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.
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 ... 543 »
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!