Gold collapsing. Bitcoin UP.

[Richy_T]

OK, so one of the latest moans and whines from the small-blockers is that many nodes are running old versions of the software . My thought is that many of these are abandoned nodes. Anyone have any ideas on how we could test that. One metric would be nodes which are not running 24/7. Those are unlikely to be doing meaningful work. I also suspect that there are a bunch out there that were installed on servers a long time ago by various sysadmins and forgotten. Any thoughts?

 

[jaffer]

There is only one fundamental problem with transferring wallets from hand to hand, and that is you can not prove that you don't know the secret key.

It can not be proven that that the secret key is not known by the issuer, and therefore we should assume it is known by the issuer, and could also build the system on that assumption.

A system based on redeemable notes would not suffer from practical problems of hiding private keys on the note itself. It would not require the user to check that the seal is not broken.

We may not like government issued fiat, but the fact is that fiat notes works very well for day-to-day transactions for small amounts of money, at least in democratic countries.

But over time more fiat tends to be created by governments, which would inflate the money supply and make the money worth less.

This would not be possible with a bitcoin backed currency. It could not be inflated without notice.

The system should not be used for storing large amounts of money.
It should only be used for daily transactions. There amount of money that is controlled by the issuer
would then be low on a global scale.

It would be possible for a private company to issue the notes instead of a government,
and in non-democratic countries that might be a better choice.

But governments need a well-functioning economy, and it is in their interest to keep the economy healthy.
Any misbehaving with the money would likely lead to government change.

And when the system is based on bitcoin any theft attempt will be be noticed.

 

[sickpig]

@sickpig
looks like our efforts over at the f2pool thread worked; 1.35.

that's for real. they almost included in their statement a cut'n'paste version of the post I made here and on BCT. this what I'm referring to

Firstly, Segwit has only 1.6MB theoretical effect. There’s considerable complexity in code development, which would make other applications difficult to upgrade, or even unwilling to upgrade. If only 50% tx adopts Segwit, the 6-12 months hard work will only achieve 1.3MB effect, which is more or less meaningless.

I didn't realize it was such a big deal posting on f2pool thread, again I should know better.

That said Anthony Towns gave updated the computations on gain provided by SegWit based on the last changes committed by Pieter wullie. to make a long story short in case of p2pkh txs the gain raised from 166%-173% to174%-181%.

sipa is for sure a hell of engineer.

 

[Richy_T]

hint: hover over the "1 year ago" on reddit and it'll tell you exact date of post. It's Apr 19th 2014 in this case.

Anyone else having problems with the last line or two of included reddit posts being outside of the box?

 

[cypherdoc]

@Richy_T

yeah, i am.

also, clicking the text link below the box doesn't take me directly to the post; simply to the beginning of the thread which isn't helpful.
[doublepost=1453672672][/doublepost]

OK, so one of the latest moans and whines from the small-blockers is that many nodes are running old versions of the software . My thought is that many of these are abandoned nodes. Anyone have any ideas on how we could test that. One metric would be nodes which are not running 24/7. Those are unlikely to be doing meaningful work. I also suspect that there are a bunch out there that were installed on servers a long time ago by various sysadmins and forgotten. Any thoughts?

personally, i believe they are full nodes who disagree with the direction core dev has been taking the updates w/o entirely abandoning the core software. i know i was doing that before i finally switched to XT and then to BU. it's a form of protest.

 

[lunar]

@cypherdoc think I forgot to get back to you? From a few weeks back when I mentioned the work around to this problem.

1. Click on 'perma link' under the reddit post you require.
2. Then from that new page click on the 'embed' link under the same post and that will give you the full embed code.
3. Paste this into 'add Media' URL here on bitco.in

Now 'read more' should show the whole post ?

Edit can't find this option from mobile.

 

[79b79aa8]

gmax getting ravaged (click on the 'x hours ago' to be taken to source):

 

[rocks]

personally, i believe they are full nodes who disagree with the direction core dev has been taking the updates w/o entirely abandoning the core software. i know i was doing that before i finally switched to XT and then to BU. it's a form of protest.

Many people only update when you have to. There has been no need to update nodes while at the same time updating introduces a slight risk of making a mistake.

For 2-3 years I ran an old node and only upgraded when Armory needed a 0.11.x client. Otherwise I'd probably still be on 0.8 or 0.9 branches....

When faced with a hard fork we will see most nodes upgrade. And the ones that don't will simply fall off the network until their user tries to access bitcoin, sees the client can't, and then upgrades. None of this is a big deal.

It would be nice if older clients could communicate the branch they are on is X deep and some other branch is X+Y deep, that's the only thing missing right now IMHO, otherwise fork away
[doublepost=1453677424][/doublepost]

gmax getting ravaged (click on the 'x hours ago' to be taken to source):

He needs to stay on /r/bitcoin where people who disagree with him are banned (like myself). Otherwise realality must hurt

 

[lunar]

Sunday evening Humour

I give you... The sound of r/bitcoin

 

[AdrianX]

If no paper notes are ever redeemed they could be double issued.

But if a (small) part of the notes are in fact redeemed this would force the issuer to not double issue notes.
Otherwise if a non-backed note is found, this would destroy the confidence in the paper money.

It would not even be necessary to hide the private key on the note, it would actually be better without.
It could work like this:

An organization or preferably a government could issue notes with a bitcoin address printed on it along with a denomination.

The amount printed on the note should be stored in the bitcoin address of the note.
This could be verified by anyone at any time.

The notes should be redeemable to digital bitcoins without any fee.

However, the issuer could have printed several identical notes.
To make sure this is not the case, concerned citizens should redeem some notes at regular intervals.
There should only be two transactions fro each note:
One deposit at the day of printing and one spend when the note is redeemed.

If there are several deposits for the same address, this means that the issuer has cheated
and printed several identical notes.

This will make the notes as anonymous as todays fiat paper money, and would scale,
since the wast majority of transactions would be off chain.

This would give a fully backed, anonymous and scalable currency this would not be possible for a government to tamper with.

Or is there something I have not thought about?

This has been done before https://www.casascius.com the government did crack down on the business accusing him of money laundering. In 2011 when it released it was discussed quite thoroughly. Ultimately the system is dependent on the reputation of the issuer. Still there were some counterfeiting attempts.

 

[rocks]

@AdrianX

Ultimately the system is dependent on the reputation of the issuer.

Which of course is completely unnecessary in a trustless system such as Bitcoin.

At the same time casascius coins were popular. At first I thought it was because people tend to like physical transfer for in person transactions, but casascius coins were not used much for in person transactions, instead they were mostly used for long term storage. So its not entirely clear to me why they were popular.

It might be that casascius coins were functioning as a hardware wallet of sorts. This was before any of the existing hardware wallets were available. Some people seem to like the security of knowing "where" their coins are.

As bitcoin becomes more popular with non technical people there probably is an opportunity for creating physical Bitcoins that are viewed as secure and can be traded in person. I'm sure there are good enough solutions out there, would be a fun project.

 

[AdrianX]

I have a few first batch casascius coins, I paid 2BTC for each 1BTC coin. also sent 10BTC to a Random public key by mistake when purchasing. Oh bitcoin was so cheap back then.

 

[cypherdoc]

@AdrianX

Which of course is completely unnecessary in a trustless system such as Bitcoin.

At the same time casascius coins were popular. At first I thought it was because people tend to like physical transfer for in person transactions, but casascius coins were not used much for in person transactions, instead they were mostly used for long term storage. So its not entirely clear to me why they were popular.

It might be that casascius coins were functioning as a hardware wallet of sorts. This was before any of the existing hardware wallets were available. Some people seem to like the security of knowing "where" their coins are.

As bitcoin becomes more popular with non technical people there probably is an opportunity for creating physical Bitcoins that are viewed as secure and can be traded in person. I'm sure there are good enough solutions out there, would be a fun project.

I'll tell you why they are/were popular; they serve as valuable collector items.

Far from hardware wallets, as well, as you had to trust casacius. Fortunately for the community, we could. Even so, never add any coin above what they came with.

 

[Richy_T]

@AdrianX
So its not entirely clear to me why they were popular.

I bought mine as a cool collectible.

Unfortunately it caught a little corrosion when I set it on fire.

 

[AdrianX]

I felt so stupid when bitcoin hit $1000. I also thought these coins would be a collectable but I realized the price I paid will always be double the face value. If bitcoin hit $10,000 I would have paid $20,000 for a coin that would most likely be worth $12,000 even then in fiat that's a 10,000% return but I paid in bitcoin not fiat so it represents a loss to me.

I realised the better investment would be to just hold the bitcoin as it's going to be more valuable than the collection value of the coin.

 

[Richy_T]

That's not really the way to look at it though as you could have easily replaced that 1BTC (assuming you didn't. If you did, you're good).

It's like the guy who bought the 10,000 BTC pizzas. The sad thing isn't that he spent all those for the pizzas, it's that he didn't replace them. Even just buying 100 back would have made it an amazing spend.

Trust me, exchange rates can drive you nutty if you let them. You can't get caught up in what-ifs

 

[Roger_Murdock]

gmax getting ravaged (click on the 'x hours ago' to be taken to source):

So /u/nanoakron says to /u/nullc, in relevant part:

Given that most of the bandwidth is already taken up by relaying transactions between nodes to ensure mempool synchronisation, and that this relay protocol would reduce the size required to transmit actual blocks...you see where I'm going here...how can you therefore claim block size is any sort of limiting factor?

And /u/nullc replies with:

I am currently leaving redmarks on my forehead with my palm.

The block-size limits the rate of new transactions entering the system as well... because the fee required to entire the mempool goes up with the backlog.

But I'm glad you've realized that efficient block transmission can potentially remove size mediated orphaning from the mining game. I expect that you will now be compelled by intellectual honesty to go do internet battle with all the people claiming that a fee market will necessarily exist absent a blocksize limit due to this factor. Right?

So doesn't Gmax's argument that "the block-size limits the rate of new transactions entering the system" actually make some sense? Am I correct in assuming that nodes don't bother relaying transactions that have a low probability of actually making it into an upcoming block (because of an inadequate transaction fee)? If maximum allowable block size is small, the number of candidate transactions that have to be relayed by nodes can be correspondingly small? So Gmax's point is that a smaller blocksize limit reduces the bandwidth requirement for running a full node, which is one of the arguments for why a larger block size limit is dangerously "centralizing."

"Size mediated orphaning" is a separate argument against big blocks, no? This is the idea that large blocks incentivize pool centralization thanks to the "self-propagation" advantage of larger pools (which mitigates the risk of size mediated orphaning). More efficient block transmission, which is what Xtreme Thinblocks is designed to enable, should undercut this argument of the small blockers by, at the very least, increasing the size of what constitutes a "safe" block size limit. However, Gmax's claim that efficient block transmission can potentially remove size mediated orphaning from the mining game seems like quite a leap. Obviously, "efficient" transmission is not the same as instantaneous transmission.

What am I missing?

EDIT: Unrelated, but here's a comment from /u/ForkiusMaximus over on reddit explaining why, assuming we do need a blocksize limit, that limit should be decided through an emergent process by the market. Not necessarily anything new here from our perspective but it's a very well-done writeup.

 

[molecular]

OK, so one of the latest moans and whines from the small-blockers is that many nodes are running old versions of the software . My thought is that many of these are abandoned nodes. Anyone have any ideas on how we could test that. One metric would be nodes which are not running 24/7. Those are unlikely to be doing meaningful work. I also suspect that there are a bunch out there that were installed on servers a long time ago by various sysadmins and forgotten. Any thoughts?

I had similar thoughts yesterday. Ended up thinking we should just hardfork and then we'd see.

 

[Peter R]

So doesn't Gmax's argument that "the block-size limits the rate of new transactions entering the system" actually make some sense?

Well if "system" = "Blockchain" then it would seem to be a truism. The block size is by definition exactly equal to the change in size of the Blockchain.

If "system" = "mempool" then I would agree too (at least on average). The average mempool size assuming 100MB blocks will be a lot bigger than the average mempool size assuming 1MB blocks.

But I don't see how this has anything to do with the block size limit unless the free market equilbrium block size is greater than the limit (and Jeff Garzik's "fee event" has occurred and nearly all blocks are full).

So Gmax's point is that a smaller blocksize limit reduces the bandwidth requirement for running a full node, which is one of the arguments for why a larger block size limit is dangerously "centralizing."

Note that we've now switched from talking about the block size to the block size limit. As far as I can see, the limit only matters if it is actively constraining the actual block size and blocks are essentially always full.

"Size mediated orphaning" is a separate argument against big blocks, no? This is the idea that large blocks incentivize pool centralization thanks to the "self-propagation" advantage of larger pools (which mitigates the risk of size mediated orphaning). More efficient block transmission, which is what Xtreme Thinblocks is designed to enable, should undercut this argument of the small blockers by, at the very least, increasing the size of what constitutes a "safe" block size limit. However, Gmax's claim that efficient block transmission can potentially remove size mediated orphaning from the mining game seems like quite a leap. Obviously, "efficient" transmission is not the same as instantaneous transmission.

Agreed. Advances like thin-blocks reduce orphaning risk for a given block size but cannot completely eliminate it.

 

[solex]

However, Gmax's claim that efficient block transmission can potentially remove size mediated orphaning from the mining game seems like quite a leap. Obviously, "efficient" transmission is not the same as instantaneous transmission.

What am I missing?

What you are missing is that despite Maxwell having been moderator of the mining sub-forum on BCT for many years, is that he completely lacks empathy with what it means to be a reasonable-sized miner actually in business. He does not trust them to do the right thing, and he fully expects them to stuff blocks full of every low-paying transaction available, just to squeeze every last satoshi out of the fees to supplement the block reward.

Miners are rational (mostly!) and also, the bigger they get the more rational they will be in protecting their income stream. This brings a conservatism which is more than evident by the fact that they shied way from the 8MB+ BIP101 and like the 2MB Classic. If a hard-fork succeeds Maxwell thinks they are going to churn out 2MB blocks pronto, maybe 1MB of business and 1MB of whatever spam they can find.

The reality is @Zangelbert Bingledack's checks and balances flowchart. Miners are going to be responsible because they are fully aware that many full node owners are just helping the network for free. Miners are sensitive to the market price of BTC driven by the economic majority which includes non-mining node owners.

In fact, his fear is ridiculous for Classic's 2MB because the network will be fine with that sized block. He should let this change happen so that it can prove him right that blocks fill with spam, and a small limit like 1MB is necessary.

edit tl;dr
there is an economic incentive for block-size limiting beyond the direct size/orphaning risk equation