Bitcoin Forum
January 18, 2020, 09:23:16 AM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 [232] 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 ... 872 »
4621  Bitcoin / Bitcoin Discussion / Re: Major crash no. 5 for BU nodes. on: May 09, 2017, 09:41:50 PM
2. if you read all the REKT campaigns and comments gmaxwell writes you will see where the real threats are made
Outright lie.
4. all the 'rekt xt 2014' rekt classic 2015 rekt BU 2016-17 are all dramatic distractions purely to try getting people to cower down and sumbit themselves over to relying on blockstream.
Blockstream has nothing to do with those threads.

G.max - blockstream had nothing to do with the REKT campaign.. you really wanna push it?

https://bitcointalk.org/index.php?topic=1162684.msg13070891#msg13070891

here is gmaxwell both mentioning the testnet bug like its a problem where testnet should not bug out and should flow like a real coin...(facepalm). oh and also being in the REKT campaign topic.

.. oh and the bip9 threat to maybe at 90% kill off 5% to get to 95% and then kill off the other 5% to get to prettmy much above 99%
yep read bip 9, yep it can be changed. even gmaxwell admits this.
BIP9 changed to a new quorum sensing approach that is MUCH less vulnerable to false triggering, so 95% under it is more like 99.9% (C) under the old approach.  basically when it activates, the 95% will have to be willing to potentially orphan the blocks of the 5% that remain(B)
If there is some reason when the users of Bitcoin would rather have it activate at 90%  ... then even with the 95% rule the network could choose to activate it at 90% just by orphaning the blocks of the non-supporters until 95%+ of the remaining blocks signaled activation.(A)

^ this is where the UASF comes in (A leads to B leads to C)

speaking of UASF
i wonder who is heading up that campaign...
oh yea Samson mow, newest blockstream employee

lauda seriously you are making it too obvious that you are defending blockstream and not a diverse decentralised peer network..
4622  Bitcoin / Bitcoin Discussion / Re: Major crash no. 5 for BU nodes. on: May 09, 2017, 08:34:53 PM
I count about 11.

Honestly though, I don't care either way. I just want to stir the pot also.

Wow, repeating proven fraudulent claims from the BU folks, good for you.


Those ticks are spider restarts, a data artifact.  There has never been an exploited node crasher for the Bitcoin project (and AFAIR there has only been one potential one, which we fixed before it was exploited-- The BIP37 integer divide by zero bug)

gmaxwell uses a bug found on TESTNET.. as a fake way to suggest that classic doesnt work..

UM. testnet is suppose to break. thats the point of it.. throw every attack vector at it..
by trying to presume that testnet should have rules is like saying a cat litter box should only contain diamonds and the cat is not allowed to defecate in it.



so gmaxwell.. never says he cant recall a bug that causes an error in core?
https://github.com/bitcoin/bitcoin/issues/9997
... wait..is this gmaxwell himself having an error with his own client!!!!!!!
4623  Bitcoin / Bitcoin Discussion / Re: Major crash no. 5 for BU nodes. on: May 09, 2017, 08:05:39 PM
The issue here is that we have BU who is actively trying to discredit core and take over as the mainchain and actively has bugs on their live "production ready" software. The what ifs with core are just that but currently BU has a terrible track record and has essentially vile people behind it like Jihan Wu who has talked about attacking competing chains and mines empty blocks during backlogged transactions.

1. if you stop reading reddit, you will see that no threats are actually made. the non-blockstream endorsed implementations are just plodding along, no deadlines no PoW nukes, no mandatory threats..

2. if you read all the REKT campaigns and comments gmaxwell writes you will see where the real threats are made
3. you keep thinking its a "take over" rather then keeping the network diverse while upgrading to new limits in a way that avoids blockstream domination
4. all the 'rekt xt 2014' rekt classic 2015 rekt BU 2016-17 are all dramatic distractions purely to try getting people to cower down and sumbit themselves over to relying on blockstream.
5. blockstream/core are not perfect. they even admit they prefer to hid their issues for atleast 30 days AFTER a fix is found

https://github.com/bitcoin/bitcoin/issues/10364
Quote
but we do not publicly announce bugs even after they have been fixed for some time.
..
announcing bugs with exploit guidelines 30 days after a fix is released would put a ton of our users at massive risk.

https://github.com/bitcoin/bitcoin/issues?q=is%3Aissue+is%3Aopen+label%3ABug

if you think that prtending blockstream(core) is perfect and should be treated as the supreme being of bitcoin control. then you are not thinking about bitcoin the network. your only thinking about FIAT2.0

..
oh and lastly
https://blockchain.info/block-height/465117
Quote
Relayed By    BTCC Pool
Number Of Transactions    1
Output Total    12.5 BTC
Estimated Transaction Volume    0 BTC
Size    0.266 KB
4624  Bitcoin / Bitcoin Discussion / Re: Buggy Unlimited crashes, AGAIN!! Price rallies. on: May 09, 2017, 07:37:32 PM


i have already, multiple times said to gmax, if segwit is so backward compatible why not just make a segwit TX, hand it to BTCC and get BTCC to make a segwit block containing a segwit tx. to show that its network safe and backward compatible..

would that block just get orphaned immediately right now?

nope(if the promise had merit/ were truly "backward compatible")
secretly YES, but shhhh

and thats the point in me saying for him to just do it.. because it then reveals its not as backward compatible and safe as promised.

what blockstream are not telling you is activation day is about changing the DNS seeds to make it so segwit nodes become the main tier of the network and old nodes are then manually add-noded as a secondary network layer

its ven in the documentation.. if you dont want to upgrade, you have to download segwit to use as a filter(gmaxbuzzword) / bridge(luk jr buzzword) to connect to the network

and then all the blocks are then stripped and formatted to the old nodes if the tier network allows old nodes to connect to it.
what will be noticed is the old nodes become part of a cesspit of incompatible nodes that connect and disconnect to other nodes that end up not having good block height, delayed syncing, or just prunned so that the amount of clean connectable nodes becomes harder to obtain.

as explained before
Franky,  you should explain what you mean by tier network.  I don't think anyone understands.

Quote
ever ask yourself why there are no 0.8 or below nodes on the network
and how easy it could be to start making other implementations not have access.
EG anything below 0.13.1 (70014) can find themselves 'lost' in the future

code in a DNS seed:  (70001 is v0.8+)
Code:
#define REQUIRE_VERSION 70001
 if (clientVersion && clientVersion < REQUIRE_VERSION) return false;

simply change to:  (70014 is 0.13.1+)
Code:
#define REQUIRE_VERSION 70014
 if (clientVersion && clientVersion < REQUIRE_VERSION) return false;

and anything not segwit just wouldnt get a list of nodes from a DNS

and most of the segwit users wont want to manually white list old nodes to offer up a nodes list the other way(addnode).
hence why even the segwit documentations says

https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/#not-upgrading-1
Quote
The easiest way to prevent this problem is to upgrade to Bitcoin Core 0.13.1 or another full node release that is compatible with the segwit soft fork. If you still don’t wish to upgrade, it is possible to use a newer Bitcoin Core release as a filter for older Bitcoin Core releases.

Filtering by an upgraded node


In this configuration, you set your current Bitcoin Core node (which we’ll call the “older node”) to connect exclusively to a node running Bitcoin Core 0.13.1 or later (which we’ll call the “newer node”). The newer node is connected to the Bitcoin P2P network as usual.
For the older node, first wait for the newer node to finish syncing the blockchain and then restart the older node with the following command line parameter (this may also be placed in the Bitcoin Core configuration file):


yep if you dont want to upgrade. you have to still download a segwit node just to whitelist yourself, to be filtered down data from segwit nodes that ar upstream (a layer above, of a tier network).

which makes me laugh about the whole "everything is fine segwit is backward compatible and no need to upgrade" promises of segwit going soft

i hope this wakes you up to the TIER network of gmaxwells (upstream filter) and (luke JRs bridge node) word twisting of said tier network of control
where blockstream becomes top of the foodchain..

by tier, it means LAYERS. as oppose to a PEER network where the implementations are on the same layer (same level playing field)




4625  Bitcoin / BitcoinJ / Re: Received and Lost Bitcoins in 1 minute!!! on: May 09, 2017, 07:07:09 PM
for someone to steal ur coins so fast means they have your private key.

things to check

think about all bitcoin related downloads you have
have you ever downloaded any of them scammy "bitcoin generators"
where did you get your bitcoinJ from

did the bitcoinj program generate your address or did you import it from another program/pc previously.


4626  Bitcoin / Bitcoin Discussion / Re: It's that time again, it's time to do your part to Support Net Neutrality on: May 09, 2017, 06:20:31 PM
OP's topic explained via "last week with john oliver"

OP's video may not be available in some countries. some other videos have parts snipped out. but here is one that explains it but has the video reflected / mirror imaged. so still not perfect

https://youtu.be/aL2nJ8WgAhc?t=1m17s
4627  Bitcoin / Bitcoin Discussion / Re: Major crash no. 5 for BU nodes. on: May 09, 2017, 06:08:34 PM
Seriously though imagine the consequences if BU became the main chain, the price alone would drop so hard due to major bugs every week. Bitcoin is too valuable to let such joker's have their way.

reality check
bitcoin holders see that a brand crashed but network survived, giving hop/proof that their funds/assets are safe in a diverse network.

reality check
BU, xt, classic, nbitcoin(?maybe not), btcd, bitcoinj, and all the other implementations want a PEER NETWORK of diverse decentralisation on a single chain

reality check
"Seriously though imagine the consequences if blockstream became the only codebase, the price alone would drop so hard if there was a bug in the only codebase. Bitcoin is too valuable to let such joker's have their way."
FTFY
hope this opens your mind to why diversity=good vs blockstream control=bad... rather than the opposite


P.S i have made no insults but i predict my post would get deleted as it does not fit the propaganda of REKTing anything not blockstream endorsed.
4628  Bitcoin / Bitcoin Discussion / Re: Buggy Unlimited crashes, AGAIN!! Price rallies. on: May 09, 2017, 05:50:00 PM
Well, you have to be very proud making this argument!

lol

nope, but when you stop playing the BU vs debate and start thinking about the network and thinking about the 120 years and the direction bitcoin is going. you start to see the big picture.

that trying to cause drama just to make teams x,y,z bad to give the network over to blockstream is actually worse then calling out bugs of other implementations.

also hiding cores issues to pretend they are perfect is not helping the network either.
hiding core issues does not help

if you care about bitcoin and are independent you would not be kissing anyones ass..
if you care about bitcoin and are independent you would not think or dream that your utopian god(dev) will still be around in 2-120 years to look after you.

it just sometimes takes a while to shake people out of their blockstream devotion dream
4629  Bitcoin / Bitcoin Discussion / Re: Buggy Unlimited crashes, AGAIN!! Price rallies. on: May 09, 2017, 05:34:30 PM

Note to franky - SegWit is a backwards compatible protocol upgrade.



Do you even know what that means?  

Yes.

For the ordinary user, SegWit is backwards compatible.  It needs a majority of the hashrate to avoid a chain split, but by default it doesn't cause one (as I understand it).  Therefore it would be an upgrade of Bitcoin with a consensus, and if in the future there was a split that separates from consensus that was agreed before, that one would be the "new coin" to put it that way.

Feel free to correct me on that but I'm pretty sure that I can call it backwards compatible.

You are correct -- however:  Proposals like BitcoinXT, which require a majority of hashrate to activate, ALSO do the same thing, even though it is a hard fork... yet we still had plenty of shills/idiots trying to label it an "altcoin".

actually segwit is not as backward compatible as promised/promoted.. its stripped and tiered to be backward translatable.

but should there be an issue where nodes need to downgrade and go back to a single block.. (deactivating segwit). all the people with funds on segwit keys get stuck or end up having funds treated like anyonecanspend.
yep thats right.,, shocking revelation

also although segwit creates a tier network that filters out older nodes from receiving unconfirmed segwit tx's at normal tx relay(prior to block confirmation) a malicious person could MANUALLY copy and paste a tx from a segwit node and put it into a standard block and mess with that tx.

this is why blockstream are screaming for anything non-segwit to "f**k off" because of that risk.
this is why blockstream even if soo backward compatible blockstream dont just activate at any rate.
this is why blockstream even if soo backward compatible blockstream wont lt non-segwit pools add a normal block after activation.

i have already, multiple times said to gmax, if segwit is so backward compatible why not just make a segwit TX, hand it to BTCC and get BTCC to make a segwit block containing a segwit tx. to show that its network safe and backward compatible..
4630  Bitcoin / Bitcoin Discussion / Re: Buggy Unlimited crashes, AGAIN!! Price rallies. on: May 09, 2017, 05:05:02 PM
as for BU drama
689->281 =408 drop

still not beating last times 420 drop or cores recently 560 node drop or even the core node crash of 2013..

"biggest node crash in history"

um you forget the core 2013 DB event

hell because so many blockstreamist babies cry "why do i mention cores actual biggest boo boo of thousands of nodes" (for obvious reason)
but anyway lets look at more recent numbers..

by actually counting the nodes drops in the image sources that icebreaker used



so bu dropped 420

.. but wait.. core crashed 560 nodes on the 17th... hmmmm

so BU still has to get a 560 node attack to surpass cores loss
4631  Bitcoin / Bitcoin Discussion / Re: Please run a full node on: May 09, 2017, 04:16:47 PM
Nope, it won't win anything more than if it were keeping his agreement with other miners, because it has only a fraction of the hash rate, and can hence only provide just as many blocks as it would when with his peers.  In other words, that pool is betting on making a very short chain, with much less PoW than the rest of his peers, and breaking his agreement.

In other words, if this pool has 10% of all the hash rate, when his peers have mined 90 blocks on the new chain, he will have mined 10 blocks on the old chain.  Most merchants and exchanges will not see their transactions on this small chain because the blocks are too full.  So merchants and exchanges would still be locked out of bitcoin for 90% - while they would be running entirely NORMALLY if they simply upgrade their node to the majority hash rate of the miners' rules, and see all their transactions.

you have no clue..
now you are meandering into trying to argue about hash power.. yet you dont even understand hashpower either

you are presuming if it takes pool A 10minutes.. then it would take pool B 20 minutes, pool C 30 minutes.
that is not the case.
pools B and C could have found a block just SECONDS later.. but because there is only 1 winner. no one cares about the runners up timing.

if you take 1 pool away its not going to take 20 minutes to make a block. it can still take 10 minutes average block, just less competition so that the runners up now become winners more often, without affecting the average time much

i think its time you go to a shop and get some dice.. and some friends and family and play out some scenarios of randomness.. and see some real world scenarios play out.. it will surprise you

take your 10% of network hash scnario for instance
buy 100 dice..

get 10 people and give them 10 dice each. and ask them all to keep rolling until they get a total of lets say 600(adding each roll)
at very luckiest 1 person MIGHT get it in 10 rolls.. at unluckiest 1 person might get it in 60 rolls.

what you wont find is that if after playing the game for 2 weeks you found out the average took 20 rolls .. does not mean
if you took one person away it would average 40 rolls,
took one person away it would average 60 rolls,
took one person away it would average 80 rolls,
took one person away it would average 100 rolls
took one person away it would average 120 rolls
took one person away it would average 140 rolls
took one person away it would average 160 rolls
took one person away it would average 180 rolls
took one person away it would average 200 rolls

you would see the average would still be ~20 rolls. but now there are less people competing. so other people win more often.. and getting the result just miliseconds/couple roll variance before the other


4632  Bitcoin / Bitcoin Discussion / Re: Please run a full node on: May 09, 2017, 03:40:14 PM
Well, they would realize that all merchants are simply locked out of all transactions, unless merchants use the new rule software on their full node, or connect their wallet to a miner node.  Because there aren't any other transactions in accepted blocks.

So yes, miners can't cash out their coins, as long as ALL USERS decide not to upgrade, and accept being locked out of bitcoin, their funds and their transactions at the same time.

1. pools are not going to waste 16 hours to double prove what they learn in 3-seconds to 10 minutes.. which is they cannot spend funds
2. pools are not going to waste days/weeks/month to really trying to push it in the HOPE that nodes download a MD5 hashing rule implementation..
after all even core suggest it would take a year to get clear node acceptance..

reality is..
if there was some secret cartel of "lets make md5 blocks for the next 6 months to force nodes to be less secured"
initially 20 pools have that motive.. but soon enough a pool gets greedy and jumps back to sha256 and wins every block.
4633  Bitcoin / Bitcoin Discussion / Re: Please run a full node on: May 09, 2017, 03:30:32 PM
We are in the scenario where all pools agree upon a protocol, and the full nodes want another one.  Pools only care about their block being accepted by other miners

nope. because IF pools right now made blocks 465623-465723 that were, say using MD5 hashing..

by this evening.. they would find out that all the merchants wont see their rewards of 465622+
the pools would have most definetly realised that merchants wont buy their 465622 reward by at most 465623

Stick to the case where all miners agree on a set of rules, where the full nodes don't agree with, if you want to show the power of full nodes imposing their rules on miners.

so pools wont continue making md5 hashed blocks for 16 hours because 1 pool will see a nice easy income by switching back to sha256 and win every block that is spendable to the merchants and have no competition
4634  Bitcoin / Bitcoin Discussion / Re: Please run a full node on: May 09, 2017, 03:15:59 PM
but if pools were to change the rules they would get orphaned
Quote
2017-01-29 06:59:12 Requesting block 000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5
2017-01-29 06:59:15 ERROR: AcceptBlock: bad-blk-length, size limits failed (code 16)

No, if SOME pools would change the rules.  But we are considering the case where ALL pools fix the rules (the same ones, or the same change).

You are just printing what your local full node would tell YOU.  But if all miners are in agreement on the rules (old ones or new ones) - that's the case we consider - then there's no orphaning.  Because only miners can orphan blocks, by building on other blocks.

and while say pools BCDE are creating their blocks ontop of B for 16 hours.

pool A gives nodes blocks that are rule A acceptable. and pool A get to spend the funds(pool Awins every 10 minutes, zero competition)

so 16 hours earlier.. it would be like

nodes 399,999 height rule A
poolb 400,000b height rule B
poola 400,000a height rule A

nodes 400,000a
poolb 400,001b
poola 400,001a

..16 hours later
nodes 400,100a
poolb 400,101b - dang it i cant spend 400,001 and it looks like i cannot spend the other 99 blocks either. dang it i wasted half a day
poola 400,101a - woo hoo i won every block for last 100, PARTY AT MY HOUSE 1250 btc to spend Cheesy thanks B for being a dumb & orphaning urself for 16 hours

..16 hours later
nodes 400,101a
poolb 400,102a - ok i lost 100 rewards, ill just stick with rule A from now on.. i wont be changing the rules that easily again
poola 400,102a - dang it B learned his lesson.. ok guys party only every other block, we have competition again, seems they learned their lesson

..
which is why NOW when a pool sees their bloc getting ropped by the ntwork.. they wont continue for 16 hours they realise their mistake straight away.

(btw, strictly speaking, an invalid block is not orphaned but rejected: the definition of orphaning is a VALID block that is not built upon ; by definition, blocks in the chain are valid).

by the way strictly speaking an orphan was 'suppose' to be used in terms of, when a CHILD (newest addition) gets rejected purely because the parent(previous block) disappears..

but reality is a new block can be an orphan if the parent still exists but just gives up its child..

check the definition
An orphan is a child whose parents are dead or have permanently abandoned the child.

most pretend that "orphans" = parents are dead.. but the reality of human orphanages/foster care system is that children do not have to have dead parents to be classed as orphans.
4635  Bitcoin / Bitcoin Discussion / Re: Please run a full node on: May 09, 2017, 02:59:25 PM
Of course they can if they configure their wallet to connect directly to a miner pool node !   And do you think that a merchant or an exchange is going to stop its business for a day, while the competition accepts the new rules on the chain, and gets its node and wallet up and running again ?

your ignoring the past and creating scenario's that never happened..

pools learn in seconds if their block is going to be accepted.. they wont just continue for 16 hours HOPING merchants adapt..
pools learned this lesson the hard way years ago..

it seems you are trying too hard to downplay satoshi's consensus mechanism and trying too hard to make bitcoin sound like the fiat system.

its time you stop looking at the end result and thinking "its just a database" and instead actually look at all the different security mechanisms that make bitcoin completely different to fiat.
4636  Bitcoin / Bitcoin Discussion / Re: Please run a full node on: May 09, 2017, 02:54:45 PM
No Satoshi actually envisioned that we would reach a stage where only big companies would be hosting nodes. We already see a scenario where only

people with fast internet and lots of disk space are capable of running FULL nodes. It takes a lot of bandwidth too, so you will have to take that into

consideration, if you want to run a FULL node. All of this can become pretty expensive, if you are living in some 3rd world country with expensive data

packages and slow internet.  Angry

1. his whole mindset (full context) is that there would be ~100k full nodes and no need for millions/billions of full nodes. the reason for this is:
a. the more nodes to propogate to makes it more delayed to get the data to everyone. so having 7billion full nodes actually hurts a decentralised network. (x degree's of separation)
b. not everyone NEEDS to be a full node
c. it would mainly be businesses and enthusiasts that NEED to run full nodes
4637  Bitcoin / Bitcoin Discussion / Re: Please run a full node on: May 09, 2017, 02:48:11 PM
but now and again find out that they still have lessons to learn (orphans happen weekly)

These orphans have nothing to do with full nodes.  They have to do with the propagation delay of blocks amongst mining pools.
In other words, if, say, an orphaned block appears on average once or twice a week, say about every 400 blocks, it means that it takes on average 600 seconds / 400 blocks = 1.5 seconds for mined blocks to propagate to all miner pools
(rough estimation).

It means that within 1.5 seconds, a miner pool has received a valid block, has verified it, and starts mining a new block on top of it.  So one out of 400 times, a pool has found, by coincidence, a competing block, before realizing that a competitor was faster.

(BTW, this also indicates why miners are most probably directly connected: they could never have such a low orphaning rate if the 1MB blocks propagated through the P2P network: the delays between sending a block and having all other miners stop their work and start mining on top of yours would be too long, and would cause much more orphaning).

nooo
the MAJORITY of orphans happen now because of propogation delay....
 because pools are no longer risking changing the rules to make orphans happen for other reasons..

but if pools were to change the rules they would get orphaned
Quote
2017-01-29 06:59:12 Requesting block 000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5
2017-01-29 06:59:15 ERROR: AcceptBlock: bad-blk-length, size limits failed (code 16)
4638  Bitcoin / Bitcoin Discussion / Re: Please run a full node on: May 09, 2017, 02:37:37 PM
==> what "orphaning effect" ?  Orphaning occurs when OTHER MINERS decide to mine upon ANOTHER block than the orphaned block.  If miners decided to mine upon block A, with blocks B, C, D and E, there simply isn't any other set of blocks around that a P2P node could "prefer".  Suppose that a majority of P2P nodes decides to "orphan" block B.  But the miners have been building blocks C, D and E on top of B.  What happens ?

Well, these nodes stop.  They stop at block A.  And they can't find any other block that pleases them.  B wasn't according to their taste.  But there's NO OTHER BLOCK around that is built upon A.  Nobody has ever made a block on top of A with a higher PoW than the chain B,C,D,E.  In fact, nobody ever made a block on top of A.

but then pools see that all the merchants cant see their rewards for BCDE..
the users waiting on transactions cannot see BCDE

and pools have to wait until Z4 before they can even spend B...

so way way way before z4 (z4=going through the alphabet 4times(100 block confirm maturity)) occurs just to spend B.. pools realise they better make blocks according to rule A otherwise they have wasted half a day building b-zb-zb-zb-z that would be unspendable.

this is why instead of having orphans of 100 blocks deep where pools realise they cant spend their funds..
they only at most regularly have orphans of 1 block deep. because:
they know its foolish to keep mining b-z 4times.
they know its foolish to keep mining b-z 4times HOPING the delay would force 6000 nodes to download and waste a week re-syncing to new B rules.

pools only move to B rules if the nodes accept it, which pools find out about alot sooner than 6 hours+ when its time to spend.
pools can usually find out within a few minutes if their block is 'good' for the majority

some pools realise in 3 seconds
Quote
2017-01-29 06:59:12 Requesting block 000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5
2017-01-29 06:59:15 ERROR: AcceptBlock: bad-blk-length, size limits failed (code 16)
4639  Bitcoin / Bitcoin Discussion / Re: Please run a full node on: May 09, 2017, 02:25:19 PM
its not just a mining game of who builds the biggest tower of blocks the fastest wins. where everyone then copies(like sheep) the fastest built tower..

=> but it is exactly like that.

(because there is no OTHER tower)

there are other towers.. you are just seeing it from the mid-endgame... you have not seen it from the start-midgame.

EG your only seeing the end result. you have not played out the scenarios from beginning to end

the reason there is now only one tower is because the diverse pools and nodes have learned their lessons. so you dont really see much drama of the different towers.
but now and again find out that they still have lessons to learn (orphans happen weekly)
4640  Economy / Trading Discussion / Re: For New Investors - The 3 Percent Bitcoin Rule on: May 09, 2017, 02:19:35 PM
I have a better rule. I keep 50% of my coins in cold storage, and don't plan to access them until 2030.
These coins are not going to be sold at short term peaks/valleys, and are my bet for long-term wealth creation.

a few have the 50% rule

only invest an amount that if 50% was lost, wont make you want to commit suicide.

if the price doubles and you really need the funds, sell half (meaning 100% ROI while keeping half as bitcoin)

if that remaining half doubles. sell half of the remainder.. keep half (25% of original stash sell 25% of original stash keep)
if that remaining half doubles. sell half of the remainder.. keep half (12.5% of original stash sell 12.5% of original stash keep)

but only sell if you really need the funds or you think you can use the funds to buy in cheaper later if its just an obvious speculative spike
Pages: « 1 ... 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 [232] 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 ... 872 »
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!