Bitcoin Forum
September 29, 2016, 11:51:54 AM *
News: Due to DDoS attacks, there may be periodic downtime.
 
  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 ... 802 »
5521  Bitcoin / Development & Technical Discussion / Re: A question on ECDSA signing (more efficient tx signing)? on: July 18, 2013, 11:21:32 PM
I'm not sure that you can do what you described above. i.e. you can't just add a lot of private keys, sign a message and then add up the corresponding public keys and use this to check the signature (if that is what you meant) even if you are using EC point addition. I'll have to have a look when I'm more awake (sober)  Smiley

No problem. I am sure it can be done.  It is used for deterministic wallets for example and it for verifiable secure vanity address generation.  It is an interesting property of ECC keys.  I just wanted to know if any crypto experts saw any potential reduction in security as I have limited knowledge in the field of ECC.  Unless I was drunk I don't recall it even being covered in college.

You may be right about signing and verifying in the method you described.  I will try some experiments with OpenSSL.  My assumption would be that if both are possible that given n keys that n key additions plus one signature (or verification) would be faster than n signings (or verification).

5522  Bitcoin / Bitcoin Discussion / Re: Once again, what about the scalability issue? on: July 18, 2013, 11:09:29 PM
People, stop saying that scalability is not a problem and writing about how cheap hard drives are.
The scalability is the number one problem stopping Bitcoin from becoming mainstream.
It doesn't matter how fast the drives are growing, right now the blockchain keeps all the old information which is not even needed, and grows indefinitely, how hard is it to understand that it is a non-scalable non-future-friendly scheme?
I am sure the devs know this and are doing their best to address it and I am grateful for that. But saying that it's not a problem is just ignorant and stupid.

Quote
We won't get some real big transaction volume because of this issue.
I can't see how anybody is even arguing against this. I mean, it's even in the wiki: https://en.bitcoin.it/wiki/Scalability

The historical storage is a non-issue and the scalability page points that out.  Bandwidth (for CURRENT blocks) presents a much harder bottleneck to extreme transaction levels and after bandwidth comes memory as fast validation requires the UXTO to be cached in memory.  Thankfully dust rules will constrain the growth of the UXTO however both bandwidth and memory will be an issue much sooner and quicker than the storing the blockchain on disk. 

The the idea that today's transaction volume is held back because of the "massive" blockchain isn't supported by the facts.  Even the 1MB block limit provides for 7 tps and the current network isn't even 0.5 tps sustained.  We could see a 1,300% increase in transaction volume before even the 1MB limit became an issue.  At 1 MB per block the blockchain would grow by 50 GB per year.  It would take 20 years of maxed out 1MB blocks before the blockchain couldn't fit on an "ancient" (in the year 2033) 1TB drive.  

Beyond 1MB the storage requirements will grow but they will run up against memory and bandwidth long before disk space becomes too expensive.  Still as pointed out eventually most nodes will not maintain a copy of the full blockchain, that will be a task reserved for "archive nodes" and instead will just retain the block headers (which is ~4MB per year) and a deep enough section of the the recent blockchain.


5523  Bitcoin / Development & Technical Discussion / Re: Any documentation (other than the code) on the format of the wallet.dat file? on: July 18, 2013, 10:21:54 PM
I don't think so.
It's a berkeley db file.

Look at the pywallet code if you want more than one point of view.
kds is the key and vds is the value.

For example, the (key, value) pair for an unencrypted private key would be:
('\x03key\x21\x03\x01\x01\x01...\x01', '\x20\x54\xfd...\x31')
If the public key is '03010101...01' and the private key is '54fd...31'

Thanks I can follow the python code a lot easier than the reference client.

Still the lack of documentation is kinda sad.  It just means countless hours wasted "relearning" the same thing by each developer.
5524  Alternate cryptocurrencies / Altcoin Discussion / Re: Miner's Official Coin LAUNCH - NUGGETS (NUGs) on: July 18, 2013, 10:08:12 PM
Block 250 has to return a 0 subsidy. Superblocks can not kick in to some future block number that gives people time to update the client.
Edit:  or maybe 250  has to be a 0 or a superblock chance,  have to find the original code to remember for sure.

You were right on the first one.  Since block 250 already exists now and it is 0 coins then any change other than that will cause a retroactive fork back to block 250.  So block 250 MUST be zero and superblocks must NOT be enabled until some block in the future.

However at the time jackjack published the fix it was prior to block 250 so if implemented then it would have been fine however that ship has now sailed so the "fix" which causes the minimal collateral damage (to existing coin holders and exchange accounts) is to "fix" it such that it preserves the existing chain (flaws and all) and then "enhanced" future blocks only.
5525  Alternate cryptocurrencies / Altcoin Discussion / Re: Miner's Official Coin LAUNCH - NUGGETS (NUGs) on: July 18, 2013, 10:02:47 PM
Block 250 has to return a 0 subsidy. Superblocks can not kick in to some future block number that gives people time to update the client.


Edit:  or maybe 250  has to be a 0 or a superblock chance,  have to find the original code to remember for sure.

Block 250 is not supposed to be 0, I quoted r3wt stating this a few pages ago.
And yeah, I wasn't sure if anybody was really using the client so I just followed what Vlad asked. Also block 250 would create a hard fork anyway as the current code makes it 0 and my fix makes it 49.

It doesn't really matter here (given this coin is dead anyways) but as an academical point of view if a hard fork is necessary it should be a future hard fork.

It doesn't matter what block 250 "should have been", block 250 on the current longest chain has a value of 0 coins.  If you change that you will cause a catastrophic re-org back in time to block 250.  This is an absolute worst case scenario.  Once again this is academic because this coin is dead anyways but a good learning lesson.

Once a mistake is made and the chain has moved beyond that the "fix" is to keep it the same.   As an example Satoshi had intended the genesis block to be spendable but a bug in the code prevents it from being spent.  The "fix" is to keep that block unspendable forever.  Trying to correct it to what "should have been" would cause a irrecoverable hard fork if/when someone tried to spend the genesis block.

The mistakes were:
a) block 250 is 0 coins
b) super blocks are not possible through the current block due to a bug.
c) no subsidy decline just drop to 0 in 7 years (we will ignore this one because it isn't pressing although it does ensure this coin is DOA).

The fix is:
a) keep block 250 as 0 coins.
b) keep no superblocks through some future block (estimate the time necessary to get super majority of nodes to upgrade)
c) implement superblock fix on blocks AFTER the block in "b"

This will keep the current longest chain valid and allow migration at some future block height to enable the superblocks.  Otherwise you introduce the abiltity to double spend.  Some users have already received coins in blocks 251+.  Those users have sold them on exchanges (in theory).  Changing the "correct" value for block 250 would cause all nodes running the corrected code to see the entire existing chain from block 250 onward as invalid.  The coins held by exchanges would disapear in the reorg.

Obviously any hard fork is bad and testing and proper deployment should be done to minimize the need for hard forks however if you must use a hard fork it should only be done in a forward fashion.  At block XXXX in the future old nodes and new nodes will fork not at block yyyy which is way in the past we just erase the majority of the existing change.
5526  Bitcoin / Development & Technical Discussion / Docs on the structure and format of the wallet database on: July 18, 2013, 09:38:49 PM
Title says it all, any documentation (other than the code) on the structure and format of the wallet database?
5527  Other / Beginners & Help / Re: Can someone explain membership requirements? on: July 18, 2013, 09:28:15 PM
10 posts and 4 hours: ability to post outside the newbie section

This is 1 post and 4 hours.

Didn't it change with the new activity thing?

Yes it was 5 post and 4 hours and now it is just 1 post and 4 hours.
5528  Other / Beginners & Help / Re: Can someone explain membership requirements? on: July 18, 2013, 09:21:30 PM
10 posts and 4 hours: ability to post outside the newbie section

This is 1 post and 4 hours.
5529  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.

5530  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.
5531  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.  
5532  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. 


5533  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.
5534  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%.
5535  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.
5536  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


5537  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".
5538  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.
5539  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.
5540  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.

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 ... 802 »
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!