Some time ago, I read somewhere on this forum that a SegWit (or SepSig if you prefer) hard fork would be cleaner than a SegWit soft fork.  I believe the same post implied that the soft fork technically took advantage of a potential vulnerability that should be closed.  IIRC, the same post indicated that closing that potential vulnerability would require a hard fork.  Now the article link posted at https://bitcointalk.org/index.php?topic=1343346.0 indicates that the core team is planning on hard forking to 2-4-8 in addition to soft forking to SegWit.  Given that last point, why on earth wouldn't we just add SegWit, close the potential vulnerability, and include the 2-4-8 change all in the same hard fork?

[Here are supported facts:]

I don't normally create self-moderated posts and don't intend to censor anyone in this one, but I did decide to make this post self-moderated simply because the topic could easily lead to inflammatory posts in spite my intentions.

The block size debate seems to be ongoing, albeit at a lower and more reasonable rumble.  Honestly, I'm a bit cynical regarding where bitcoin is headed vs where I believe it was intended to go.  I'm also pretty set in my beliefs regarding many arguments across the spectrum of the debate.  However, I'm not posting to argue any specific point.  Primarily, I want to try to propagate and/or invalidate the potentially provable information I believe to be true.  To that end, I am going to post some of that information here now.  I will update this OP as responses that prove and disprove my points are provided.  I may also update this OP with additional information that I recall later.  I may even add additional information provided by other posters to this OP to the extent that they are factual in nature (as opposed to opined).  Hopefully this OP can serve as a point of reference for people who want to validate their beliefs regarding facts that should help in regarding formation or evolution of their opinions in said debate.


All of that having been said, here are some alleged facts that I would love to see proven (or disproven in cases where that is possible):

The 1 MB block limit was added due to concerns regarding storage because there were no alternatives to full nodes

The 1 MB block limit was added due to concerns regarding bandwidth because there were no alternatives to full nodes

The 1 MB block limit was added at a time when 6Mb DSL might have been considered fast by a majority of miners and nodes

The USA is somewhat behind the rest of the developed world in bandwidth speeds

Broadband was defined as >56Kbps (i.e. ISDN) / 4 Mb/s+ (USA FCC 2010) when the 1MB block limit was created *presumably a fair number would be somewhere near 4MB/s given the proof on when the 1MB block limit was added.

The FCC in the USA has since redefined broadband as 25 MB/s in 2015, which is >400x (i.e. ISDN) / 6.25x (USA FCC 2010) the definition of broadband when the 1MB block limit was created *presumably 6.25x would be a reasonable calculation based on my comment on the previous fact above.


Here are supported facts:

Satoshi predicted and had no problem with a few large mining farms vs the majority of users being miners

(bold emphasis added by me)

The current system where every user is a network node is not the intended configuration for large scale.  That would be like every Usenet user runs their own NNTP server.  The design supports letting users just be users.  The more burden it is to run a node, the fewer nodes there will be.  Those few nodes will be big server farms.  The rest will be client nodes that only do transactions and don't generate.
- snip -

The design outlines a lightweight client that does not need the full block chain.  In the design PDF it's called Simplified Payment Verification.  The lightweight client can send and receive transactions, it just can't generate blocks.  It does not need to trust a node to verify payments, it can still verify them itself.

The lightweight client is not implemented yet, but the plan is to implement it when it's needed.  For now, everyone just runs a full network node.

I anticipate there will never be more than 100K nodes, probably less.  It will reach an equilibrium where it's not worth it for more nodes to join in.  The rest will be lightweight clients, which could be millions.

At equilibrium size, many nodes will be server farms with one or two network nodes that feed the rest of the farm over a LAN.

- snip -
Simplified Payment Verification is for lightweight client-only users who only do transactions and don't generate and don't participate in the node network.  They wouldn't need to download blocks, just the hash chain, which is currently about 2MB and very quick to verify (less than a second to verify the whole chain).  If the network becomes very large, like over 100,000 nodes, this is what we'll use to allow common users to do transactions without being full blown nodes.  At that stage, most users should start running client-only software and only the specialist server farms keep running full network nodes, kind of like how the usenet network has consolidated.
- snip -

Satoshi was still developing when the 1MB block limit was created

Looking at github, it appears that the 1 MB block size limit was added in version 0.3.1 on July 18, 2010:

https://github.com/bitcoin/bitcoin/commit/9d2174b6f5f3fac2463c7ebc2dbb9004b3740d23#diff-23cfe05393c8433e384d2c385f06ab93R18

Satoshi posted here in bitcointalk.org as recently as December 12, 2010 indicating that he was "developing" version 0.3.19:

There's more work to do on DoS, but I'm doing a quick build of what I have so far in case it's needed, before venturing into more complex ideas.  The build for this is version 0.3.19.
- snip -

The 1 MB block limit was added at a time when the only way to run a wallet was to run a full node
There are now legitimate lightweight wallet alternatives to running a full node

As far as I know, the first non-full node wallet was MultiBit.  I'm not sure how to prove that there weren't any other SPV wallets before that.

If you are willing to accept that MultiBit was first, then the announcement of MultiBit was on September 12, 2011:

I am pleased to announce the release of a new bitcoin client called MultiBit.
- snip -

We've already established that the block size limit was added in 2010, so if there were no other SPV wallets before MultiBit (in 2011), then the only way to run a wallet was to run a full node.

Furthermore, in May of 2010 (just 2 months before the block limit was added) Satoshi stated that there were no SPV wallets yet:

- snip -
Simplified Payment Verification is for lightweight client-only users who only do transactions and don't generate and don't participate in the node network.  They wouldn't need to download blocks, just the hash chain, which is currently about 2MB and very quick to verify (less than a second to verify the whole chain).  If the network becomes very large, like over 100,000 nodes, this is what we'll use to allow common users to do transactions without being full blown nodes.  At that stage, most users should start running client-only software and only the specialist server farms keep running full network nodes, kind of like how the usenet network has consolidated.

SPV is not implemented yet, and won't be implemented until far in the future, but all the current implementation is designed around supporting it.

Here are the discredited "facts":

It was intended for the 1 MB block limit to be raised or removed in the future

That depends on whose "intention" you are talking about.

From the very moment that Satoshi added the 1 mb block limit, there were probably people that wanted the limit increased or removed immediately.  Satoshi and others were already, at that time, talking about raising it "in the future".  But there were probably people that saw the limit when it was created and decided right then that they never wanted it to change.  What was intended doesn't really matter.  It took time for people to form opinions on what the long term effects of such a limit would be.

If you are looking for evidence though, here's someone wanting to change it to 7 MB in October of 2010:

We should be able to at least match Paypal's average transaction rate...

Code:

- snip -
+static const unsigned int TX_PER_MINUTE = 1400;
+static const unsigned int TX_AVG_SIZE_GUESS = 256;
+static const unsigned int MAX_BLOCK_SIZE =
+ TX_PER_MINUTE * TX_AVG_SIZE_GUESS * 10 * 2;
- snip -

And here's Satoshi saying that we could increase it "in the future":

- snip -
We can phase in a change later if we get closer to needing it.

I listed this in the discredited section because I believe Satoshi's intentions are generally implied here even though the "fact" didn't indicate as much.  Based on the snippet above, it doesn't appear that it was so much an intended action as an anticipated possibility.

Notifications have usually worked pretty good for me, but they seem to have recently ceased.  I just noticed several topics that I'm not seeing notifications for, some of which I had previously received notifications for.  A quick search appears to indicate that no one else has posted about anything like this in at least a couple months, and it just started happening to me in the last couple weeks.

Got this information in an e-mail from McAfee today...

Vulnerability to CVE-2015-2035/GHOST is currently being investigated across all McAfee products.

Impact:
The GHOST vulnerability is a serious weakness in the Linux glibc library. It allows attackers to remotely take complete control of the victim system without having any prior knowledge of system credentials. This buffer overflow vulnerability can be triggered both locally and remotely.  CVE-2015-0235 has been assigned to this issue.

The GNU C Library or glibc is an implementation of the standard C library and is a core part of the Linux operating system.  Linux distribution vendors have released patches for all distribution as of January 27, 2015.

If it is accurate, then it seems like glibc would be used in a lot of places, possibly including bitcoind or bitcoin-qt...

I was reading the oclvanitygen thread for kicks and came across this:

In addition, while you can possibly get a collision on the address, you still can't spend from that address unless you have the correct private key.  So even if you do happen to get a full match on the address, you might still not have the correct private key to go with it. (addresses are hashes of the public key, which have a smaller space than the public key, so at least there's a greater potential for a collision on the address)

Reading it caused me to ponder a security question...  Unless I am behind the times, current general knowledge seems to be that one should not re-use addresses because the availability of the public key might make it easier to break the private key.  Given this, I assume TheRealSteve's statement is at least partially incorrect.

Specifically, if the public key is not available, then this part of the statement is wrong:

"In addition, while you can possibly get a collision on the address, you still can't spend from that address unless you have the correct private key.  So even if you do happen to get a full match on the address, you might still not have the correct private key to go with it."

IIRC, and even if I hadn't actually previously read something to this effect, logically speaking, the first key combination successfully used to spend bitcoin has its public key tied to the address, and no other public key can be used in the future (which also prevents any other private key from being used except in an m of n scenario), so when the public key has not been tied to an address yet, a different key combination could be used in the event of a collision (however unlikely) because there is nothing to say the alternate public key is not the original.

Now, assuming my analysis is correct, this begs the question of which is riskier today (granted that which is riskier could change in the future if any specific piece of cryptography in use is broken in the future), and statistically speaking, what are the odds that define each scenarios risk:

1) Re-using an address or otherwise publishing your public key for said address in the blockchain.
Risk: Public key is used to make it easier to break private key

2) Keeping the public key private to avoid the risk in (1), as is currently recommended.
Risk: Collision allows someone else to assume control of your address

I understand the odds for (2) are astronomical and posted all over the place, but I don't know if there are calculable odds for (1).  Assuming there are, it would be neat to know how much safer (2) is, and it would be somewhat validating/fulfilling (albeit certainly unlikely) if it turns out (1) is safer when we assume no other cryptography breakage will occur.

So, can the odds for (1) be calculated?  Also, does any cryptography breakage already exist which would change the odds for (1)?  Finally, is it possible to calculate the odds of any future cryptography breakage that Would affect (1)?

https://www.yahoo.com/travel/welcome-to-bitcoin-boulevard-in-cleveland-no-cash-94439973607.html

http://www.gyft.com/blog/gyft-first-data/

This article doesn't mention bitcoin directly, but Gyft does accept bitcoin, and the article says this:

we will continue to accept all forms of payment.

While that could turn out to be inaccurate, if it is accurate, it may mean that

First Data, the global leader in payment technology and services

will be getting involved in bitcoin.  I have never heard of First Data, but this seems like newsworthy information, and I believe a company blog is similar to a press release, which would imply this thread is appropriate here.

Once upon a time, I read something somewhere that indicated that change addresses had additional information posted in the blockchain vs third party addresses.  I had long since forgotten about this, so I am hoping someone else can confirm whether this was ever true and whether or not it has changed.  Sadly, this newbie post reminded me because it triggered my urge to want to correct the poster:

Actually the transaction only shows the public key of the address you are sending the coins from. That's why some coins are likely lost forever because they were sent to an address which are unlikely to be associated with a public/private key pair.
They are named something like "1DontSendBitCoinsHere"...

That urge was quickly replaced by the same question asked by another newbie that the aforementioned post was supposed to answer:

OK, newbie here but please bear with me because I'm sure many people reading this thread would like to ask this same question but are afraid to look noob. You keep saying not to reuse addresses and keep balances on new addresses. Now as I understand it, in order to send coins to any address the network needs to be made aware of it by means of a transaction which will be forever recorded on the blockchain with the public keys of the addresses. So what's the point in tranferring the coins to a new address if its public key is going to be made public by the transaction anyway, even if the address owner only made that single transaction using that address?

Obviously the "don't re-use addresses" advice would be garbage if transactions work the way I remember reading that they work.  I find it hard to believe (but not impossible based on some other things I have seen) that garbage advice would be quite so rampant, so I have to believe that either A) I am remembering wrong or B) bitcoin core wallet was changed to not broadcast public keys for change addresses in transactions.

Anyone who has been around here long enough to know what I read happen to remember it and know how to find it?

[Bitcoin wallets]

https://news.yahoo.com/massive-malware-campaign-steals-everybodys-125834620.html

In addition to logging user keystrokes, the NightHunter malware also gathers and relays information about the Web browsers, instant-messaging and email clients, password managers, Bitcoin wallets or video games present on an infected computer.

Anytime I enter my passphrase in bitcoin-qt on Windows, it crashes (I can't even run bitcoin-qt on Linux).  When I run bitcoind on Windows or Linux and use walletpassphrase or walletpassphrasechange, I get this error:
error: {"code":-1,"message":"CKey::SetSecret() : secret must be 32 bytes"}
The same wallet passphrase works fine on the same wallet with pywallet.
This is the second time I have had passphrase problems (but the first time I have posted about them).  Is there some set of passphrase guidlines in order to avoid situations like this?

I wasn't sure where to post this, but thought Pools might be the best section for pool operators to see the suggestion (as opposed to suggesting it to a specific pool operator).  I was just messing around with bitcoind and noticed this option:

Code:

signmessage <bitcoinaddress> <message>

I know several pools advocate payout locking and using PINs and the like.  Seeing this option made me wonder if it wouldn't be more secure to require a new payout address to be signed by the old one.  For instance, when I sign FakeNewAddress with 1B19RDfQtFNDsAa9toRWEXZbrFRZvZcET6 I get this:

Code:

G4Z1xAHdiqLnIY/+V5a0m3wmaTfjPUcJhlZZiwUgAx/lKlQbFvCnZpB3GxslYqNKuSb08T87obPaopN25NPRX6o=

So if I entered FakeNewAddress into an address field and the above into a signature field, the pool server could run this:

Code:

bitcoind verifymessage 1B19RDfQtFNDsAa9toRWEXZbrFRZvZcET6 G4Z1xAHdiqLnIY/+V5a0m3wmaTfjPUcJhlZZiwUgAx/lKlQbFvCnZpB3GxslYqNKuSb08T87obPaopN25NPRX6o= FakeNewAddress

and it should return true.
Even if it wouldn't be desirable (for instance, because the Windowns bitcoin-qt executable dosen't appear to support the walletpassphrase command, which is necessary to unlock an encrypted wallet before signing) to be required for all address changes (after the initial address input), it might be a nice optional security feature to override a 24 hour payout lock or otherwise permanent payout lock, at least for users who have their wallet stored in multiple locations.

I am connecting via ssh and getting this:

Code:

X Error: BadIDChoice (invalid resource ID chosen for this connection) 14
  Major opcode: 53 (X_CreatePixmap)
  Resource id:  0xe00014
X Error: BadIDChoice (invalid resource ID chosen for this connection) 14
  Extension:    145 (RENDER)
  Minor opcode: 4 (RenderCreatePicture)
  Resource id:  0xe00015
bitcoin: Fatal IO error: client killed
X Error: BadAtom (invalid Atom parameter) 5
  Major opcode: 23 (X_GetSelectionOwner)
  Resource id:  0x910004
bitcoin: Fatal IO error: client killed


************************
EXCEPTION: N5boost12interprocess14lock_exceptionE
boost::interprocess::lock_exception
bitcoin in ThreadSocketHandler()

terminate called after throwing an instance of 'boost::interprocess::lock_exception'
  what():  boost::interprocess::lock_exception

I am able to launch firefox through the same ssh session, and I have historically been able to launch bitcoin-qt this way on this particular pair of machines.  The only change I have made is adding a bitcoin.conf to the .bitcoin folder in ~ (home).  I stopped bitcoin-qt before doing that and started bitcoind after.  I then wanted to see if bitcoin-qt would perform / start the daemon functions, so I launched it and got this error.  The bitcoin.conf looks like this:

Code:

rpcuser=user
rpcpassword=pass
rpcport=8337
rpcallowip=*
daemon=1
server=1

However, stopping bitcoind, renaming bitcoin.conf, and starting bitcoin-qt leads to an exception as well.  Is there anything else I should try, or am I likely to find that this problem goes away when I restart the machine (or ssh connection)?

Overnight I received .001 BTC on address X and .001 BTC on address Y.  Both of these addresses are the invisible kind (the ones leftover BTC are moved to when you do a send).  My transaction history shows .002 BTC being shown on address X.  At first I thought this was a glitch in the sending software and address Y wasn't used, then in looking at block explorer, I saw that it was a glitch in bitcoin-qt.  Seeing as how it has already happened, I'm not sure there is much I can do about it as far as trying to figure out why it did that, but should I continue to trust my wallet.dat, or is it time to switch to a new one in case this one is corrupted?

I knew the bitcoin client was supposed to generate new addresses whenever coins were sent, and I wasn't sure about when coins were received.  Anyway, upon receiving coins on an address in my address book (that wasn't the one in the "Your Bitcoin Address" section of the client [I always keep the same {first} address there]), a new address was generated and placed in that field on the client.  This wasn't my first receipt, but it was my first receipt against the particular address in question.  Since I noticed the new address, I copied it for later and changed the default address back.  I then noticed it wasn't in my address book anymore.  Out of curiosity, I had .0005 BTC sent there to see if it would show up in my client, and it did.  However, that address STILL isn't showing in my address book.

So I'm not sure about two things.

1) Should a new address be generated by a receipt in any scenario?

2) Should it be possible to have coins received in a wallet to an address that isn't shown in the address book (specifically when the address in question definitely had BTC sent from the outside as opposed to BTC left over from a sending transaction)?

Anyone have any thoughts?  If this does look like a bug, is there somewhere/somehow I should report it?

So this quote is from a post that so far seems to be a scam, and I only note that so people don't think I'm linking to it because I'm in on it or something...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If you used the Open Source FPGA Bitcoin Mining project as your starting base, I am making you publicly legally aware that that project is covered entirely by the terms of the GNU General Public License. By using any part of the Open Source FPGA Bitcoin Mining project, you must conform to the legal obligations set forth in the GNU GPL. If you do not conform to the legal obligations set forth in the GNU GPL, you will be prosecuted in all applicable legal jurisdictions.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQIcBAEBAgAGBQJOJiDFAAoJEFFoGj2A5YKR5uIQAJ6OyAziHZAPpwHzc3RYhy+2
d/p0zGb/+fPQjrjtvGVCai15JL6yC1B4SZgJ584SQNIATl9w16K8994DaI/7Wh+R
uWGzti+E1qI+Z5oJU3K+ku9RwSTL3Bu/aqJgu/csYdibOQO2A4zwAeFSE6mqim/4
DEpfNbUU4Ca1BhR754I+aFHQnY6/3tDhp3U6dl1clDAxs+aTkFRItLdNjlrTUjAW
Tqt9+ei3ZovSK6ceYYOzI84qY5Lh48QVthGAoiGOK3YC/ggtL+JC/1vut3ZGNcy8
1UNhn4LWwLn+gi/A3Ge146SBxBvGDOdXb7SD+6nRlGXFIKKIoAGMW4nzhXbEHXQu
wInXUMnQCaCAmrXLom35+HFBmo7InzWeqPUxDqpW0DpWN6RfufDH8fryIRLdfz9T
BH/PY7QRoZub51B13NEPU1kEv365ADIDgPvribZsF+14wxRO2RGr/JzgBaCQDZEo
1sQnIsNI+iSJm7tqdAxYrDA8t+Bb/+IImTf0K8Vjk4mG+NHhEXxIkVGgh4+Aso0U
AnaTTlY0A0xEXth6H6wkbOKSbNkT+gsSzbWNVT1hFCpzJuUXyHoN3+JvRtnXBzJh
i/No2AFBC6LyAPxzMOwS7QzcmIx1dnebXJ812w6gCB5T/R3Jvtf5JX5TQr698vTy
Es4gk6uQYSR9nFgPCjS6
=QRTV
-----END PGP SIGNATURE-----

This is the first instance I've seen of PGP/GPG being used in regards to bitcoin, so I figured I'd take the opportunity to ask for a bit of help (perhaps a refresher is all I need, or perhaps someone knows of some issue I'm unaware of).  I haven't used PGP/GPG mu in quite a while.  I just downloaded the latest version (for Windows) with Kleopatra and imported my keyrings, but when I try to verify this I'm told it can't be verified.  I thought when I used it before it would import keys from signatures, but maybe I'm remembering wrong.  Regardless, I can sign a block of text with one of my keys and it fails to verify too.  I was going to create a separate key for bitcoin, but I didn't realize that they have to have e-mail addresses and can't have other types of IDs, but in doing that, I noticed that I can't generate 4096-bit RSA certificates.  That's what some of mine are, and I thought that might be why it can't verify them, but I'm pretty sure WinPT would way back when.  Anyway, another issue I had on Windows once upon a time was that several different tools didn't seem to properly verify files (maybe only large ones, I don't remember), and I never really figured out whether the problem was the tools (md5sum, sha1sum, etc) or Windows itself.  Also, for the record, I have NOT chosen to refresh OpenPGP certificates (I have never submitted my certs online or downloaded certs online, primarily because last time I messed with this stuff there was no open server or it wasn't so simple).  That aid, anyone here have any thoughts regarding this whole scenario?

So I have been using Windows task scheduler to deploy mining on startup (and additional mining on idle in Windows 7).  I was running GPU mining in Windows XP through task scheduler on startup with puddinpop (extracted from guiminer).  I am now working with a Windows 7 machine I could GPU mine with, but I can't do it through the task scheduler (I tried puddinpop [extracted from guiminer] and diablo; they both work fine from a command prompt).

Is it possible to run a gpu miner in Windows 7 automatically without it being present on the desktop?  I have seen references to stealth miner, but not come across it yet, and I'd rather have slightly more control over it then it sounds like that would give.