Bitcoin Forum
April 23, 2014, 01:07:56 PM *
News: Due to the OpenSSL heartbleed bug, changing your forum password is recommended.
 
  Home Help Search Donate Login Register  
  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 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 ... 727
941  Bitcoin / Press / Re: [2014-01-30] VICE US Gov Closes In On Bitcoin & Some Bitcoiners Are Smiling on: January 31, 2014, 05:00:00 AM
Quote
In other words, its time for Bitcoiners to follow the rules.

The irony is that NY despite being heavy handed with regulation has a rather narrow statuatory definition of money transmission.  It is highly unlikely that exchanging one currency into another meets that criteria (hint conventional currency exchangers are not money transmitters under NY law).

The regulators even commented on the fact that they likely will need to use the power to expand the scope of regulation to cover virtual currencies AS THE EXISTING REGULATIONS DO NOT COVER THAT ACTIVITY.

So how exactly would Bitcoin "follow the rules", when the rules as written today this 30th of January, in the two thousand and fourteenth year of our lord aren't applicable?  Somehow use precognition and follow the rules today, that regulators will think of next year?
942  Bitcoin / Bitcoin Discussion / Re: New York wants to regulate Bitcoin on: January 31, 2014, 04:43:49 AM
I Watched both days of the hearings in New York (You can watch them here: http://www.totalwebcasting.com/view/?id=nysdfs  ).  I wasn't too concerned with the hearings.  To me I walked away with the imrpession that yes bitcoin will be regulated but not over regulated to the point that it hurts innovation or the growth of bitcoin.

Why because a regulator, on TV said so?  

A regulator's idea of not over regulating and the entire rest of the world's idea of not over regulating are two different things.  
943  Bitcoin / Bitcoin Discussion / Re: Fee deducted from the transferred amount. Insane. on: January 31, 2014, 03:47:35 AM
Have you asked your customers?  It would be a good thing to know and they likely are the only ones who are going to know for sure.

944  Bitcoin / Bitcoin Discussion / Re: A question regarding off-line wallets... on: January 30, 2014, 08:57:46 PM
However this is done with ECDSA (here is a great video explaining it) not SHA-256 which is the hashing algorithm used to mine blocks for Bitcoin.

Well Bitcoin is "complicated" so this isn't exactly correct.  

Most payments on the Bitcoin network are "PayToPubKeyHash" so the network is unaware of what the PubKey is, it only knows the hash of the pubkey being paid received an output.  The sender's client takes the address and reverses it to the PubKeyHash.  The PubKeyHash is actually what goes in the output of the tx.   Until that output is spent the network doesn't know what the correct pubkey is.

So to validate a spend the network needs to validate three things:
a) that the transaction is signed by the private key which corresponds to the public key (signature is valid).
b) that the PubKey when hashed (SHA-256) produces the PubKeyHash in the output of the prior tx (this pubkey corresponds to the address paid).
c) that this output has not already been spent (it is not a double spend).

An example might help.  Lets take this random tx:
https://blockchain.info/tx/83d51f7c87f275867288958d4f01afbde346370dedd3723cfe1c89ef3ba94012

Now to make it "simple" for end users Blockchain.info displays the Bitcoin address (i.e. 0.51 BTC was transferred to 162r6LJBJPhFQ3A9DjTKiww9sahzYWi1sV).  However the actual transaction doesn't include the address.  It includes the PubKeyHash.  The sender's client took the address 162r6LJBJPhFQ3A9DjTKiww9sahzYWi1sV and reversed it back to the pubkeyhash 373206576366c5c4cbd43e0e127262ce57bfe19d

If you look at the bottom of the page (you may need to enable showing scripts) you will see this:

Quote
OP_DUP OP_HASH160 373206576366c5c4cbd43e0e127262ce57bfe19d OP_EQUALVERIFY OP_CHECKSIG

In crude simplification it is saying this output (0.51 BTC) is locked and can only be spent by a tx signed by a private key which corresponds to a public key, that when hashed (SHA-256 & RIPEMD-160) produces this exact hash 373206576366c5c4cbd43e0e127262ce57bfe19d .  The Bitcoin network has no idea what pubkey hashes to that value (because hashes are one way functions) but it will instantly know it when it sees it.

If you attempted to spend this output with an incorrect pubkey which you could complete check "a" above, when your pubkey was hashed it would produce a different output.  Say it produced 966ca2c8a091088b8129ee3b053c51d799261eac .  Since 966ca2c8a091088b8129ee3b053c51d799261eac does NOT EQUAL 373206576366c5c4cbd43e0e127262ce57bfe19d the transaction is invalid (doesn't validate rule "b" above) and all nodes simply simply discard the transaction.
945  Bitcoin / Bitcoin Discussion / Re: A question regarding off-line wallets... on: January 30, 2014, 08:53:58 PM


TL/DR version:  2^128 is much bigger than you think.

Got it... thanks.  I guess a subquestion of my prior question is would the private key always be the same if the two addresses are the same?  In other words, what if I used the bitaddress.org script to randomly generate a public address and private key, and the public address I got was the same as your public address,  would I then also get your private key or could our keys be different?

Kevin

There is no guaranteed one to one relationship between private keys and public keys or between public keys and addresses (hashes).  As long as a private key can properly sign the transaction it is "valid" even if different.

So in theory you could have two private keys a & b which both produce the same public key K.  You could also have a set of keys (a & A) and (b & B) which when hashed produce the same address.  Both of those are forms of collision.

Public key cryptography is based on probability.  We can never say "it can't happen" we can simply say "the odds of it happening are so small that an attack would be infeasible".
946  Bitcoin / Legal / Re: Is bitcoin registrated trademark name ? on: January 30, 2014, 08:50:34 PM
I thought trying to trademark something like Bitcoin would get thrown out because it's already in use and in the public domain?

In the theoretical world where are government functions work perfectly it would be.  The rejection would be universal across every country and would occur no matter how often companies attempted registration again.

In the real world?  Patent and trademarks are big business they are routinely used by large companies (who have hundreds of lawyers who do nothing but seek patents and trademarks) and used as a weapon.  Against larger competitors they are used to secure cross licensing deals, against smaller competitors they are used to simply destroy the competition.
947  Bitcoin / Legal / Re: Is bitcoin registrated trademark name ? on: January 30, 2014, 08:34:19 PM
I mean... can I use the term bitcoin freely in my business ?

No, it's not trademarked, yes you can use it freely.

Ahem
https://www.mtgox.com/press_release_20111014.html
https://oami.europa.eu/eSearch/#details/trademarks/010103646

Of course at the time MtGox stated they "had" to keep the trademark as there is no way to release a trademark into the public domain.  However there is now a non-profit foundation, however the trademark remains with a for profit company.  All for your own good, of course.  We all know that MtGox, its owners, and all future owners until the end of time will never attempt to profit from this very valuable trademark.

So it certainly is trademarked and today MtGox (without any legal obligation on their part) says you can use their property as you see fit.  Will they next year? Next decade?  Of course MtGox could easily transfer the trademark either to an existing non-profit or create a new perpetual trust whose sole goal is to protect the Bitcoin trademark but that hasn't happened.  I am sure they just haven't go around to it yet.
948  Bitcoin / Bitcoin Discussion / Re: A question regarding off-line wallets... on: January 30, 2014, 08:21:35 PM
It doesn't matter if it is online or offline if you create a private key which can sign for an existing address you can spend those coins.

Of course the probability is so asininely small that for all practical purposes it is ~0% (offline doesn't increase or decrease this chance).  You won't do it today, you won't do it even with a planetary sized super computer operating at the thermodynamic limit for billions of years.

This may seem "weird" but all public key cryptography works on a similar concept.  For example you in theory "could" by just mashing random keys on your keyboard create a private key which would allow you to impersonate a bank's secure website because your private key can produce the signature that a browser would verify to ensure it is at the correct webserver.   Once again the odds of doing this are so asininely small that it can be considered ~0% for all practical intents and purposes.

Likewise here is my PGP public key:
http://pgp.mit.edu/pks/lookup?op=get&search=0xC5B8C5DDCDBD1C8E

The only thing which prevents you from signing documents as me is a random number (my private key).  In theory you could "find" that private key either intentionally or by dumb luck but practically it isn't going to happen. 

TL/DR version:  2^128 is much bigger than you think.
949  Bitcoin / Technical Support / Oops on: January 30, 2014, 07:06:16 PM
ops
950  Bitcoin / Development & Technical Discussion / Re: Euler's totient function algorithm compatible with SHA-256? on: January 30, 2014, 06:50:26 PM
Ok could you explain why using ECDSA keys are more viable over RSA keys short of the difference in speed and size of the key. I am a bit new to this and trying to understand the functionality of SHA-256.

Not sure why you keep linking ECDSA with SHA-256?  

ECDSA has smaller keys for a given key strength than RSA.  Since the blockchain is a historical ledger and the size of a transaction directly correlates to the size of the keys and signatures RSA would be a far inferior choice.  ECDSA achieves 128 bit security using a 256 bit private key (and 256 bit compressed public key).  That would require 3,076 bit RSA keys to provide the same level of security.  That means signatures and pubkey on the input side of a transaction would be ~12x larger.  If we assume a block was filled with 2 input and 2 output tx then for a given number of transactions Bitcoin-RSA would have blocks which are 8x larger.

Bitcoin doesn't "require" SHA-256.  It is possible to pay directly to the pubkey.  The using of a hashing function is completely separate from the use of a public key cipher.  So what is confusing is you keep asking about ECDSA and then say you are trying to understand the functionality of SHA-256. 

Bitcoin (as it relates to address & transactions) uses SHA-256 to provide the following benefits
a) reduction in the size of transactions (payments are to pubkeyhash not pubkey)
b) reduction in the size of addresses
c) (combined with checksum and address format) provide a method to detect invalid addresses and thus prevent human error
d) provide a level of quantum computing resistance.  Shor's algorithm only works against a private key when the pubkey is known.  Addresses are an encoded and checksumed representation of the pubkeyhash not the pubkey.

Bitcoin or Bitcoin-RSA could either be used with or without SHA-256 so if you question is on ECDSA why keep bringing up SHA-256?



951  Bitcoin / Bitcoin Discussion / Re: CEO OF BITCOIN EXCHANGE ARRESTED on: January 30, 2014, 06:35:05 PM
That just does not make sense to me. What makes bitcoin so special it deserves arrests? Why not a bank cashing a persons check and then that person buys drugs with the fiat? Or some type of comparison like that?
I was thinking the same thing. Maybe there was an agreement to send and receive (i.e. launder) coins. Huh

Launder could be receiving and sending coins, any coins. Huh

Money laundering requires intent.  Receiving coins that you have no knowledge or reasonable suspicion they are involved in illegal activity is not money laundering.  Criminals have money.  I know it is a shocking fact but they do.  Not just Bitcoins, but also good ole US dollars as well.

There is a big difference between being an innocent counterparty, and actively evading the AML program your own company put in place.

952  Bitcoin / Development & Technical Discussion / Re: Euler's totient function algorithm compatible with SHA-256? on: January 30, 2014, 09:16:57 AM
That was a random jumble of buzz words and phrases saying absolutely nothing.

953  Bitcoin / Legal / Re: BitInstant CEO arrested by FBI on: January 30, 2014, 01:23:18 AM
If Shrem has a good lawyer, maybe they'll try to negotiate a settlement similar to the HSBC case.

HSBC's "deal" involved paying $5B, accepting a $20B plus prison time suspended sentence with 5 year probation, and the not so subtle threat that if HSBC went down it would take down the US financial system, and plunge the country back into recession.

Not sure that is going to work here.
954  Bitcoin / Bitcoin Discussion / Re: CEO OF BITCOIN EXCHANGE ARRESTED on: January 29, 2014, 10:20:54 PM

Not exactly, the criteria is rather vague and open ended.  The intent of the requirement is for financial institutions (including MSBs) to file reports on activity that is suspicious.  Suspicious doesn't mean criminal, or known to be unlawful beyond a reasonable doubt, it simply means suspicious.

From FinCEN point of view there is no such thing as an unnecessary SAR.  SAR doesn't mean criminal activity.  Plenty of criminal activity simply never warrants a SAR because there is no circumstance that creates any level of suspicion by the financial institution.  On the other hand every day thousands of SARs are filed on legitimate activity.

It is a suspicious activity report not a criminal activity report.

http://www.fincen.gov/financial_institutions/msb/msbsar.html


The actual wording in 31 USC 5318 (g) is "relevant to a possible violation of law or regulation."

So yes, unlawful is part of it.  It doesn't have to be beyond a reasonable doubt.

The non-disclosure requirement applies to reports made "voluntarily or pursuant to this section or any other authority".  So it covers SARs that are required, and also reports that are made voluntarily.

Perhaps FinCEN does not consider any SAR "unnecessary", but MSBs are required to report certain things per 31 CFR 1022.320.  Reports not required by this regulation could be considered voluntary.


I think we are going around in circles.

Quote
MSBs are required to report certain things per 31 CFR 1022.320

1022.320 is extremely broad and vague, as pointed by others.  

You have no idea if a tx you believe is routine, is reported by an MSB because THEY believe it fits the guidelines in 1022.320.  The idea that you would know what rises to (as an example) "serves no business or apparent lawful purpose" in the mind of the compliance officer of every single financial institution (to include MSBs) in the world, all of which are prohibited to share such criteria with you, and for whom there is a penalty for not reporting (if regulators later believe the report was intentionally withheld), is just silly.

For example say you transferred $5,000 to PayPal but you mistyped and only wanted to transfer $500.  So when it clears you transfer back $4,500 but pick the wrong account and transfer it into a different account linked to your PayPal account.  It is possible (I have no idea only PayPal would know) that they would view that as "serves no business or apparent lawful purpose", it is also possible that they wouldn't.  The criteria is very subjective.  Likewise if you deposited cash into your bank account and then later had an emergency that day and withdrew cash from a different branch that might also (once again solely up to the determination of the financial institution) result in a SAR.  I am not saying it would, because I am not foolish enough to think I can predict the actions of thousands of different entities when it comes to a loose and subjective set of criteria.

You may think you know when a SAR is required or not but the criteria is so broad and vague, that a given activity may be reported by one entity and not reported by another.  
955  Bitcoin / Bitcoin Discussion / Re: How are fees channelled to miners? on: January 29, 2014, 09:34:18 PM
Thanks for the clarity DeathAndTaxes.  Could you suggest any resources for digging into the low-level mechanics of mining operations?  These forums are obviously a fantastic reference but do you know of anything more formally organized for a proper course of study?  Cheers!

It likely isn't the answer you want to hear but ...

the source code

https://github.com/bitcoin/bitcoin

If you mean the low level mechanics of the actual mining software you would need to look at the source code of those projects (cgminer, etc).
956  Bitcoin / Bitcoin Discussion / Re: CEO OF BITCOIN EXCHANGE ARRESTED on: January 29, 2014, 08:38:26 PM
An MSB is obligated to file a SAR when the transaction meets the criteria.
The MSB is prohibited to notify the client that a SAR has been filed.
Even when directly asked or subpoenaed an MSB is prohibited from indicating if a SAR has or has not been filed.

An MSB is obligated to file a SAR when the transaction meets the criteria, but the criteria are not secret.

The MSB is prohibited to notify the client that a SAR has been filed, but the client should be able to figure out if the MSB was obligated to file a SAR.

The only thing the client is really prohibited from knowing is whether the MSB filed an unnecessary SAR.

Not exactly, the criteria is rather vague and open ended.  The intent of the requirement is for financial institutions (including MSBs) to file reports on activity that is suspicious.  Suspicious doesn't mean criminal, or known to be unlawful beyond a reasonable doubt, it simply means suspicious.

From FinCEN point of view there is no such thing as an unnecessary SAR.  SAR doesn't mean criminal activity.  Plenty of criminal activity simply never warrants a SAR because there is no circumstance that creates any level of suspicion by the financial institution.  On the other hand every day thousands of SARs are filed on legitimate activity.

It is a suspicious activity report not a criminal activity report.

http://www.fincen.gov/financial_institutions/msb/msbsar.html
957  Bitcoin / Bitcoin Discussion / Re: How are fees channelled to miners? on: January 29, 2014, 08:23:21 PM
It's included in the block which is usually solved by a pool, and divided to each miner (depending on their share of the work done).

How would this work for solo miners, would they ever get tx fee revenue?

If they find a block, then yes.

What happens is that every transaction contains one or more inputs and one or more outputs. The difference between the total BTC value of the inputs and the total BTC value of the outputs makes up the transaction fee. These coins don't directly go anywhere, in a way they go into nothingness. But miners are allowed to add up all these differences and add them to their base block reward (the 25 BTC we're currently at) when creating their reward-transaction.

OK so if they find a block, get rewarded 25 coins how do they add tx fees to this amount and actually see the coins?

They aren't awarded 25 coins.  They are awarded the current subsidy (right now 25 BTC) PLUS the value of fees of all tx included in the block.  For most blocks right now that is slightly more than 25 BTC.

Example of a recent block.
https://blockchain.info/block-index/463885

Notice the first tx has no input only an output.  That is the coinbase tx.  It is how miners "get paid".  The protocol requires a block to have one and only one coinbase tx per block.  It is the first tx in any block.  Unlike any other tx it has no input only an output.  The miner is minting some coins from nothing (the subsidy) and collecting the tx fees for all tx in the block at the same time.

You will notice the value of the coinbase is not 25.0000000 BTC it is 25.09845377 BTC.   The value of all the fees paid on the 706 tx in the block combined is 0.09845377 BTC.

The miner paid itself 25 BTC (subsidy) + 0.09845377 (fees) = 25.09845377 BTC (total).

Miners can't cheat because all nodes on the network verify blocks.  All nodes know what the current subsidy is and they can verify the amount of fees paid on all the tx in the block.  If the coinbase is "too much" the block will be rejected.   As a weird exception the miner could actually pay himself less.  A coinbase of 25.09845376 BTC for this block would be valid as would a coinbase of 25 BTC or 0 BTC.  However a coinbase of 25.09845378 would be instantly recognized by every node on the network as invalid and deleted.

958  Bitcoin / Bitcoin Discussion / Re: How are fees channelled to miners? on: January 29, 2014, 08:18:55 PM
Rannasha explained it.  It is actually a pretty clever solution and it only loosely couples the tx (and fee) to the miner.

Miners (solo miner is no different than a pool) are allowed to put a special tx in the block called the coinbase.  Now to prevent unlimited printing of coins, all nodes compute what the coinbase should be a block which pays miners "too much" is simply considered invalid by the rest of the network and deleted.

To be valid the value of the coinbase <= value of block subsidy + (value of all tx_inputs in the block - value of all tx_outputs in the block).

Note miners can (and have probably due to bugs) pay themselves less.  They could even pay themselves nothing and in essence unmint coins.  It likely was an oversight as I see no good reason for the validation requirement to not be coinbase = value of subsidy + fees.

959  Bitcoin / Bitcoin Discussion / Re: $75 fee? Why????? on: January 29, 2014, 06:49:52 PM
The default fee for that transaction would either be 0 or 0.1 mBTC ($0.08) so this was selected by the user.

However I do think it would be a good idea if the client warned users before doing something that 99.9999999999% of the time is simply a mistake.  Paying a fee 100x what is required is almost always going to be a mistake and for the one in a million that it isn't the user could always override the warning.

Quote
"WARNING:  You are about to send a transaction with a fee of 90 mBTC per kB.  This is 900x the minimum fee required, and more than 450x the average fee paid by Bitcoin users in the last 24 hours.  

Are you sure you wish to pay a fee of 90 mBTC?

[Yes - Send with 90mBTC fee]  [No - Cancel Transaction] [No - Reduce fee to 0.1 mBTC]

960  Economy / Speculation / Re: Satoshi's long term plans on: January 29, 2014, 05:13:32 PM

And here if you want to back into the dark ages before any forum <shudder>.
http://www.mail-archive.com/cryptography@metzdowd.com/msg09959.html

IIRC this is the first known post by "satoshi" (obviously "satoshi", either a single person or group, used the internet prior to this post.  This would be the first post under the satoshi psuedonym).
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 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 ... 727
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!