I've posted a somewhat blue-skies idea on troll^wBitcointalk that some
here might find interesting:
https://bitcointalk.org/index.php?topic=277389.0
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/18/13 8:09 PM, John Dillon wrote:
> On the other hand, a tx with some txin proofs can be safely relayed by SPV
> nodes, an interesting concept. Do the UTXO commitment people have
keeping proof
> size small in mind?
More than a kilobyte, probably
My apologies, that was for Peter
On Mon, Aug 19, 2013 at 5:00 AM, John Dillon
wrote:
> -BEGIN PGP MESSAGE-
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> hQEMA8xUMVQPvvGFAQf9HL/SN/TZNQuVAjz5ggDzVzpYEzLRkFlgTR2lPURaR28F
> G0SgcvJmt1cvucxZRxzSUDCx58Ub16dzx9IBKQ+GDDUXbHGqExfbeIFx96okNsSm
> GmRRyOR
-BEGIN PGP MESSAGE-
Version: GnuPG v1.4.11 (GNU/Linux)
hQEMA8xUMVQPvvGFAQf9HL/SN/TZNQuVAjz5ggDzVzpYEzLRkFlgTR2lPURaR28F
G0SgcvJmt1cvucxZRxzSUDCx58Ub16dzx9IBKQ+GDDUXbHGqExfbeIFx96okNsSm
GmRRyORm+L7rdpQ3G8HcfKr1R9YufgaAjsa05eXlXl+fgpYrSBgitY6T3IZ9c0Z7
eF6yjogj5iaDUP2m7xLmRyaQvT/0GdRYk+c2JOH0
On Mon, Aug 19, 2013 at 03:09:07AM +, John Dillon wrote:
> That is good too.
>
> I'll bounty 2.5BTC to implement the first attack, and 0.5BTC for the second.
> Should be easy to do as a patch to satoshi bitcoin I think. The implementation
> must include a RFC3514 compliant service bit to let p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, Aug 16, 2013 at 2:15 PM, Peter Todd wrote:
> On Fri, Aug 16, 2013 at 10:01:16AM -0400, Peter Todd wrote:
>> Doing this also makes it more difficult to sybil the network - for
>> instance right now you can create "SPV honeypots" that allow in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, Aug 19, 2013 at 12:59 AM, Gavin Andresen
wrote:
> Peter said:
> "In any case given that SPV peers don't contribute back to the network
> they should obviously be heavily deprioritized and served only with
> whatever resources a node has spar
On Mon, Aug 19, 2013 at 10:59:18AM +1000, Gavin Andresen wrote:
> Peter said:
> "In any case given that SPV peers don't contribute back to the network
> they should obviously be heavily deprioritized and served only with
> whatever resources a node has spare."
>
> This seems very much like a "cut
Peter said:
"In any case given that SPV peers don't contribute back to the network
they should obviously be heavily deprioritized and served only with
whatever resources a node has spare."
This seems very much like a "cut off your nose to spite your face" solution.
SPV peers are INCREDIBLY IMPORT
Did some tests with a varient of attack... In short it's fairly easy to
saturate a node's disk IO bandwidth and when that happens the node
quickly falls behind in consensus, not to mention becomes useless to
it's peers. Note that the particular varient I tried is different, and
less efficient in ba
On Mon, Aug 19, 2013 at 08:22:10AM +1000, Gavin Andresen wrote:
> Mike pointed out exactly the reason I oppose a NODE_BLOOM service bit: I
> also think it is a bad idea to start making various bits and pieces of the
> protocol optional.
> It is bad for privacy (easier to fingerprint nodes) and bad
On Mon, Aug 19, 2013 at 12:00:23AM +0200, Mike Hearn wrote:
> The original Bloom filtering spec did not make this feature optional for
> the same reason gzip isn't an optional part of the PNG specification. I see
> no reason to revisit that. It's definitely not the case that making every
> possible
Mike pointed out exactly the reason I oppose a NODE_BLOOM service bit: I
also think it is a bad idea to start making various bits and pieces of the
protocol optional.
It is bad for privacy (easier to fingerprint nodes) and bad for
decentralization (fewer nodes support your required feature set). A
The original Bloom filtering spec did not make this feature optional for
the same reason gzip isn't an optional part of the PNG specification. I see
no reason to revisit that. It's definitely not the case that making every
possible feature optional is smart design, often it's the opposite.
If in f
14 matches
Mail list logo
