So if I understand you correctly, you want this: - Enter the TXID for a transaction and priv keys for one address 1 in the transaction and another privkey for address 2 (does not need to be a part of TXID) and a number of rounds to repeat.
- Send a transaction A from outputs from the TXID with a normal fee to address 2.
- send another transaction B breaking up the inputs from A into 2890 0.00001 BTC outputs for address 1 as possible with a fee of 0.001
- Create 5 transactions C that spend 552 outputs from B to address 2 with the remainder going to a change output with a fee of 0.001 BTC
- Create transaction D with a fee of 0.000015 spending all of outputs from C excluding change back to address 1.
- repeat for the remaining the next round using the change from A and the output from D
- After all rounds are completed, broadcast all of the transactions at the same time
Why do you want to broadcast the transactions all at the same time? I can probably do this in java, but please let me know if the roadmap I listed above is correct.
|
|
|
The hash of the block must be less than the target (typically represented as having more leading 0's but that is technically incorrect). The block hash is a 256 bit number in hexadecimal form and so is the target. In order to be more difficult, the hash must be less than that target. As the difficulty increases, the target decreases, thus restricting the range of acceptable hashes. As the range decreases, it becomes more difficult to find a hash that matches the criteria. This should help as well: https://en.bitcoin.it/wiki/DifficultyI did not ask about difficulty. I asked about block comparison when there is a branch, in other words, when there are two possible block chains. That is related to difficulty. If the difficulty for a block is higher than another block, it is more difficult. The difficulty is encoded into blocks as the "bits" field. The longest blockchain is the blockchain with the highest combined difficulty. I think it is just the sum of all of the difficulties of all of the blocks.
|
|
|
Interesting proposal. The concerns I'd have include:
- If a vote must be used to initiate the hard fork, it should be 95%. Note that this concept only became necessary because of the XT code fork. Otherwise, we could of just set a date in the future and asked miners to upgrade by then.
In the presence of the many BIPs, I think a supermajority criterion is needed. I am not sure why 95% would be better than 75%. I think 75% is enough, and I think 95% might not be reachable. Of course, if a consensus could be reached and "bitcoin-core" or another project convinces everybody to use the SW, then the new BIP10X protocol could be simply activated at a given block height. My assumption though was that we are dealing here in a somewhat competitive environment between different proposals. It should be 95% for supermajority. BIP 101 is idiotic for using 75% and calling that the supermajority. All previous BIPs that had soft forks used 95% of the last N (usually 1000) blocks. Since this would be a hard fork, it should definitely have at least the same supermajority standards.
|
|
|
The hash of the block must be less than the target (typically represented as having more leading 0's but that is technically incorrect). The block hash is a 256 bit number in hexadecimal form and so is the target. In order to be more difficult, the hash must be less than that target. As the difficulty increases, the target decreases, thus restricting the range of acceptable hashes. As the range decreases, it becomes more difficult to find a hash that matches the criteria. This should help as well: https://en.bitcoin.it/wiki/Difficulty
|
|
|
What app were you using?
Unfortunately, your Bitcoin is probably lost. There is no way to recover the address without any kind of backup.
|
|
|
Is Bitcoin Core completely synced yet? If it isn't the transaction might not be broadcast.
Also check your connections. Open Help > Debug Window and tell us how many connections it says you have.
What version of Bitcoin Core are you using?
|
|
|
There was an error with the database, caused by it during down incorrectly. It will reindex the database which can take a while. Your bitcoin is safe.
Again 40 GB must be download? It will not download anything. You already have all of the raw blocks, but it must organize them into a database so that Bitcoin Core can quickly reference data it needs. It will take a few hours, but not as long as downloading.
|
|
|
It looks like this one www.dzlatan.pw/get_activity.php but the only difference is OP's has ads. Anyways it would be still helpful to check the potential activity in 2 or more activity checkers. Is there anymore sites like this ? There is a site I created, bctalkaccountpricer.info which not only gets your potential activity but also estimates the price of your account.
|
|
|
still buying 1 thanks!! If you didn't get my pm, my offer is 0.23
|
|
|
Sure, why not? If I can do this through fiat, why not Bitcoin? It might get some bad press, but it will help someone and help my family.
|
|
|
You should definitely write this into a program and put it in services or project development. It would be great for analysis on finding people's alts, not just quickseller. In fact, maybe quickseller himself might even use it.
Great idea! Then people can do to others what tspacepilot claims quickseller did to him, make accusations without solid proof, just assumptions based on what others say or in this case, a script / algorithm or whatever you want to call it. No? It would be a good baseline to start with. Instead of attempting to hunt and search for proof that might not even exist, it would at least provide someone with something to work off of. It would at least show that it is possible for two accounts to be alts for further research instead of going directly to searching for blockchain evidence which can take a very long time. Such a program would also be useful for seeing whether an account was sold and roughly when.
|
|
|
I was thinking of this site of yours yesterday with people saying they are number so and so in the queue and some complaining that they have been waiting hours [including me], in any case, I was wondering, how many hits/requests do this site process each day?
I think it would be quite interesting if you don't mind to share it. I believe it to be much higher than we think it might be.
According to my ad stats, I'm getting around 17 unique ip's per day and around 24 visits per day. Been loading for about 2hours now. although i dont think its loading it feel like its stuck. i was at position 4 for a looong time. i wonder if the code actually takes that long to execute
It doesn't take that long to execute, but there is the problem where the queue isn't working. Unfortunately, the best option right now is to restart the web server software periodically to clear the queue. I think I will add a crontab task so it does that every 24 hours.
|
|
|
You should definitely write this into a program and put it in services or project development. It would be great for analysis on finding people's alts, not just quickseller. In fact, maybe quickseller himself might even use it.
|
|
|
What is the license on this? I'm starting to see some people creating their own sites with the script and posting them in the services section. This should have a license on it so any of their changes can be merged if there is any improvement. I would recommend using Affero General Public License from here: https://www.gnu.org/licenses/agpl-3.0.en.html if it doesn't already have a license.
|
|
|
If you want i can host in my paid host, i think it should work faster in two websites(hosts) with different IPs isn't it ?
The problem is that the program isn't designed to have two servers as backend. I can probably modify it to do that, but it will take some time. The site is back up. But what do you think to have a copy on the another server, another ip? And linking these 2 websites to each other? That could work. Maybe like a load balancer thing where the visitors are switched between the servers. One visitor to one server, the next on the other, and the third back on the first. This is kind of like my original idea which involved a new server for each request, but that didn't work. Or maybe a new server for each visitor that connects to a shared database so their results can come back instantly and each visit they can get the same data with the same token.
|
|
|
I've heard of this before how would this be possible and how does one do an offline transaction? does it mean it keeps a request in memory until you connect to the internet then sends it?
Using an offline computer, you would create and sign the transaction and then transfer the data (usually just the data in hex) to an online computer to broadcast. The transaction can be broadcast through Bitcoin Core or through various online services that push transactions.
|
|
|
the answer is they wouldn't
miners would find a good balance so that bitcoin TX remain low cost, because in the end the fee they collect aren't valuable if bitcoin isn't valuable, and bitcoin isn't valuable if it's expensive to use it, or less valuable. miners would bump the limit up to what the avg miner can comfortably handle probably ~8MB, and then maybe they would collectively refuse to bump the limit any future, and fee would start going up because 8MB blocks are being filled ( wouldn't that be nice if bitcoin had 8X more traffic then it has today) and then because 8MB of tx with a 0.0005BTC fee = 16BTC in fees pre block ( 8MB / avg tx size 250 bytes *0.001BTC fee) suddenly mining is very profitable, more poeple join, poeple that can comfortably handle 8MB block get knocked out and the limit rises again. or something!?
you can't argue that bitcoin is somehow more valuable if it can't do micropayment so dont try brg444
So Basically all of those arguments saying that the miners would drive up the fees to be ridiculously high are unfounded. So is this actually your solution for the block size debate? Let's leave the 1MB cap for the moment and let's play with the fees, or to say, let's increase the fees as needed. And this is fine with me, I think that even a fee of 0.0005 or even a fee of 0.001 BTC isn't amazingly big, if you send let's say $1,000 worth of Bitcoin, it's nothing to pay 0.001 or $0.23.
But what happens then if we get so many users on board that they are all ready to pay 0.0005 but there is no room for 1MB block? I guess everybody will agree and raise block size at this moment, like you said to 8MB. But what happens when even this 8MB becomes too small?
Or are we really far, far away from this point?
The cap would go up again. I thought that he meant something like BIP 100 where miners could vote to increase or decrease the block size limit. They would just keep the limit at a point that the fees go up enough to be profitable, but then they can vote to increase the size so that people still use Bitcoin. Fck altcoins. If you don't wanna pay the high fees required to maintain the Bitcoin network the alternatives are lightning, other payment channels or off-chain methods. In fact if you can't pay for it you most likely don't actually need it that bad enough Clearly you don't know much about economics. Sure there will be those hardcore fanatics that will stick with Bitcoin no matter what, but for the general populace, if fees go to high, they will go with the next best alternative. While Bitcoin dominates the market, there is still competition, and with just one screw up like ridiculously high fees, people will most likely ditch Bitcoin for an altcoin because it is in their self-interest to pay lower fees.
|
|
|
So I have been following the recent block size limit discussions going on and one thing I noticed is that people say we shouldn't raise blocks to allow a fee market to develop. Another is that BIP 100 allows miners to continue to lower the block size limit in order to force a fee market.
From what I understand, the idea is that once there are enough transactions to fill blocks up completely and have a backlog, resulting in some transactions not being confirmed in the next block. Then, in order to get into the next block, transactions will begin to have higher fees.
While this might be good to increase fees slightly, I don't understand why people say that small block sizes will force a super competitive fee market. Wouldn't people just ditch Bitcoin and go to some other altcoin (like litecoin) instead of paying ridiculous fees? Why would miners (in the case of BIP 100) lower the block size limit to increase fees if it drives away people thus decreasing their earnings?
|
|
|
|