Bitcoin Forum
February 24, 2020, 06:00:02 PM *
News: Latest Bitcoin Core release: [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 [383] 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 »
7641  Economy / Marketplace / Re: SELL 4,200 BTC! on: October 20, 2010, 04:08:21 AM
Nobody will buy your if you have no reputation.

If he sends the BTC first, there's no problem. You would be the one who could issue a chargeback.
7642  Bitcoin / Development & Technical Discussion / Decentralized Bitcoin scratch-off cards on: October 20, 2010, 03:55:18 AM
When talking about physical Bitcoin cards/tokens, most people assume that either a central server or use of QR codes would be needed to redeem the bitcoins. However, it is possible to use Bitcoin's scripting system to make bitcoin transactions redeemable with a short code, without any centralized server.

The person who is creating the physical Bitcoin card creates a transaction with an output like this:
<most of private key> OP_DROP OP_DUP OP_HASH256 <hashed code> OP_EQUALVERIFY <public key> OP_CHECKSIG

Then to redeem this transaction, the person who receives the card creates a transaction to himself with an input containing the code and signature. The code and the rest of the private key are on the card.

I imagine that a Bitcoin scratch-off would have the full transaction hash on the front and the code/key under the scratch-off portion in base58. To redeem, start typing the hash into your Bitcoin client until it tells you that it has enough to identify a single transaction (only 4-8 bytes are necessary). Then type the code/key. The money is instantly yours, with no central server necessary. If you have a computer handy while buying the card, you can verify that a card is still valid by looking at the hash on the front (the code could be fake, of course).

The first few bytes of the private key can be used as a salt.

Without the public/private keys, it would be easy for any man-in-the-middle (including any Bitcoin node) to rewrite your transaction to himself after receiving it. It's still possible for him to do this, but he would have to preemptively brute-force the full private key from the portion in the transaction, and then he would have to re-sign his new transaction on-the-fly in less than a few seconds. I think this makes the attack difficult enough for the scheme to be usable.

This can be significantly improved if the mathematical script functions are enabled (alternatively, I believe OP_SUBSTR could do the same thing):
- The output of the first transaction contains the full private key, but it requires that the provided signature start/end with some number of zeroes.
- To redeem, you need to modify and re-sign your transaction (using a nonce value with OP_DROP) many times to get a signature that meets the requirement. The number of zeroes required should be set so that this calculation takes only 5-10 minutes on most computers.
- To modify your transaction, the attacker needs to re-sign the transaction. However, he can't do it in less than the 5 seconds or so required because of the proof-of-work.

An 8-byte code would probably be sufficient. Each byte has 256 different possible combinations instead of the 96 with standard ASCII, so this would be stronger than a 16-character totally-random password. I'm unsure about the security of giving away a partial private key; if it's only possible to brute-force, 16 bytes would probably be enough, though I'd probably err on the side of caution with 32 bytes.

So if the arithmetic functions are enabled in Bitcoin, that's less than 20 characters you'd have to type: 8-10 characters for the transaction hash and 8-10 characters for the code. Anyone could generate these codes. It might be a useful cash-alternative among people who already trust each other, and it'd be very convenient for selling bitcoins at physical shops.

(Edit: realized how to use a salt without OP_CAT.)
7643  Bitcoin / Development & Technical Discussion / Re: Python code for validating bitcoin address on: October 20, 2010, 01:50:10 AM
For every leading 0x00 byte, add a leading 1 (encode). For every leading 1, add a 0x00 byte (decode). For encode, don't accept input that doesn't have an even number of bits (divisible by eight), as this doesn't make sense. For decode, pad leading zeros until you have an even number of bits.

I just check that the output immediately post-DecodeBase58 (including leading zeroes, checksum, versionNumber) is 25 bytes long. I think that Bitcoin does something similar to this.

I made some web tools for dealing with addresses:
(Source not public yet.)
7644  Bitcoin / Development & Technical Discussion / Re: [RFC] Best method for initial block download? on: October 18, 2010, 11:26:44 PM
Most of the "download" time is actually caused by the verification of all the blocks (doing the crypto verification on 130,000+ transactions). The actual download doesn't take very much time at all, as you can see if you download the database files. Things could be sped up considerably if Bitcoin just skipped verification on blocks before the latest checkpoint. There's a philosophical difference, though, which is probably why this is not already done: the checkpoints tell you when the blocks are wrong, but skipping verification would tell you when they are right, which makes things more centralized.
7645  Other / Off-topic / Re: DGCmagazine Bitcoin Issue on: October 18, 2010, 07:14:28 PM
The article is full of plagiarism from Bitcoin Market and
7646  Economy / Economics / Re: Reputation and game theory on: October 18, 2010, 04:11:59 PM
Harley4noble is a spam bot...
7647  Bitcoin / Development & Technical Discussion / Re: Key pool feature for safer wallet backup on: October 18, 2010, 01:55:09 AM
As I understood generated coins will not be in the key pool. Am I right?

They will be. Everything is.

Every received IP transaction creates a new address (taken from the pool), so be careful if you are accepting those. Someone could empty your pool in a few minutes.
7648  Bitcoin / Development & Technical Discussion / Re: Is it possible to detect double spending in the > 50% network takeover scenario? on: October 17, 2010, 01:18:42 AM
What I'm asking, is can the client know that these two 0 transactions exist? If that is possible, could the client not allow the transaction to be available for spend until like 10 transactions?

Yes. It's a good idea. If a transaction that conflicts with yours is spotted through the network or in a block (even a block in a shorter chain), then remove your version from all RPC listings and display it specially in the UI. The existence of any conflicting transaction means that the person who sent you the transaction is trying to defraud you.
7649  Bitcoin / Development & Technical Discussion / Re: Is it possible to detect double spending in the > 50% network takeover scenario? on: October 16, 2010, 11:11:05 PM
If I send you 100 BTC's, from wallet abc to your efg, what split would occur naturally? If the network were split, potentially both could have the same spend... right? But they would be to the same wallet.

If you double-spend, then both recipients will get transactions with 0 confirmations. The network isn't sure yet which one came first, since the simple TCP network can't be counted on. Normally after one block the network will decide which one is valid. However, it is possible (though unlikely) for two blocks containing different versions of the transaction to be generated at the same time, in which case it would take another block to figure out which one is valid. (It's possible for this to happen a second time, but too unlikely to think about.)

So a detection mechanism could say, "This new block would replace a block that is 5 blocks deep in the main chain. Any transactions in that chain that conflict with transactions in the main chain are likely to be double-spends." It could not say (with reliable accuracy), "This new block is now the latest block in the main chain. However, one of its transactions conflicts with one that I received via the TCP network first, so the block's version must be a double-spend."
7650  Bitcoin / Development & Technical Discussion / Re: Is it possible to detect double spending in the > 50% network takeover scenario? on: October 16, 2010, 06:41:35 PM
You could probably distinguish original transactions from double-spent ones if the attacker is rewriting blocks that are more than one block deep. You can't be sure for transactions with only 0 or 1 confirmations, since this kind of "split opinion" could occur naturally.

If the legitimate network regains control and it's clear that the main block chain is full of double-spends, the network could start building on some shorter chain before the event to reverse the double-spends. This would probably also reverse some legitimate transactions, though.

Just detecting that someone is messing with the network is much easier, and I wouldn't be surprised if Bitcoin does try to detect this at some point.
7651  Economy / Economics / Re: Price Deflation Discourage Investment? on: October 15, 2010, 03:42:04 PM
The bitcoin community's overall investment seem to be increasing not stagnating.

Bad argument. 7200 BTC are created daily.
7652  Bitcoin / Development & Technical Discussion / Re: Pooled/Remote Mining on: October 15, 2010, 12:28:53 PM
I believe standard Bitcoin software rejects blocks attempting to spend coinbase that hasn't matured. If this could be changed to allowing the spend but making those transactions 0/unconfirmed until the coinbase matures then the whole problem goes away and we're all very happy.

I think it's possible to create a coinbase transaction with one generation input and several outputs.
7653  Bitcoin / Development & Technical Discussion / Re: [PATCH] implement getblock RPC command on: October 15, 2010, 03:50:24 AM
Hummm...  I was able to use one patch or the other.  When trying to use both patches, I couldn't apply the patches.  Perhaps I did something wrong.  I will try again.

patch is not meant to be used blindly. You're supposed to look at the reject file manually and figure it out.

The problem is caused when trying to patch the section of rpc.cpp around line 1330. Both patches try to apply their changes to the bottom of the list, with context looking up. They modify each other's context. To fix this, they should be applied to the top looking only up or the bottom looking only down. (Not sure if you can actually do this, however.)
7654  Bitcoin / Bitcoin Discussion / Re: Would you consider BTC safe at this point? on: October 14, 2010, 06:46:02 PM
I think the technology is pretty safe. There's nearly no chance that your bitcoins will be lost because the network screwed up.

I expect the price to go down in the short term, however.
7655  Economy / Marketplace / Re: PHP Programmer needed for a quick job on: October 13, 2010, 11:01:17 PM
Thanks ive got it sorted now, maybe you can help me with one last thing, how can i display ฿ icon in html?

7656  Bitcoin / Bitcoin Technical Support / Re: Warning : Check your system ( Help me ) on: October 13, 2010, 10:38:14 PM
If someone rejects a block that most of the network accepts, won't the rejecting nodes eventually give up on the rejecting branch and move to the longer branch that accepted it?

If you reject a block, then all blocks after it are also invalid from your point of view, no matter how many other people accept them. If this was not the case, then an attacker could create bitcoins out of thin air by getting more than 50% of the network's CPU power. This effect was demonstrated when the overflow bug was fixed: even though 0.3.10 nodes were in the minority, they rejected all blocks produced by old clients (which contained a fraudulent and impossible transaction for 184 billion bitcoins).

This is not quite the case for timestamp issues, but there is a similar effect. If your clock is off, you won't accept any new blocks, as they'll all be too far in the future. You'll eventually get the blocks when they are no longer too far in the future, but you'll still be unable to generate because your view of the "latest valid block" is wrong.

The same problem would happen if someone double spends a coin, and nodes disagree on which one came in first. The majority will make a longer chain and the minority nodes will have no choice but to jump over.

You don't reject blocks for transaction timing/ordering issues.
7657  Economy / Marketplace / Re: PHP Programmer needed for a quick job on: October 13, 2010, 09:10:41 PM
Logout usually just deletes all authentication cookies on the user's browser and removes those tokens on the server. It's pretty easy to do.

You can probably do it yourself, but I'll do it for 100 BTC.
7658  Economy / Marketplace / Re: I can't figure out how to deposit bitcoins into MtGox on: October 13, 2010, 08:58:14 PM
Add funds -> Put an amount in the lower "Add Bitcoins" section -> Click "send bitcoins" -> A JS popup thing will appear with the address you should send bitcoins to. Funds appear after 6 confirmations.
7659  Bitcoin / Bitcoin Technical Support / Re: Warning : Check your system ( Help me ) on: October 13, 2010, 12:28:31 PM
Bitcoin should absolutely not be sending the computer's time to the network. Nor should it depend on the clock being set properly. Each node can keep track of when they see transactions come through. If they want to reject a block because it contains a transaction they saw too long ago, then they are free to reject it; no reason for the nodes to compare each other's clocks. If it's too old they will all reject it, which is what we want.

If someone rejects a block that most of the network accepts, then all of the blocks that they produce will be invalid and transactions won't gain confirmations from their perspective.

This is about times of blocks, not transactions. Block timestamps are used for the difficulty calculation, so they can't be too far off from reality.
7660  Economy / Marketplace / Re: closes on: October 12, 2010, 04:57:58 AM
I'm not surprised.

Such a high rate of chargebacks does not bode well for future CC->BTC trades, no matter what intermediary companies are used. Identity verification is the only real solution if you want to do that.
Pages: « 1 ... 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 [383] 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!