What do you mean? Undetected means the randomly corrupted address will be accepted. It could lead to a transaction to the wrong address.

This means that when 5 changed characters occur randomly distributed in the 39 characters of a P2WPKH address, there is a chance of 0.756 per billion that it will go undetected. When those 5 changes occur randomly within a 19-character window, that chance goes down to 0.093 per billion. As the number of errors goes up, the chance converges towards 1 in 230 = 0.931 per billion.

Interesting.  Using an isolated agent (such as gpg-agent) for Bitcoin signing would be a generally excellent idea, of course.

From your first link:


Right.  Though I make moderate use of some “pure Python” Bitcoin stuff, in the back of my mind, I always have the same worry.  IMO, crypto algorithms should be done reasonably “close to the metal”.  Does the Python interpreter have any behavior which opens side channels?  And in a related matter, don’t get me started on all the advice to “download bitaddress.org and burn it into a CD”, or the like.  Forget algorithm implementation side channels:  In Javascriptland, whence comes its randomness?  I peeked, and it’s not a pretty sight!

I do want to get Core’s secp256k1 running on all my systems.  Despite being plastered with warnings, “work in progress... research... Use at your own risk,” I trust it more (or distrust it less) than the vast heaps of junk out there.  I definitely trust it more than OpenSSL.  It was designed specifically for safety (as well as performance), “structured to facilitate review and analysis”, and made with an explicit design goal, “‘Be difficult to use insecurely.’”  I know the difference between a programmer and a cryptographer; and I am a programmer.  secp256k1 is exactly the kind of library I want.  I don’t want any coins lost to accident or malice!

There is also the matter of programming sanity.  Using OpenSSL, I don’t even know which context objects (if any) can be safely reused, and/or shared between threads.  The manpages do not mention such trifling concerns.  Core’s secp256k1 gives explicit instructions about this in the reasonably concise, copiously commented header which currently seems to serve as its documentation.  For my little “toy”, I am only generating keys; so I can initialize a context once, then reuse it a few billion times without reinitialization.

Core secp256k1’s README says, “Intended to be portable to any system with a C89 compiler and uint64_t support.”  Excellent!  I’ve poked around in the code; and I think the Autohell build requirement could be excised with relative ease.  But for the same aforestated reason, this is just not something I want to mess with.  (libbase58 is a different matter, plus a few orders of magnitude smaller and simpler; I should poke at it later.)

Please can someone accelerate this??

i promise i tip !

no, i'm talking about possibility to increase blocksize and keep decentralization (or even improve it a bit)

what i meant is:

miner who mined new block had added at the bottom sha256 of his transactions list for 2 blocks ahead, he sends out 2 packets:

    1st small packet consisting of 2 things: sha256 of his transactions list and solution for block

    2nd big packet of transactions for 2 blocks ahead

1st packet propagates very fast and since everyone was mining same transactions (passed from 2 blocks before) everyone can easily verify if solution is valid just with this 2 recieved information (they cannot yet verify if sha256 is correct, they trust it because proof of work)

2nd packet propagates slowly, but it has time since we are all working on next block and it propagates during that work (now they can verify sha256 of transactions list and list itself and if something is wrong go back to working on previous block)


i'm just not sure if i'm not making any mistake in reasoning, because my knowledge in matter is very limited
that's why i wanted to ask smarter people if it could work as a solution

as far as i know main problem with big blocks is propagation time, miners who recieve new block earlier get head start in competing for next block, pools can share new blocks faster among their miners further making this gap bigger, hence centralization, so i had this idea, but my knowledge is very basic and i can't seem to find a flaw in it, do you guys think it makes sense?

2-blocks shift:
if creator of block would send his transactions to be added to next after next block
and in his block include transactions passed from 2 blocks before
then after minting new block everyone on the network should already have list of transactions to be added in current block
only hash propagation would be needed to start working on current block
and transaction list for next block would be propagated during working on current block

using lightning sure its possible!

Following all the recent discussion about Segwit and Bech32, I felt the urge to have some fun.  I happily put together Core’s  secp256k1 and luke-jr’s libbase58 (plus sipa’s reference bech32) to whip up a trivial Segwit bulk address generator—which of course, just had to grow a simple regex bruteforce vanity function:


Pleased with my new toy, I grabbed my little C file plus its few dependencies, and catapaulted them to an airgap Unix machine.  It would be so nice to let it grind away on some spiffy long-term tip addresses.

No, wait:  secp256k1 and libbase58 both use autoreconf in their build systems.  Sigh.  Download GNU autoconf and its signature, load ’em into the catapault, and let fly across the airgap.  ./configure.  Easy, right?


Sigh.  So much for a way to relax and unwind.  My system has an M4, but not GNU M4.  More downloading.  Ready the catapault again.  It is running out of fuel—actually, it’s not a catapault:  It’s a magnetic railgun.  I take my airgap seriously.


At this point, I gave up and hacked together some ersatz—with OpenSSL’s[1] libcrypto, for secp256k1 and bignums (base58).  Of course, I still want to use Core’s code on machines which have autoreconf.  Thus now, my neat little C file is a mess of #ifdefs—plus a few ad hoc extern declarations to another C file, where I put my OpenSSL glue and my quicky little base58check encoder.

Then, I wrote a set of automatic runtime self-tests to make sure this bucket of bolts gives exactly the same observable behavior in both configurations.

So—is there any reasonable way to get this stuff built without autoreconf?  It’s an absurdly horrid “portability” fix, if it gives your project a build-time dependency on GNU M4, Perl (!!!), and who knows what hundred other packages in the spiralling dependency chain.  This would be inconvenient in ordinary circumstances.  It can be much worse for software expected to be used in a security-critical context, implying an airgapped machine with the minimum possible junk installed on it.  Seriously—I use the kernel’s virtual terminals there, because I reasonably distrust Xorg, window managers, toolkit libraries....  I was exaggerating about the railgun; I am not exaggerating about shell job control and my trusty old nvi.

Thanks for any reasonable[2] suggestions.

---

1. Yes, I know that OpenSSL’s build system directly uses Perl.  My platform’s distributor runs all that Perl stuff as a sort of preprocessing step, and imports the results into a vendor directory in the source tree.  It is unfortunate that that piece of bugware because such a ubiquitous dependency, though this is slowly changing.

2. Please, nobody say “just use Linux”.  That would sound exactly to me as “just use Microsoft” would sound to you.