Bitcoin Forum
July 27, 2021, 11:17:31 PM *
News: Latest Bitcoin Core release: 0.21.1 [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 ... 100 »
1  Other / Off-topic / Re: What can Bitcoin do for you? on: March 12, 2020, 10:06:33 PM
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. Roll Eyes

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.
2  Economy / Collectibles / Re: [DAILY FREE RAFFLE] 302nd JUST BECAUSE I AM IN A GOOD MOOD FREE SILVER COIN on: June 25, 2019, 03:44:13 AM
29. Taras
Thank you! Smiley
3  Bitcoin / Development & Technical Discussion / Re: How to Solve the Non-Mining Node issue and Increase Real Scalability on: June 09, 2019, 01:21:16 AM
Running LN hub isn't even profitable even if you're "giant" hub, because
1. LN client will automatically find best route (shortest hop / cheapest routing fees)
2. If you set high fees on your hub, some people would rather open new channel or use altcoin
3. Cost to open & close channel, unless you make user pay for it

The solution is simple,
Bitcoin needs to make a code change that requires all LN Hubs to run a FULL NODE.
Not the scaled down nodes, like many use, but True FULL nodes with the Full Blockchain stored and letting new users sync the entire blockchain from them.

Sounds simple, but the biggest question is "How to verify LN hubs run true full nodes"?

Send hash of all blocks?
Send all block headers?
Ask random "old" blocks?
Ask random "old" transaction (assuming txindex enabled)?

Make the code verify the blockchain is stored on the hub ,
then have it verify the Genesis Block and then verify the last block synced is within an hour.

There are probably 10 completely different ways to accomplish it.
It is up for the programmers to write the code, I'll let them choose,
unless you want to say the core devs are too incompetent to carry out such a simple task.
So is that what you are saying?

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.
4  Other / Ivory Tower / Re: Will energy become a blockchain currency? on: June 08, 2019, 02:27:43 AM
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.
5  Bitcoin / Development & Technical Discussion / Re: Random number on: June 08, 2019, 01:44:10 AM
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.
6  Bitcoin / Development & Technical Discussion / Re: How to Solve the Non-Mining Node issue and Increase Real Scalability on: June 07, 2019, 11:24:13 PM
The solution is simple,
Bitcoin needs to make a code change that requires all LN Hubs to run a FULL NODE.
Not the scaled down nodes, like many use, but True FULL nodes with the Full Blockchain stored and letting new users sync the entire blockchain from them.
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.
7  Bitcoin / Development & Technical Discussion / Re: Zero knowledge contingent payments on the Lightning Network on: June 07, 2019, 10:40:31 PM

I was however wondering why R is necessary. It doesn't allow the guarantor to run away with the money because he doesn't know TB. But the problem that the coin/voucher could lose value if the guarantor doesn't exist anymore and fails to publish it is pretty severe in my opinion.
R protects the guarantor from a dishonest buyer. If the guarantor kept their copy of TA and accepted TB 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 TA and TB 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.

So what I would do instead: The voucher provides access to a simple funded Lightning channel - that would mean, that instead of using T and R for the multisig transaction, one would use TA and TB. The guarantor, in this case, wouldn't have to interfere anymore once he sold the coin - if the buyer wants to redeem the coins with an offchain transaction, or the guarantor goes offline (and thus, cannot receive and route LN payments from the buyer), he simply closes the LN channel as he has access to both keys once he reads TA destroying the hologram.

Maybe I overlooked something important, however.

(Edit: I think I definitively am overlooking something: the problem with the setup I proposed here is that the LN channel in this case wouldn't really have a "counterparty" as both keys are controlled by the buyer once he opens the hologram. So there is no connection to the rest of LN because the guarantor doesn't control any key exclusively. Have to think a bit about that ...)

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 TB (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 TA and TB 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 TB if you trust the issuer - the vast majority of Casascius coins and other physical bitcoins use only TA, because the issuers are trusted to destroy their copy of TA after putting it on their product - but maybe TB can be made user-friendly enough to where that would not be necessary. After all, the only requirement for TB to make sense is that the guarantor must not see it. TB 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.
8  Bitcoin / Development & Technical Discussion / Re: Zero knowledge contingent payments on the Lightning Network on: June 07, 2019, 08:03:32 AM
I wonder however what would be the exact use case you have in mind. Atomic swap via LN maybe (you wrote about "exchange")? Yes, that should be definitively possible.

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 TA and the buyer's passphrase TB, 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 TB) 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 TA, and combines it with TB 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 TA, and combines it with TB 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 TA, and combines it with TB 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 TA is lost
  • The buyer had bad data storage practices and lost TB
  • The guarantor made a mistake and did not include TA 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 TB 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.
9  Bitcoin / Bitcoin Technical Support / Re: Confirm TX at given block height on: June 05, 2019, 12:08:42 AM
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.
10  Bitcoin / Bitcoin Technical Support / Re: Dust Attack on: June 04, 2019, 11:58:09 PM
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.
11  Bitcoin / Development & Technical Discussion / Re: Zero knowledge contingent payments on the Lightning Network on: June 02, 2019, 02:30:31 AM
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.
12  Economy / Collectibles / Re: [Auction] Casascius Coins / Bitbills - Ending June 1st on: June 01, 2019, 10:50:54 AM
#1 0.536 BTC
13  Bitcoin / Development & Technical Discussion / Zero knowledge contingent payments on the Lightning Network on: June 01, 2019, 01:21:13 AM
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?
14  Economy / Collectibles / Re: [Auction] Casascius Coins / Bitbills - Ending June 1st on: May 29, 2019, 04:12:39 AM
#1 0.53 BTC
15  Other / Ivory Tower / Re: Unstoppable domains and crypto payments. on: May 24, 2019, 09:59:36 AM
Thanks for posting that. Namecoin might be a useful coin to use to test that old ASIC miner I picked up a while ago.
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.
16  Economy / Gambling / Re: BetMoose.com - Betting Exchange | Prediction Market | Real World Events | P2P on: September 20, 2018, 04:33:29 PM
Has anyone else been getting a 500 error for the past few days? I'm not able to view any part of the website.
17  Local / Nederlands (Dutch) / Re: opkomende coins onder de 1 Satoshi topic on: September 18, 2018, 02:55:33 AM
Ik denk dat elke coins onder één satoshi zijn mislukkingen, en je tijd niet waard. Zij zijn moeilijk te verkopen.
18  Bitcoin / Development & Technical Discussion / Re: Is colored coins still in use? on: September 04, 2018, 12:16:04 AM
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.
19  Economy / Lending / Re: 0.006 no collateral loan on: May 15, 2018, 02:49:39 AM
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.
20  Economy / Exchanges / Anyone else have trouble with itBit verification? on: May 15, 2018, 02:40:59 AM
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?
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 ... 100 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!