It got me out of a BAD situation and is now the reason that I have a roof over my head. I spent much of my childhood looking at how cool all this is. Looking at the data structures of blocks and transactions and what the signing process is like and all that. Mining some too. I contributed where I could. Met some awesome people. It's the coolest thing ever, and I used it. It's "fun" to look at old transactions and think, wow, I bought this game for $600, that was a $900 pizza, etc.

Remember 2013 and 2017? I watched as my friends all either became millionaires or very, very depressed. I ended up somewhere in the middle. More than someone my age usually would have access to, but I wasn't about to retire right out of high school.

And eventually home life gets a little worse, then a lot worse. It's contentious living with my parents. It wasn't safe anymore. Bitcoin gave me the ability to just go. My sister and I were both legal adults. I had no job, no car, nothing like that, but I was able to get a nice place if I made a big security deposit and advance on rent. Found a job pretty quickly. We were saved.

I still have a little bit left. Enough that I could call on it again in a time of need. But it's fun to watch the charts after all this time. I will always be a member of the bitcoin community.

29. Taras
Thank you!

Well, what stops a LN user from just removing the extra requirements from their client? It's open source after all. That doesn't sound like it would make them incompatible with the network.

The hard part is proving that you will always be able to get x hydrogen for your x energy credits. How do you issue energy credits? Currently the only solution I can think of isn't really a solution - having a central issuer take your hydrogen and give you credits and a promise to give you hydrogen back if you should return those credits. The promise is easier to transport and weighs less than the hydrogen it is purportedly backed by, but centralizing things is a step backward - we'd have to instead first find a way for a computer to easily verify that a difficult computation took place that... resulted in electrolysis of water. I'd love to hear of a way to produce such a proof, but I can't be sure that it is possible.

Chains like Luckycoin and Dogecoin make use of randomness when determining block rewards, so it is possible.

There's a lot of lottery drawings by members of this forum. Instead of selling an item, they sell a lottery ticket to try and win that item. They agree on a way to randomly generate a number, so that the seller can't defraud the bettors. Here's how they solve this problem:

The seller announces they are going to host a lottery with a prize. The lottery will end after a certain bitcoin block in the future is mined; say 1000 blocks from now. After that block number that was agreed upon beforehand is mined, the lottery is over and the winner is announced. The seller announces how the winner will be chosen with this block when the lottery begins. Usually, what they do is, they agree to take the last 4 bits of the hash of that future block. The bettors buy tickets with a unique 4-bit number attached - no two tickets have the same number. If their number is the number taken from the last 4 bits of the block hash, then they won! Nobody can know the hash of the block until it is mined. Even if you are a miner, and you only want to mine a block that ends with your lottery ticket number, making a block that does not end with your lottery ticket number and choosing to discard it for that reason is an immediate BTC12.5 loss. And you probably won't solve another block in time before someone else does anyway, so you couldn't guarantee you will win. The only way to profitably tamper with this drawing without a massive risk (which likely outweighs the value of the lottery prize) is with a successful 51% attack, or perhaps an as-of-yet unknown SHA-256 vulnerability.

You don't have to use 4-bit numbers; you could do 8-bit, or 64-bit, or any number, as long as it cannot exceed the current difficulty target, which is a very massive number. Technically, every block hash is a random number between zero and the difficulty target.

That doesn't make the solution simple, that makes it impossible. How do you force LN hubs to run a full node? Where do we draw the line between hub and not hub? Do all participants draw that line differently? If you could, as a network, choose not to do business with a node with a large number of channels unless they can also verify it is running on a full node, somehow, what does that do? The hub could divide its channels across several of its own nodes, keeping under the threshold to be considered a "hub". I think this idea is either virtually impossible or useless.

R protects the guarantor from a dishonest buyer. If the guarantor kept their copy of T_A and accepted T_B as the secret. the buyer could accept a lightning redemption, at which point the guarantor will use T to spend the multisig commitment (which in this case could be T_A and T_B instead of T and R). However, the guarantor doesn't care if this transaction takes a long time and wants to include a low fee. The buyer in this situation would also have the right to spend the commitment, even after collecting the lightning money, because they too have T. They can include a higher fee than the guarantor, since they have already gotten the full value of the voucher over lightning anyway, so they can take the on-chain commitment after already accepting the lightning redemption. Taking from the guarantor double the value of the voucher.

I believe there are good precautions the guarantor can take to ensure that R is published after they close down. They can send an encrypted list of every R for each voucher issued to several trusted escrows, which can be decrypted with a majority of their keys. If the escrows should find that the guarantor has died, or cannot continue for legal reasons, or became evil or whatever, they can publish R themselves.


The thing to remember also is, the buyer might not know the first thing about bitcoin. They might have just used a tool on the guarantor's website to agree on T, they might be using an SPV lightning web wallet to redeem this. And the person who redeems the voucher may not be the same person as the buyer. Transferring ownership should be as easy as placing the voucher and T_B (probably on the same card) into someone's hands, and that guy you saw at McDonald's the other day had better be able to figure out how to use it. If they have to operate a specific pre-existing lightning channel, it may be a little stressful to figure out how to buy their first coffee with their new bitcoins.

I don't like it, but it's looking like it may be necessary for the guarantor to offer a less-provably-trustworthy method of redeeming the voucher using a lightning payment, by just taking from the owner T_A and T_B and the LN invoice off Bitlum with a web form or something, and then the owner has to trust that the guarantor will make good and send the LN payment. Or someone with c-lightning could do it the right way by using T as the secret, because they know their way around the software and don't need to exchange trustworthiness for ease-of-use (that is, if c-lightning or some other software now or will ever support specifying the secret). You could also abolish T_B if you trust the issuer - the vast majority of Casascius coins and other physical bitcoins use only T_A, because the issuers are trusted to destroy their copy of T_A after putting it on their product - but maybe T_B can be made user-friendly enough to where that would not be necessary. After all, the only requirement for T_B to make sense is that the guarantor must not see it. T_B could be a simple pass phrase.

Ideally, the owner would never, ever have to use T and R to claim the bitcoins on-chain, unless they really wanted to. But the option's there and can probably be made simple enough if bad things happened.

Say I want to issue a single-use voucher code/card that can be redeemed for bitcoins, and prove:

a) That it can be claimed for its value even if I go out of business or die unexpectedly, and
b) That I can not abscond with its value.

This would be easy to do with on-chain transactions, and Casascius addressed both of these conditions in 2011 with his two-factor physical bitcoins. He issued token coins, not voucher cards, but it's the same idea. However, this is no longer feasible with low-value transactions, because of the current fee economy. Early Casascius products were sold for a couple dollars; vouchers of equal USD value issued today would be tedious to redeem, because of the transaction fees involved sometimes eating a large portion of their value.

The idea is to be able to create a low-value voucher code that can be redeemed through LN. Here's what I had in mind so far:

1. The guarantor and buyer of the voucher generate a two-factor key T, using the guarantor's code T_A and the buyer's passphrase T_B, with a scheme akin to casascius.com/2factor
2. The guarantor generates a "revocation key" R
3. The guarantor sells the buyer a physical card with the voucher code covered by a tamper-evident security hologram
4. The buyer confirms receipt of the card and the guarantor funds a 2-of-2 multisig script (using the pubkeys of T and R) with the value of the card; the fee to fund this script is a part of the card's premium (Hopefully with Schnorr signatures to reduce the size of the script and redeem script)

Now assume some time has passed and the buyer (or whoever now owns the card and T_B) would like to redeem the value of the card with LN, and the guarantor still exists:

5. The buyer removes the security hologram and accesses T_A, and combines it with T_B to generate T
6. The buyer signs a message to prove that they have T; the guarantor still has the pubkey of T
7. The buyer generates a lightning invoice using T as the secret; the guarantor pays the invoice and thus receives T (the voucher has been redeemed)
8. The guarantor uses T and R to collect the value of the card from the multisig address, paying a low fee and letting it confirm eventually

Alternatively, the buyer could choose to redeem with an on-chain transaction instead, for some reason, while the guarantor still exists:

5. The buyer removes the security hologram and accesses T_A, and combines it with T_B to generate T
6. The buyer signs a message with T, declaring that they are not interested in a lightning payment
7. The guarantor sends R to the buyer, permanently revoking the buyer's right to claim the voucher with a lightning payment
8. The buyer uses T and R to collect the value of the card from the multisig address (the voucher has been redeemed, but maybe with a large fee)

And if the guarantor does not exist anymore, for whatever reason, a lightning payment will not be possible:

5. The guarantor has failed, and publishes R (or in case of death, perhaps using a will or dead man's switch)
6. The buyer removes the security hologram and accesses T_A, and combines it with T_B to generate T
7. The buyer uses T and R to collect the value of the card from the multisig address (the voucher has been redeemed, but maybe with a large fee)

The guarantor can not have T until they have paid the value of the voucher in full to its owner. So the card can not be invalidated to the benefit of the guarantor. There are still some ways that the card could be made void:

• The card is destroyed, and thus T_A is lost
• The buyer had bad data storage practices and lost T_B
• The guarantor made a mistake and did not include T_A on the card
• The guarantor had bad data storage practices and lost R; if they instead lose the public key for T but can still publish R the card can still be redeemed by its owner with an on-chain transaction
• The guarantor shut down or died, but R was unable to be published

That may look like a long list, but if the guarantor is competent it should not run into these problems (though we have seen incompetent issuers of physical bitcoins before). The buyer can take care by keeping the card safe, and by keeping T_B near or on the card itself. By putting virtually indisputable bitcoin value on a physical object of low enough value to just give away as a gift, you have created something to get people interested in bitcoin. You can see testaments to the power of just putting something in people's hands by reading the early replies to the Casascius coins thread. Physical bitcoins no longer have this utility, and have over time instead become more of a collectible item for people that are already very, very interested in bitcoin. It is just not economical to create low-value pieces, even in base metals like brass or aluminum. We know this is the case because nobody is doing it anymore. Well, either that or it is actually just a stupid idea in general. But I don't think that is the case, because people still fund high-denomination pieces.

This would probably not be economical for the guarantor of voucher cards in this situation either, especially after jumping through legal hoops. But the guarantor is very interested in getting bitcoin into more people's hands.

You can use OP_CHECKLOCKTIMEVERIFY to get a transaction into the blockchain now (and confirmed), but unspendable until a certain block in the future. The payment will not be reversible after it is confirmed, and the money becomes unusable until the block in the future, when only the recipient is allowed to spend it. Coinbin has a tool to generate an address that uses OP_CHECKLOCKTIMEVERIFY, but it only supports using one public key. This is different from just creating a transaction and adding a time lock to it. This transaction will be published and confirmed in the blockchain before it can be spent, not after.

This kind of spamming for the sake of advertising is nothing new, this has been happening for years. I remember fondly a time long ago when I received a 1 satoshi dust payment, while I had three outputs each with BTC0.33333333 - i spent those outputs along with the dust satoshi and consolidated them into precisely BTC1. The one time dust was handy.

There was a lot of spam like this because a popular block explorer allowed you to attach easily-readable public messages to bitcoin transactions. Just spam a thousand addresses, and a thousand people will see your spammy message. It was a stupid idea that was since gutted.

Can we configure the payment to use any secret of our choosing? Such that it could be generated months or years before the payment takes place? Provided the payer gets the hash of the secret at the time it is generated.

#1 0.536 BTC

I was wondering if it is now or will soon be possible to make a Lightning payment through which the payee discloses an arbitrary secret to the payer, provided the payer has a hash of the secret beforehand and can only get the secret when the payee is paid. The payee must not be able to withhold the secret if they are paid. I'd like to hear if anyone knows of a way to make an exchange like this using Lightning, or if this is really only feasible with an on-chain script?

#1 0.53 BTC

Not likely. Namecoin is merge mined with bitcoin, so the difficulty is comparable to bitcoin's and probably not the job of a single old ASIC, unfortunately.

Has anyone else been getting a 500 error for the past few days? I'm not able to view any part of the website.

Ik denk dat elke coins onder één satoshi zijn mislukkingen, en je tijd niet waard. Zij zijn moeilijk te verkopen.

If colored coins means OpenAssets in particular, I don't think so. I believe they use the 0x4F41 prefix, and there's nothing like that in opreturn.org's last 30 days graph, though I don't know how credible opreturn.org is. Omni appears to still be in use and, afaicr, accomplishes many of the same things.

No collateral, no loan. Did you read the stickies? I suggest that you click the "lock topic" button on the bottom left corner of the page if you value your account, unless you can provide collateral.

I opened an itBit account in December and submitted the information for the onboarding process. When I try to log in, I get a message telling me that a verification process is underway and that it should take 7-10 business days. However, it has been 6 months. I tried logging in again several times (including today) and it still says to wait 7-10 business days. I haven't been contacted in the last 6 months. Does anyone know if I missed something or did anyone else have the same problem?