Bitcoin Forum
December 11, 2018, 06:44:06 PM *
News: Latest Bitcoin Core release: 0.17.0 [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 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 ... 547 »
341  Bitcoin / Development & Technical Discussion / Re: If coin daemon is running, block data also will be increased? on: April 05, 2018, 06:01:15 AM
342  Other / Meta / Re: any mods here? on: April 05, 2018, 01:18:05 AM
how can trust be given if there is no transaction?
Trust is not inherently tied to a transaction. Trust can be given for any reason. While a trade is what is most obviously something that warrants trust (or mistrust), people can do other things too that warrant trust. Furthermore, the forum has no idea of whether a transaction took place, and it is difficult for moderators to verify that.

The person who added that trust feedback is not responding and ignored our messages.
They aren't obligated to respond to you, nor are the moderators.

This is definitely supposed to be a moderator issue, if it relates to allegedly breaking some forum rules and has nothing to do with the member who left the feedback!
It is not a moderator issue, the trust does not break any forum rules. Some people like to also give negative trust to people who they believe to break forum rules, in addition to reporting the user to moderators. They are allowed to do that.
343  Bitcoin / Development & Technical Discussion / Re: Write text/image in blоckchain of bitcоin on: April 03, 2018, 08:39:00 PM
Yes. Also you can use the script of the transaction to embed some text as Satoshi Nakamoto have done in the genesis block of Bitcoin.


Read more here:
That's not how Satoshi put text in the genesis block. The text was put in the coinbase (aka scriptSig of the coinbase transaction), not in an output. Many miners still do this today, usually to identify who mined the block.
344  Other / Meta / Re: any mods here? on: April 03, 2018, 08:32:42 PM
Trust is not moderated unless it is blatant spam.
345  Bitcoin / Development & Technical Discussion / Re: What's the worst thing that could happen with Schnorr signature on: April 03, 2018, 08:17:20 PM
Schnorr signatures is actually a somewhat broad topic that includes many things. Schnorr signatures are a cryptographic scheme, but to actually be used in Bitcoin, you still have to use that cryptography in a specific way besides just the signature algorithm itself. There are certainly insecure ways to use Schnorr signatures, just as there are insecure ways to use ECDSA or RSA signatures.

Didn't we have the case, developers found that Schnorr signatures made Bitcoin susceptible to new ‘rogue attack’ vectors ?
Yes, there was. There was a scheme using Schnorr signatures for key aggregation that was originally thought of that was insecure. But this doesn't mean Schnorr signatures themselves are insecure, just that specific cryptosystem that happened to use Schnorr signatures.

If the Schnorr signature protocol is not robust enough, badly implemented, broken or whatever. What could be worse for Bitcoin?
It would mean that, at worst, sensitive data such as private keys (but not necessarily private keys) are revealed which allows an attacker to be able to forge or create a signature that he should not be able to. This could result in coins be stolen.

While most of us are excited to see these solution coming, there are still some fears we should have, don't you think? ]
Not really. The cryptography itself can be proven to be sound. It is just mathematics, there's nothing special about it. For example, the key and signature aggregation scheme that uses Schnorr signatures that is likely to be used - MuSig - has a formal security proof that takes up a large part of the paper describing that scheme. Since it is just mathematics, the proof, assuming that there are no errors in it (so it needs review from other cryptographers), proves that the cryptography is sound assuming that the discrete logarithm problem is hard (which we currently do assume). This means that any software which follows the spec for MuSig will not create anything that results in sensitive data being leaked.

Of course there could be some insecure implementation of MuSig, but that's not a problem unique to it. There have been many insecure implementations of ECDSA which has resulted in lost coins. Even secure implementations that use a bad PRNG results in leaked private keys.

Schnorr needs to be robustly developed and tested prior to potential rollout, because Bitcoin is a multi-billion dollar market cap, and not a test environment in your VM with a 250 Mb ram
It certainly will. But with regards to the cryptography itself, the scheme itself will probably not be accepted unless it has a formal security proof.
346  Other / Beginners & Help / Re: How to ping a blockchain network on: April 03, 2018, 04:33:15 PM
The network is not some private network thing that is pingable or has its own block of IP addresses. There is no "network IP" or "network domain"; it is just many machines that have opened connections to each other and are sending data to each other using the Bitcoin network protocol.
347  Bitcoin / Bitcoin Technical Support / MOVED: mycelium wallet problems after phone backup on: April 02, 2018, 08:09:00 PM
This topic has been moved to Trashcan.

348  Bitcoin / Development & Technical Discussion / Re: The “26 blocks fork” in April 2013 on: March 31, 2018, 03:43:04 PM
Thank you for taking time to explain this. I wasn't aware of the fact that new blocks were being built on both sides of the fork. But to tell the truth I still don't know how to interpret the words of Andreas Antonopoulos whom I respect very much and think that his videos are among the very best Bitcoin related ones:

They [the nodes running Berkeley DB] would start processing the transactions to validate them, they would open file descriptors, they would process the first 1024 transactions. And then they would attempt to validate transaction 1025, choke on it, crash, and restart. They would restart, join the network, ask it what the latest block is, receive the exact same block, start validating 1025 transactions later, choke, crash, reboot, ask for a block, validated, choke, crash, reboot. Problem is half the network adapted to Level DB, half the network was on Berkeley DB. The network suffered a complete bifurcation almost perfectly 50-50% balanced, and one side could not move forward. They couldn't move to the next block because every time they got on the network they would try to validate the same block.

I thought that meant that the nodes running Berkeley DB could not create new blocks.
I don't think any Bitcoin 0.7 nodes were actually crashing. They were simply unable to validate the larger blocks created by 0.8. None of the threads from that time indicate any sort of software crashing.

For reference, see, Here's also writeup explaining the events of the fork and the actions that were done:
349  Bitcoin / Development & Technical Discussion / Re: BIP32 Child Derivation Function - Can't Find My Mistake on: March 30, 2018, 11:25:59 PM
]I already did. They're in the final quote under the names il * G  and m's ECpub respectively.
Can you print them in hex? The negative makes things slightly harder to check things.

The X component of m's Pub is correct and iL * G is also correct.
350  Bitcoin / Development & Technical Discussion / Re: BIP32 Child Derivation Function - Can't Find My Mistake on: March 30, 2018, 09:51:02 PM
Before you do the adding, can you print out what you get for
Point::mul($il, $secp256k1_G)

Make sure that those are what you expect them to be.

The only thing that can be wrong here is that either you are adding the wrong things or Point::add is broken.
351  Bitcoin / Development & Technical Discussion / Re: The “26 blocks fork” in April 2013 on: March 30, 2018, 09:08:27 PM
My question is Why do we call it a fork given that one part wasn't able to build new blocks?
They were able to build new blocks, and new blocks were in fact being built on both sides of the fork.

What happened was that miners who were using Bitcoin 0.8 had the majority of the hash rate, so they were finding blocks that were invalid to 0.7 nodes. IIRC miners still use 0.7 nodes were able to find blocks, just much more slowly. Then once the fork was known to have happened, the Bitcoin 0.8 miners downgraded to 0.7 and resumed mining on the 0.7 fork of the blockchain. Once that fork over took the 0.8 branch, all nodes once again began using the same blockchain as the chain valid to 0.7 was valid to 0.8 and had more cumulative work.

I suggest you read the post-morten BIP, BIP 50
352  Bitcoin / Development & Technical Discussion / Re: Must all nodes run Bitcoin core on: March 29, 2018, 06:44:27 PM
Provide an example of any consensus rules that have ever been enforced on the Bitcoin network that were not introduced by the developers working on the core client.
BIP 91 Reduced threshold for enforcing Segwit activation. It happened but code enforcing BIP 91 was never merged into Bitcoin Core. The author of the BIP is also not someone that many would consider to be a Bitcoin Core developer.
353  Bitcoin / Development & Technical Discussion / Re: bech32 generation in the GUI question on: March 29, 2018, 05:05:34 PM
What, are you saying that you will not be able to choose between nested and bech32 format anymore? from what I understand, it reads as if they will remove the checkbox... why? How will I choose what format do I want to generate then?
No, the "New" button in the "Receiving Addresses" dialog was removed. You can still generate bech32 addresses with the "Receive" tab; nothing has changed there.
354  Bitcoin / Development & Technical Discussion / Re: Why is private key in wallet 214 bytes? on: March 29, 2018, 03:39:47 PM
I see, the 214 bytes is made of version + private key + parameters + public key.
Another question, when the wallet is encrypted, the ckey entry for private keys only contains 48bytes, which is 32 bytes private key + 16 bytes IV, is that right?

Why the different db store strategy?
For compatibility reasons. Earlier versions of Bitcoin Core (including the original Bitcoin 0.1.0) used OpenSSL to do key operations. When keys were written to disk, they used the OpenSSL format which includes all of this extra data. Later, when key encryption was introduced, it was decided that for encrypted keys we could use a different format (since encrypted keys are already backwards incompatible with earlier versions). So for encrypted private keys, we only store what we need, not the full extra stuff. We could bump the wallet version and change the unencrypted key storage format to just be the private key, but no one has bothered to do that and it really isn't all that important.
355  Bitcoin / Development & Technical Discussion / Re: Why is private key in wallet 214 bytes? on: March 29, 2018, 06:42:03 AM
Those additional bytes are for the elliptic curve parameters and the full public key. This format is described in section C.4
356  Bitcoin / Development & Technical Discussion / Re: If there is no bitcoin-cli file in VPS server? on: March 27, 2018, 04:50:06 PM
You interact with bitcoind with the JSON-RPC protocol. So you can use cURL to do that. Or you can just copy a version of bitcoin-cli to your server. It's just a wrapper that can speak the JSON-RPC protocol, particularly for bicoind. It is a separate portable binary.
357  Bitcoin / Development & Technical Discussion / Re: It is NOT secure to use hardware wallets (and it never was) on: March 27, 2018, 04:47:56 PM
I'm not objecting just confused: Is it about firmware, BIOS, fucking NVIDIA device drivers or what? We have Linux and Free BSD, don't we? Is it impossible to have Core's wallet running on top of a clean installed Linux?

I'm seriously interested in your term 'closed source computer', actually it is my main research topic for the last couple of years, I'm just wondering how deep is your interpretation of this concept and whether you have developed any idea as an alternative?
There's more to a computer than just the OS. A lot of firmware such as processor microcode are closed source. So it doesn't matter whether the OS you use is open source; if the firmware for your hardware and the hardware itself is closed source, then you are at risk of that closed source being malicious or containing something that can be exploited. One example of this is the Intel Management Engine which could allow someone to remotely access and control your computer and there's no way to disable it because it is baked into the hardware and firmware, both of which are also closed source.
358  Bitcoin / Development & Technical Discussion / Re: strMainNetDNSSeed and pnSeed? on: March 27, 2018, 04:41:57 PM
stdMainNetDNSSeed is the array of DNS seeders for the mainnet. DNS Seeders are used by Bitcoin Core on the first run to get nodes to connect to.

pnSeed is an array of fallback seed nodes that Bitcoin Core can connect to if it is unable to find nodes to connect to from its own database or from the DNS seeders.
359  Bitcoin / Bitcoin Technical Support / Re: I've been fight the core download for months on: March 27, 2018, 04:45:33 AM
The error with peer banning is happening because a block that it read is probably corrupted and that block is marked as invalid. Then Bitcoin Core will try to continue to sync from its peers, but those peers are sending it the block that it had marked invalid so it will ban those peers. Eventually it will ban everyone it could get a connection to. To fix the peers banning problem, stop Bitcoin Core, delete the file named peers.dat, and start Bitcoin Core again.

I suspect that you have a hard drive failure. You have experienced what appears to be two cases of corrupt blocks on your hard drive. I suggest that you run hardware diagnostics to see if it finds anything wrong with your hard drive. You should stop running Bitcoin Core for now as it won't be doing anything if it can't sync the blockchain.
360  Bitcoin / Development & Technical Discussion / Re: Is bip125-replaceable set to 0 on confirmed txes? on: March 27, 2018, 04:37:12 AM
gettransaction for a tx that was sent with RBF shows "bip125-replaceable": "no".
Is the flag reset once a tx gets into a block?
Yes (basically). Once a transaction is confirmed, it is, by definition, no longer replaceable under BIP 125, therefore the field bip125-replaceable will say "no".

The current way is more confusing, as one expects the command to interpret the bit data of the transaction.
There's actually a bit more to whether something is actually replaceable than just the signalling. That is included in the checks for labeling a transaction as replaceable.

Knowing that RBF can't be used on txes already in a block seems self-evident? Especially to people who would use commands to check it.
Just because a confirmed transaction signals it does not necessarily mean that it was actually replaceable when in the mempool.

(Can anyone move the thread to Development & Technical Discussion?)
I moved it for you, but next time, do it yourself (OPs can move their threads) or use the report to moderator link.
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 60 61 62 63 64 65 66 67 68 ... 547 »
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!