Bitcoin Forum
March 28, 2015, 03:57:18 AM *
News: Latest stable version of Bitcoin Core: 0.10.0 [Torrent] (New!)
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 ... 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 [277] 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 ... 801 »
5521  Bitcoin / Development & Technical Discussion / Re: A question on ECDSA signing (more efficient tx signing)? on: July 18, 2013, 09:20:28 PM


Given:
private keys a & b
Public keys A & B
Data to be signed d

Is it possible to create a signature S such that it can be verified given only A, B, and d?

Why not sign the data d with private key a and then sign the result with private key b to give you S.
Use public key B then public key A on S to result in data d.

Would this solve the original problem?
Even though, as pointed out, there are distinct items of data so it wouldn't work in practice anyway.

This would be for a new (incompatible) transaction format.  There would be no distinct items.  Transactions would simply be signed at the tx level.  At this point it is merely academic, I just want to know if it CAN be done and if doing so results in a reduction of security.

I don't believe it is possible to verify a double signature the way you described.  Remember is verification the entity with the public key isn't recreating the signature and comparing it to the original (if they could do that they could counterfeit the signature on any data).  They entity doing the verification can only validate if the signature is valid or not (i.e. true or false).  

I may be wrong on this one.

5522  Bitcoin / Development & Technical Discussion / Re: Exhausting the keypool (workaround for "watching wallet" in bitcoind) on: July 18, 2013, 09:16:27 PM
It would be more elegant (and also safer) to literally erase (overwrite with random data) the private keys, instead of encrypting them with the "unbreakable" password.
Maybe jackjack could add such an option to his so useful pywallet tool.

Agreed.  That would be a useful option "overwrite private keys".  If the overwritten wallet is ever unlocked it will cause issues but if the wallet remains locked the private keys are inaccessible and bitcoind doesn't know they are overwritten or missing.

An even better solution would be to create and use a watching wallet in bitcoind itself.  The core devs seem reluctant to make changes/improvements to the wallet since it will be made obsolete by deterministic wallets however it would be a useful option.  The wallet header could contain a flag to indicate it is a watching wallet only and only contains public keys.  To avoid significant code the fact that there are no private keys could be hidden by simply encrypting the wallet (not necessary for a security standpoint but would make all private key functions inaccessible to the wallet without a lot of refactoring).

Quote
The watching wallet cannot create new keys, but the spending wallet can, so in theory you still need to repeat the process once for awhile.
Though in practice, if you told it to used -keypool of thousands, it should take you awhile to consume it all.

Agreed we have already used 5,000 key keypools in the past.  That should be fine for most use cases.
5523  Bitcoin / Development & Technical Discussion / Re: Exhausting the keypool (workaround for "watching wallet" in bitcoind) on: July 18, 2013, 09:06:14 PM
Your logic seems solid, but I do not see any question in the OP.

Of course bitcoind will not fill the key pool if you don't unlock the wallet - that's kind of obvious.
Unless you have just found a critical bug, but the theory is that it cannot even if it wanted to.
 

Sorry I had it phrased as a sentence.  Embarrassed

Is it correct that bitcoind will always exhaust the keypool and not refill it under any circumstances when it has an encrypted and locked wallet?
Is is correct that bitcoind will always return an error when requesting a new address when the keypool is exhausted and can't be refilled?

Essentially the security (against lost) of funds depend on those two conditions always being true.  
5524  Bitcoin / Development & Technical Discussion / Re: C# Node on: July 18, 2013, 08:58:57 PM
Blockchain size is not finished growing and it's pretty large to be storing in a relational data store.  I'd be tempted to just store it in the file system.  Most people are running a logging file system these days so making a backup when doing any work might be sufficient.

For a standard node you are right there likely is very little use to store the full blocks in a database.  For efficiency full nodes generally just validate the block, store the header, and use the block to update the UXTO. In essence using full blocks just to build the UXTO.  Full nodes normally never need the historical blockchain except to build the UXTO in a trustless manner.  For most nodes a flat file is more than sufficient and this why the reference client does just that.

However I think it IS useful as a development platform to parse and store the blockchain in a database.  This is useful to building higher level tools for analysis.  I imagine that is how sites like blockexplorer and blockchain.info work. 


5525  Bitcoin / Development & Technical Discussion / Re: A question on ECDSA signing (more efficient tx signing)? on: July 18, 2013, 08:48:24 PM
Some ECC signing systems can do grouping operations where you can compose all the keys and all the data being signed and validate the whole thing with negligible probability of accepting if any were invalid and zero possibility of rejecting if all were valid.  But AFAIK ECDSA is not such a scheme, and the ones I know of have larger signatures. (uh, though if you were to use it to always merge all the signatures in a block— that might be interesting).

Maybe we are speaking of different things but doesn't ECDSA allow creating a composite key by simply adding the two private keys together.   The signature (which would be the same size as the individual keys) can be verified by completing the same ECC arithmetic on the public keys.  For example say a hypothetical transaction (not in Bitcoin network and not necessarily in the same format) has the following information in the transaction.  At this point the format/structure isn't really important.

Transaction Body:
Version
NumInputs
ArrayOfInputs[]
NumOutputs
ArrayOfOutputs[]

Each Input is in the following format:
PrevTxHash
PrevTxIndex
PubKey

So far this is very similar to Bitcoin however there are no scripts in the tx inputs.  Each input simply consists of the information necessary to identify and authenticate it (tx id, index, and public key).  At this point lets ignore the format of the outputs as it isn't particularly important for this discussion.  Now unlike Bitcoin where each input has a signature (the simplified tx is signed w/ private key corresponding to the pubkey listed for the input) could we instead have a single signature for the entire transaction.  Also lets ignore coinbase/generation tx for the moment.

So for a transaction with more than one public key in the inputs we first create a composite key by performing ECC arithmetic.  Lets call the composite key the tx key.  We would take a list of the inputs, remove the duplicate private keys and create the tx key by adding the private keys together.

tx.privkey = privkey[0] + privkey[1] + ... privkey[2]

Then we sign the entire tx once with the tx key.    The single tx signature would be appended to the tx.

Version
NumInputs
ArrayOfInputs[]
NumOutputs
ArrayOfOutputs[]
Signature


To validate we would take the list of inputs, remove duplicate pubkeys, and create a composite in the same manner as the privkeys.

tx.pubkey = pubkey[0] + pubkey[1] + ... pubkey[2]

The tx (composite) pubkey will validate the signature created by the tx (composite) privkey.

This method would be more limiting than the Bitcoin script system however it would (with a few other changes) result in an up to 50% savings in terms of bandwidth and storage requirements.  The computing power requirements should be roughly the same.  Given that over 99%+ of the transactions to date on the Bitcoin network are "standard" pay to pubkeyhash we are sizable savings.  With the use of versioning other more advanced tx would still be possible so it would be possible for an alternative crypto-currency to have the best of both worlds.  For "simple" transactions a significant reduction in resource requirements while still having the ability to create more complex transactions.

Is there any security risk to a format like this?  Any reduction in key strength?  I can't seem to find anything that would indicate it is the case but this really isn't my area of expertise.

Quote
... its certainly possible to— in a single transaction— expose a bunch of public keys, compose them, and sign with the composition. But the space reduction is reduced by the need to expose the public keys... and it would make taint analysis more potent because you multiple parties cannot securely sign in that model. It's also incompatible with sighash single. If you wanted an incompatible ECC specific change— you could instead add public key recovery. This would get similar space savings, but also save on transactions with a single input while not breaking the ability to confuse taint analysis with joint transactions, or breaking alternative sighashes.

I assume by "compose" you mean ECC addition of the private keys (as well as a separate ECC addition of the pubkeys). Right?  I agree there is a need for public key for each input to validate the signature however the signature is significantly larger.  For Bitcoin the pubkey is 34 bytes for compressed pubkey (66 bytes for uncompressed pubkeys).  An alternative CC could simply mandate the use of compressed public keys in the protocol.  The signature is 72 bytes.

Bitcoin Tx Input Format
TxOutHash - 32 bytes
TxOutIndex - 4 bytes
ScriptLength - variable (1-9 bytes, 1 most common)
Signature - 72 bytes (including encoding)
PubKey - 34 bytes (compressed keys)
Sequence - 4 bytes
Total: 147 bytes (Signature is 48% of Input size)

Quote
and it would make taint analysis more potent because you multiple parties cannot securely sign in that model. It's also incompatible with sighash single.

Agreed.

Quote
If you wanted an incompatible ECC specific change— you could instead add public key recovery. This would get similar space savings, but also save on transactions with a single input ...

Interesting.  Can you provide information or reference on public key recovery?

Quote
One thing that I do sometimes wish is that transactions were themselves hash trees internally.  It would be very nice to be able to give to someone all the data they need to build a current UTXO securely (and thus also verify that there is no permitted inflation in the chain) without sending them a bunch of deeply burred signature data which isn't personally interesting to them and which they believe has adequate hashpower security to only do randomized spot checks.

I read this a couple of times and still couldn't conceptualize how hash tree in transaction would add security.  I bookmarked it though.
5526  Bitcoin / Bitcoin Discussion / Re: Once again, what about the scalability issue? on: July 18, 2013, 08:09:46 PM
Leaving it offline too long?

Aye, I'm a non-hardcore casual bitcoiner. But that was an example of an issue related to slow downloading/uploading speed. Freshly mined blocks can't be pruned.

If you are a casual user unable to keep the client online why not just use a SPV client.  You aren't contributing to the decentralization of the network if your node has an uptime of ~3%.
5527  Bitcoin / Development & Technical Discussion / Re: Exhausting the keypool (workaround for "watching wallet" in bitcoind) on: July 18, 2013, 03:47:03 PM
Well since we have covered everything except the question in the OP I am going to assume there is no flaw in the work around logic.
5528  Bitcoin / Development & Technical Discussion / Re: Exhausting the keypool (workaround for "watching wallet" in bitcoind) on: July 18, 2013, 11:43:26 AM
Is there a way to tell how many keys there are left in the keypool?

From the getinfo() RPC Call

Quote
E:\bitcoin\bitcoind>bitcoind getinfo
{
    "version" : 80202,
    "protocolversion" : 70001,
    "walletversion" : 60000,
    "balance" : 168.78386905,
    "blocks" : 247193,
    "timeoffset" : 1,
    "connections" : 8,
    "proxy" : "",
    "difficulty" : 26162875.68256990,
    "testnet" : false,
    "keypoololdest" : 1369918535,
   "keypoolsize" : 99,
    "paytxfee" : 0.00010000,
    "unlocked_until" : 0,
    "errors" : ""
}

The "keypoolsize" reflects the current number of keys in the keypool not the desired size.

You can verify this with the following sequence:
walletlock()
getinfo()
getnewaddress()
getinfo()
getnewaddress()
getinfo()
walletpassphrase()
getinfo


5529  Other / Off-topic / Re: Life in prison for running a payment processor? on: July 18, 2013, 11:33:19 AM

Sorry for the off topic comment, but how does a guest post in the forum?  I thought all users had to be registered.

The user was registered at the time they created the post however since then at some point for some reason the user's account was deleted.  When that happens all posts created by the user are assigned to "Anonymous guest".
5530  Alternate cryptocurrencies / Altcoin Discussion / Re: Miner's Official Coin LAUNCH - NUGGETS (NUGs) on: July 18, 2013, 07:02:04 AM
Wait for the golden blocks to kick in.  People will have a lot of fun mining these.  I really think they will mine and behave differently than superblocks coins.

Goldenblocks are identical to superblocks in everything but name.  The code used to generate them is almost identical to LuckyCoin which was released two months ago and is dead/dying at this point.

Quote
Would happen if say I have agreaf idea like a golden block idea and I decide to encrypt the code so nobody can copy it.  Would anybody care?

First golden block wasn't a great idea so likely your next great idea won't be a great idea either however you can't encrypt source code.  You could release the client as a closed source binary but nobody with half a brain would install a closed source program on a computer.  For all they know you "great idea" is to record keystrokes and steal any other coin's wallet on the computer.

Quote
Cause why would I pay some PhD guy who knows how ,much to improve my coin just to have a guy copy it next week tweak it and that's it for me.  Forget that.

Yeah because you wrote your coin from scratch.  Er wait you didn't it was 99% copied from Litecoin which was 99% copied from Bitcoin.  You wouldn't even have a coin (as crappy and short lived as it will be) without the power of open source projects.

Quote
If I do that I want exclusive rights to any code he writes so what would happen in the alt coin community.
The MIT license does allow you to release as closed source however it is a dead end.  Of course you never listen to anyone so go ahead and release the updated client as a restrictive license.
5531  Bitcoin / Development & Technical Discussion / Re: A question on ECDSA signing (more efficient tx signing)? on: July 18, 2013, 05:53:10 AM
Even if there is, a different piece of data is being signed for each input/key.  i.e. "Data to be signed, d" in your question above is not consistent.  Look up OP_CHECKSIG for details.

This would be an incompatible break, and I harbor no illusions it would ever be used for Bitcoin.  Lets consider this mostly theoretical possibly for some future altcoin.  The transaction structure would not necessarily need or be the same.  You can assume the d is the same for all inputs.  One method would be that the entire tx is signed (all inputs, all outputs) but the exact structure is not that important.

Doing a little more research I believe it is possible to use elliptic-curve arithmetic to add the private keys together to create a "master" private key for signing and this master private key can be verified by adding the public keys together to form a master public key.

I was going to do some testing with OpenSSL but I need some sleep.
5532  Bitcoin / Bitcoin Discussion / Re: Do I really need a Bitcoin wallet? on: July 18, 2013, 05:48:28 AM
Been mining a few months with my PC's GPU and up to 8 coins now. My Jalapeno arrived today so I should be getting coins much quicker. Now that I'm actually starting to get some decent cash, I don't want to lose it.

I'm wondering what is best way to manage the coins. Now the coins I mine I simply have the mining pool send to my account at Mt.Gox. Is that a bad idea? I figure there is a much higher chance of me screwing something up on my end with a bitcoin wallet than Mt.Gox screwing something up.

Appreciate any advice on using a bitcoin wallet vs just keeping coins at an exchange place. Thanks!

If your coins are at MtGox (or anywhere you don't have the private key) then you don't have ANY Bitcoins.   MtGox has your Bitcoins and MtGox has given you an IOU which you can see on your account page.  If MtGox disapears, gets sued into oblivion, gets hacked, has their servers seized by the Japanese govt, etc then THEIR coins are gone and the IOU is worthless.

Now for some people this risk is acceptable only you can decide.  If having an IOU from a company you know almost nothing about on the other side of the planet where if they don't pay you have almost no recourse to recover your funds "good enough"?  If yes then sure you don't need a wallet.

5533  Alternate cryptocurrencies / Altcoin Discussion / Re: Miner's Official Coin LAUNCH - NUGGETS (NUGs) on: July 18, 2013, 05:43:48 AM
Get out of here?  How that possible of nobody own them?  Oh, unless somebody own a couple million nobody knows about.  

It is comments like this which make you lose all credibility.  Despite how poorly your coin launched.  How would people have coins ... I don't know maybe they mined them?  Kinda weird that the "miner's coin" would have miners who have coins.  I just deleted the rest of your comment because if you took even the slightest bit of time or effort to educate yourself you would know it is impossible and not need make stupid accusations.
5534  Bitcoin / Bitcoin Discussion / Re: Once again, what about the scalability issue? on: July 18, 2013, 02:45:31 AM
What 3rd party server.  I run my own node and will be able to for at least a century at this rate in blockchain growth.
5535  Bitcoin / Development & Technical Discussion / A question on ECDSA signing (more efficient tx signing)? on: July 18, 2013, 02:21:46 AM
Bitcoin signs each of the inputs for tx with a separate signature.  This adds significant size to the overall transaction size. The size of the most common Bitcoin tx can be computed as the following:

Size (in bytes) = 10+147*NumIn+34*NumOut

This applies to tx with standard outputs, scripts of less than 256 bytes each, and all inputs use compressed public keys.  If the public key for the input is uncompressed the size is 32 bytes larger.

The largest portion of a balanced (number of inputs and outputs are equal) comes from the input portion and the largest component of the input is the signature which is 72 bytes with encoding.  If we assume the average tx consists of two inputs and two outputs that makes the average tx size 368 bytes.  Roughly 39% of that or 144 bytes is from the two signatures for the two inputs.  However a tx is only valid if all the signatures are valid.

Is it necessary to store each signature separately?
Is there some ECDSA operation which could allow verification that data was signed by multiple private keys with a single signature and multiple public keys?

Given:
private keys a & b
Public keys A & B
Data to be signed d

Is it possible to create a signature S such that it can be verified given only A, B, and d?
5536  Bitcoin / Bitcoin Discussion / Re: Once again, what about the scalability issue? on: July 18, 2013, 01:10:33 AM
We won't get some real big transaction volume because of this issue.

It will just force the economies around the system to change.  Not everyone will be able to maintain a real block chain.  We need to work on trust issues with relying on 3rd parties to verify transactions for us....

this doesn't slow the machine down, just causes change.

WOW so we should just give up and forgot about the core of bitcoin. We should just turn over and die I guess. I see another person that drinks the core dev team juice. The blockchain needs to be reworked to fix a very simple problem with the need for a complex solution.

Satoshi believed from day 1 that not every user would maintain a full node.  That is why his paper includes a section on SPV.  Decentralized doesn't have to mean every single human on the planet is an equal peer in a network covering all transactions for the human race.   tens of thousands or hundreds of thousands of nodes in a network used by millions or tens of millions provides sufficient decentralization that attacks to limit or exploit the network becomes infeasible.
5537  Bitcoin / Bitcoin Discussion / Re: Once again, what about the scalability issue? on: July 18, 2013, 12:05:48 AM
Blockchain size - 8.3 GB

UXTO ~0.24 GB and growing linearly by about 0.1 GB per year.

Seeing as my workstation has 16GB of RAM and 3TB of storage I will probably need to upgrade my system by the year 2130.  I put it on my google calender.
5538  Bitcoin / Hardware / Re: Butterfly Labs shipping 300 units a day on: July 17, 2013, 11:50:14 PM
What is really annoying for people like me is that I ordered 3 Jalepenos in the first couple of weeks.  They should have arrived and paid for themselves by now, but I UPGRADED my order to the better mini single, which no one has yet seen!!.

I wish I could down grade my order again.  Id be much better off.

If everyone had just ordered Jalepenos the entire BTC net would have been better off, greed for bigger and bigger rigs will kill the ROI for everyone. Avalon made a huge mistake launching a 60GH/s rig straight up, too much of a leap from FPGA. It started a trend which is already causing problems. They should have simply sold 10 x the number of 6GH/s rigs. for a much better balanced net, and they could have charged more per GH/s.

Many humans suffer from greed, ordering big rigs straight up is an obvious example of this, like dogs competing for a food bowl.

Nonsense.  If 6GH/s rig would be profitable then buying 10x 6GH/s rig would be equally profitable or renting a small amount of commercial space and buying 1000x 6GH/s rigs.  CPU and GPU rigs are constrained by the cludginess of trying to scale out.  Rigs which communicate with a host over USB lack any such constraint.

Either way the network is going to grow to where it is barely break even for new hardware (including electrical cost) from there it is only going to grow if/when either the exchange rate rises or more efficient devices are produced.
5539  Bitcoin / Bitcoin Discussion / Re: Bitcoin Address Collisions. on: July 17, 2013, 11:07:37 PM
Nobody said it it is all clumped one end however as pointed out even w/ 1 trillion ASIC address generation machines, each producing (and checking) 1 trillion addresses per second all running non stop for the next 1000 years AND all Bitcoins are evenly divided into the maximum possible addresses with 1 Satoshi each the odds that any machine will find any collision with  funded address in less than 1% in the next 1,000 years.

Sure all public key cryptography is based on "odds".  You could in theory generate a private key in ONE ATTEMPT that matches the one used by google and produce a fake gmail site which validates SSL properly.  However the odds are vanishingly small.  The same thing applies to Bitcoin address collisions.

The odds of anyone finding any collision via brute force in their lifetime is essentially 0%.
5540  Bitcoin / Bitcoin Discussion / Re: Bitcoin Address Collisions. on: July 17, 2013, 10:28:11 PM
Assuming Bitcoin takes off, and your salary is 0.000000000000000000000000000000000340 satoshis or an even lower amount, then even 0.50 won't be that bad.

Depends on how unrealistic you think Bitcoin will "take off".  The entire planet uses ~$4 trillion USD worth of currency, if we included demand deposits (M1) that number is still only ~$19T.  If Bitcoin replaced all other forms of currency (and demand deposits) on the planet (likely requiring some many wars to force the last of the resistant to bend to the Bitcoin overlord government) 1 Bitcoin would be worth ~$904,000 USD (in 2012 dollars purchasing power) and 1 satoshi would be worth ~0.9 US cents (2012 dollars purchasing power).  I think as unrealistic as this is (and the every address holds only 1 satoshi) we can consider them the theoretical upper bound.

http://www.bullionbullscanada.com/guest-commentary/dollardaze/5640-growth-of-global-money-supply


Even the M3 is only ~$60T.  This is not an apples to apples comparison because it includes non-currency financial accounts but lets say Bitcoin replaces those as well (there is no good reason just giving you the benefit of the doubt).  Even then 1 S would be worth about 3 US cents (2012 dollars purchasing power).  All private wealth on the planet is ~$135T that isn't even remotely close to currency including everything from real estate, to equity in companies, to debt ownership, to tangible goods (cars, planes, fine art, etc).  Still even if for reasons that escape comprehension the Bitcoin money supply was greater than all wealth on the planet we are still talking about 1 Satoshi is ~ 7 US cents.  The idea that a satoshi would ever represent a significant amount of wealth is just silly. 
Pages: « 1 ... 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 [277] 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 ... 801 »
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!