Bitcoin Forum
November 13, 2018, 11:38:27 PM *
News: Latest Bitcoin Core release: 0.17.0 [Torrent].
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 [35] 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 ... 239 »
681  Bitcoin / Development & Technical Discussion / Re: Synchronizing wallet balance from a pruned node on: November 01, 2015, 06:46:42 AM
Doing that invalidates the security provided by running it in the first place. (also I make no promises that someone can't elevate giving you database files into full remote code execution).

If you're willing to trust a source of the database why not just dump out the utxo database and just give people a feed of it?
682  Bitcoin / Development & Technical Discussion / Re: Synchronizing wallet balance from a pruned node on: October 31, 2015, 10:15:45 AM
if I didn't import enough watch-only addresses] and then use listunspent RPC.
So import a million, performance is acceptable with very large numbers of keys.

This sounds like you're asking about something for yourself to run.

Another issue is that currently pruning disables the Bitcoin Core wallet so
Mostly as a precaution as it hadn't been adequately tested.  It's enabled in master now and has been for a long time; considering the crazy things you were considering (concurrent access to the wallet database?!?) running master should be a no brainer.

If it would be useful to you, supporting rescan that goes back as far as the non-pruned data shouldn't be a big deal-- mostly an interface question of changing the rescan argument to take a depth and permit the import w/ rescan when the depth is compatible with the current level of pruning.  For what I think you're trying to do you really only need to rescan back a block or two, no?
683  Bitcoin / Development & Technical Discussion / Re: Ghost address 1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E appeared in my wallet.dat on: October 29, 2015, 11:50:41 PM
Yes, I experienced corrupted wallet issue and I resolved it via -salvagewallet on a standard bitcoin core for windows. No, I never used any other utilities apart from the bitcoin core for linux and windows. I also did several rescans. This wallet has thousands of addresses and hundreds of thousands of transactions, its size is about 0.8Gb.
Great, may be a bug in salvagwallet where it's willing to add empty keys. I'll look into that...  potentially a result of the same reading code that accepts them at runtime.

Could you please compile a win64 or win32 binary for me?
Will do.  I'll let you know shortly. (Sent PM with a link to a binary)

Bitcoin core 0.9.3. doesn't have this feature? Check on private and public keys?
Correct, in versions before 0.10.0 (I think) we only checked the first key on decrypt. Later versions check all of them once per execution, as a result of PR#4670.
684  Bitcoin / Development & Technical Discussion / Re: Ghost address 1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E appeared in my wallet.dat on: October 29, 2015, 06:36:03 PM
seen this. thanks. still, how it ended up in my wallet? with the private key in it? or it's just some fake private key?

Right your wallet has an encrypted key object in it with an empty pubkey.  It's not clear how this could have happened.  Has the wallet ever become corrupted, have you ever used any special wallet utilities on it?

In any case, the entry is meaningless and should be ignored.

yes, my wallet.dat is encrypted with a 128-bit password.

Right. The code path for non-encrypted keys checks the pubkey already; so I couldn't see how this was possible unless it was encrypted.

Can you try and see if it rejects this? If you're not compiling it for yourself, please tell me what OS you're running and I'll get a test binary for you.
At first, I was unable to unlock it with the latest version 0.11.1
Right, when it decrypts it checks that the private key and public keys agree, finds that they don't and then rejects the corrupted wallet.
685  Bitcoin / Development & Technical Discussion / Re: Ghost address 1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E appeared in my wallet.dat on: October 28, 2015, 09:09:33 PM
Is this wallet encrypted?

Would you be willing and/or able to test a patch?
686  Bitcoin / Alternative clients / Re: What is the best SPV for handling large number of users? on: October 28, 2015, 05:39:58 AM
Services providing services to other users should almost certainly not be using SPV.
687  Bitcoin / Development & Technical Discussion / Re: Why are transaction malleable in the first place? on: October 27, 2015, 06:12:47 AM
They shouldn't be malleable; lack of canonicalization was an oversight.
Canonicalization is not sufficient to eliminate malleability; and some forms of malleability are very useful. intentional, features-- like the ability to construct anyone-can-pay transactions.
688  Economy / Services / Re: What is most best way to agree on something if all actors are known? on: October 27, 2015, 12:37:49 AM
When all the actors are known the problem you're trying to solve is called "distributed consensus" and there are many fine algorithms for it.
689  Bitcoin / Development & Technical Discussion / Re: tampering with bip70 payment requests on: October 27, 2015, 12:22:42 AM
The mechanism would be that you've transported it over a secure transport in the first place, e.g. HTTPS or encrypted email. No different than a Bitcoin address or plain payment URI.
690  Bitcoin / Development & Technical Discussion / Re: Dust threshold changed without any mention in 0.11.1 on: October 26, 2015, 07:12:50 AM
How do you define toxic waste exactly ? Any usage which does not use bitcoin as value transfer ? how arbitrary is that ?
I wasn't even speaking about bitcoin. I was speaking about traditional toxic waste and your yard.  Smiley Uranium hexafluoride in alumnium cans, if we must name something specific... My point being that your argument was generic, "Using Nicolas Dorier's lawn for other purposes is not abuse if you are willing to pay the price".  Smiley

In any case, going back to Bitcoin, no one is obligated to relay or mine any particular transaction; and might not do so if they think they're harmful by whatever criteria they're using. One need not define anything.

But to your question of "arbitrary", do you intend to insult me?   I do not think it is arbitrary to say that Bitcoin, which was created, operated, maintained, and adopted with the express stated purpose of being an P2Pecash system ... has an intended purpose of being a P2P ecash system, and that use of that that is using the system outside of its stated purpose. By comparison there are alternative networks based on the Bitcoin code base which have stated purposes which explicitly include other things; and, as a point of history, when someone first proposed storing name registrations in the Bitcoin system the system's creator vigorously opposed this and recommended doing so in an alternative network.

That's sadly, the best impartial authority we can get, if you have a suggestion unbiased of personal view about what ought to be considered waste, I'm interested to know. (I'm talking solely about Blockchain use cases, not about technical decisions which help to keep properties of what make bitcoin unique)
Uses which are not related to Bitcoin ecash and instead just ride atop it as a communication/storage channel (or worse, try to explicitly compete with the Bitcoin currency and replace it in the market while using Bitcoin's own network) are a pretty good start.   Case in point, we're in a thread where someone was upset because nodes were blocking transactions of theirs which were creating purposefully unspendable txouts (e.g. adding non-Bitcoin bloat to the UTXO set) in order to run a commercial service called "crypto graffiti" which does what it says on the tin. I think that this is indisputable abusive: It benefits nothing but it's operator/users to the cost of every current and future user of Bitcoin, it uses the system not as an ecash system (which is what virtually all of its users signed up for), but as a messaging and free perpetual data storage layer,  this (data storage) usage potentially risks subjecting node operators to nuisances (e.g. DMCA notices), and even the name acknowledges its nature. ... but on the scale of abusive things it's not very interesting: something can be abusive without being worth worrying about, as the overall behavior of the system already confines the amount of damage to uninteresting levels.  It's only worth mentioning that it's abusive by way of explanation as to why I do not expect this kind of use to be reliable.
691  Bitcoin / Development & Technical Discussion / Re: Dust threshold changed without any mention in 0.11.1 on: October 26, 2015, 04:42:52 AM
Using Bitcoin for other than monetary purpose is not abuse if you are willing to pay the price. (may it be either in fees or in dust)
You can't abuse Bitcoin anyway. Some tried, did not worked so much.
So, if I start accepting fees for it... people can leave toxic waste in your yard?  After all... they paid a fee.

Things are not so simple as you make them out to be. One user (drawn from a tiny subset of mostly a dozen people, currently) ... collects a fee then everyone else for all time in the future takes a bandwidth and storage cost.

Fees are a useful mechanism and, at times, an effective tool, but they do not themselves create moral authority or guarantee system survival because they do not and cannot pay the enormous externalities that dominate the system costs and they do not reflect a consensual interaction with all people they might impact.
692  Alternate cryptocurrencies / Altcoin Discussion / Re: Block lattice on: October 24, 2015, 08:30:15 PM
It appears (from the writeup) that you are unaware of sybil attacks?

The graph of transactions in bitcoin already functions like what you describe (except 'accounts' are single use txouts); Bram Cohen likes to call Bitcoin without the blockchain "bitpeso".  In Bitcoin the blockchain is overlaid on top of "bitpeso" to resolve "complex forks" (using your language) in a manner that allows someone to join the network and know which resolution is authoritative in a way which is both robust to sybil attacks and does not require membership (because a membership process would create control over the system).

In your description you appears to liberally conflate forks and double-spending.  In Bitcoin, double spending a traditional txout requires malicious behavior, just as you describe.  Blockchain forking in the absence of double spending is benign and no different to the "multiple resolution rounds" you mention from your resolution protocol but fail to describe detail sufficient to permit any analysis.
693  Bitcoin / Development & Technical Discussion / Re: Should websites refuse to send coins to an already used address? on: October 24, 2015, 08:16:26 PM
Two more.questions regarding to that:
1) It was known how to generate a new address without a ptivate key back in 2009? If I'm right, this comes from a modern BIP (deterministic wallets) Shocked
I invented it in 2011:  as a response to people reusing addresses because they didn't want to have private keys online. It was later standardized as BIP32.

2) I don't care about privacy, I prefer to have a working Donation address all the time rather than being 100% a ghost. :p
You may not currently care, and its your right to screw over your future self (which you may well be doing)-- but reuse also harms _other_ users in Bitcoin, who do care about privacy, and this degrades the fungibility of coins; since coins which are linked to this or that party are clearly different, and differently valuable than coins which are linked to other parties or are not linked.
694  Bitcoin / Development & Technical Discussion / Re: Should websites refuse to send coins to an already used address? on: October 23, 2015, 08:46:37 PM
Reuse of an address is the sole business of its owner. It's a matter of choice, for most people simplicity is the most important.
Pedantically, the reuse of address harms third parties... and the decision to send coins is the sole business of the sender. I don't think you can answer this questions with simplistic reductions to arguments about free choice: there are multiple people involved in the question, and their free choices may conflict.

I may sound paranoid, but the creation of a new address shouldn't never be done online and automatically. Creating a new private key every time you spend gives me chills.
New addresses can be generated without generating new private keys.

Monero, for example, has no address reuse at all in the blockchain-- it's required for the prevention of double spending there. It seems to do okay with it.  The original bitcoin software never addresses w/ pay-to-ip; and even with addresses in use it the practice of reusing is somewhat inexplicable from a technology standpoint: it _really_ screws up your privacy along with that of people you transact with, and you can't reliably tell which of the payments you had outstanding were confirmed.... I think if it had been realized that people would behave the way they do, it likely would have been prohibited in the Bitcoin system from the start.

[I make these points as points of correctness, not to further argue it-- I think warning is more prudent, and will also have the effect of educating on this matter).
695  Bitcoin / Development & Technical Discussion / Re: Why are transaction malleable in the first place? on: October 23, 2015, 05:16:04 PM
Although the CIYAM Wallet is not currently being used (except for testing by myself) I am wondering if I could get some help to change my ECDSA signing (assuming it isn't correct).

The code is here:

I'd appreciate a link to let me know how to fix it if it isn't right.

(can it be done using OpenSSL or do I need to include the Bitcoin ECDSA code to get it right?)

It can be done using OpenSSL,

The code from Bitcoin core for this-- back when it used OpenSSL for signing:

        BN_CTX *ctx = BN_CTX_new();
        const EC_GROUP *group = EC_KEY_get0_group(pkey);
        BIGNUM *order = BN_CTX_get(ctx);
        BIGNUM *halforder = BN_CTX_get(ctx);
        EC_GROUP_get_order(group, order, ctx);
        BN_rshift1(halforder, order);
        if (BN_cmp(sig->s, halforder) > 0) {
            // enforce low S values, by negating the value (modulo the order) if above order/2.
             BN_sub(sig->s, order, sig->s);

(You might also want to look to using libsecp256k1 for signing in the future, not only does it handle this for you, it is sidechannel attack resistant and OpenSSL is not for this curve, it's also likely much better tested code than OpenSSL for this particular application.)
696  Bitcoin / Development & Technical Discussion / Re: Why are transaction malleable in the first place? on: October 23, 2015, 12:15:48 AM
Thanks for your reply.

One standard issue in cryptography that I was alluding to was the necessity of having canonical forms, so that signatures (which use hash functions) work properly after a message is mangled by the network.  This problem was obvious when encrypting messages sent over email, e.g. PGP and PEM (early 1990's). Another standard (but more subtle) issue is the opportunity for covert channels, which need only be low bandwidth before they can effectively leak a private key.  Thus an experienced cryptographer would have understood there might be a problem and could have looked for it. Indeed, in the case of bitcoin the problem was noted back in October 2012, as I pointed out in an earlier post.
Absolutely, though its worth noting that while canonical encodings like DER are known and specified, virtually nothing enforces them. Bitcoin, from day one, has used a canonical encoding (DER)-- unfortunately, the underlying implementation in OpenSSL had undocumented behavior where it also accepted invalid DER until a couple months ago. (likewise, (all?) other similar libraries, such as bouncy castle behaved likewise-- this wouldn't have been escaped by not using OpenSSL). I spent some amount of time looking for precise DER implementations and BER implementations for reference test points in libsecp256k1 and was unable to find _any_ open source software which precisely implemented (no more accepted or rejected than specified) them. Even OpenSSL's recent fix for their behavior was not to correct their parser but instead to attempt to round-trip the encoding, which is not a guarantee. (You can see this list for some of the crazy things the OpenSSL parser, as an example, would accept.).

(And FWIW, the whole Bitcoin network has filtered these encodings everywhere for several years,  even though it required quite some wallets (like Armory and MTGOX) change their behavior).

But that deals with serialization, I am aware of no evidence that anyone has observed the algebraic malleability of ECDSA prior to us, and no evidence that anyone else took any action against it (now or previously).

As far as leaving serialization elements out of protocols, great care must be taken there too as there have been many vulnerabilities created by leaving things out. For example, the original PGP fingerprints hashed the modulus and exponent (but not their potentially non-canonical serialization), but also as a result had no delimitation so someone could move some bytes of your modulus into the exponent until they found a key they could factor, and then they'd have a weak key with the same fingerprint as you.

Signatures being covered under identifying hashes is ubiquitous, e.g. x509 certificate chains work just like bitcoin in this respect; and this interacts poorly with cert blacklisting due to malleability.

In any case, I don't want to belabor this, but you were really harsh and critical where I think the reality is almost 180 degrees out:  Bitcoin suffered from undocumented behavior in third party code; the outside world while somewhat aware of problems from non-canonicality has largely not acted on it-- Bitcoin Core is a leader in responsive and responsible handling of this, and our efforts resulted in the discovery of an additional form which appears to have not been known/discussed previously), which our ecosystem (out of all the ECDSA users in the world) appears to be the only ones at all protected against.

I really don't care much what armchair jockies on the forums (not specifically referring to you) think, and so I don't usually expend a lot of resources bragging... but to have someone be really harsh on a matter where I think our response has shown considerable innovation and leadership is, at least a little, bit frustrating!

Also, the closing of a low/high-s covert channel would not be significant until deterministic signatures were used. In this regard, I note the date on RFC6979 is August 2013, which is after the bitcoin dev's were aware of the problem.
It is unclear what you mean by "would not be significant", but the matter is largely orthogonal-- 6979 or not, implementations that do not heed the lowS behavior specifically will produce non-lowS signatures at a half the time per signature, leading to most of their transactions being blocked.  No wallet that I'm aware of has ever provided a "resign" button that might break through-- and when wallets do create new transactions they usually use a new random selection of coins, so 6979 would also produce a new signature. Even if they did provide a "resign" and used a random signature, once your transaction has more than a couple inputs the probability that it would pass a lowS test becomes very very low.

RFC6979 does not really close a covert channel either, alas, it is impossible to determine if a device is using 6979 without access to its keys and a malicious device could use 6979 99.99% of the time but then sometimes change to a kleptographic method (perhaps triggered by the message itself).   The RFC does eliminate the strong need for a good RNG at signing time --  a common implementation problem-- and make review/auditing somewhat easier.

I did a little searching around to see if I could find a non-bitcoin example of the problem, but didn't find anything, probably for the reasons above.   This may not help you with regard to the HSM vendor, but as a customer of such a device I would not want to have an obvious potential covert channel, even if the output could be "fixed" by software in a nearby computer, since if the nearby computer could be trusted there would be no need for the HSM in the first place.  (Comment inapplicable if said HSM always outputs high-S.)

Unfortunately if the device has free choice of its nonce (which having control of low/high S implies) then it has a high bandwidth covert channel.  E.g. produce the nonce as H(ECDH(attacker_pubkey, pubkey) || message_to_be_signed). More elaborate versions of this allow the embedding of additional data, beyond just leaking the current private key. Even if something constrains the choice of nonce, a malicious device can do rejection sampling to turn get N bits of covert channel out of the nonce by doing 2^n computation-- low vs high isn't different except by being computationally cheaper to use.   So, I'm not sure I'll be able to sell it in terms of covert channel suppression, but it's worth a try. Thanks for the suggestion.

697  Bitcoin / Development & Technical Discussion / Re: Should websites refuse to send coins to an already used address? on: October 22, 2015, 11:42:45 PM
Warning about it, at least, would be productive-- as there has been a fair amount of loss from people accidentally using the wrong address (in addition to the other ways reuse causes systemic harm).  If you mean "already used" ever, then prohibiting it requires a forever growing database, which isn't all that scalable.

A middle ground would be warning (or refusing) any that the site itself had previously sent to; and I think there was general agreement to do that kind of warn on (wallet local) reuse in bitcoin core in the past.
698  Bitcoin / Development & Technical Discussion / Re: Dust threshold changed without any mention in 0.11.1 on: October 22, 2015, 07:49:33 AM
Boy what a bad loser you are. End users will read these notes:
Don't look at me: I had no idea mangled the release notes. Thanks. No one working on Bitcoin core has any control over, but I'll report it now that you've brought it to my attention.

you are just being a lazy programmer who thinks it would be easier to kindly ask anonymous bitcoin users not to generate massive amounts of UTXOs rather than to implement code that solves the issue on the protocol level. If you now say that dust threshold is meant to defend against UTXOs then stop complaining about people who make UTXOs and are willing to pay the price (whatever it is).
I didn't contact you, you started this thread with a bunch of accusations and ranting, because -- apparently-- you weren't willing to "pay the price".

And no, just because there is a fine on something doesn't make it appropriate to do just because you're willing to pay the fine.

now get back to work
Please do not address anyone on this subforum in this manner. None of the developers of Bitcoin software owe you anything, and this sort of disrespect is most unwelcome.
699  Bitcoin / Development & Technical Discussion / Re: Why are transaction malleable in the first place? on: October 21, 2015, 10:32:45 PM
That "mild" denial of service attack is likely to be perceived as a failure of the bitcoin system when it is experienced by a new bitcoin user.  This is particularly true if the sender makes two transactions in rapid succession from a balance of "old" coins, where the second transaction uses a change address from the first transaction.  This leads to counter-intuitive behavior, since the naive user believes he had all the necessary funds in hand, only to discover that the second transaction "bounces".

I suggest placing more emphasis on what bitcoin users experience, even if it means a little inconvenience for some developers.  
It's not users vs developers-- it's users vs users that are in question here.

In the case of the attack you cannot respend unconfirmed coins without issues while an attack is going on, in the case of lowS enforcement with half of your transactions will randomly get stuck (and never get unstuck, holding your coins hostage). Both are bad experiences for the user. I think the latter is considerably worse: any system's abstractions leak from time to time. Bitcoin isn't a system of "account balances", and for good reason. 99% of the time wallets can simulate that it is, but sometimes the fact that it isn't matters more (and even in ordinary use, the fact that it isn't has significant impacts on fees that can be worth the user's attention).

In the case of the former, it has been a non-issue until recently because no attack of this specific type was going on-- though, of course, we knew one could begin at any time (and immediately deployed all non-disruptive fixes);  in the case of the latter software was chaining over time-- but some users will just find that their preferred software just never gets updated for it; good luck sweeping their funds into another wallet with half (or more) the transactions getting stuck. Some users will try to install fixes but end up with malware instead and have their coins stolen, etc. While there was no attacks waiting for the migration to conforming to happen naturally was an approach which was intended to mitigate total disruption (and I believe it did)-- absent amaclin's demonstration it might have gone with virtually no disruption at all.

At every moment in this process we were thinking about protecting the user's experience and the value of the Bitcoin system to them-- from anticipating an issue no one had thought of before, to implementing, testing, reviewing, deploying fix code-- nagging other developers to fix their software, etc. All of these things took considerable work.  Simply saying "ah ha, today, this new rule is enforced due to this currently hypothetical attack: deal with it!" would have been much simpler.   Sometimes there is just a genuine conflict between different harms.

There was plenty of time to have fixed this a long time ago with an orderly phase-in.
What you are complaining about _is_ an orderly phase in, and is why only ~5% of transactions were affected instead of most of them.

I'm still waiting on a hyperlink to a _single_ ECDSA implementation that dealt with ecdsa inherent malleability prior to Bitcoin's. You argue that it was a standard problem with a standard solution, if so it cannot be too much effort to find an example. [I'm not just asking for didactic purposes, I'm concerned about a HSM vendor that is uninterested in changing their behavior, and if a non-bitcoin example exists it would be helpful (but I could not find one).]

perfect moment to say: BIG THANK YOU for your continuous and well thought contributions and work on bitcoin core.
the core team has earned my trust over a long term and clearly deserves it (this includes other too).
(well i might disagree about blocksize but hey, i doubt there is anything in this world where anybody agrees with me)
Thanks! it's good to hear comments like this.
700  Bitcoin / Development & Technical Discussion / Re: Dust threshold changed without any mention in 0.11.1 on: October 21, 2015, 09:59:16 PM
WTF are you talking about? What you might see as abusive is by no means an objective evaluation of the situation. Keep your petty feelings to yourself. As a core developer you should not allow yourself to give in to your emotions. It is your job to find a solution to the UTXOs because that number will increase EITHER WAY. With or without abuse.
Data storage has a cost. The field you are putting bitcoin unrelated data is a public key field, it isn't Hyena's-file-sharing-field. It's used to set the rules for coins to be spent in the future. When you start cutting me a paycheck you can start dictating what my job is, but under no condition will it ever be to aid you in your quest in externalizing your data storage costs onto Bitcoin users.

and the change to the relay fee was absolutely release noted
FALSE. Stop lying in my face. When I searched the release notes there were no indication to the minrelaytxfee config parameter and the default value that might have changed as a result. It is pathetic to see you try to cover up this mess. Be an adult and admit that the release notes were lacking that info.

Perhaps you should get control of your emotions before posting? It might help prevent you from making errors,  I think release notes are clear on this, and it was also covered in the release candidate release notes.

For the avoidance of any residual confusion, let me quote from them here:

Notable changes
Minimum relay fee default increase

The default for the `-minrelaytxfee` setting has been increased from `0.00001`
to `0.00005`.

This is necessitated by the current transaction flooding, causing
outrageous memory usage on nodes due to the mempool ballooning. This is a
temporary measure, bridging the time until a dynamic method for determining
this fee is merged (which will be in 0.12).

(see, as well as the 0.11
release notes, in which this value was suggested)

Not only was it covered in the 0.11.1 and 0.10.3 release notes, but the 0.11.0 notes recommend users make the same change for themselves manually.

you missed an important part from the release notes.
I await your apology with abated breath.

or else I suspect we wouldn't be enduring your vicious invective.
your petty childish emotions. Calling my activities vicious?!
invective (noun)
1. insulting, abusive, or highly critical language

Be grateful to me for highlighting the UTXOs issue because when a malicious user starts to abuse this vulnerability you will not have a chance for a reasonable debate.
You may be suffering confusion on this point, the dust limits are a fix and don't require having any debate with you (reasonable or otherwise); economic thresholds that discourage the creation of uneconomic to spend (or unspendable) txouts-- and were it not, you would have no cause to complain. And indeed, the protection it provides is not absolute, but it doesn't need to be.  If you send hazardous materials through the post you might get caught, or you might not. But the odds are enough to provide all that is needed to keep you from harming the system. You will not be the first person to intentionally harm a shared resource to brag about how bold and brave you are for revealing issues, it's nonsense-- but also irrelevant, nodes can happily go on blocking your transactions regardless.

I suggest you take your "weakness demonstrations" to the local law enforcement office and helpfully show them how breakable their windows are... Be sure to tell them how grateful they should be for you highlighting their vulnerability. I think they are likely much more equipt to provide you with the education most suited to your current needs.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 [35] 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 ... 239 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!