Chances are, if you were to download the bootstrap using an external source, the process would take longer than if you synchronized it using the client. The client can synchronize and download the Blockchain from your peers simultaneously. This would be way faster as opposed to if you were to get the outdated bootstrap and have the client verify it at the end.

If you want any significant speedup, you would have to find someone with a pre-validated data directory so that your client won't have to validate it all over again. I wouldn't consider this as secure as the other methods though.

Is this the correct thread for this topic ? I will give my 5 cents anyway

My understanding of hashgraph is that it will use timestamped "blocks", not really blocks but lets use that for this explanation.
When a node gets a transaction it will tell a few other nodes about the transaction, those nodes in turn would do this too and so on it will propogate throughout the network. Each node tells the other one about it with a timestamp attached. This timestamp is a basis for a transaction to be valid. When a certain amount of time is passed then  that gets set as the "block". This is my understanding of how it works in a basic form.

This uses a legacy protocol called gossip protocol, this was developed in the 1960's or something. It was never really used much. Which brings up concern number one for me, if this legacy protocol is the base of hashgraph then how do we know it has been stress tested and battlehardened. Even today we find exploits with TCP/IP. TCP/IP is the basis for the internet and networks as we know them today.
Let's face it, programmers today know a lot more than the original creators did in those days, applications and protocols are developed with security in mind.

Then onto the way transactions are advertised. This sounds very similar to some more legacy networking technologies (Such as RIP routing protocol), I am unsure of what kind of loop prevention they have. From what I have read about it I don't  see a fool proof loop prevention mechanism in it, I can think that if I recieve a gossip packet  from someone else I can just modify the timestamp in the header before passing it on in my node (this might screw with the whole system). As the network grows the bandwidth requirements will probably start getting quite large which means it wont  be usable on mobiles.
I didn't research this extensively though, so this point might be mute. But the bandwidth requirement will go up as the network scales. Which I think is a bit of a problem, there should be a set limit as to how many confirmations are needed for a transaction to limit the bandwidth requirements.

My biggest problem with this, like others have stated is the fact that this is patented and  developed by one company. I'm sure it will have some uses, but I dont see this replacing blockchain. Blockchain is starting to become really cool, modern blockchain 3.0 products really lay the ground for mass disruption and previously unthinkable innovation. I don't see hashgraph bringing such extensive scalable smart contract technology to the table.
If it's not open source then that means we can't see the code, that means we need to trust the entity who created it. With BTC and others the code is there for anyone to read and check, meaning we don't need to trust anyone, which is the beauty of blockchain.
"Each node in Hashgraph can disseminate sealed information (called events) about transactions created and transactions received from others, to other nodes chosen at random, these nodes will add the received events with the information received from other nodes in a new event, and then They will send to other nodes chosen at random, this process continues until all the nodes know the information created or received at the beginning, and the new information can reach each node of the network in a very fast way.

Fast: 250,000 transactions per second. (7 transactions / second in BItcoin)
More just: Better mathematical configuration (with 2/3 of the network the transaction is validated). For example, a miner could NOT decide which transaction to "make" before due to the higher fee payment.
More secure: It is asynchronous. Nobody can avoid reaching a consensus or trying to interrupt one that has already been reached.
Efficient: No new block can become obsolete.
Less storage: Allows if an event occurs, everyone knows it in minutes, and only the transaction is saved, everything else goes straight to the trash.
Less electricity costs: As they do not rely on PoW (work proof), there are no miners nor would that amount of electricity be consumed. "

This is a bit of the information I found about it.

Hi all,

I want to run a script once a week that sends an amount to a specific address. The amount sent is decided by how much was deposited into the account during the week. For instance the wallet must always have 1 BTC in it and anything over that is sent to the new address each week.

The OS i am using in ubuntu on a Raspberry Pi 3 and i know how to schedule the job using crontab but i do not know how to write the bash script. The bitcoin daemon and bitcoin-cli are all hosted on the same machine as the script.

so far this is what i have.

#!/bin/bash
if [ $(echo "$(bitcoin-cli getbalance) > 1" | bc) -eq 1 ];
then
      bitcoin-cli sendtoaddress ADDRESS $(bitcoin-cli getbalance - 1) "Automated Payment"
fi

Does anyone have any suggestions on how to improve this?

Thanks

DagCoin: a cryptocurrency without blocks

Back in 2012 I thought a lot on a new cryptocurrency that could merge the concepts of transaction and block. Each transaction would carry a proof-of-work and reference one or more previous transactions. The resulting authenticated data structure would be a Direct Acyclic Graph (DAG) of transactions where each transaction “confirms” one or more previous transactions. The confirmation security of a transaction would be measured in accumulated amount of proof-of-work referencing (or confirming) the transaction. This structure is well suited for a cryptocurrency without subsidy (such as a side-chain). On the past years I’ve read a couple of similar proposals on bitcointalk (although I cannot find the references now). When the GHOST paper was published, I perceived it as a reinforcement of my idea that a tree could give more security than a chain in case of high rate of transactions.

My open problems…

The problem that I could not solve in 2012 is how to limit the maximum cut of the generated DAG or, in other words, how to prevent all new transactions from referencing the same set of parent transactions. How to create the incentive to “move forward”? The DAG must not increase in “width”, and it should look more like a DAG-chain. Also one must prevent users from choosing old transactions to extend the DAG. I tried several monetary incentive structures to force users to choose newer transactions, but with no result. To know the last “ledger state” there must be a way to consolidate branches. Merging branches should be good, but not too good such that everyone starts merging the same branches over and over. The problem of spam was also less important, as no transaction would be able to get a “free ride” in a block, as each transaction carries PoW. Ultimately the owners of a computer that is being part of a spamming botnet would realize their computers have been hijacked based on the amount of CPU consumed. For instance, if a transaction requires a proof-of-work that takes 1 second in a standard PC, and each transaction is 400 bytes in size, then a botnet consisting in 10K computers may create transaction reaching 3 Mbytes/second. This high network bandwidth usage itself is not a problem, since it can disrupt the network only as long as the attack is active. However, there must be a way to prevent the DAG-chain from growing at that pace. It turns out that the election of an optimal data structure allows the DAG-chain to be compressed, but it requires us to change how we think about double-spends, and how we conceive the “ledger state”.

A Radical Change

The leap of faith required to find an out-of-the-box solution is to think about double-spends not as a boolean attribute, but as a probabilistic attribute, based on comparing the confirmation work on competing transactions. An the security of a transaction, as the confirmation work compared to the the work expected that an adversary may use. Also it requires to forget about the concept of a “global ledger state”. In Bitcoin there is a global ledger state. Chain reorganizations can always rollback the state, but the state is globally consistent. There is a certain probability of the last block rolling back, but the probability is the same for every transaction in that block. In this proposal, the ledger state is just the overlap of all possible transactions, each with its own confirmation probability, and there is no consistent global state.

Design Premise: “The cryptocurrency network benefits from creating a DAG growing as “thin” as possible.”

In other words, having the average maximal cut as low as possible. It seems that referencing many previous transactions (high out degree) can make the DAG thinner only if the following transactions reference the transaction with high out degree, but are themselves of low out degree. So we want high out degree some times, but low out degree another times.

I designed a DAG that tries to fulfill that premise, and an associated incentive structure such that:

 There is a benefit for users to reference as many previous transactions as possible
 Referencing many previous transactions is incentivized only when there are many previous transactions unreferenced.
 There is no competition between users to reference a previous transaction.

Here is the paper draft  –> DagCoin-v4 https://bitslog.files.wordpress.com/2015/09/dagcoin-v41.pdf

This same article can be found in my blog: https://bitslog.wordpress.com/2015/09/11/dagcoin/

Vanitygen is a command-line vanity bitcoin address generator.

If you're tired of the random, cryptic addresses generated by regular bitcoin clients, you can use vanitygen to create a more personalized address.  Add unique flair when you tell people to send bitcoins to 1stDownqyMHHqnDPRSfiZ5GXJ8Gk9dbjL.  Alternatively, vanitygen can be used to generate random addresses offline.

Vanitygen accepts as input a pattern, or list of patterns to search for, and produces a list of addresses and private keys.  Vanitygen's search is probabilistic, and the amount of time required to find a given pattern depends on how complex the pattern is, the speed of your computer, and whether you get lucky.

The example below illustrates a session of vanitygen.  It is typical, and took about 10 sec to finish, using my Core 2 Duo E6600 CPU on x86-64 Linux:

Code:

$ ./vanitygen 1Boat
Difficulty: 4476342
Pattern: 1Boat                                                                 
Address: 1BoatSLRHtKNngkdXEeobR76b53LETtpyT
Privkey: 5J4XJRyLVgzbXEgh8VNi4qovLzxRftzMd8a18KkdXv4EqAwX3tS


Vanitygen includes components to perform address searching on your CPU (vanitygen) and your OpenCL-compatible GPU (oclvanitygen).  Both can be built from source, and both are included in the Windows binary package.  Also included is oclvanityminer, the vanity address mining client.  Oclvanityminer can be used to automatically claim bounties on sites such as ThePiachu's vanity pool.

Current version: 0.22

Windows x86+x64 binaries here.  PGP signature here

Get the source from GitHub.  Includes Makefiles for Linux and Mac OS X.

FAQ

What types of patterns can vanitygen search for?

Vanitygen can search for simple prefixes or regular expression matches.

Prefixes are exact strings that must appear at the beginning of the address.  When searching for prefixes, vanitygen will ensure that the prefix is possible, and will provide a difficulty estimate.  Exact prefixes are case-sensitive by default, but may be searched case-insensitively using the -i option.

Prefixes are also very fast to search, and a list of thousands of prefixes may be specified with little or no reduction in key search rate.

Regular expressions are programmable pattern filters.  They are very powerful, and can be used to match prefixes, suffixes, varying-length sequences, etc..  For a quick tutorial, see http://www.regular-expressions.info/quickstart.html.  To enable regular expressions, use the -r command line option.  Unfortunately, regular expressions are very slow, and will have a significant impact on key search rate.  Because of this, regular expressions should only be used if their expressive power is needed.

Oclvanitygen is only effective at searching for prefixes.  Regular expressions will not work effectively with oclvanitygen, as oclvanitygen is currently unable to execute the regular expression on the GPU.

How do I specify a list of patterns?

Vanitygen can accept a list of patterns to search for, either on the command line, or from a file or stdin using the -f option.  File sources should have one pattern per line.

Upon finding a match for a given pattern, vanitygen will stop searching for additional matches for that pattern.  To search for multiple matches for each pattern, use the -k option.

How do I import the private key into bitcoin?

If you wish to spend coins received on a vanity address created by vanitygen, you must import the private key into a bitcoin client.  There are two popular methods of doing this with the standard Satoshi bitcoin client:

    Use the importprivkey command.  To do this, select Help -> Debug Window, and in the window, on the bottom line, enter importprivkey <privatekey>, e.g.

Code:

importprivkey 5J4XJRyLVgzbXEgh8VNi4qovLzxRftzMd8a18KkdXv4EqAwX3tS

    Jackjack's pywallet script is an all-in-one tool that directly modifies the wallet.dat file.  This works with a normal, unpatched bitcoin client, but does require Python with the bsddb package.


If I stop vanitygen when it reports 60% complete, how do I have it restart where it left off?

You don't need to.  The percentage displayed just shows how probable it is that a match would be found in the session so far.  If it finds your address with 5% on the display, you are extremely lucky.  If it finds your address with 92% on the display, you are unlucky.  If you stop vanitygen with 90% on the display, restart it, and it finds your address with 2% on the display, your first session was unlucky, but your second session was lucky.

When I double-click on vanitygen, a black window appears for a split-second and disappears, what do I do?

Currently, vanitygen only runs on the command line, and does not have a graphical user interface.  To use vanitygen, you need to open a command line window and change to the directory where you extracted the vanitygen program.  An easy way to do this in Windows 7, hold down the shift key, right-click on the folder where you unzipped vanitygen, and select "Open command window here."  Then, you can type the vanitygen command at the prompt.

Can I use vanitygen to find someone else's private key from their bitcoin address?

Yes.  Vanitygen is a cryptographic brute-forcing application, and can be used to search for a complete address.  However, you will be unhappy with the amount of time required for it to find a match.

How do I report a bug?  What do I do if it crashes?

Post to this thread, send me a PM, or send me an email!  Please run vanitygen with the -v flag for verbose output, and please include the console output in your report.

How do I build vanitygen from source?

Please refer to the file INSTALL in the source distribution.

What key search rate can I expect from hardware X?

Detailed list forthcoming.  Some ballpark estimates are listed below.

Dual-core desktop CPUs, 32-bit mode: 100-250 Kkey/s.
Dual-core desktop CPUs, 64-bit mode: 150-450 Kkey/s.
Quad-core desktop CPUs, 32-bit mode: 200-400 Kkey/s.
Quad-core desktop CPUs, 64-bit mode: 300-750 Kkey/s.

As vanitygen performs a lot of large integer arithmetic, running it in 64-bit mode makes a huge difference in key search rate, easily a 50% improvement over 32-bit mode.  If you are using a 64-bit edition of Windows, and not using a GPU, be sure to use vanitygen64.exe.

In custom builds, CPU performance will be less than expected if the OpenSSL library is an older version (<1.0.0d) or is not built with the appropriate optimizations enabled.

General formulas for expected performance on GPUs

NVIDIA GeForce 96xx, 98xx, GT 1xx, GT 2xx, GTX 2xx (G90/GT200):
Key/s = (CUDA Cores) x (Shader MHz) x 17

AMD Radeon 58xx, 59xx, 67xx, 68xx (VLIW5):
Key/s = (Stream Processors) x (Core MHz) x 20.1

AMD Radeon 69xx (VLIW4):
Key/s = (Stream Processors) x (Core MHz) x 13.6

AMD GCN, NVIDIA Fermi/Kepler: Please contribute some numbers!

Unfortunately, AMD VLIW4 does not perform as well as VLIW5 with the same number of cores/clocks.  Oclvanitygen is sensitive to integer multiply throughput, and VLIW5 can multiply concurrently with other operations, whereas multiply consumes all four ALUs in VLIW4.  At similar clocks, a hobbled Radeon 5830 will outperform a Radeon 6970.

I have a lot of compute power, and want to make vanity addresses for others.  How do I do it?

The difficulty with this is convincing your customer that, once you provide them with a vanity address, you do not have a copy of their private key.  Some methods of doing this have been discussed on the forum, and vanitygen currently supports one of them.  To generate an address securely, your customer generates a private key, and provides you with the public key part.  You use this public key as part of the address search, and when you find a match, you provide them with a partial private key.  The customer then adds the partial private key to their private key to get the vanity address.  Because the customer never disclosed their part of the private key, only they have access to the complete private key.

There are many ways to get a key pair, but to do address-for-hire, you need the complete public key in hexadecimal format.  The bitcoin address is not sufficient.  One way to generate one and get this is to use the keyconv utility, keyconv -G, and get the following parts:

Code:

$ ./keyconv -G
Pubkey (hex): 041d2e778ae6d9124736df131cd22d3a2483f336c55156d87a84c4bdc6d89f8518e33de85ae0f907a7128c476281bc8cc7742b43a54ccc2c7824dc4c4a438a7fbc
Privkey (hex): 61E00B1C57E7F0D508C7C3795F90C0ACEC1DCAF6A7B82C951D23F728FD53E4BE
Address: 15wRE5VA5uhxs5o6LayZC6imES2SeZeXd4
Privkey: 5JZPftgcsaG5Unp24cf47zP7JZEZkfnSAZzefezAVNRomKHZE8f


The customer saves the privkey part in a secure location, and provides you with the Pubkey (hex) part.

Then, you run vanitygen or oclvanitygen, and specify the customer's public key:

Code:

$ ./vanitygen -P 041d2e778ae6d9124736df131cd22d3a2483f336c55156d87a84c4bdc6d89f8518e33de85ae0f907a7128c476281bc8cc7742b43a54ccc2c7824dc4c4a438a7fbc 1Boat
Difficulty: 4476342
Pattern: 1Boat                                                                 
Address: 1BoatWxEHyVXkjS78d16LMuj8YMdZ1Kce8
PrivkeyPart: 5KCwog8Ndt64ZicNSGoDBRf4vACBptM2GUtSJCmkbqpieC8idcP


Because a public key was specified, vanitygen now provides a PrivkeyPart rather than a Privkey result, which is useful only to your customer.  The customer then takes the partial private key produced by vanitygen and adds it to their private key.  This can be done using ThePiachu's handy website, or using the keyconv utility:

Code:

$ ./keyconv -c 5JZPftgcsaG5Unp24cf47zP7JZEZkfnSAZzefezAVNRomKHZE8f 5KCwog8Ndt64ZicNSGoDBRf4vACBptM2GUtSJCmkbqpieC8idcP
Address: 1BoatWxEHyVXkjS78d16LMuj8YMdZ1Kce8
Privkey: 5J1Jieusaa6vegTQZ7PNG3hMcsM2FjgHPK1BkPjbYyQsWb9k5vj


Here, keyconv is able to recreate the final address found by vanitygen, based on the two private key parts.  It is also able to create the final private key.  This is infeasible for someone who does not have both parts of the private key, and provides your customer with real security.

This process is very complicated.  A simpler way to do it is to use a bounty pool such as vanity pool.

How do I participate in vanity pool?

To do this, use the oclvanityminer program.  Oclvanityminer works much like a familiar bitcoin miner.  It connects to a bounty server, downloads a list of bounties, automatically chooses one, searches for a match, and submits the results back to the server when one is found.  Oclvanityminer periodically reconnects to the bounty server to check if bounties have been claimed, or more profitable bounties have been posted.  An example session:

Code:

$ ./oclvanityminer -u https://vanitypool.appspot.com/ -a 1samr7UZxtC6MEAFHqr1h3Kq453xJJbe4
Searching for pattern: "1satoshi" Reward: 0.100000 Value: 0.000007 BTC/MkeyHr
Difficulty: 51529903411245
Searching for pattern: "1Satoshi" Reward: 0.100000 Value: 0.000007 BTC/MkeyHr
Next match difficulty: 25764951705622 (2 prefixes)
[6.14 Mkey/s][total 62914560][Prob 0.0%][50% in 33.6d]


Note that vanitypool and oclvanityminer are currently under development.

How secure are the addresses generated by this program?  Will someone be able to guess the private key and steal my BTC?

Vanitygen uses the OpenSSL random number generator.  This is the same RNG used by bitcoin and a good number of HTTPS servers.  It is regarded as well-scrutinized.  On Linux, the RNG will be seeded from /dev/urandom.  Guessing the private key of an address found by vanitygen will be no easier than guessing a private key created by bitcoin itself.  Nonetheless, if you feel the default RNG is unable to provide numbers that are sufficiently difficult to guess, vanitygen can be directed to seed the RNG from an external file using the -s option.

To speed up address generation, vanitygen uses the RNG to choose a private key, and literally increments the private key in a loop searching for a match.  As long as the starting point is not disclosed, if a match is found, the private key will not be any easier to guess than if every private key tested were taken from the RNG.  Vanitygen will also reload the private key from the RNG after 10,000,000 unsuccessful searches (100M for oclvanitygen), or when a match is found and multiple patterns are being searched for.

What security measures should I take?

    Secure any systems used to generate addresses.  Don't run web browsers on them.  Keep malware and unauthorized individuals out.
    Ensure that any private keys reported by vanitygen are stored and transmitted securely.
    The command line method of importing private keys into bitcoin requires you to enter your private key on the command line.  Bitcoin takes a long time to perform an import, and while it is running, your private key will be visible in the output of "ps," so be careful!  Also, the private key may be leaked to your shell history file.  Kill your shell and shred your shell history file after importing.


What are the other methods of generating vanity addresses?

The original method of generating vanity addresses is a patch to the official bitcoin client created by Gavin Andresen.  Details can be found here.

Forum user Nyhm created an in-browser vanity address generator.

There is a new vanity address generator for Android.

Anyone can tell me if....

- An address starting with 1 is not segwit
- A bech32 address (bc1) is segwit

Are we ok? but...

- An address starting with 3 may be segwit

Don't we have yet a method to see if the address starting with 3 is a segwit or not? Or only once spend we are able to see if the P2SH is segwit or multisig

Thanks  Undecided

Friends,
I've seen that being non-user of SegWit, there are no such benefits or advantages that we can accrue.
So, I wish to learn how to switch to SegWit completely?

I became aware of Segwitaddress.org to create an address directly from there, but if I use that address, will I be able to sign messages through that address (as the address is being provided with the private key itself)?

I also used an option that asks for a "WIF Private Key" (I entered my Legacy address, i.e.; 19RidcN96xgXkWi8gDwxcmbjjdjfrxpxvv's privkey) there and got an address that could be used to receive funds. But what I don't get here is, where will I see those funds and where can I use them from?
I mean, if I use the same privkey in any wallet, it will still show 19RidcN96xgXkWi8gDwxcmbjjdjfrxpxvv as my address and not the one I get from segwitaddress.org, what should be done here? As well, should I keep me Legacy address' privkey even if I adopt SegWit completely?