On Saturday, June 16, 2012 11:39:00 PM Gregory Maxwell wrote:
> On Sat, Jun 16, 2012 at 5:41 PM, Gavin Andresen
wrote:
> > RE: 0x06/0x07 'hybrid' public keys:
> >> Any opinions? Forbidding it certainly makes alternative implementation
> >> slightly easier in the future, but I'm not sure the hassl
On Sat, Jun 16, 2012 at 5:41 PM, Gavin Andresen wrote:
> RE: 0x06/0x07 'hybrid' public keys:
>
>> Any opinions? Forbidding it certainly makes alternative implementation
>> slightly easier in the future, but I'm not sure the hassle of a network
>> rule change is worth it.
>
> I say treat any transa
RE: 0x06/0x07 'hybrid' public keys:
> Any opinions? Forbidding it certainly makes alternative implementation
> slightly easier in the future, but I'm not sure the hassle of a network
> rule change is worth it.
I say treat any transactions that use them as 'non-standard' -- don't
relay/mine them b
Hello all,
while OpenSSL's silent support for compressed public keys allowed us to
enable them in a fully backward-compatible way, it seems OpenSSL supports yet
another (and non-standard, and apparently useless) encoding for public keys.
As these are supported by (almost all?) fully validating cl
On Saturday 16 Jun 2012 09:42:21 Wladimir wrote:
> Which is a perfectly reasonable requirement. However, one could simply
> standardize what a 'thin client' and what a 'thick client' does and
> offers (at a certain version level), without having to explicitly
> enumerate everything over the protoc
> I'm just afraid that the currently simple P2P protocol will turn into a
zoo of complicated (and potentially buggy/insecure) interactions.
This is my biggest fear too. I would rather be extremely conservative in making
any changes to the protocol unless absolutely needed. That includes the bl
On Sat, Jun 16, 2012 at 10:16 AM, Andy Parkins wrote:
>
> It's less of a problem in a (nearly) stateless protocol like Bitcoin.
>
It's currently (nearly) stateless, however it would be short-sighted to
think it will stay that way. State is being introduced as we speak; for
example, connection-spe
Joseph is quite accommodating and doesn't want to hurt the network.
That said "asking him to stop" seems like the worst possible solution
possible. His site is quite reasonable.
I think if I fix bitcoinj to have smarter fee code he might stop
attaching a small fee to every TX, but I'm not sure.
O
> I'd much rather have an overloaded node respond with 50% fp rate filters
> as an option if there aren't many full nodes available than simply
> disconnect SPV clients.
I don't think the bloom filter settings have any impact on server-side
load ... a node still has to check every transaction agai
The bottleneck for the android Bitcoin Wallet app is rapidly becoming
bandwidth and parse time.
On Fri, Jun 15, 2012 at 8:42 PM, Amir Taaki wrote:
> Why though? The bottleneck is not network traffic but disk space
> usage/blockchain validation time.
>
>
>
> - Original Message -
> From: M
On Saturday 16 Jun 2012 02:34:53 Amir Taaki wrote:
> Introspection/command discovery is nice, but I would prefer it to be
> immediately done in the first version exchange so no assumptions as to
> how a network is operating need to be made.
That would need a change of the current version message.
On Saturday 16 Jun 2012 07:45:00 Wladimir wrote:
> As replied on the github issue:
>
> Personally I still think it's better to have a clear standardized
> "protocol version", that implies what capabilities are supported,
> instead of a capability-based system that explicitly lists them.
>
> Capab
[resend, sorry gavin]
I think these ideas all make a ton of sense, some have been floating
around for a while in various forms but it's good to draw them
together coherently.
> o Fill up the "free" space (if any) with the highest-priority
> transactions, where priority is a function of transactio
On Fri, Jun 15, 2012 at 10:55 PM, grarpamp wrote:
> While happily processing these:
> received block ...
> SetBestChain: new best=... height=... work=...
> ProcessBlock: ACCEPTED
>
> bitcoind very often refuses to answer rpc queries such as getinfo/stop,
> or signals such as kill/ctrl-c. It eve
14 matches
Mail list logo
