Bitcoin Forum
May 09, 2016, 01:05:17 AM *
News: New! Latest stable version of Bitcoin Core: 0.12.1 [Torrent]
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 ... 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 99 100 101 102 103 104 105 ... 114 »
1081  Bitcoin / Development & Technical Discussion / Re: Difficulty adjustment needs modifying on: October 03, 2011, 02:10:15 PM
Nope, bitcoin still has the off-by-1, as for now it's deemed "too big to fail" and fixing it would mean a backwards-incompatible change to the blockchain.

First: sorry for conflating the off-by-1 and the asymmetric adjustment issues.  As I said, I haven't taken the time to consider changing the bitcoin difficulty adjustment algorithm (too big a change for too little benefit, in my opinion; if we lose 90% of hashing power in a month then there that is a sign something much more serious is wrong with bitcoin than the difficulty algorithm; speculation on what will happen when the block reward drops seems pointless to me, I don't think we'll know until it happens).

Second: I've written 'discourage blocks' infrastructure:
  https://github.com/gavinandresen/bitcoin-git/tree/discourageblocks
  (code reviews welcome)

... which should give us the ability to nudge miners to Do The Right Thing.  Discouraging blocks that appear to be gaming the off-by-one bug should be enough incentive to prevent 50+% cartels from forming, without requiring a blockchain-splitting change.
1082  Bitcoin / Development & Technical Discussion / Re: OP_EVAL response on: October 03, 2011, 01:43:53 PM
If the mediator generates the script and you use the hash without checking the script then you would have to fully trust the mediator.

So in an escrow situation all three parties have to exchange public keys and agree on one particular way of putting them together into a Script that they all agree on (so they all agree on the Script's hash).  That seems OK-- the three parties have to exchange public keys before creating any transactions in any case.
1083  Bitcoin / Development & Technical Discussion / Re: Difficulty adjustment needs modifying on: October 03, 2011, 01:28:01 AM
Fine, then ponder this for a while:
  https://bitcointalk.org/index.php?topic=42417.msg517020#msg517020

Executive summary:  asymmetric difficulty adjustments and adjustments based on time are really, really hard to get correct.

I haven't thought about it hard, but I trust ArtForz when he says he thinks it is IMPOSSIBLE to get it right.
1084  Bitcoin / Development & Technical Discussion / Re: Difficulty adjustment needs modifying on: October 03, 2011, 12:59:45 AM
I'm sure there are other 'security problems', but at least mention them ...

He did. He said ArtForz brought them up in the Alternative Currencies board.

See this thread for details:
  https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772
1085  Bitcoin / Development & Technical Discussion / Re: OP_EVAL proposal on: October 02, 2011, 08:42:32 PM
Summary of a discussion that happened in IRC chat this afternoon:

There are 10 no-op opcodes that are explicitly for expansion:
  https://github.com/bitcoin/bitcoin/blob/master/src/script.h#L150

They are currently enabled, and do nothing.

If we did the obvious thing and used one of them for OP_EVAL, then, surprisingly, OP_EVAL would not necessarily cause a block chain split.  Why?

Old clients see:
 
Code:
<sig> <...serialized script...>  DUP HASH160 <hash> EQUALVERIFY OP_NOP1
New clients see:
 
Code:
<sig> <...serialized script...>  DUP HASH160 <hash> EQUALVERIFY OP_EVAL

Old clients will consider the transaction valid as long as <serialized_script> hashes to the correct value and is not OP_FALSE, because a script evaluates as valid if it leaves a non-false value on the top of the stack when it is done.

New clients will do full validation: the hash has to be right AND the <serialized script> has to be valid (has to leave a non-false value on the top of the stack).

So:  If upgraded clients and miners start producing transactions and blocks with OP_EVAL in them, they will be accepted by old clients and miners as valid.

That means OP_EVAL could be supported as soon as 50+% of the network hashing power upgraded, instead of requiring that 100% of the network (clients and miners) upgrade before a certain time or block.

Anybody want to volunteer to write a BIP that works through all the details?
1086  Bitcoin / Development & Technical Discussion / Re: Mac .dmg, bitcoin 0.4rc2 on: October 02, 2011, 05:15:04 PM
Bugs can be reported via the github issues system:
  https://github.com/bitcoin/bitcoin/issues

... although the entire GUI is changing for the next release, so reporting GUI bugs like not being able to sort in the address book will be a waste of time.
1087  Bitcoin / Development & Technical Discussion / Re: OP_EVAL proposal on: October 02, 2011, 05:05:36 PM
Once the details are hammered out and there's a testnet implementation (which I see little reason *not* to rush; it's only testnet), then it'll be time to summon as much security-researcher attention to it as possible.

I agree. Security is really high on the priority list; I'd like to see secured bitcoin addresses in people's forum signatures within a year. I'm sure one of the alternate blockchains will take this idea and run with it, so much of the hammering-out will happen there.
1088  Bitcoin / Development & Technical Discussion / Re: Proposal to modify OP_CHECKSIG on: October 02, 2011, 03:48:38 PM
I split ByteCoin's OP_EVAL post and followups into it's own thread.
1089  Bitcoin / Development & Technical Discussion / OP_EVAL proposal on: October 02, 2011, 03:45:16 PM
RE: be wary of OP_EVAL:

Agreed, we need to think hard about whether or not attackers could Do Evil Things like create an innocuous little script that pushed an infinite amount of data onto the stack or something  (lets see... Serialized(<OP_DUP OP_DUP OP_EVAL>) OP_DUP OP_EVAL would do that...).  Disallowing recursion (no OP_EVALs allowed in the OP_EVAL data) would, I think, prevent all of that mischief.

RE: OP_EVAL means no more IsStandard:  I agree with ByteCoin.  A ScriptSig would be IsStandard if it's ScriptPubKey was IsStandard, and if it's ScriptPubKey was the generic OP_EVAL form then the last value pushed by the ScriptSig would also have to pass the IsStandard test (deserialized into a Script).

RE: data should always be protected by a hash script:  I think the answer is "don't be an idiot" and "use standard transaction types that have been banged on / thought through."

RE: sender/recipient negotiating a transaction: I think that may become the most common way of creating a transaction, but I don't think it will ever be the only way.

1090  Bitcoin / Development & Technical Discussion / Re: Question regarding logging on: October 02, 2011, 03:16:28 PM
-logtimestamps  command-line param or logtimestamps=1 in the bitcoin.conf file.
(I dont' remember when that option was added, a 'git blame util.cpp' will tell you, look for fLogTimestamps)
1091  Bitcoin / Development & Technical Discussion / Re: Very few normal people would wait days for the blockchain to download. on: October 02, 2011, 01:55:33 AM
The new QT GUI (in git HEAD) has a nifty block-chain-download-progress indicator.

I'd like to pull together a version 0.5 release candidate and start testing it early next week.

Maybe the big feature for version 0.6 can be fast initial download (I'm thinking the best thing to do for brand-new, starting-with-an-empty-wallet installations is to download only block headers, function as a 'lightweight' client, and 'backfill' full blocks until you're caught up with the full chain-- then function as a 'full' client).
1092  Bitcoin / Development & Technical Discussion / OP_EVAL proposal on: October 02, 2011, 01:10:08 AM
I like OP_EVAL better than BEGIN...ENDDIGEST.
1093  Bitcoin / Development & Technical Discussion / Re: Proposal to modify OP_CHECKSIG on: October 02, 2011, 12:26:42 AM
I'm going to shoot myself in my foot again thinking about stuff late in the day and week when my brain is tired...

... but here are some half-baked thoughts:

The:   DUP HASH160 <hash> EQUALVERIFY   that we're currently using to hash a 65-byte public key into a 20-byte bitcoin address could be generalized into something like:

n DIGEST160 <hash> EQUALVERIFY  :   create a secure 160-bit hash from the <n> items on the stack, make sure it matches a given hash.

That would be very useful for creating multisignature transactions where <hash> is really some arbitrary combination of public keys.

But it would be really spiffy if the complicated transaction could be in the ScriptSig (specified when the coins are spent) and not the ScriptPubKey (so the sender doesn't need to know what kind of transaction they're funding).  Maybe something like:

ScriptPubKey:  END_DIGEST160 <hash> EQUAL

... and the generic ScriptSig would be:

<sig1> <sig2> ... <sign> BEGIN_DIGEST160 ... an arbitrary script with public keys and CHECKSIGs and stuff....

BEGIN...END_DIGEST160 would create a secure hash for all the opcodes and data between the begin and end.

I think I can convince myself that would always be secure.  Concrete example of the simplest, one-key transaction would be:

ScriptSig:  <signature>  BEGIN_DIGEST160 <public_key> CHECKSIGVERIFY
ScriptPubKey: END_DIGEST160 <hash> EQUAL

Nobody can put another Script in the ScriptSig, because that would change <hash>.
And the signature must be valid because it is checked in the ScriptSig.

If we're going to schedule a blockchain split to support new stuff, something like this seems like the right thing to do.
1094  Bitcoin / Development & Technical Discussion / Re: Proposal : standard transactions for security/backup/escrow on: September 30, 2011, 08:33:08 PM
I understand gavin, he prefers having less, but soon. The more general implementation (groffer's proposal) can substitute it later (v0.6 ??).

Yes, I want wallet security and backup as soon as possible, so I want transactions that support that functionality relayed and included in blocks as of the 0.5 release, if possible.

Current state:  (old news for those of you on the bitcoin-development mailing list)
I've made a PULL request for "standard"  (a and b),   (a or b),  (a and b) or c   transactions to eventually support keys split between different devices, wallet backup, and wallet-backup-with-split-keys.
  https://github.com/bitcoin/bitcoin/pull/541


Supporting lockTime or 2-of-3 escrow transactions or more generic 'standard' transaction in the future is certainly possible. Put together a solid pull request that adds support for relaying/including in blocks, with unit tests and a testing plan and, assuming there's general consensus that what you're proposing is safe and secure and is near the top of the "will make bitcoin better" priority list, it will get pulled.

1095  Bitcoin / Development & Technical Discussion / Re: feature request: split the wallet and p2p client on: September 30, 2011, 03:00:21 PM
Honestly, I don't think the future of bitcoin is running "heavy" nodes on our personal computers.

I think the vast majority of people will be using bitcoin through web or mobile apps in the not-too-distant future. So I'm not personally inclined to put a lot of effort into splitting the node and wallet, unless that makes creating lightweight web and mobile apps easier.

That said, the new QT gui does a much, much better job of letting you know what bitcoin is doing, both during initial startup and initial blockchain download.
1096  Bitcoin / Bitcoin Discussion / Re: Bitcoin version 0.4 released on: September 29, 2011, 12:55:03 AM
Submit bugs here: https://github.com/bitcoin/bitcoin/issues
Although all of the GUI code is being replaced in the next version, so don't bother submitting UI bugs.

RE: debugging what bitcoin is doing in the 10 minutes it takes for the window to come up:
  tail -f ~/.bitcoin/debug.log
... should tell you what it is busy doing.  Probably loading the block chain and reading the wallet (do you have a very large wallet.dat?)
1097  Bitcoin / Development & Technical Discussion / Re: How to create block query tool (python/c++)? on: September 26, 2011, 07:18:50 PM
Very cool etotheipi.

Have you tried using mmap() to page the blockchain file into RAM instead of copying it explicitly? Operating systems are typically very well optimized for accessing mmap()'ed files.
1098  Bitcoin / Development & Technical Discussion / Bitcoin QT pulled on: September 26, 2011, 04:15:57 PM
I pulled Bitcoin QT into the master branch of https://github.com/bitcoin/bitcoin/ this morning.

See doc/readme-qt.rst for instructions on building Bitcoin QT.

And I updated doc/build-*.txt; they are now instructions for building bitcoind and don't mention wxwidgets at all.

There are still loose ends to tie up, like modifying the build scripts and the windows installer; I hope to tie those up in the next week or so, and have a release candidate for a version 0.5 available soon.
1099  Bitcoin / Alternative clients / Re: Bitcoin-Qt, the future Bitcoin client GUI [user input needed] on: September 26, 2011, 03:57:43 PM
I pulled Bitcoin-QT into the main bitcoin tree this morning.

1100  Bitcoin / Development & Technical Discussion / Re: Proposed RPC command: sweepprivkey on: September 25, 2011, 01:30:03 AM
Encouraging people to expose their private keys makes me nervous. They're "private" for a reason, and it seems to me the vast majority of private keys will, a few years from now, either be stored on a secure device which is designed to never reveal them or will be split.

Why would a merchant "wish to accept typed or scanned Bitcoin private keys as payment" ? They're going to generate a transaction immediately anyway, it seems to me making a payment that way just opens up more potential ways of getting defrauded (e.g. merchant keeps the private key in case more bitcoins are ever sent to the same address, or merchant sends change to the same address and then a few days later uses the private key to take back the change).

I don't see any privacy or transaction-fee-saving advantages, either; am I missing something?

(I do see the usefulness of importing private keys into your wallet, that's a different feature that I'd like to be in the next release).
Pages: « 1 ... 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 99 100 101 102 103 104 105 ... 114 »
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!