Probably not, due to all the non-bitcoin overlay things people are interested in. (E.g. the altcoins, colored coins, etc).

I disagree with the claim that its unrelated. Scarcity of block space is what enables a market for it; absent complete miner collusion, with unlimited block sizes there is a defection problem (the rational move for the miner is to take very low fee paying transactions instead of turning their nose up at them in order to drive the market price for fees above zero).

Yup, But doing that also eliminates some of the incentive alignment arguments in the first place: E.g. that you'll take care of your keys, and not delegate (or do so only cautiously), not leak them, etc.. because your funds depend on them.

Sort of moot because the whole approach seems fundamentally unsound (or at least none of its advocates have stated a clear set of reasonable assumptions under which their system is secure (and where a centralized ledger wouldn't be)). https://download.wpsoftware.net/bitcoin/pos.pdf

I agree with that argument in general, and I think many other people have made it somewhat different forms as well...  But so long as the node operating cost is insignificant, I think it doesn't apply.

Are you missing that the transaction load (and thus cost) is limited by the hard rules of the network, just as the supply of coins is... under the current rules there is no risk of nodes becoming too expensive to run. (I just ask because you used such absolute language in you message).

This cannot be done with the design of Bitcoin today.  I've previously (incompletely) sketched out what would be required, but we're a fair ways away from that. And so far there has been virtually no interest in moving things in a direction to support things like that inside Bitcoin.

With the rest of your post you seem to be describing a closed cartel system for mining--  if we have that, why not dispense with the mining, trust it to keep the ledger... (and call it paypal?). Centralized systems are much more efficient and easier to make reliable. I think Bitcoin's (unique) value derives almost exclusively from not being centralized.

For simplistic implementations, yes (though you have to get it right). High performance ones... not really. For high performance you really want to hoist the boundary checking.

I'm not sure what advantage this system really offers over Moxie... as moxie is deployed and has toolchain support.

In general, I worry that this kind of system is too low level for a consensus system-- e.g. getting high performance will require dangerous complex execution enviroments; but it's an interesting domain. It also has no facility for dead code elimination, or other facilities which are more obvious when you understand the difference between with script does in a consensus system... that it's not really performing computation, but verification of computation.

Is the source code available to see exactly what transactions f2pool will accept under this interface?  (Eligius' node code is available).

If you accept transactions other nodes will not accept it still facilitates double spending, somewhat. The attacker sends a non-relaying transaction to you first, then floods the network with another transaction.

Kind of annoying that this has every instruction taking memory operands directly, instead of a load/store architecture like Moxie.  This makes it much harder to write a secure virtual machine, since you need to make sure there are boundary checking in many places instead of just two.

Thanks for following up, ... yep, known and expected behaviour, a side effect of the initial sync process.  The next major version (which will have headers first sync) should greatly improve it.

It doesn't, your front node would have begun pulling the chain after a new block was observed on the network and relayed to it by one of its external peers.

You don't say what it was displaying, precisely.

They are not yet in a released version of the software.

Yes they are,
$ ./bitcoind -help | grep white
  -whitebind=<addr>      Bind to given address and whitelist peers connecting to it. Use [host]:port notation for IPv6
  -whitelist=<netmask>   Whitelist peers connecting from the given netmask or ip. Can be specified multiple times.


Because it isn't in that version of the software.


Yes,
./bitcoind -help | grep bind
  -bind=<addr>           Bind to given address and always listen on it. Use [host]:port notation for IPv6
  -whitebind=<addr>      Bind to given address and whitelist peers connecting to it. Use [host]:port notation for IPv6
  -rpcbind=<addr>        Bind to given address to listen for JSON-RPC connections. Use [host]:port notation for IPv6. This option can be specified multiple times (default: bind to all interfaces)


Works for me, what are you setting, precisely?

This is just caused because of people using weird version numbers on blocks in testnet, it's harmless.

The value there is the git commit id of the code being used.

It's trivial to prove an absence in a ordered data-structure (like the linked list of blocks): You just reveal whatever is at the position the missing data would have to be at.  It's only the revealing of absent data in an unordered datastructure which is space infeasible.

WRT limiting in the implementation route of an opcode, ... you already see one reason it's less important: the ability to nest sidechains,  the other reason is that the verifier only needs to understand the transaction releasing coins back, everything else in the other blocks that isn't on the hash-tree path can be formated differently.

Weird and not new.

It's complaining about a combination of things; one is that BIP32 non-hardened keys effectively share the same private key (as far as someone who has the master public key is concerned).  This is documented in the BIP and is the reason for the hardened keys existing. The other is that ECDSA implementations with broken RNGs can compromise users private keys. This is also well known.

Community concern about that (see my own post http://permalink.gmane.org/gmane.comp.bitcoin.devel/2734 and https://bitcointalk.org/index.php?topic=285142.0) is why limited entropy devices like trezor use derandomization already. Incidents like bc.i's compromise in the past are largely unrelated (broken JS code that could just fail to use randomization at all), or just toy implementations which which were seemingly intentionally insecure.

In the case of Bitcoin Core the system has a strong CSPRNG seeded by strong system randomness and other inputs. There have never been any incidents there, and if there were any they would also compromise the ordinary private keys regardless of derandomization of the ECDSA. Support for derandomization exists only in pre-release openssl (and has for more than a year), though the new library Pieter wrote has support for it (and resolves a number of other issues with OpenSSL).  But since the private keys depend on the same randomness, and the randomness is strong everywhere Bitcoin core is supported, I haven't considered it a major priority.

Many of the author's other complaints are just strange, e.g. arguing Bitcoin "lacks a cryptographer to tell us elementary truths about which elliptic curves are mainstream (P-256 and not many more!) and which ones are dodgy, with a collapse of bitcoin looming if bitcoin cryptography is broken some day", which is just weird as there are a great many cryptographers working on Bitcoin (including ones carrying PHDs), so I can only assume what thats really complaining is that no one is paying him, in particular, to give us bad advice like using curves with suspicious fake-random unexplainable NSA sourced parameters. Also I find it weird that after saying that he complains about widely deployed standards compliant randomized DSA to the favor of more recently developed standard-violating derandomized DSA. (As seen in the posts, I'm also in favor of using derandomized DSA, it's just odd to fault Bitcoin for being non-mainstream in not using NIST curves, while at the same time faulting it for not violating the DSA standards).

I see that his latest writing has toned down the ransom-note-esq random modulation into ALLCAPS, but it still succeeds in being chuckle worthy with gems such as "In August 2013 we found on the Internet another file posted anonymously by a certain Greg, which contained 131 bad randoms".

P2pool used to store its sharechain commitments (which is how it achieves trustless, serverless pooled mining) in a zero value anyone can spend output.  To clean up the utxo set some people spent all those outputs at some point. (that might have even been me making that txn, dunno).

It now uses a op_return... now that bitcoin core knows it doesn't need to track those, so there is no useless utxo to clean up.

One of the people seemingly involved (fire000) who was attacking everyone negative is now flooding my mailbox with demands that I remove the negative rating I left on him (after encountering him crap-flooding random unrelated threads just to harass people who raised an alarm on this stuff.

(apparently I'm supposed to be scared that he and his sketchy cronies will negative rate me on the forum, oh noes)

Be careful with assumptions like these.  All (reachable) peers are malicious peers if an attacker controls your network connection. (E.g. compromised your ISP or router, or they are your ISP)

Most of the time taken for hosts when its slow to sync is orphan handing or waiting for slow peers.  This is currently being fixed.

http://sourceforge.net/p/bitcoin/mailman/message/32921390/

So thats 14763 per second?  Thats not favourable compared to running on the cpu but there may be many optimizations still available for you.

This sounds like dangerously crackable snake oil cryptography.  If there is plaintext with a known xor relationship then reuse of the pass key bits allows their recovery,   

Please don't make up novel cryptosystems and encourage other people to use them unless its strictly necessary. There are many existing, mature, well reviewed systems for symmetric encryption.

This also appears to be offtopic.

They aren't random. They're a pure function of the data in the block. They are not (believed to be) predictable in advance, but miners can influence them by changing the data in the blocks to get different results. This is how mining works.

The security of doing that is limited. If you entire raffle process is known in advance miners can cheat your raffle at some cost by throwing away otherwise valid blocks that would go a direction they don't like in your raffle.

There are ways to avoid this (e.g. first publishing a commitment to a secret which is combined in the selection) but really, to be frank, if you're asking very simple questions like this you likely have a long way to go before you're ready to design a cryptographic protocol for other people to use. You probably need to spend some more time reading.