I've been thinking about the benefits or drawbacks of users connecting directly to miners.
Casascius Instant Partial Confirmation proposes a method where users can locate miners by addresses published on blocks.
These addresses could be normal IP, Tor addresses or whatever system each miner chooses to be located.

Currently the P2P network serves two purposes:

1. Send transactions from users to miners
2. Send blocks from miners to users.

These two transports are coupled together now but this may not be the best idea. One can imagine that users could connect directly to miners to send the transactions and the P2P network is only used to broadcasts blocks. Users willing to send a tx would choose a random sample of K miners of the last X blocks, possibly weighed by network hash power percentage. Then send the tx only to those miners.

The benefits/drawbacks would be:

- PRO. Less than half the network bandwidth usage (also users never see txs that never got into a block because of low fees)
- PRO. Less than half the CPU usage in clients (not true on v0.6.3+)
- PRO. P2P network less susceptible to DoS by spamming.
- PRO. Less memory usage for client application (no need for Tx cache, Sig chache, Orphan Tx cache, etc.)
- PRO. Huge simplification in client application

- CON. No 0-confirmations for transactions (at least not in the way it's done today)
- CON. Miners have to find there own methods to prevent DoS attacks to their servers.
- CON. Miners are less anonymous (but they are not completely anonymous in Bitcoin anyway)
- CON. New miners must publish empty blocks until they are known by the network.


Migrating from the current system gradually would be very easy by:

- adding the possibility to connect directly to miners
- reducing the incentive of users to broadcast the tx using the P2P network by reducing the bandwidth available for tx exchange.

What do you think?

Best regards,  Sergio.

[APPECoin]

passerby, and other users and some people that visited my blog post (http://bitslog.wordpress.com/2011/09/17/total-anonymization-vs-bitcoin-pseudonymous/) have asked me how a peer to peer system with total anonymization may actually work.

Since I have very little time to finish the paper now I will publish the key design points. The system is called APPECoin (Anonymous Peer-to-Peer electronic Coin). Anonymization is based on these premises:

1) Untraceable tokens: When user A sends a token X to user B, he just publish the fact in a signed transaction, as in Bitcoin. The miners, at periodic intervals, shuffle all (or a sub-set of) the existent tokens by re-encryption. The shuffle protocol (and encryption algorithm) has a designed "backdoor" so each owner knows exactly which are the re-encryption tokens of his own original tokens, but not the tokens from the other users. Miners shuffle are proven by Zero knowledge proofs, so no token can be added or removed by the miner. After shuffles, all token identifiers change, but still no cheating can occur. A user can have a high confidence his tokens have been anonymized after several rounds of shuffles (like confirmations) and the shuffling by at least one honest miner.

Suppose that after the shuffle, token X is now token Y. If B sends the token Y (ex-X) to C, then nobody knows that is the same token X that was given by A.

2) Unlikeable user accounts:  Destinations addresses are re-encyrpted in each transaction (a crypto masking) so when A sends a token to B, nobody knows he is using B's public key, but still B can identify he is the destination of the transaction and accept the token.

3) Private transaction amounts: The value hidden in each token in the network is unknown until you receive the token and open it. Only tokens created by coinbase have publicly known value, until they are shuffled for the first time.

4) Private account balances: You cannot group tokens by signature address, nor you can infer how much money or how many tokens a certain user has. Tokens can be divided or combined by a special transaction without disclosing the tokens amounts (division/combination is done using Zero knowledge proofs). You can re-combine tokens securely so you have enough "change".
 
The system uses an accounting system similar to the txout tracing system that Bitcoin use. Also users can shuffle their own tokens securely publishing a ZNP or use a shuffling service, as in Bitcoin. The advantage is that, as amounts are unknown, the shuffling service leaks very few information about the permutation.

Nevertheless there are a few disadvantages of the system:

- In the long term transaction fees will be higher than in Bitcoin, since messages tend to be larger and the system demands more CPU from nodes to verify miners shuffles.

- As a result, the maximum transaction rate could be lower than in Bitcoin. This is not necessary so, because many other factors alter transaction rate, such as the performance of the signature algorithm chosen.

These design key points [not the full design] were also published in my blog (http://bitslog.wordpress.com/2012/07/27/appecoin-anonymous-peer-to-peer-electronic-coin-design/)

Best regards,
 Sergio.

PS: If you like APPECoin and want me to keep on working it, I accept donations or funding, since I don't have much spare time now!

I want to describe a new P2P protocol I´m implementing for an alternate cryptocoin as a proof of concept.

The protocol allows cross-coin p2p trading without a central point. It seems to me that it is the "holly grail" of alternate crypto coins. And this is an idea that can change the cryptocoin ecosystem for good, where all coins trade against each other. The benefit for alternate chains is enormous: they don´t need to provide an exchange site, they can trade automatically against Bitcoin. It also means that alternate cryptocoins will rely on Bitcoin and will support Bitcoin because they need  it to enter the cryptocurrency game.


This is short explanation:

Suppose that there are two crypto-coins, XC and BTC. Each coin XC and BTC has its own blockchain and client. The user A has some XC and want to buy some BTC in return. User B wants the opposite. First both parties find each other (in a central directory or by a P2P protocol) and fix the trade price (A pays "a" XC and B pays "b" BTC back). There are two payments A->B (in XC) and B->A (in BTC). We well call these payments first and second payment, respectively. Both users have an address in the XC system and an address in the Bitcoin system.

The protocol works as follows:

1. User A commits to the first payment of "a" XC to the address of user B in the system XC. This is a special payment with a "contract" that is automatically allowed if a certain "proof" is published as a special transaction in a limited interval after the publication.

2. User B sends b BTC to A via Bitcoin in a standard way. This is the second payment.

The contract specifies that a piece of the Bitcoin blockchain (a branch) should be copied into a special transaction called "proof" into the XC blockchain to prove the second payment has actually taken place.

The contract also specifies:

• The chain branch size (N). This is how much effort in terms of confirmations (PoW) must be added after the block where the second payment is published.
• The hash of the block where the branch should start (root block). The root block should be chosen to be some blocks in the past to avoid choosing a block that will be discarded by a competing branch. For example, if current block is BLK and the previous block of BLK is Prev(BLK), parties can choose a root in Prev^3(BLK) with a length of at least 9 blocks (6 confirmations after current block)
• The maximum number of blocks after the root block where the second payment can appear. This is to prevent the payment being done just after the XC contract interval has expired, thus making the trade one-way only.

3. When the proof transaction (that matches the contract) is published in an XC block, clients automatically accept the first payment (that specifies the contract), thus paying "a" XC from A to B.

Notes:

1) Not the full Bitcoin blockchain branch needs to be included in the XC blockchain. Only the headers of the N blocks, the Merkel branch that proves the existence of the second payment and the transaction of the second payment. Generally less than 800 bytes are required for the full  "proof".

2) All this protocol works transparently. The user only setups maximum/minimum trade prices and trade quantities.

3) Generally B is the most interested that the "proof" is published, but if B doesn´t do it  (and the second payment was done) then A itself can publish the proof.

4) The "proof" is included in a block as a normal transaction and can pay a fee to the miner, but the minimum fee is specified in the contract. Both parties should take care of specifying fees that allow the transactions to be selected by the miners to be included in a block. If the fee is not enough, a higher fee can be specified when the proof is sent. It is recommended that the fee for the miner of the "proof" be much higher than normal fees to give a strong incentive to miners to include this transaction in all competing blocks.

5) The security of the system is relies on the premise that no party can build a blockchain branch longer and faster than the "global" branch in a limited interval (e.g. 20 blocks). Also the proof cannot be constructed in advance, since the root block (which is almost the current block) is specified in the contract.

6) If the trade fails because the interval has elapsed and the second payment was not done, the first payment is canceled.

7) The coins committed in the first payment cannot be used until the contract is canceled or it is accepted.

I have a proof of concept of this protocol working. I will release the code when it's ready. The system is implemented in a way to understand contracts for all other alternate currencies and unknown ones. The user specifies a "template"  for the second payment message, with placeholders for the fields that are unknown (the transaction signature) and fixed values for the remaining fields (amount of money, public key of recipient,etc.). And also a template for the block format (field of linkage, hash algorithm, etc.).

Best regards,
 Sergio.

PS: I named the protocol P2PTradeX, because there was no result when I googled that word.

The supposed "Provably Fair Shuffling Through Cryptography" https://techblog.bitzino.com/2012-06-30-provably-fair-shuffling-through-cryptography.html leaves much to be desired to be called "Provably fair".

These are only a few reasons:

(1) Client_seed is not big enough (32 bits) to assure a fair statistical distribution. The server can try each possibility in advance...

(2) The server knows the shuffled deck (every card) BEFORE the user, so the server can abort the game (showing any strange error message) if the deck is too good for the user.

(3) Last but not least, the site is HTML5 only (no open source client application), so there is no way to know if the client-side javaScript code is actually verifying anything !!!

(4) Where is the "proof" for the "Provably Fair" algorithm?

The only way to implement secure card games on the Internet is by using Mental Poker protocols (crypto newbies, check it on Wikipedia). And it happens that I designed the fastest MP protocol so far... humbly 


Best regards,
 Sergio.

I want to analyze how a block with merged mining looks like. I've read that dumb transactions are used for merged mining, and that those transactions transfer 0 BTC from an address to a hash for the alternate chain block. But I've never actually seen such a transaction in a block.

Blockexplorer.com has a service to search for nonstandard transactions, but it is unavailable at this moment.

Can anyone post the block number of a block that has merged mining ? With the block number I can dump the block with the tools at Blockexplorer.com or blockchain.info.

Best regards,
Sergio.

It has been said that double hashing in the PoW of the blocks serves to prevent hash extension attacks. This has been refuted: that attack does not make any harm because the hash preimage is public.

Today I realize that there is another reason why double hashing can be useful.

Double hashing can be used to prove that one have a block with certain PoW, before sending the whole header to a peer.

Suppose that H=Hash(W) and W=Hash(Block-header).

We want that blocks travel as fast as they can through the network to reduce the chances of the creation of parallel chains.
The Bitcoin block header size is generally 81 bytes, so each peer must receive at least 81 bytes in order decide if the block will be accepted, and forward it.
But if a node firsts sends only W, then the peer can compute H'=Hash(W) and conclude immediately that a lot of work has been put in order to build W. So the peer can immediately stop what is doing (downloading/uploading transactions) and set maximum priority to receive the block whose header hashes to W and resend it to its peers.

I know that it's not much that is gained (32 bytes instead of 81), but at least that is an use for the double hash.
 
Best regards,
S

There are so many threads that the Development forum does not serve as an information source for past discussions.
The same questions and suggestions reappear as older threads are hidden in the forum pages.

Could the forum administrator reorganize the forum in sub-folders to allow old threads become visible and accessible.

I offer my help to do the classification job.

Best regards

I´ve dedicated some time to research Bitcoin security and resiliency and I´m investigating some possible attacks and corresponding patches. The problem is that I cannot use more of my work time for the project, since I must earn my living. Since I really would like to go forward with this research, It would be great if the community (the developers, the exchanges, all of us) could donate bitcoins to create vulnerability bounties. This would give an incentive for researchers like me to leave out other tasks and focus on Bitcoin. Also bounties would reduce the risk that vulnerabilities are sold in black markets.

For example, we could give bounties (sorted by severity) for:

1. Remote code execution
2. Stealing money by exploiting bugs using specialty crafted transactions/blocks.
3. Low cost Denial of Service of the whole Bitcoin network
4. Lost of privacy / pseudo-anonymity.

In the first 3 cases people should immediately download a new client version to allow the network to keep running.

I think we won´t find many vulnerabilities of type 1-2 but we might find many vulnerabilities of type 3-4. A vulnerability of type 3 may render Bitcoin out of reach for days, and this would cost exchangers (and most of us) a lot of money.

What do you think?

Best regards,
 Sergio.

Some time ago I watched the video "28c3: Bitcoin - An Analysis" by Hamacher, & Katzenbeisse that, among other things, suggests Bitcoin is "doomed to vanish" because of the number of lost coins per year. (see http://www.youtube.com/watch?v=hlWyTqL1hFA).

Lost coins are inaccessible unspent transactions because scriptPubKey is invalid or because the owner of the related private key lost the key.

The video proposal is to give back the lost coins to the community. There is a a simple way to do it: every year (at a certain point, using the block number as index) all coins that were not transferred for the last 5 years are returned to a miners prize pool. The prize pool is divided in equally sized shares and for that year each block mined has an additional price of one share.

With this scheme, every user who owns bitcoins and want to keep them should, every 5 years, transfer the money to another of his addresses.

A 5 year interval does not hurt people using Bitcoins for lifetime savings, and gives enough time to those people to be notified of the change in the protocol.

What do you think?

Regards, Sergio.

I'm trying to build a model of the Bitcoin network to analyze the effect of block chain competitions on the current state of Bitcoin and versions with reduced block interval. The objective is to publish a paper on the resilience of the network and estimate the probability of a sustained block chain competition

I need to figure out:

1. What is the diameter of the Bitcoin network?

2. How much time it takes a Bitcoin mined block to propagate to every node?

3. How much time it takes a single node to broadcast a block after it has received it?

4. What is the strategy of nodes and miners in the presence of competing chains? Do they abort and switch to the longer chain?

5. How many nodes are connected by each node by default ?

Can anyone help with any of these items?

Sergio.

How?

Check out the papers

http://bitslog.wordpress.com/2012/04/16/mavepay-a-new-lightweight-payment-scheme-for-peer-to-peer-currency-networks/

and

http://bitslog.wordpress.com/2012/04/09/mave-digital-signature-protocol-for-massive-bulk-verifications/

Buy the new MAVEPAY P2P currency at a discount and be the first to own some mavecoins ! (this is a joke)

Disclaimer: I did it.
Apologies: I created a new thread because last thread title wasn't helping spread the curiosity.

Best regards,
 Sergio.

As I promised in the thread about Poker, here is the preliminary version of my paper on new digital signature protocols suitable for Bitcoin-like networks.

I've posted the MAVE paper on my blog:
http://bitslog.wordpress.com/2012/04/09/mave-digital-signature-protocol-for-massive-bulk-verifications/

Another paper (HBOW) with notes of how to properly implement MAVE for a p2p cryptocurrency is coming soon.

Please read it, comment it and give feedback.

Thanks.
 Sergio.