Yeah, I'm fully aware of the meaning of k and why you need to pick it at random.  My concern is that you are setting yourself up for a repeat.  Do you remember that time when you wrote a shitty not-so-random key generator, and then wrote a program that "found" your shitty weak keys?

If you use a shitty not-so-random k generator, and then you exploit your shitty ks, no one gives a fuck because you are exploiting your own lousy programming, not the software people are using, and not the math it is based on.

I could be wrong about that, of course.  Your latest scam might not depend on using shitty k values.  It is also entirely possible that you don't understand that message signing is done on hashes instead of integers.  Or, you may have "discovered" the property of key-recovery that gmaxwell mentioned earlier.

 

This forum is in peril.

Trolls and morons have already driven most of the developers away.  Spam (and people padding their stats for future spamming) are killing old threads and making some boards nearly useless.  I monitor a bunch of old threads, and I don't even bother reading half of them when they pop up with new posts any more because I've learned that they are filled with "Me too" and "neat!" posts.

This place is a tool to foster communication.  Incentives should align with that goal.

Paid advertising in sigs and posts gives people incentives to hurt the community through hard and soft spamming, and should be stopped.

I propose a few options.

Option 1:  Disallow commercial advertising in sigs, even unpaid.  Any link to a product or service that isn't both free and Free, or text describing or pointing to same, is "commercial".  Give one warning and clear out their sig.  If they put it back (or a different ad), permanently disable their signature.

Option 2: Disallow all advertising in sigs.  Same as above, but even disallow mentions of free and Free projects (such as mine).

The second one would be much easier to enforce, with less effort from moderators and less whining from violators.

Neither one would put an end to the flood of useless posts, but they would help.


This only helps a little.  Even when one user blocks sigs, they still see all of the posts that are used to bolster the user's activity to enable better advertising for the people that haven't blocked sigs.

Not the way you are thinking, no.  The script checker only looks at two things, the output script that is being redeemed, and the arbitrary data provided by the redeemer.  It has no view of the transaction amount, and it has no view of the upcoming output.

And it wouldn't help you at all if it could be done.  What you should do is make a 1-of-2 multisig address and send to it now instead of later.  If these other keys are more secure than the key that is receiving the money (like on a webserver), you should move the funds out quickly.

I don't normally consider contracts expiring when their agreed-upon expiration dates hit to be fraudulent.  Why would I start now just because some software is mediating the event?

At any rate, the question is not "Could this feature be useful in some unusual situation some day?".  It is rather "Is this feature, upon consideration of many scenarios, expected to be a net gain for the system?".  In this case, the answer looks like a pretty clear no.  It would be misused and abused in ways that will cause mayhem, probably a thousand times for every time it is used properly and intentionally.

Right now, you can convince yourself of the safety of your transactions by taking simple steps like making sure that you are connected to the bulk of the network, making sure your received payment has a number of confirmations sufficient for your risk tolerance, and making sure that no competing transactions are visible.  Having expiration heights degrades that safety by a factor that is difficult to estimate.

P.S.  Your DOS scenario is the stuff of movie plots.

In my opinion, this topic belongs in Alternative Clients, not here.

Because if the transaction stops being valid after block X, and X is in the middle of the reorg, then it can no longer be placed in a block.

Sorta like the DNSBL systems for ignoring email spam.

Simple text box in your profile where you can list user names, and then when the ignore function is working, it operates on the union of your ignore list and the ignore lists of the people you've listed.

A more advanced version of this feature could add named ignore lists.  I could then organize my lists into categories, and people could select only the ones they want.  For example, rather than ignore everyone that I've ignored, someone could use kjj.scammer to ignore only people on my scammer sublist.

I think you are either overestimating how much data bitcoin moves, or underestimating how much data packet radio can move.

bitcoind getblockhash 291050
bitcoind getblock 00000000000000004642ed8eb619f2f84aaf201dbf0ba5fc87c425d040455d5a

The lesson that you should learn from this is that a website named blockchain.info, despite the fancy name, is not a reliable source of information about bitcoin.


The closest that you can get meaningfully, is the timestamp of the block.  The timestamp in the block is usually very close* to the actual time that block was found, and is absolutely sure to be within the fuzzy window that the network defines for validity.

You could also run your own service and keep track of the exact instant that you first see each block.  However, this will quickly run into the problem of no one giving a fuck when you first saw it.  In theory, this problem can be overcome by becoming important in the community, but most people would probably just prefer to use the global timestamp that is already in the block, and accept the limitations thereof.

* And by "very close", I mean within the "reasonable accuracy of a few minutes" that you are asking for.

Your understanding of what is happening in the account system is completely and utterly wrong.  Please go educate yourself before you lose a bunch of money that doesn't belong to you.  The search function will probably help you in this matter, or google.

Your reasons for wanting it are speculation and you seem to be operating under some grave misunderstandings of what mining is all about.  It defines the order of transactions.  Everyone still always validates everything.


VPN


VPN.  Also, physical location of what?  Reported by what?  Authenticated by what?

No.

Though if it concerns you, you could create your own cryptocurrency that requires that blocks be signed, and then use PKI to enforce authentication, and then impose whatever other rules you desire using that identification.  I don't recommend it, and no one will use it.

There is no SHA-1024.

http://en.wikipedia.org/wiki/SHA-2

Stop.  Accounts do not work the way you think they do.  Odds are good that you are setting up to shoot yourself in the foot  Stop right now and go find out how they really work.

Accounts are credited when transactions come in to an address owned by that account.  They are debited when transactions are created that specify the account.  They can be adjusted in pairs by a move.

Those are the ONLY times that accounts are updated.  Assigning a used address to an account is not in that list.  Most spends are not in that list either.

Keys do not belong to accounts, and the wallet pays absolutely positively no attention to accounts when picking transactions to spend.

Make a couple of bogus privkeys, use bitcoind to generate the 2-of-2 address, and use your script to generate it.  Post the keys, the redeemscripts (both of them) and the two resulting p2sh addresses.

Since we are all repeating what always is said in these threads, I'll add my 2 cents.

We have no promise that each possible outputs of our hashing algorithms are reachable by some valid input.  So, addresses where the private key has been lost are fundamentally different from addresses that never had a private key to begin with.  Thus, coins sent to the bitcoin eater are "more lost" than coins sent to bitomat depost addresses.

Physics won't let us iterate all possible private keys, but if we could, we are sure to find the bitomat coins.  We aren't sure at all that we'll find the bitcoin eater coins.

Account?  Methinks you have some more books to be hitting.

Also, this won't work.  For either rule to work, you need some way to decide which of two events was first, which is exactly what the bitcoin network is doing.