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
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)
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
On Saturday, December 17, 2011 7:28:12 PM Luke-Jr wrote:
> On Saturday, December 17, 2011 6:46:34 PM Gregory Maxwell wrote:
> > Sorry to be curt— I'm a little irritated that discussion on recovery
> > in OP_EVAL was dropped because "input script size doesn't matter
> > because of pruning" and now p
On Saturday, December 17, 2011 6:46:34 PM Gregory Maxwell wrote:
> Sorry to be curt— I'm a little irritated that discussion on recovery
> in OP_EVAL was dropped because "input script size doesn't matter
> because of pruning" and now people are talking about adding another
> address type which creat
On Sat, Dec 17, 2011 at 4:52 PM, Luke-Jr wrote:
> I propose that full public key addresses be required to be "compact" (length
> 33), and use version 21 (begins with '4', and is redundant with ver 20 for 20-
> byte data). Any reason this wouldn't be workable?
Would introduce yet another address t
I propose that full public key addresses be required to be "compact" (length
33), and use version 21 (begins with '4', and is redundant with ver 20 for 20-
byte data). Any reason this wouldn't be workable?
--
Learn Window
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
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
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
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
While I think firstbits is an interesting idea, I agree with Matt on
this one. Firstbits, while being a clever idea, produces a less
desirable solution in comparison to the current alias proposals.
In addition to Matt's reasons, I would like to add that it is still a
block of random characters,
On Sat, 2011-12-17 at 12:14 +0100, Jorge Timón wrote:
> Don't know much about QR codes, but I thought they have a length limitation.
> Why jav wants to use not just addresses but firstbits then?
Under no circumstances should the use of firstbits ever be supported.
It doesn't scale, not even close,
I don't see reason why not. It could just be another, longer, address type.
The advantage being that it allows for shorter transactions in the block
chain (right?).
Wladimir
On Sat, Dec 17, 2011 at 7:32 AM, Luke-Jr wrote:
> IMO, we should standardize and support public key addresses. While not
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
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
Don't know much about QR codes, but I thought they have a length limitation.
Why jav wants to use not just addresses but firstbits then?
"Allow a field "green_address_list" (short "gal") to specify
acceptable addresses in Firstbit format directly in the QR code and
only use the "green_address_deta
17 matches
Mail list logo
