Re: [Bitcoin-development] Protocol extensions

not to trust a particular node. --Zell Faze --- On Thu, 12/22/11, Andy Parkins wrote: > From: Andy Parkins > Subject: Re: [Bitcoin-development] Protocol extensions > To: "Joel Joonatan Kaartinen" > Cc: bitcoin-development@lists.sourceforge.net > Date: Thursday, December

Re: [Bitcoin-development] Protocol extensions

On 2011 December 22 Thursday, Joel Joonatan Kaartinen wrote: > On Thu, 2011-12-22 at 11:52 +, Andy Parkins wrote: > > Why should they have to? Joining the network as a node is very low cost > > to the other nodes. You can't force any node not to be lazy, since > > their option is to disconnec

Re: [Bitcoin-development] Protocol extensions

Just adding to Joels comment: The only one with an incentive to do validations are miners (otherwise they could risk having their mined blocks invalidated later by less lazy miners) and the ones who are to send and accept a transaction. In a distributed stored and validated block chain setup, y

Re: [Bitcoin-development] Protocol extensions

At first the idea of using negative announces seems attractive, but remember that a malicious node might trigger verification for every transaction, which may lead to a DoS. Regards, Chris On Thu, Dec 22, 2011 at 1:14 PM, Joel Joonatan Kaartinen < joel.kaarti...@gmail.com> wrote: > On Thu, 2011-

Re: [Bitcoin-development] Protocol extensions

On Thu, 2011-12-22 at 11:52 +, Andy Parkins wrote: > Why should they have to? Joining the network as a node is very low cost to > the other nodes. You can't force any node not to be lazy, since their option > is to disconnect themselves. As to maliciousness, that is defended against > bec

Re: [Bitcoin-development] Protocol extensions

On 2011 December 22 Thursday, Michael Grønager wrote: > But, there is in fact a subtle difference: If anyone can choose to verify > at random, you will see lazy implementations where random means none, and > as it is random you cannot, from the outside, judge if a node is taking > part in the vali

Re: [Bitcoin-development] Protocol extensions

It is analog to getting assigned a random part (based on IP) of the hashspace and then only verify transactions within this fraction. But, there is in fact a subtle difference: If anyone can choose to verify at random, you will see lazy implementations where random means none, and as it is rand

Re: [Bitcoin-development] Protocol extensions

On 2011 December 21 Wednesday, Christian Decker wrote: > Supernodes will be those nodes that verify all transactions and make them > available to miners. Since miners will become more and more specialized > these supernodes are likely to be owned by the miners themself. To be a > miner either you

Re: [Bitcoin-development] Protocol extensions

Agree, but even before that, we will meet problems of the current 1MB/10min limit. The calculations from the scalability link surely indicates that there are 2 options for scalability either go for trusted supernodes backed by huge hardware resources or something else would be needed. The super

Re: [Bitcoin-development] Protocol extensions

I think it would be a lot more than that. According to the Scalability page (https://en.bitcoin.it/wiki/Scalability) if Bitcoin took over all credit card transactions, that would be about 1.14GB per block. I believe that is 58.5PB per year. (6*24*365*1.14/1024) This would also mean the distribu

Re: [Bitcoin-development] Protocol extensions

I find it likely that we will at some point have supernodes. If we have browser based wallets then the server for these automatically becomes supernodes. Further, if we move along that direction, it becomes much simpler to use both the scheme I proposed or to use a a lot of other schemes for sha

Re: [Bitcoin-development] Protocol extensions

Is it just me or does it seem inevitable that at some point supernodes will emerge that other nodes trust to validate transactions for them? Supernodes needn't even store the entire block chain and transaction pool...it would be sufficient that they keep lists of IP addresses of other trustworthy n

Re: [Bitcoin-development] Protocol extensions

DHTs and Bitcoin: First, lets define the problem we want to solve: scalability - when bitcoin takes over all credit card transactions (!), and even before that, we will meet a scalability problem. The blockchain will grow rapidly, (1MB/10min or 50GB/yr) and we will constantly have transactions

Re: [Bitcoin-development] Protocol extensions

There are other issues besides IP address anonymization that would need to be addressed. I'm sure at least a good number of you have read http://arxiv.org/abs/1107.4524 and have seen Dan Kaminsky's slideshows. i.e. all fund aggregations (transactions with multiple inputs using different public key

Re: [Bitcoin-development] Protocol extensions

> Developers could even choose to integrate Tor functionality into the > client itself at some point. > The "satoshi" bitcoin client already supports use over TOR with the proxy option - I think this was something Satoshi made regular use of. ---

Re: [Bitcoin-development] Protocol extensions

On Tue, 20 Dec 2011 10:10:23 +0100 Wladimir wrote: > Probably would need to package the block chain with it, as downloading that > over Tor takes ages and causes unnecessary load on the network... I actually started a freenet plugin for blockchain distribution in summer (first rough steps only)

Re: [Bitcoin-development] Protocol extensions

On Mon, Dec 19, 2011 at 10:43 PM, Jordan Mack wrote: > On 12/18/2011 1:19 PM, Stefan Thomas wrote: > > Let those who want anonymity connect through Tor, Freenet, etc. It's > > easy to add anonymity via an extra layer, but it is impossible to add > > performance on top of a slow system. > > That

Re: [Bitcoin-development] Protocol extensions

On 12/18/2011 1:19 PM, Stefan Thomas wrote: > Let those who want anonymity connect through Tor, Freenet, etc. It's > easy to add anonymity via an extra layer, but it is impossible to add > performance on top of a slow system. That's a very good point. This is needless complication at the protoc

Re: [Bitcoin-development] Protocol extensions

Hey Chris, The storage would be distributed, messages are routed on behalf of others, which makes finding the origin of the query hard to find (think Tor) This type of intermediate routing makes Tor slow . Bitcoin

Re: [Bitcoin-development] Protocol extensions

2011/12/17, theymos : > My preferred solution for handling scalability in the future is to > have lightweight clients download only headers and Merkle trees (which > are both small and easy to distribute), and then require senders to > contact recipients directly in order to transmit their transact

Re: [Bitcoin-development] Protocol extensions

bitcoin-development@lists.sourceforge.net Sent: Sunday, December 18, 2011 6:06 PM Subject: Re: [Bitcoin-development] Protocol extensions The whole point of having headers built at a constant size and generation rate is to minimize the amount of data needed to "understand" of the blockchain w

Re: [Bitcoin-development] Protocol extensions

The whole point of having headers built at a constant size and generation rate is to minimize the amount of data needed to "understand" of the blockchain while simultaneously maximizing integrity/security in the presence of untrusted nodes. Barring the 50%-attack, you only need a couple honest

Re: [Bitcoin-development] Protocol extensions

On Sat, Dec 17, 2011, at 05:27 PM, Jordan Mack wrote: > I don't like the idea of a header only client, unless this is just an > interim action until the full block chain is downloaded in the > background. Development of these types of clients is probably > inevitable, but I believe that this breaks

Re: [Bitcoin-development] Protocol extensions

On Sunday 18 Dec 2011 01:27:10 Jordan Mack wrote: > I don't like the idea of a header only client, unless this is just an > interim action until the full block chain is downloaded in the > background. Development of these types of clients is probably > inevitable, but I believe that this breaks th

Re: [Bitcoin-development] Protocol extensions

On Sat, Dec 17, 2011 at 7:44 PM, Jordan Mack wrote: > While using DHT for storage of the block chain is an intriguing concept, > I do not see how it is feasible. As Gavin noted, DHT is a system that is > difficult to impossible to guarantee against data loss or manipulation. > > Even if we found a

Re: [Bitcoin-development] Protocol extensions

theymos' full node and lite node write up got me thinking. There are two problems here that we are trying to solve: - The scalability of broadcast messages. - The resources required to sync and verify the block chain. I see three distinct groups of clients: - Miners (dedicated servers & desktops)

Re: [Bitcoin-development] Protocol extensions

While using DHT for storage of the block chain is an intriguing concept, I do not see how it is feasible. As Gavin noted, DHT is a system that is difficult to impossible to guarantee against data loss or manipulation. Even if we found a way to store the block chain in DHT, how would transaction

Re: [Bitcoin-development] Protocol extensions

On Sat, Dec 17, 2011, at 02:06 PM, Gavin Andresen wrote: > Although I do also wonder if we'll ever run into a problem with full > nodes refusing to answer requests from lightweight nodes (there might > be a tragedy-of-the-commons problem lurking there). This seems likely. Also, even if many full n

Re: [Bitcoin-development] Protocol extensions

Criticism accepted, although I'd appreciate it if you supply some reasons about why it's such a bad idea :-) The idea was never really popular and before starting work on a real implementation I wanted to test the water, and should it turn out it's complete non-sense I'm happy to accept that. I do

Re: [Bitcoin-development] Protocol extensions

On Sat, Dec 17, 2011 at 8:37 AM, Christian Decker wrote: > My idea was to structure the network in a hypercube and use prefixes to > address different parts of the network, and use those prefixes also to find > the location where an item (transaction, block, ...) should be stored. Each > vertex in

[Bitcoin-development] Protocol extensions

There was a discussion about using DHT's for transactions a while back on the forums:  https://bitcointalk.org/index.php?topic=723.msg7908#msg7908 If you can figure out a scheme that is secure from malicious Sybil attacks then you're smarter than I am. And additional protocol messages for lightwe

Re: [Bitcoin-development] Protocol extensions

A while back I had proposed a similar idea to the DHT, although my main goal was to reduce the need for broadcasts. My idea was to structure the network in a hypercube and use prefixes to address different parts of the network, and use those prefixes also to find the location where an item (transa

Re: [Bitcoin-development] Protocol extensions

Hey Eric, Two comments. 1. The ability to query for transactions belonging to pubkeys or bitcoin addresses is supported today by several implementations: * blockexplorer.com * bitcoin-js * my own libBTC (will more on this soon) To query for transactions you need to use json-rpc and not the bitc

[Bitcoin-development] Protocol extensions

Hey, guys. I haven't posted here before so I'll introduce myself. My name's Eric, I've been developing cryptocurrency-related software for several months now, I've implemented some libraries for dealing with core bitcoin datastructures, made some custom builds of bitcoind and interfaced it with a