On Thu, Jul 17, 2014 at 2:35 PM, Kaz Wesley wrote:
> A node should be able to forget invs it has seen without invalidating what
> peers
> know about its known txes. To allow for this, a node assembles a bloom
> filter of
Another option would be to just guarantee to keep at least the last N
sent i
I'm moving this design document to a gist so that I can integrate
changes as they come up:
https://gist.github.com/kazcw/43c97d3924326beca87d
One thing that I think is an important improvement over my initial
idea is that the bloom filters don't need to be kept around and built
up, they can just be
A couple of half-baked thoughts:
On Thu, Jul 17, 2014 at 5:35 PM, Kaz Wesley wrote:
> If there's support for this proposal, I can begin working on the specific
> implementation details, such as the bloom filters, message format, and
> capability advertisment, and draft a BIP once I have a concre
OVERVIEW
To improve block propagation, add a new block message that doesn't include
transactions the peer is known to have. The message must never require an
additional round trip due to any transactions the peer doesn't have, but
should
be compatible with peers sometimes forgetting transactions t
On Wed, Jul 16, 2014 at 10:56 AM, Jeremy wrote:
> Hey all,
> I had an idea for a new transaction type. The base idea is that it is
> matching on script hashes much like pay to script hash, but checks for one
> of N scripts.
This seems strictly less flexible and efficient than the Merkelized
Abstr
* the general cost of any network-wide change, versus P2SH which is
already analyzed by devs, rolled out and working
* the cost of updating everybody to relay this new transaction type,
whereas P2SH Just Works already
fair -- I think that there may be a big benefit realizable with this kind
of syst
On Thu, Jul 17, 2014 at 6:14 PM, Jeff Garzik wrote:
> Historical note: On one hand, Satoshi seemed to dislike the early
> emergence of GPU mining pools quite a bit.
>
To my knowledge, Satoshi left the project before mining pools got a
traction.
slush
---
On Thu, Jul 17, 2014 at 09:35:20AM -0400, Mark Friedenbach wrote:
> Can someone explain to these guys and the public why promising to limit
> yourselves to *only* a 50% chance of successfully double-spending a 6
> confirm transaction is still not acceptable?
Hi, Mark.
We were asked on the bitcoin
Define acceptable. The 40% thing is marketing and a temporary
solution. And people come down on both sides of whether or not
marketing "40%" is a good idea.
I think it is a baby step that is moving in the right direction. You
want the numbers and sentiment moving in that direction (down, versus
Can someone explain to these guys and the public why promising to limit
yourselves to *only* a 50% chance of successfully double-spending a 6
confirm transaction is still not acceptable?
q=0.4
z=0 P=1
z=1 P=0.828861
z=2 P=0.736403
z=3 P=0.664168
z=4 P=0.603401
z=5 P=0.55062
Here is a good article that helped me with what's going wrong:
http://www.oracle.com/technetwork/articles/javase/supplementary-142654.html
Basically, Java is stuck at 16 bits per char due to legacy reasons. They
admit that for a new language, they would probably use 32 (or 24?) bits
per char.
\u
I noticed this article today.
GHash Commits to 40% Hashrate Cap at Bitcoin Mining Summit
http://www.coindesk.com/ghash-commits-40-hashrate-cap-bitcoin-mining-summit/
Here's a quote from Satoshi when the mining arms race began:
"We should have a gentleman’s agreement to postpone the GPU arms rac
Glad we got to the bottom of that. That's quite a nasty compiler/language
bug I must say. Not even a warning. Still, python crashes when trying to
print the name of a null character. It wouldn't surprise me if there are
other weird issues lurking. Would definitely sleep better with a more
restricte
13 matches
Mail list logo
