Bitcoin Forum
November 17, 2018, 08:15:22 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 ... 547 »
321  Other / Meta / Re: Scams vs Spam on: April 06, 2018, 03:10:26 PM
I don't know, I always thought it would be better to just ban confirmed scammers, this argument of ''he is just going to use another account if we ban him'' makes no sense since he can use another account anyways even if he is not banned. Banning at least would make it harder for them, forcing them to actually have a new account and with the merit system it gets even harder. If mods can take the time to look into spam and ban users for it they also could look into scams, no?
This rule has nothing to do with ''he is just going to use another account if we ban him''. Moderating scams means that the staff needs to both investigate a potential scam (which takes a lot of time), and determine what is and is not a scam. This requires a significant amount of effort and takes a lot longer to do and is more opinion based than identifying and deleting spam.
322  Bitcoin / Development & Technical Discussion / Re: Lightning Network -QA on: April 06, 2018, 03:06:57 PM
so, first. What is push_amt in LND?
Why I wanna use it in with another nodes? Whats use cases?
It lets you immediately pay the other party when you create the channel instead of creating the channel and then updating the commitment immediately afterwards to pay the other person.

And some global question, how to build biggest LN Node? Just fund it with some bitcoins and open channel to every big node?
You would have to open as many channels as possible with every other node on the network. Autopilot won't do this for you.

Or, I can just run Node with Autopilot and wait?
Already waiting more than week,  and here is statistics: Active channels 6
Autopilot does not just open as many channels as possible. It isn't designed for that. Autopilot will not magically make you the biggest node on the network, nor will it open tens or even hundreds of channels for you.

How to open 100 channels? 1000?
Use the channel opening commands and open then manually.
323  Alternate cryptocurrencies / Altcoin Discussion / Re: Why coind program spit out Assertion error? on: April 06, 2018, 06:11:00 AM
How that could be... first 2 VPS I launched run well and each sync with other, and now running well, mining well.
Reindexing calls different code than a normal start or first start up. It is breaking in the InitBlockIndex function, so go to that function and make sure it is correct. Particularly make sure that that function is creating the correct genesis block (in 0.8 which is what you seem to have forked from, it creates the genesis block independently of the chain params too).

And also I git download from source, and made -qt, run it, it says 8 hours behind, there stops sync.
Qt may also have different code paths than what you thought. Or it just isn't connected to your nodes.

As an aside, you need to stop asking simple debugging questions like these in this forum. We are not your personal support for everything software engineering and Bitcoin cloning related. You should know how to debug simple bugs like this - the source code file and line number where the error occurred are given to you!! You should learn simple software engineering skills and debugging skills before even thinking about making your own altcoin. And even then, you should understand how Bitcoin works before doing so. It is extremely clear that you have no experience with software engineering or debugging software and that you have no knowledge of how Bitcoin works. I ask that you stop asking questions for every single problem you have and instead read documentation and tutorials for working in C++, use some common sense, and do your own research (note research does not mean ask everyone else about problems you are having) first.
324  Alternate cryptocurrencies / Altcoin Discussion / Re: Why coind program spit out Assertion error? on: April 06, 2018, 04:59:23 AM
The hash of your genesis block does not match what your software says the genesis block hash should be.
325  Bitcoin / Development & Technical Discussion / Re: What happen write number like this at code? on: April 06, 2018, 04:58:43 AM
So if type like,

nSubsidy >>= (nHeight / 5,112,000);

then 5,112,000 become to what number for computer?  
It doesn't become any number. Code is just text to a computer and is completely meaningless until it is compiled. That number will never have meaning to a computer because it will never be compiled into machine code that has meaning to a computer.
326  Bitcoin / Development & Technical Discussion / Re: What happen write number like this at code? on: April 06, 2018, 01:29:30 AM
Compilers don't understand human comma separating for numbers. This code should fail to compile.
327  Other / Meta / Re: Scams vs Spam on: April 05, 2018, 09:05:51 PM
Scams are not moderated; we leave that up to the community to police itself. That is why there is a trust and feedback system.
328  Bitcoin / Bitcoin Technical Support / Re: -addresstype= on: April 05, 2018, 04:48:55 PM
Bitcoin Core 0.16 intentionally makes it more difficult to generate legacy addresses because we want to move towards segwit by default (particularly bech32). Thus there isn't really an easy way to make legacy addresses from within the GUI.

However you can use the debug console (or RPC interface, i.e. bitcoin-cli) to generate legacy addresses when -addresstype is not set to legacy. getnewaddress has a new address type parameter that lets you specify what type of address to generate.
329  Bitcoin / Bitcoin Technical Support / Re: Bitcoin extended public key transacaction listening on: April 05, 2018, 06:02:29 AM
They get it by deriving a lot of addresses from the xpub and then looking up the transactions related to those addresses. They follow the BIP 32 specification for deriving public keys from a parent public key.
330  Bitcoin / Development & Technical Discussion / Re: If coin daemon is running, block data also will be increased? on: April 05, 2018, 06:01:15 AM
331  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.
332  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.
333  Other / Meta / Re: any mods here? on: April 03, 2018, 08:32:42 PM
Trust is not moderated unless it is blatant spam.
334  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.
335  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.
336  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.

337  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:
338  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.
339  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.
340  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
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 ... 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!