Just set your dang clock correctly. Get the time you want to display by picking the appropriate timezone.  So long as the time+timezone results in the correct time bitcoin will work fine. You can also set it back when you're done if you really insist on having a clock set >2 hours in the past.

Ah, I hadn't seen how you handled the non-completion case.  So in Bitcoin-style hashchains when that contract was mined it would consume the inputs forever unconditionally. If it did not, you could not have pruning.

Do you plan on breaking pruning or having the satisfaction rules change as a function of height or?

You can't create timeouts in Bitcoin, locktime sets the earliest valid time. So you pre-create the refunds... but yes because the timeout wouldn't be identical in both chains there is some exposure.

I don't see how you avoid extortion in your scheme that wouldn't just apply here.  E.g. you could do the pre-created refund tx only on one side in what I described... and have the other side be the send-hash-first side.  If they don't you perform the refund after the timeout, thus no race.

(Not that in general I think that using chain fragments is bad— but I think it's interesting in external oracles, and less in chains themselves)


Both users would txouts before releasing a secret, so any funny business would have to be in the scriptsig.  If your scriptpubkey looks like if  H(stack) == 123456...  Then I could always copy from your scriptsig anything the satisfied that, even if it computed the value. Though yes, a program for this would have to have a pretty general solver to figure out how to extract the data.  So long as the abort transactions are sufficiently far out that shouldn't be a problem, and you'd have proof of your counterparty being evil.

Correct. The script sig would push the x and y values and the script pubkey would hash and compare them.

(You can also reduce the extortion risk  by using nlocktime, on specially constructed refund transactions. E.g. "Abob_pub + H()+H()" OR "Abob_pub2&&Aalice_pub" and have bob sign a refund txn with far future nlocktime using abob_pub2)

I'm sure someone could give some figures on how often these results could be expected by chance.

Though since today seems to be the day for silly theories.

It was pointed out on IRC that you could do somewhat tidy laundering this way.


Identity X with dirty coins gambles until they lose Y coins.

Then using identity Y, they make more bets, and someone with knowledge of the MAC secret filters their candidate transactions  to help them win until they've won Y/2 (or whatever).

This would be pretty hard to distinguish, except for the weird effect would have on the odds, especially if they weren't careful about the distribution they drew the winning bets from... and it would be impossible to connect the parties beyond they were both participants at some point in the game.

It would also explain rapid, almost certainly bot-based, playing of a negative ev game, reasons for capping the total (make the distribution of bets more regular).  Plus elvis came down from a UFO and told me it was true.

You can do this with far less complexity, and the same extortion risk like this:

Alice and Bob want to trade Acoins and Bcoins. They each pick secrets. Asecret and Bsecret.
They each tell each other H(Asecret)=Ah, and H(Bsecret)=Bh.

After agreeing on the amounts they each form transactions
AAlice 1 Acoin ->  ABob_pub + H(x)==Ah + H(y)==Bh
BBob  1 Bcoin ->  BAlice_pub + H(x)==Ah + H(y)==Bh

once both transactions are in one or the other reveals their secret out of band. The redemption works for all or none.

As mentioned, there is holdup risk here, which could be solved by adding semi-trusted observer keys to optionally release the funds in the case of defection.

But I think the fragment protocol  described here has the same risk.  (and the obvious ways to do avoid it make it possible to rip off one party by delaying the mining of the solution).

As Gavin says, spend-to-pubkey is valid— and it's used by the reference software for mined blocks. (and, IIRC, it used to be use for send-to-IP transactions, you'd connect to an IP and the peer would give you a pubkey to send to)

That it would increase the security is doubtful, however.  The hash function has comparable size to the ECDSA security margin, and while hash functions can be attacked being able to generate a _valid_ ecdsa key which you have the private component to which matches an arbitrary (or even any of billions) of specific hashes is basically inconceivable to me and itself would likely require both an ECDSA break and a hash break of a kind never seen on any modern hash.

If I were a betting man, I'd say it's more likely (but still unlikely) that someone would find a way of compromising some ECDSA public keys with large but feasible amounts of computation.  Under this threat model the use of hashed keys is protective, because your public key isn't revealed until just before compromising it is pointless so long as you do not reuse addresses.

There is, in fact, a oddbal altcoin proposal call MAVEPAY which uses ordered disclosures of hash preimages as its _only_ signing primitive.  (it's crazy for a bunch of reasons, but fact that you can build a plausible signing system out of just ordered disclosures of single hash inputs (e.g. not high overhead like lamport) suggests that you shouldn't discount the security benefit of that)

It makes sense after you've seen people argue that their 'losses' and betcaps are "proof" that a favored gambling strategy is a "sure win".

Same reason casinos promote grand stories of card counting blackjack sharks bilking casinos and pretend to be concerned about card counters,  while simultaneously employing multi deck continuous shuffling machines that moot card counting.

I maintain modified openssl Fedora rpm's for my own use:

https://people.xiph.org/~greg/openssl/

Perhaps some other people might find them useful, either outright or just the spec file changes.

I observed it on 3.3.7-1.fc16.x86_64 and 3.4.2-4.fc17.x86_64.  Not all vulnerable systems hit it, it depended on the system load at the time of the leapsecond.

Sadly, this doesn't do what you think it does. Wallet data ends up in your database directory.... so you can easily leak private keys that way if you're not using the integrated encryption,  and if you lose your disk while your wallet hasn't been flushed the copy on the flash may be unreadable without a manual recovery effort.

Well, you can do things like run sloccount on it— which actually gives reasonable figures for 'typical' software... though bitcoin isn't especially typical, there is a whole novel distributed algorithm at its center, its own network protocol, and as you mention more than typical care was put in to making it secure.

Feeding the earliest commit in git (easier than finding the first release zip file) to SLOCCount gives me
Total Estimated Cost to Develop                           = $ 464,573

The question:

How can we have free transactions, but not make it possible for someone to cheaply DOS the system into oblivion by simply typing "while true; do bitcoind sendtoaddress `bitcoind getnewaddress` 0.00000001 ; done" ?

To solve this we ask:  What characterizes that kind of activity which is distinct from normal usage?    We can't tell that the DOS transactions are all coming from a single party because they can just use many addresses.  We can't really single out smallish transactions because regular users make small transactions and the attack would work just as well even it was moving 50 BTC in each transaction. What characterizes them is that they're rapidly moving the same coins over and over again.

Bitcoin days destroyed is a simple metric that measures coin velocity, and it's basically what the prioritiy system uses.  Sum(input_values * input_ages) / tx_data_size = priority.

Our priority system in effect uses the transaction's Bitcoin days destroyed to pay for them— evidence that the user isn't engaging in a maximum speed coin recycling— in lieu of fees.  The metric is directly connected to real DOS attack behavior, it doesn't depend on the impossible task of distinguishing users, it doesn't disproportionally penalize low value transactions, it expends a real scarce resource (though not one that users consider otherwise valuable), it doesn't actively encourage bad behavior, and it's demonstratively effective. If you don't have enough priority or pay a fee peer nodes will not relay your transaction, miners will not mine it— not until it does have enough priority via aging.

With this metric an attacker is required to have an enormous and near unending supply of unmoved coin in order to sustain an attack or they must spend on fees (or con some suckers into paying fees for them).

The downsides are that it can be a bit inexplicable for the users— "you can't make a free txn now, but you can after the next block??", which is made worse by the fact that the reference software doesn't really try to construct transactions in a way that avoids fees— and more complicated to find _optimal_ coin selections with this metric (it makes the objective non-linear). But otherwise it's a pretty excellent metric.

Because if namecoin was widely used the cost of running a full node would increase. It has _far_ less usage than bitcoin and already it's about 18% of the blockchain size.  Namecoin's design, unfortunately, doesn't enable lite resolvers (there can be no equivalent of a SPV node, like bitcoinj, for namecoin with its current design) of any kind which I think will probably doom its adoption.  I posted a sketch of a design to solve this last year, but other than the addition of merged mining namecoin development appears to be more or less completely dead.

I consider this to be fatal flaw which will ultimately prevent the adoption of namecoin unless it is resolved.


That makes no sense at all and doesn't follow from the technology.  Namecoin is fundamentally more computationally costly to maintain because you _must_ have multiple unspent outputs pending in order to have multiple registered names (whereas any amount of bitcoin can be represented by a single txout), and you must carry additional indexes on them in order to perform lookups. (bitcoin txn only require lookups by txid).

These aren't any terrible flaws, but they're reasons why a full namecoin node— if as widely adopted as bitcoin— shouldn't be expected to be less expensive to run.

A fully validating bitcoin node can actually be operated with less than 100 mbytes storage, though the code for this is not mainline yet.


Can someone please decode this for me— because I don't have an idea what you're talking about.  I can assure you that I'm not trolling.
 
To the contrary, you've still made no suggestion about how namecoin could do anything to address the fundamentally hard problem of this thread: Demonstrating the independence of weakly trusted central servers, as required for the exponential security model given in the OP to hold.

Code misunderstanding detected:  The fees used in the generation of a txn have absolutely nothing to do with the current block size.

The most common cause of this kind of failure I've seen in the past is when a wallet is contaminated by zillions of very small inputs and ends up selecting so many the the resulting txn is >100KB, which it refuses to issue.

Litecoin carries a patch the sets a minimum value for inputs to be considered in coin selection.

Relative to the number of users namecoin is currently much more expensive to maintain. Or do you really think that namecoin has as many as 18% of the users as Bitcoin.


I understand the namecoin system very well.

It seems kind of odd to me that you'd invoke running a full namecoin node as a means to avoid running a full bitcoin node— and only a partial means, since it doesn't do anything to tell you if the parties you're communicating with are actually distinct.

How does namecoin help you know that they're distinct?   How does namecoin— as it's used today— help you defend against an attacker who has control of your router?  How do you resolve namecoin without having a namecoin full node without trusting someone (resulting in the same problem you're trying to solve here)?

A very tall assumption on the internet when identities are fairly cheap.  The question of interest is for a given definition of "organizations" how much does it cost me to make your P as low as I like?  If your definition would let you include individuals the answer is very low.

These sorts of assumptions can also fall down if the attacker has the ability to influence your routing unless you have a good way to validate the identities— and most ways of having good authentication and good ability to distinguish control work against having a lot of peers.

Bitcoin could have been created as 'one peer one vote' system under the logic given here but it would have been trivially exploited if it did.

[Edit: Oh, maaku said this all pretty succinctly, so succinctly that I missed it]

People are working on something better than that which won't compromise a node's ability to function as an autonomous fully validating node but will still make things much faster and use less storage.

More important than supporting header only (SPV) mode, but rather the ability to start as a SPV node and sync-up and transition in the background.  But this isn't yet in the immediate pipeline.