It took you guys 8 months to unlock this poor guy's funds? Funds that were his to begin with.... I'd be pissed if you would lock my money for 8 months...

If your original tx has the rbf flag set, it can be replaced by another transaction using the same unspent outputs as an input. You can change the address(es) being funded, as well as the values they're funded with.  This is why services like bitpay don't like rbf tx's

The reason for the reset is twofold (IMHO)

First: Eventough the network is "flooded" with ASIC's, i  still succeeded in CPU mining about 10 blocks since i started my faucet... Mainly because the hashrate sometimes drops (for some reason) and if after 20 minutes no block was solved the difficulty drops to 1 for 1 block. At this point, you have a shot at solving a block. If this drop in hashrate coincides with a retarget, the next 2016 blocks will have diff 1, then 2, then 4,....
However, at the moment, solving a block only gives a coinbase reward of 0.19 tBTC. Not enough for really big projects.

If the testnet would have been reset, i would have mined >500 tBTC instead of 2.5.

Secondly: resetting the testnet would send a message to anybody burning electricity by mining on the testnet with a power-hungry ASIC... You can burn as much electricity as you like, we'll still reset the testnet and your tBTC stash is gone. Next time only cpu mine when you need tBTC and keep your ASIC away.

In the ideal situation, i guess some devtime might need to be allocated to the testnet. There must be things that can be implemented on the testnet to make it a little less prone to ASIC-mining, or at least make sure the block reward doesn't drop as fast. It is true, however, the more of these features get implemented, the bigger the difference between the testnet and the main net gets. However, as it stands, the testnet is almost "used up". If you need tBTC for a project it's very hard to get any decent amount for testing. This wasn't the reason why the testnet existed...
For example, the coinbase reward halving on the testnet could be disabled, the POW algo could be changed, the testnet could be reset at each new core release, unused unspent outputs could be truncated after x months (to discourage hodling), a huuuuge premine could be implemented by the designers, and they could run their own faucet with claims of 1-10 tBTC.

Either the transaction had a rbf flag, it wasn't broadcasted succesfully, you waited untill the original transaction was dropped from the mempool of most of the other nodes, the first transaction was invalid or you got extremely lucky to have had it relayed by nodes that were either patched or for any reason didn't have the original tx in their mempools.

The default action for a node when it receives a transaction double spending unspent outputs from an unconfirmed transaction in their mempool without the original tx having an rbf flag is to reject the second (double spending) transaction. This is the case with default node implementations.

Anyways, removing a broadcasted, valid, transaction from your own mempool does not remove it from the mempool of any other node.

The protocol simply does not allow you to remove non-rbf transactions from other node's mempools, simple as that (and for tx's with the rbf flag, you do not remove the original tx either, you simply replace it). So any function from any wallet that says otherwise is simply removing the transaction from your wallet, removes it from your mempool and/or stops broadcasting the transaction. But once a succesfull transaction is broadcasted, it stays broadcasted, and the only thing that'll remove it from other node's mempools is time (a long time) or the presence of the rbf flag in the original tx.

you can remove all transactions from your own mempool by stopping core, deleting the mempool db, and starting your wallet with -zapwallettxes, but that's just from your own mempool. AFAIK, the gui has a feature to "abandon transaction", but that's more or less the same (it differs on a couple things on a deeper level, for example iirc abandoning only works after the tx is no longer in your own mempool so it clears the tx from your wallet not your mempool) . Once a valid transaction has been broadcasted, it'll be stored in the mempool of most of the other nodes of the network, nodes you have no controll over whatsoever.

There is no way of "deleting" a transaction from other node's mempools, the only way it'll get cleared from other node's mempool is if your transaction is included into a valid block, or if the node itself decides to remove the transaction (usually because the mempool is over a certain size, or if the transaction remained unconfirmed for a certain amount of time).

I would discourage to abandon or zap unless you have a very good understanding of what you're doing... Eventough you no longer have a record of an unconfirmed transaction that has been abandoned, it might still be available in the mempool of a mining node, so a miner might still use this transaction in his/her block. You might end up paying somebody twice, or you might end up double spending an unconfirmed output, and the receiver might brand you as a "scammer" as a result (eventough you had no intention to scam)

You can't delete a transaction once it's broadcasted (doesn't matter if it has the rbf flag or not). You either wait untill it's confirmed or untill most nodes dropped it from their mempool, or you bump the fee (create a new transaction to replace the previous one, but not deleting it).

Why would you want to delete a broadcasted transaction?

And it's about time this reset happens again... Current block reward is ~0.19 tBTC, the difficulty however is usually ~13.3M, with the occasional drop to 1, then building up to >10M over the course of hours/days...

The estimated hashrate is:
D * 2**32 / 600
13.300.000 * 2**32 /600 = ~95 Th

Yup, that's right, if we "guess" nobody would be dumb enough to actually run a profitable, latest gen, miner on the testnet, so we're probably talking about S7's or less, we can conclude that at this moment, there probably are the equivalent of 20 S7 ASIC's running on the testnet...


Since i started my tbtc faucet, i've been solo mining with my cpu using 2 threads, trying to find a block when diff drops to 1 (if no block has been found for 20 minutes) or when the diff drops to 1 just before a retarget, so i try to hit a block before diff climbs back to a value i cannot cpu mine anymore.

In the many months i've been cpu mining, i've found like 10 blocks, totaling like ~2,5 tBTC... If i were a developer that needed these tBTC to do big projects, i'd be forced to buy a recent gen ASIC and start to actually mine the testnet with an expensive ASIC just to get the tBTC i need to develop.

I've heared people saying that any development you can do with 1 tBTC should also be possible with 0.0001 tBTC, just by editing the sourcecode. I only think that's partially true, some developments just need large quantities of tBTC. Imagine building a mixer, or an exchange, or a high traffic ecommerce system and having to work with 0.01 tBTC to toroughly test your development. Values would start to get really, really, really small, and fees would basically burn your 0.01 tBTC after a couple of minutes of high volume testing.

I've also been criticized for asking collateral whenever i lend out tBTC to somebody i don't know... The matter of the fact is: tBTC might be worthless, but at current diff and block rewards it is by no means free to mine... I would never ever sell tBTC, but if i lend some out, i would want the most of it back after the lender finishes testing.

Just to clarify, the testers will get payed for their tests (in other words: they'll receive a couple of buck to run the tests, so they won't have to risk their own money), or will they receive a code so you'll charge a 0% fee (but they'll still risk their own money), or something else?

Theoretically, yes, but he'd have a much better chance of winning his state lottery several times in a row... It's all about odds here, sure there is a chance you'll be hit by an astroid at the exact time you're sitting on the toilet while being spied on by a transexual paparazi photographer who thinks the earth is flat.... The odds, however, are not that big. Defenately not big enough to start bribing all transexual paparazo's not to take your pictures while you go to the toilet.

As for your exact question, a GPU vanitygen tool could find ~20.000.000 private key => public key => public key combinations/second
(https://en.bitcoin.it/wiki/Vanitygen_keysearch_rate)

There are 2^256 private keys,
It would take a GPU 183587153154040137340770841274560000000000000000000000000000000 years to scan the complete keyspace

But you say 1 billion worth of equipment... Let's assume Bezos gets bulk discounts, and he's able to buy GPU's + risers + motherboard + PSU's + shelves + S&H + taxes for the astronomically small amount of $250/GPU (everything included).

His 1 billion buys 4 million GPU's...
I found this study from 2018: https://news.bitcoin.com/study-finds-less-than-40-of-btc-addresses-are-economically-relevant/ It says there are 27.000.000 addresses in use. Let's assume by now there are 50 million addresses.

It would still take Bezos
91793576577020068670385420637278000000000000000 years to have a 10% chance of finding a private key belonging to a funded address.

The sun will only live ~10 billion years (https://spaceplace.nasa.gov/sun-age/en/)
Even if Bezos magically finds hardware that's 1 million times as performant as a GPU, it would still take the lifetime of 9.179.357.657.702.006.867.038.542.063.727 suns to have a 10% chance of finding the private key for a funded address.

I won't even start about the amount of power he'd burn while trying...

Offcourse, this theoretical example starts from completely random keys, if there's a flaw in the RNG a lot of variables change

No problem, everybody has to learn someday.

In your case, you would have needed an unspent output with minimum value of 659 sats:
546 sats (to get over the dust limit) + 113 sat (as a minmum tx fee since you tx is 113 bytes and tx's with a fee under 1 sat/byte will not be created by electrum's gui interface).

It IS possible to manually create a transaction with a 63 sat fee, altough it probably will be rejected by most nodes.
It IS possible to manually create a transaction with an unspent output under the dust limit, altough it probably will be rejected by most nodes.

Your wallet is just anticipating on the fact allmost all  nodes will reject such transactions, and it is programmed not to create such transactions from the gui.

Well, if you read my previous post, that's what i told you...

Electrum will only allow you to create a tx with 1 sat/byte, your transaction has a size that's over 63 bytes, so there is insufficient funds. Electrum has this minimum because the developer knows that a tx with a fee of less than 1 sat/byte will also be rejected by most nodes.

Your transaction is probably ~140 bytes, so if you chose a 1 sat/byte fee and want to fund an address with 546 sat, you'll need a balance of ~686 sat, which you don't have.

That's why my previous post clearly indicated that those funds are more or less "stuck" unless you fund your wallet with some extra sat's... The only thing you did was prove what i said before.

You have 0.00609 mBTC, thats 609 satoshi's. Any output value under 546 will be considered dust.
609-546 = 63

So, you could create a tx funding an address with 546 satoshi's, this transaction would not violate the rule you're currently violating. However, most nodes also have a rule not to relay transaction that do not have a minimum fee per vbyte. Most likely your transaction sending 546 satoshi's would break THAT rule instead since you only have 63 satoshi's left for the fee and even a 1 input 1 output transaction from a native segwit wallet is to big to be relayed with a 63 sat fee.

I'm pretty sure you only have one unspent output funding your wallet, since 609 sat is not dividable in 2 unspent outputs that do not break the dust relay setting. But yeah, that one unspent output is more or less "stuck" (until you fund one of the addresses of this wallet with more unspent outputs).

nope, not the kind of signatures you are talking about.


By email? By text message? in a PM? Posted on a forum? Carved in stone?

HCP already answered this in this very thread: https://bitcointalk.org/index.php?topic=5248354.msg54428683#msg54428683

You're mixing up the unspent output that's being created and the fee. If you'd try to send 100 satoshi's and payed a 500000000 sat/vbyte fee, it would still be rejected.

It's because all those unspent outputs have to be stored in all the node's utxo db's. IIRC, there is/was a general concensus that nobody wanted to waste space on an unspent output of a couple satoshi's. That's why they chose a "minimum" unspent output value that they felt comfortable spending space on and decided not to accept transactions under said minimum into their mempool, nor would they relay them to other nodes.

It would be possible to run a node with a much lower limit, if you found a node witch has altered the default value, you could probably broadcast your transaction to that node, but that node wouldn't be able to relay the tx to other nodes, since the other nodes would reject it (due to dust output)

In your case, you don't have to look at any unspent outputs funding change addresses tough... You're trying to send 100 satoshi's, meaning you're trying to fund an address with an unspent output of 100 sat, this in itself is dust and will cause your transaction to be rejected by allmost all nodes.

yes. It's creating an output with a value that's to low. A node could potentially change the default value, but i think it used to be around ~500 sats. Any transaction creating an unspent output smaller than this value would be rejected by nodes having the default configuration.

Signing messages, sure... But i think you're getting a bit confused about some key concepts here.

The description you're entering in your wallet is basically just a piece of text that will be saved in YOUR wallet file. It does not end up in any transaction that's being generated. It is for your reference only. Even if you delete your wallet and restore it from the seed, those pieces of text will be gone.

Signing a message is using your private key and a piece of text as an input, and creating a signature as output. Using the address belonging to the private key, any individual can verify the signature, but they cannot create a signature with the address alone.

If you want data to be stored in the blockchain, i'd probably point you here: https://en.bitcoin.it/wiki/OP_RETURN

There are also block explorers that allow you to enter metadata for an address/transaction/... This metadata is stored in the (relational) database belonging to the block explorer. It is also not stored into the blockchain, it's just private data belonging to the explorer, data they can show, hide, delete, update,...

Nodes have a rule against creating dust outputs, you're breaking it.

You know the Description is stored in your wallet only, right? Nobody else will ever see the text "are you alive", it is not broadcasted, it is not included into any blocks, it will never be shown to anybody (well, it's shown to us in the screenshot you created, but that's simply because you created a screenshot)

If i follow the link you posted, this is what i see:


This sounds about right... But yeah, some explorers might have trouble with the 50 BTC reward funding this address... It's possible some have flaws when converting btc to fiat... I wouldn't care to much tough...

What do you mean, is this bugged? No, it is not... Why would it be bugged?
People can fund whatever address they want for whatever reason. The people funding 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa are probably doing so to beg (since it's an address that's looked up pretty often, so they "advertise" their address) or maybe to boast, or to pay homage to satoshi...

Well, your wallet holds private keys, the public keys of those private keys are hashed. These hashes are your addresses.
In the past, somebody funded your addresses: somebody else created a transaction, and one or more of the outputs of said transaction were funding an address whose private key belonged to your wallet. You have one or more unspent outputs funding one or more addresses, the sum of the value of these unspent outputs is seen as the balance of your wallet.

When you click "send", you wallet will combine one or more of those unspent outputs with a total value equal or greater to the amount you want to transfer PLUS the mining fee. If the sum of the values of the used unspent outputs is bigger than the amount you want to transfer plus the fee, a change address is used. This change addres also belongs to your wallet, and it's funded with the leftover value.
In the meantime, while selecting unspent outputs to use, and finding out wether a change address is needed, your wallet also calculates the optimal fee. Sometimes you can pick your own fee, sometimes a slider is used, sometimes the fee calculation is hidden altogether, but your wallet calculates the weight of your transaction and adjusts the fee accordingly.

After the unsigned transaction is created (unspent outputs are used as an input, new unspent outputs are created as output), the transaction is signed with the private key(s) belonging to the addresses whose unspent outputs are being used as an input.

The signed transaction is now broadcasted to the nodes. Each node checks if all unspent outputs used as input are available in their utxo db (db with all valid unspent outputs), they also check the signatures. Invalid transactions get rejected, valid ones get broadcasted to other nodes.

In the end, the transaction ends up in the mempool of about all the nodes of the network. Some of these nodes belong to miners. Miners sort the transactions from highest fee/Wu to lowest fee/Wu. They take the top tx's (untill the block is full), calculate a merkle tree, put the merkle root in the block header they're trying to solve (together with the sha256d hash of the previous block header) and try to find a nonce for which the sha256d of the new header is under the current target.

If they succeed, they found a valid block, and they can broadcast it to the network.

As soon as a signed transaction is broadcasted, the receiver usually sees an incoming, unconfirmed transaction. Once a transaction ended up in a valid block, the receiver will see the transaction is confirmed.
When new blocks get mined on top of the block containing a transaction, the receiver will see +1 confirmation...

As long as a transaction remains unconfirmed, it'll stay in the node's mempool. Each node can truncate their mempool, so if a transaction remains unconfirmed for to long, most nodes will have dropped it from their mempool. This is one of the reasons why it's a bad idear to accept 0 conf transaction.