WOW Way to burn your biggest adopters who put your transactions into the
chain...what a douche.
From: Mike Hearnmailto:m...@plan99.net
Sent: 1/06/2015 8:15 PM
To: Alex Mizrahimailto:alex.mizr...@gmail.com
Cc: Bitcoin
Nah don't make blocks 20mb, then you are slowing down block propagation and
blowing out conf tikes as a result. Just decrease the time it takes to make a
1mb block, then you still see the same propagation times today and just
increase the transaction throughput.
PM, Thy Shizzle thyshiz...@outlook.com
wrote:
Nah don't make blocks 20mb, then you are slowing down block propagation
and blowing out conf tikes as a result. Just decrease the time it takes to
make a 1mb block, then you still see the same propagation times today and
just increase
*
*This message was created with 100% recycled electrons. Please think twice
before printing.*
On Mon, May 25, 2015 at 9:30 PM, Thy Shizzle thyshiz...@outlook.com wrote:
Nah don't make blocks 20mb, then you are slowing down block propagation
and blowing out conf tikes as a result. Just decrease the time
Yes This!
So many people seem hung up on growing the block size! If gaining a higher tps
throughput is the main aim, I think that this proposition to speed up block
creation has merit!
Yes it will lead to an increase in the block chain still due to 1mb ~1 minute
instead of ~10 minute, but the
Nicolas, can you think if there would be a problem with allowing blocks to be
created faster instead of increasing block size? So say if difficulty was
reduced to allow block creation every 2 minutes instead of 10 minutes, can you
think of any bad outcome from this (I know this is different to
Zero conf :D
From: gabe appletonmailto:gapplet...@gmail.com
Sent: 16/04/2015 12:15 PM
To:
bitcoin-development@lists.sourceforge.netmailto:bitcoin-development@lists.sourceforge.net
Subject: [Bitcoin-development] Where do I start?
Background: I'm a CS student
If the IP discovery is your main motivation, why don't you introduce some onion
routing into transactions? That would solve this problem easily, of course
there is an overhead which will slightly slow down the relay of transactions
but not significantly, also make it an option not enforced, for
: Re: [Bitcoin-development] Address Expiration to Prevent Reuse
On Fri, Mar 27, 2015 at 1:51 AM, Thy Shizzle thyshiz...@outlook.com wrote:
Yes I agree, also there is talks about a government body I know of warming
to bitcoin by issuing addresses for use by a business and then all
transactions can
this kind of surveillance activity. But
I have a feeling that will be a different thread which is more
technical and so won't comment on it here, except to say it will
likely involve working toward giving the user an anonymity option
which can be exercised as part of any transaction.
Thy Shizzle
I don't believe that at all. Analyzing information publicly available is not
illegal. Chainalysis or whatever you call it would be likened to observing who
comes and feeds birds at the park everyday. You can sit in the park and observe
who feeds the birds, just as you can connect to the Bitcoin
implementations storing word lists of all words and
languages.
Thanks for clarifying,
-Neill.
On Thu, Mar 12, 2015 at 04:21:59AM +, Thy Shizzle wrote:
I agree that it's true that a static wordlist is
required once people have started using BIP39 for anything real and
changing the word lists
Yes apologies for the broken threading, it was the result of me auto forwarding
between mail providers etc.
To fix this issue I have created this new dedicated outlook account
(thyshiz...@outlook.com) that I shall use for all my subscriptions here and I
am unsubscribing the yahoo address. This
Strangely enough, it has started to work properly and I didn't even touch my
code just had it sitting there in the loop/ping circuit it was performing and
capturing with wireshark.that is quite odd!
Hi, so I have my .NET node communicating on the P2P network just fine, so I
figured as I'll
as I've shown, you can work a version into it, I was going to actually
propose it to the BIP39 authors but didn't think it was an issue.
I think BIP39 is fantastic.
I think Electrum 2.0 (And everyone) should use BIP39 On 2015-03-11 06:21 PM,
Thy Shizzle wrote:
H I don't think it's fair
That's disappointing the Electrum 2.0 doesn't use BIP39.
From my interpretation of BIP39, wordlists DO NOT REQUIRE to be fixed between
wallet providers. There is some recommendations regarding the wordlists to
help with things such as predictive text, so mobile apps can easily predict
the word
Yes I agree with this sentiment.
As for the version, don't forget we can kinda brute force our way to
determine a version, because lets say there is 10 versions, we can generate the
seed for all 10 versions and then check to see which seed was in use (has
transacted) and then use that seed. If
+, Thy Shizzle wrote:
That's disappointing the Electrum 2.0 doesn't use BIP39.
Agreed, but I don't know the full background on this.
Changing the wordlist in the future has ZERO effect on derived seed, whatever
mnemonic you provide will always generate the same seed, BIP39 is not mapping
Hi, so I have my .NET node communicating on the P2P network just fine, so I
figured as I'll now start looking at making and validating transactions etc I
should probably migrate to test net. Now I see that we are up to the third
generation testnet testnet3, and I am sending my messages now
Hi, so just a thought as my node relays addresses etc. If I wanted to really
slow down communication over the P2P network, what's stopping me from popping
up a heap of dummy nodes that do nothing more than exchange version and relay
addresses, except I send addr messages with all 1000
are kept for high performance. Defining
DEBUG_ADDRMAN will introduce frequent (and expensive) * consistency checks
for the entire data structure. */
On Wed, Mar 4, 2015 at 5:40 PM, Thy Shizzle thashizn...@yahoo.com.au wrote:
Hi, so just a thought as my node relays addresses etc. If I wanted
21 matches
Mail list logo
