This sounds right and even timely for me.

I do not like mBTC since it scales with 3 magnitudes.
People used to 2 magnitude moves from USD or EUR to cents and not to 1/10 cents.

Should we rather go for BTc for BT(c)ents, or cBTC?

Yes. The longer we maintain unworldly policies like relaying zero fee transactions and dust the faster this will happen.

What we might choose is if the "Banks" will be the old ones or we provide funding to some arising out of this new community. The first step for the second alternative is to reduce funding dependency on inflation by enforcing fees.

The same applies to funding innovation that ensures the decentralized nature of the system is preserved to the extent possible.

You make a very valid point that miner seek to maximize fee/size and that nodes should make sure tx favorable on that measure get to them.

Since tx size is also driven primarily by the number of inputs and outputs we have identified two goals (containing UTXO and high fee/size) driven by same parameters. Do we find arguments to determine the relative weight of the two goals, such as (w being a fraction in [0,1])?

fee = (w(nr_of_outputs/nr_of_inputs) + (1-w)(nr_of_outputs + number_of_inputs)) * FEE.

I think the principal privacy leak is if two or more addresses are used as input for the same transaction while they have not previously received funds from same source address. If that is correct then privacy enhancing algorithms will in effect avoid aggregation hence bloat the UTXO. I apologize if I missed a contrary argument. Please point me to it.

I just fixed a subtle one that fits your description. Maybe this was it. You might admit without me claiming that I am done , I know there is still work to do.

https://github.com/bitsofproof/supernode/commit/96c6ffb00f55d2e8b95e55e3237309f86e6e11f2#src/main/java/com/bitsofproof/supernode/core/CachedBlockStore.java

Let us recognize that it is not dust as defined by an arbitrary threshold, but coin fragmentation in general that drives cost of the network.

A simple transaction has number of outputs to inputs ratio of 2, if addresses are infrequently re-used (as required to maintain high level of privacy) this leads to an exponential hence problematic expansion of the open transactions set. There are legitimate use cases for privacy but they should be weighted against their cost to the network just like dust.

I suggest to deal with dust and fragmentation in a combined approach to also incentivize dust collection and aggregation.

Let us assign a minimum fee (FEE) for the ratio of number of outputs to inputs, a transaction with ratio n should offer n*FEE fee to be relayed or mined.

Transactions collecting dust would become cheap compared to those fragmenting.

Zero fee transactions should not be relayed or mined (other than of their ratio is below 1/FEE so they become free for collection of dust)

This will offer synchronous remote invocation for a few functions and have an asynchronous message bus for notification and broadcast between known extensions or authenticated clients. The API (BCSAPI) is supposed to isolate components that need highest level of compatibility with bitcoind from the rest, where innovation should take place. The BCSAPI seeks to serve low level data, such as validated transactions and blocks chain events or outputs by address eliminating the need to hack into core components or interpret binary storage.

I do not plan to imitate bitcoind's RPC out-of-the-box but, make it possible to implement extensions/proxies connecting to above API that create a compatibility layer if you need.

This is a project in development, so interfaces or database schema will likely change. Keep watching this space for a ready to go before using it for real or committing serious development on top of the API.

Suggestions, wishes are welcome.

I would suggest to take a look, but that seem to offend you.

I will work to deploy also those tests to my implementation.

I understand that you are deeply concerned of your investment. My opinion is that my work contributes to appreciation of that investment, just as it does to mine. I believe that I am not working on a pointless re-implementation, but performing the long due reengineering of a proof of concept code, so it will enable innovation and not protect but multiply our wealth.

There is the danger of a fork but also a bottleneck on innovation imposed by a monolithic, archaic and hard to maintain code base that fails to separate concepts of communication, validation, archival, wallet, mining ... Imagine innovation that could be unlocked e.g. for wallets or data mining if it were not all part and tightly coupled within the sacred code and therefore feared to be touched.

I think the best way to avoid people writing competing implementations of a great and open idea is creating and maintaining an implementation they find welcoming in design hence build onto. bitcoind is rather badly suited on that measure. No wonder others emerge.

This brings me back to the original thread where I offered to read my code as it is more detailed than the wiki and easier to digest than the Satoshi code. People read my code likely recognize that there is quite a work in there and that it was written with modularity in mind, so they do not create yet an other script engine for their project, not because I FUD, but because it is welcoming and I do seek to resolve any incompatibility I find myself, with existing test cases, or if I am told an issue.

Happy New Year to you!

I just worked several days to successfully pass all script tests the bitcoind source tree has to offer.

I do not require you to do anything. I politely asked to substantiate your claim, and I also understand that you do not have to.

Point me to a bug in it, please.

If operands are not available for an operator, that means the script is invalid.
Better not assume anything. For certainty, read the Satoshi code.

I also started reading the wiki but there are lot more subtle features in the Satoshi code than described there.
It is very painful to achieve highest level of compatibility with it. My implementation passes the unit tests
for valid and invalid scripts as used by the Satoshi code. You might read that for starter as it is far easier to understand.


https://github.com/bitsofproof/supernode/blob/master/src/main/java/com/bitsofproof/supernode/core/ScriptEvaluation.java
 

An update on testing progress.

The bitsofproof supernode now passes bitcoind´s script and transaction related unit tests as stored in the Satoshi code:

base58_encode_decode.json
script_invalid.json
script_valid.json
tx_invalid.json
tx_valid.json

I think this is a promising result of compatibility. May I honor the compiler of those tests, they really helped to pinpoint very subtle differences.

In 2013 I will write more complex tests for blocks an chain events.

I am afraid that any remedy will only push out your timeline running a full node a few months or a year.

You will have to decide to be in the business of running a full node, that will become as serious as it is now to be a mining pool operator,
or you move your bitcoin with most of the customer to a tablet.

Above statements are not ideological, just rational thinking.

I also regret that times of all having equal "vote" will be gone. They are actually already gone. A mining pool operator has more than equal "vote" compared to your full node since long, e.g. he can exclude transactions from blocks, you do not. You will hardly win a real world argument against blockchain.info with a merchant remote from you by pointing to your screen.

I work on an implementation that aims to support creation trustworthy centralized services, unlock innovation so we preserve as much of the the zero trust environment as possible. The future will unlikely be a homogenous set of nodes, since it is not already.

Peter works on a short term remedy with 0.8 for us.

You however need "plenty" of cache, otherwise the database seek will be an orders of magnitude bigger problem than signature validation. The assumption that the UTXO set fits into memory is in danger for small footprint implementations or if fragmentation of coins increases exponentially through privacy options that avoid aggregating.


Yes, it prepares for that. Pruning can however only be turned on on network scale if nodes specialize, so we have archiver that allow for bootstrapping, since you can not (yet) transfer UTXO without trust.

Not to lessen you effort, that I admire, but I believe my implementation will be easier to taylor to behave differently at different sites or to add to the protocol e.g. to transfer UTXO using the ideas developed in this forum.

Going forward verification time will likely dominate the bootstrap not network download.
The bottleneck in verification is also not signature checking but seeking for input referenced as the database grows.

Real remedies in my opinion are
1. pruning the database of spent transactions
2. containment of dust (e.g. mandatory or even predatory transaction fees on them or lower transaction fees for aggregation).

I updated so you can now redirect. Since it is a just a preview I will not invest more into it.

I will try to disable Ipv6 for IRC and not listen by default. The exception is because of the password at the beginning. I disable that too.


This is just a demo and it meant to demonstrate that it is doing a lot and fast.
I will let the log filtered to INFO at the console and write the rest into a file.
But its too late for me today...

I am not sure, since I saw this occasionally and could not yet find the reason. Try re-running, you might get an other IRC server assigned. IRC discovery sucks. I can not offer a quick fix there I am afraid. 

Did you try production leveldb that uses DNS discovery ?

I apologize that was not intentional. I uploaded a plain zip here:

ftp://bitsofproof.com/supernode.zip

It should not. Is it because of the location you try to install it ? If not I create an other one.

The version is superseded and the file mentioned below is no longer offered

I have an alpha quality preview for those curious of the supernode but do not like dealing with java.

You find a windows installer under ftp://bitsofproof.com/supernode-0.7-SNAPSHOT-setup.exe

You can download a plain zip of executable here
ftp://bitsofproof.com/supernode.zip

It is a compiled version of the original java code to native windows 32. It does not require you to install a java runtime.

The program does not do anything directly useful since it has no wallet. Should you figure it is still useful for some purpose, do not use it yet for real. It just downloads the chain and then validates and relays transactions. For production chain it validates and Merkle roots and proof of work until block 213900, therafter full validation of scripts. It does full validation from the beginning on testnet3.

Execute the installer and choose some empty new directory as target (without spaces in the path like "Program Files").
Once installed unzipped you may execute as:

1. production net with LevelDB. Data will be stored in a sub directory called data

2. production net with embedded relational db (derby) - data will be stored in a sub directory called derby

3. testnet3 in memdb - data remains in memory and starts over at every execution

It will ask for BCSAPI password at start. Just hit enter.

I am curious if the packaging works well on different machines and how you like it.