Bitcoin Forum
January 16, 2019, 05:03:44 AM
 News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 Home Help Search Login Register More
 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 ... 549
 21 Bitcoin / Development & Technical Discussion / Re: Question about finding a block on: December 31, 2018, 05:35:35 AM Quote from: irukandji on December 31, 2018, 04:45:27 AMNot sure i understand this but would be grateful if someone could help. This is what I understand.1.Finding a block means guessing a number.Kind of.Quote from: irukandji on December 31, 2018, 04:45:27 AM2.That number involves showing that the transaction involves the right keys and then ..putting it through some meth equation?  Is that right?No. Miners do not prove that transactions are correct, that's not their job. The process of mining has nothing to do with showing transactions are correct or have correct keys. However a miner will want to still verify transactions are valid (their proof of correctness is contained within the transaction and is produced by their creators, not the miner) so that the block they produce is also valid. A valid block has more than just a valid proof of work, it's contents must also be valid.What miners do is try to find a block which hashes to less than a target value (you can view this as the hash beginning with some number of 0's). The way that they do this is to increment a value called a nonce. It is just a number which is part of the data that is hashed. So miners are trying to guess a nonce which results in a block hash that has some number of zeroes in front of it. It's a bit more complicated than that, but that's a basic understanding of what miners do to "solve a math problem" (it's not really a math problem).
 22 Bitcoin / Armory / Re: segwit and mining pool on: December 28, 2018, 01:31:57 AM Quote from: abeandund on December 27, 2018, 10:52:36 PMI'll just not spend from that address until done mining.  Will there ever be a way to sign, other then switching back to legacy addresses?There's ongoing work on a new standard for signed messages, although it isn't super well developed yet.
 23 Bitcoin / Armory / Re: segwit and mining pool on: December 27, 2018, 10:29:56 PM Signing messages with any non-legacy address type is not supported. The existing signed message standard in Bitcoin is really only for the legacy P2PKH address type and does not work for Segwit addresses or P2SH addresses.
 24 Bitcoin / Development & Technical Discussion / Re: How to configure inbound/outbound connections of bitcoind ? on: December 26, 2018, 04:31:44 PM There are no configuration options for dictating what you accept from other nodes or what you send to other nodes. There is not and never has been such options. You will either need to modify the source code of Bitcoin Core to do this yourself, or you will need some other software which acts as a filter between your node and the rest of the Bitcoin network.
 25 Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.17.1 Released on: December 25, 2018, 07:22:05 PM Quote from: Kolikalex55 on December 25, 2018, 05:33:29 PM Apologize if I'm wrong. I was told that bitcoin is not controlled by anyone, but updates are coming out. As it turned out, he has no developers .  How do updates happen ?) Thanks for the reply.These are updates for a particular software called Bitcoin Core. Bitcoin Core is descended from the original Bitcoin software that Satoshi published. It is just the most popular of the many node software that people can run. The Bitcoin Core software is constantly being updated and changed, but that does not mean that Bitcoin itself changes. While the software may change, the same consensus rules are still being enforced and those do not change.
 26 Bitcoin / Bitcoin Technical Support / Re: Core node is constantly re-indexing? on: December 25, 2018, 04:25:08 PM debug.log file please.
 27 Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.17.0 Released on: December 25, 2018, 04:10:16 PM BItcoin Core 0.17.1 has been released
 29 Bitcoin / Development & Technical Discussion / Re: [SCALING] Minisketch on: December 21, 2018, 12:01:20 AM Quote from: aliashraf on December 20, 2018, 10:28:30 PMIncreased UTXO size means increased user base, doesn't it?Not necessarily.Quote from: aliashraf on December 20, 2018, 10:28:30 PMAnd you think it is infeasible to have a UTXO an order of magnitude bigger? Why?The same reason that it has been for the past several years: a larger UTXO set makes verifying blocks slower and increases node requirements thus making it more expensive for people to run nodes. More transactions in general (which correlates to a larger UTXO set) makes it harder to run a node which means that there will be less nodes and thus less decentralization.I am not against Bitcoin adoption in general. I am for more people using Bitcoin. However I do not believe that we can support having more people at this time with current technology. Minisketch does not change this fact because it is used for network relay, which is completely unrelated to blocks, consensus, and the UTXO set. Not every new technology in Bitcoin is for making more transaction throughput. In this case, this new technology is to reduce the total bandwidth cost for a node, which is good, but unrelated to transaction throughput.Let's not turn this thread into another block size argument. That's completely off topic.
 30 Bitcoin / Development & Technical Discussion / Re: [SCALING] Minisketch on: December 20, 2018, 08:20:36 PM Quote from: ETFbitcoin on December 20, 2018, 08:16:22 PMWhile some devs thought Minisketch could be used to connect to more nodes, IMO increase block size is more viable as current block size simply not enough if Bitcoin if mass adopted (and almost everyone use LN)Increasing the block size still increases the UTXO set size and the time to sync and validate all blocks. Minisketch does not help with initial sync or with validation, it only reduces the amount of bandwidth you consume for normal transaction relay (i.e. relaying unconfirmed transactions after you have already synced).
 31 Bitcoin / Development & Technical Discussion / Re: What is the first byte in message signature result? on: December 20, 2018, 08:14:16 PM Quote from: Coding Enthusiast on December 20, 2018, 11:33:48 AMMethod 2 (Finding recId during signing or from R which is the point, and s which is the integer):I still don't understand what the mathematical logic behind this is yet.During signing when R is produced (multiplication result of k * G), we use R.y and the value of s to get the recId. Here is the c# code:Code:int recid = ((R.X > curve.N) ? 2 : 0) | (R.Y.IsEven ? 0 : 1);recid = (s > curve.N / 2) ? recid ^1 : recid;* This is a more complete version of the link posted above by @darosior since it is considering the rare case of R.X being bigger than curve order.* This seems to be working but I am not sure.* I believe this is the function in bitcoin core that is responsible for signing messages (recoverable sigs) but I am not sure if I understood it correctly specially the overflow part!This is correct, and that is the function that is used.Overflow just means that R.x > curve.N. Again, viewing the recid as a bitfield, what this code does is set bit 1 to 1 if it overflows, i.e. R.x > curve.N. It sets the entire recid to the number 2 because 2 is 10 in binary. This sets bit 1. The 0th bit is set by the | (R.Y.IsEven ? 0 : 1). This is because we choose a 0 or 1 for the 0th bit, and Bitwise OR it with the number 2. This will make sure that bit 0 is set, and if bit 1 was set, that will also be included in the final recid.Quote from: Coding Enthusiast on December 20, 2018, 11:33:48 AM* Additionally there is this comment by Pieter Wuille which doesn't make any sense27 = lower X even Y. 28 = lower X odd Y. 29 = higher X even Y. 30 = higher X odd Y.Sure it does. The first byte is just 27 + recid + compression. Ignoring compression for now (so it's 0), you have 27 + recid. If the recid is 0, then 27 + 0 = 27. A recid of 0 means that there is no overflow (lower X) and y is even (even Y). So 28 = 27 + 1. Recid 1 means low X, odd Y. 29 = 27 + 2. Recid 2 means high X (R.X > curve.N) and even y. Lastly 30 = 27 + 3. Recid 3 means high X and odd y.
 32 Bitcoin / Bitcoin Technical Support / Re: Bitcoin core v0.17.0 Masterkey on: December 20, 2018, 08:05:24 PM Quote from: spart3x on December 20, 2018, 01:24:44 PMin Bitcoin core v0.17.0 is the masterkey represents a sufficient backup? (taken with the dumpwallet command)No, it is not. The master private key cannot be restored to a wallet at this time. Everything is derived from the hdseed instead (the seed is used to get the master private key, which is then used to derive all of the private keys used). You can get the hdseed from dumpwallet and use that. That is sufficient to get all of your private keys, but restoring just that to a wallet may not necessarily get you all of the transactions that you have received. The seed can be restored using the sethdseed command.
 33 Bitcoin / Development & Technical Discussion / Re: What is the first byte in message signature result? on: December 19, 2018, 05:05:18 PM Quote from: Coding Enthusiast on December 19, 2018, 06:47:08 AMThat doesn't quite answer my question though. I understand that it is a "recovery ID" but I am trying to figure out how that number is obtained. For example to sign "123" with the key to this address "muRAUfvSXQKXJm9sPsAbPsxDTMsMJoDQes"I add 0 * n to r (first iteration of first loop)Calculate Q with R, (first iteration of second loop) it is invalidcontinueCalculate Q with -R, (second iteration of second loop) it is validbreak.The byte should be 32 meaning only 1 is added (27 + 4 + 1). Trying to figure out why 1 was chosen based on above operation?You can think of the recovery id being a bit field of length two. Bit 0 indicates whether you should use R or -R. Bit 1 indicates whether R.x overflows n. So in this case, you have the bitfield be 01 = 1. Bit 1 is 0 because you do not overflow n (x=x, not x=x+n). Bit 0 is 1 because you are using -R.Furthermore, this does in fact correspond to the loop. If instead of counting the number of operations that you do, count the number of Q's that you generate. If you put each Q into a list in the order that you generate them (including invalid ones), the recovery id is the index of the correct Q. In this case, Q[0] was invalid, Q[1] is the one you want. So the recovery id is 1.Another way to look at this is to say the outer for loop is j from 0 to h (h=1 for secp256k1) and the inner loop is k from 0 to 1 (instead of 1 to 2 used in sec1). Then you add j and k together to get the recovery id. In this example, j = 0, and k = 1, so the recovery id is 1.
 34 Bitcoin / Development & Technical Discussion / Re: What is the first byte in message signature result? on: December 19, 2018, 06:11:44 AM Signed messages use a thing called public key recovery to get the public key and then get the address to compare that against the address provided. In this way, the public key does not need to be provided in the signature which makes it much shorter. However, public key recovery will result in multiple public keys, up to 4 of them. The first byte encodes a number 0 to 3 which is the recovery id. This number is used to determine which of those 4 public keys is the actual public key. There's some mathematical properties in the recovery id which can be used to calculate the actual public key without the use of a loop. And the recovery id can be calculated at signing time due to the same properties.The first byte also encodes the compression.I'm pretty sure that the 27 is just a random number that Pieter decided to use when implementing this.
 35 Bitcoin / Development & Technical Discussion / Re: Is it possible to sign/create a transaction without specifying inputs? on: December 19, 2018, 01:55:07 AM I'm not sure I understand what you want to do.Are you trying to have a presigned transaction where the outputs are unknown. Then you can add outputs afterwards without having to sign again?If so, that is not possible and is unsafe. If this were possible, anyone could just change the output to whatever they want, so anyone can change the outputs to give them money and not the person you wanted to pay. Furthermore, you cannot use opcodes to restrict the recipients because opcodes cannot inspect other inputs and outputs of the transaction they are in.
 36 Bitcoin / Bitcoin Technical Support / Re: [initial connection] Some questions at the start of designing a bitcoin client on: December 17, 2018, 05:14:21 PM Quote from: jackg on December 17, 2018, 04:16:03 PMIs version and block height the same? No. There are protocol version numbers which indicate support for various features. Block height is completely unrelated as the p2p protocol is not related to consensus state. A list of protocol version numbers and their descriptions is available here: https://btcinformation.org/en/developer-reference#protocol-versionsQuote from: jackg on December 17, 2018, 04:16:03 PMDoes the user_agent have an unlimited size or should I check the source code? Hypothetically as this will all be in one network packet, it can have an unlimited size I just wanted to check. It's unlimited but there are size constraints on messages. Don't make it super long.Quote from: jackg on December 17, 2018, 04:16:03 PMWhat's service number?I assume you mean service bits. Service bits are used to indicate what services a node supports. These include things like NODE_NETWORK (bit 0) which indicates that you support sending the complete blockchain. A list of service bits and their descriptions is found in the codeQuote from: jackg on December 17, 2018, 04:16:03 PMFinally, as field size is bits and some of the fields are bigger than what is allowed for, do we just take the end of the values? I.E the nonce is 8 bits but the uint64 is obviously 64 (or are those values in bytes)? The field size is in bytes. 8 bytes is 64 bits. No field has a type that is larger than it's field size or vice versa.
 37 Bitcoin / Development & Technical Discussion / MOVED: Help to Windows compile for my crypto. on: December 17, 2018, 12:40:12 AM This topic has been moved to Trashcan.Duplicate
 38 Bitcoin / Development & Technical Discussion / Re: Answer to a tx message on: December 16, 2018, 07:51:03 PM A node may send a reject message if they reject the transaction. However, there is no required or guaranteed response to a tx message.
 39 Bitcoin / Development & Technical Discussion / Re: Difference from Electrum HD wallet to Core HD wallet.dat file on: December 16, 2018, 04:22:56 AM Quote from: ranochigo on December 16, 2018, 03:58:40 AMIn terms of convenience, Electrum wins Core with no questions. Electrum allows the user to export the keys and to store a physical copy of the seeds thus giving them the reliability of physical backups. It's not possible with wallet.dat. While it is inconvenient to do, it is possible to get the seed value (not a mnemonic, which many people, including you, confuse for being the seed) from Bitcoin Core and back that up. The seed value can be gotten using the dumpwallet command and the seed value will be there in WIF format. You can use that with sethdseed to restore the seed value to a new wallet.Quote from: ranochigo on December 16, 2018, 03:58:40 AMIn terms of security, Core would win. Core allows the user to encrypt their wallet and thus giving them a better security.You can encrypt Electrum wallets too.Quote from: ranochigo on December 16, 2018, 03:58:40 AMWhile Core allows the user to export its HD key, the wallet still has to be backed-up relatively frequently whenever the password is changed. It does seem more of a hassle to manage the wallet.dat. That is untrue. The seed does not change when the password is changed. It is only changed when the wallet is first encrypted.Quote from: cellard on December 16, 2018, 03:37:38 AMWhich are the security differences comparing the Electrum HD wallet which has an exportable seed to the HD wallet.dat from Bitcoin Core software?Besides the seed, there are other security concerns with the derivation of private keys themselves. Electrum uses a derivation path with non-hardened derivation nodes since it follows BIP 44. There is an inherent security risk to this because it is possible to retrieve the private key of the parent of a non-hardened node if you have the private key of that non-hardened node, and the extended public key (xpub) of the parent. With hardened derivation, this is not possible. Bitcoin Core uses exclusively hardened derivation paths. Unfortunately this makes public derivation impossible so it is more annoying to use as you have to import addresses to watch.I would trust Bitcoin Core more in general.
 40 Bitcoin / Development & Technical Discussion / Re: Question about Bitcoin Digital signatures on: December 15, 2018, 10:53:11 PM Quote from: zebox6 on December 15, 2018, 07:54:56 PMThank you for answering guys So if I get it right,- The transaction is signed with Bob's private key + ECDSA (if you know the process or have an article about it, I would be interested)Close. The transaction is signed with Bob's private key using ECDSA. ECDSA is an algorithm. You can read about how it works on WikipediaQuote from: zebox6 on December 15, 2018, 07:54:56 PM- Alice can decode the signature with Bob's public key.Alice verifies the signature with Bob's public key (provided in the transaction). She does not just decode it, but decoding (interpreting the values in a piece of data) is necessary to get the values inside of the signature.Quote from: zebox6 on December 15, 2018, 07:54:56 PM- So,  if the transaction is not hashed, how can Alice know if the transaction has been modified ?Part of ECDSA is hashing the message to be signed. In this case, that is the transaction. The message hash itself is not included anywhere. However, because the message is provided (it's the transaction), we can easily compute the hash of it in order to verify the signature. if the transaction were modified, the hash would not match the hash that was used to create the signature, so the signature would not validate to true. Thus the transaction would be invalid.
 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 ... 549
Bitcointalk.org is not available or authorized for sale. Do not believe any fake listings.
Sponsored by , a Bitcoin-accepting VPN.