Thanks for the reply Franky1, but it still does not answer the question. I want to know, if stronger Algorithms have been tested yet, and if it required the same resources or if additional resources would be needed to use it. Most of these stronger algorithms are not used, because it's too resource intensive and slow. < If I understand it correctly > Most of these SHA algorithms were created by the NSA, so it is just logical to think that they too would be compromised.. if QC could be strong enough to crack it.  using testnet, does not involve: the 7 year historic data or the exohashes of mining power. ontop of that if its then playing around with different algo's then it is not a fair "bitcoin test". but other algo's have been tested. yes. and thats where some of the other alts came to be. but concerning bitcoin future scenario's specifically the argument flips around from: 'should we change bitcoin to use Y instead of X' to a debate of: 'oh no, old coin holders(ie: nakamoto) wont move funds over to Y, so should we destroy old coins, with a deadman switch to stop d-wave users from getting "free" coin'. |
|
|
|
|
this is all old news from atleast 6 months ago
the news paper article is resurrecting old news and written to confuse the matter
they mention one bunch of hackers/script kiddies that do DDoS attacks and another group of hackers/script kiddies who throw ransomware at employee's who use their work pc's to look at dodgy sites and download dodgy things.
many banks have been informed by security advisors months ago that it might be worth keeping a stash of bitcoin in the event that the second scenario happens. but this still does not mean the banks will do this. its just a recommendation from security analysts as a precaution.. and an old recommendation at that.
it seems due to the bitcoin price moving forward, some people thing they should use this as a way to push the price forward more by showing why everyone should buy buy buy, via news articles 'reporting' that some whales are soon gonna buy..
though the reality is the news articles are about 6 months behind the story they are resurrecting
|
|
|
|
Didn't see it being mentioned anywhere, nor is is worth the trouble, but wouldn't full clients like bitcoin core do the trick; and in return users that
are running them could get priority transactions over the users that only sent theirs with fee ?!
That would give users incentive to run full node, and still there wouldn't be an option for people to exploit that fact because there wouldn't be any real profit
for users that run them, other than priority transactions. Is this doable at all , since it would have to be coordinated with large pool operators i guess ?
replace the word CORE with "any diverse fullnode including core". and you might have something. EG full nodes get a fee discount. lite-nodes and web wallets pay a premium.. though this is already kind of happening. blockchain.info users are already highlighting/complaining their tx's have an automated premium (above average) cost. also on the flip-side btcc and xapo are doing the opposite. offering zero fee if customers use their webwallets for their services. so things need to flip around if your idea should be a way to entice people to be full nodes. emphasis on diverse full nodes rather than everyone running one codebase. |
|
|
|
|
kprawn at the moment sha (any level) is not the target of QC. the real target is something like ECDSA.
this is because sha is more of a binary logic problem which limits QC's efficiency and ability. but ECDSA is a vector problem something QC can solve easier.
this means QC can be thousands of times more efficient solving a vector problem compared to a normal computer.
but QC can be only a couple times more efficient at a binary problem compared to a normal computer.
if i had a d-wave system. id prefer to 'crack' ecdsa way before wasting a few lifetimes cracking sha.
but even before worrying about QC. id be looking into solving the LN risk. (of signing using the same key many times a week). after all devs say try not to use the same key more then once due to what it may reveal. so LN has to think that through when developing a method to sign locked funds of a specific keypair.
that is a bigger risk to sort through right now
anyway back to the bitcoin ecdsa problem
my opinion is where each keypair should have its own specific curve rather than everyone using the same y2 = x3 + 7. curve. thus adding some more randomness to prevent brute forcing.
but when changing to a new ecdsa mechanism for the keypairs, might aswell change to a different sha level too
|
|
|
|
|
the incentive is the desire to keep bitcoin decentralised and diverse and thus secure the blockchain against corruption of any sort..
its not as if it requires a data centre now or in the future.
after all even at 4mb of bloat (core's new happy number) thats only a MAXIMUM possible 208gb bloat a year= 1tb every 5 years.
at which time most people upgrade their computers anyway.
also a 2tb hard drive is under $100. so its not like you need to spend alot if your into building a PC. even a standard $400 branded pre-made desktop PC have 2tb as standard (10 years+ of upto 4mb block bloat)
as for the internet. again adsl is more than enough. and fibre is even more.
i know some people will cry that they are having internet issues. but no "bitcoin incentive" will cure that cry.
no money in your pocket can change limitations of the cabling reaching your property.
most ISPS upgrade an entire area at a certain time. not a single house over night.
if you are having issues. then cut down on how many connections you have. 8 is about reasonable 60 is overkill (unless you have good reason to be a supernode)
if you care about bitcoin security more then your ping speed of playing call of duty on the side. good
if you care more about playing call of duty than bitcoin security, then good keep playing. but dont expect to get paid just to run a node.
most node users are those with a big desire for bitcoin security. not financial gain of just running a node.
if running a node becomes just a financial gain. then many people will start running 1000+ nodes from one location.. which is no better for security than running just 1.
my personal point of view.
i would rather see 6k nodes where 2k each are run by different implementations. (diversity)
where all 6k nodes are running from different locations. (not stacking up multiple nodes at remote hosting/ home garages)
rather than
200,000 nodes all running one implementation due to some commissioned earnings reward to use specific node.
half many are running via a single owner.
EG
things like 21.co running hundreds of nodes all set up and located but in control of 21.co engineers=bad
individual diversity and distribution=good
|
|
|
|
|
bitcoin is a never ending story.
no one owns the IP rights to the story. and there is no single copy of the story, there are many books. but any person can be part of the story and everyone gets to read that same story and add a new line to the story as long as it fits the story
|
|
|
|
Then the affected users have every right to get the authorities involved. People with criminal minds should not be allowed to get away with their exploits. they have the right to. but technically they have been baited and switched. by now having *cough* equity *cough* in bitfinex, they are now part of it. thus by reporting it. their own "equity" would get locked and then put into a government pot that gets eaten up by lawyers for a couple years. its a smart thing. make users scared to lose out on something twice, if they take legal action. so now they have to follow the carrot (hoping bitfinex pays them back), because the stick (legal action) loses them more. afterall. its been a couple years.. how many mtgox customers have got anything at all back. but how many lawyers have got a nice christmas bonus |
|
|
|
|
remember folks an ETF is not a way to buy actual bitcoins.
its just "shares" in a company that disclose how my bitcoins the company is holding. and people just 'gamble' (market speculate) on the value of the company.
which is then bait and switched to presume as a "bitcoin price". although an ETF has no actual or direct impact on exchanges or gateways to buy actual bitcoins
|
|
|
|
they robbed themselves and are just doing PR to keep up the pretense that it was an outside job. the owner was going through a divorce and suddenly had to make lots of funds disapear to ensure he doesnt have to give 50% to his now ex. now the divorce is over he if secretly holding the coins but trying to gain fiat from outside investors via https://bnktothefuture.com/pitches/bitfinexthat way he can keep the coins and off load the debt to VC's. |
|
|
|
They weren't backtracking. The agreement explicitly said that they were just contributors and they would recommend a proposal to Bitcoin Core, which implies they aren't representing Core. They wouldn't be presenting something to Core if they were supposed to be Core. Also, AFAIK none of the Core devs there can actually commit to Core.
the reason why adam back and luke were invited was because they are not just some random secretary or floor cleaner .. they are part of core. they CODE! why invite a floor cleaner/secretary of a group who can only "suggest" something. when the purpose was to get the actual CODING devs that will actually agree to CODE something!! has adam back coded anything inline with what he signed??? nope. then he back tracked 100%. luke backtracked by denouncing his own coding skills too, pretending to be the equivalent to a floor cleaner. only able to make a suggestion then as the debate escalated and he then said he may code something.. but its been months since that flip flop and nothing is coming to a fruition. but hey.. lets follow the usual brush that under the carpet and pretend it never happened.
anyway its been three pages of posts where you admit that 6 months grace and 12 months coding after RC should not be required. even when th security and stability arguments of why core were delaying crap was due to those numbers. so now segwit coding is fully complete, done and dusted and ready to rock and just needs activation as you say. devs can concentrate on real blocksize increases via "algorithmically determined block size". lets hope i never see you shout for grace periods and delays now that you have been suggesting that activation in only a couple months is ok. |
|
|
|
but we know you are not just a "user" so i specifically chosen to get an answer from you.
here is the subtle point.
Your point is not subtle. Look up the definition of subtle. wait for it.. The opposition? As in Classic and BU? Or do you mean other wallets like Armory and Electrum?
Either way, no, that time frame is way too long, for both hard and soft forks. Technology moves quickly, that timeframe is much too long.
it is subtle. because here is the thing.. i did not inform you i was going to tell you my questions applied to BU. to let you presume i was talking about core and defend cores RC. to see your answer as if you were defending BU (without realising it) i was taking your mindset and answers of core to apply them BU's RC that has been released MONTHS AGO.. secondly hard forks. would work like this 95% node then 95% pool thus giving time due to 2 rounds of votes but im glad your atleast saying 12 month coding and 6 months grace is too long. 
now explain the last year of civil war.
where core agreed to flex caps. a RC was released. but then core backtracked.
When did Core agree to flex caps? When was a release made with flex caps? 2015 roadmap - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.htmlFurther out, there are several proposals related to flex caps or
incentive-aligned dynamic block size controls based on allowing miners
to produce larger blocks at some cost. These proposals help preserve
the alignment of incentives between miners and general node operators,
and prevent defection between the miners from undermining the fee
market behavior that will eventually fund security. I think that right
now capacity is high enough and the needed capacity is low enough that
we don't immediately need these proposals, but they will be critically
important long term. I'm planning to help out and drive towards a more
concrete direction out of these proposals in the following months. greyed out bit is irrelevant now due to blocks being at capacity NOW (autumn 2016) so its more important NOWbut months after the roadmap, a consensus roundtable was requested to get the "more concrete direction" so consensus roundtable in early 2016 had signatures signed and agreements agreed.. core team agreed and signed the consensus agreement including a block increase. then they backtracked and said they dont represent core and only turned up as individuals..(facepalm moment for many) |
|
|
|
|
but we know you are not just a "user" so i specifically chosen to get an answer from you.
here is the subtle point.
if there is a RC available next week with unchanged code viewable (consensus AND LOCAL) available for a weeks prior.
should there be a 12 month coding delay just so that the opposition can code something equivalent.
then after 12 months. get to 95%. and then after 95% have 6 months grace
even when the code has been viewable weeks before RC release 18 months earlier then when you finally want it activated.
give yourself an answer and hold that answer and dont change it.
now then lets add an extra dimension to the question
if there is a RC available months ago with unchanged code (consensus AND LOCAL) available even before that.
blah blah same timescale 12month 95% 6 months grace
blah blah code available before RC
if the answer is no. then you will see the issue in a minute
however lets continue
if devs have not coded a diverse implementation by the time a RC is released. it is the devs own fault .. right??
devs should instead not give own timescales to then make their own equivalent as its deemed delaying.. but just run the RC ... right??
they should not test the RC because its their fault and treated as delaying if making a request for time. and trust the RC works... right??
think long and hard about the subtle point.
now if you still think there is no reason for 12 months coding and 6 months grace after a RC, anyone asking for time should be disregarded..right?
now explain the last year of civil war.
where core agreed to flex caps. a RC was released. but then core backtracked.
oh wait i can predict you flip flopping your answers while reading this to protect your interests
do you atleast see the subtle point of hypocrisy?
|
|
|
|
Simple thing, but I cannot find a proper source - I want to get address but presented in btc not satoshi like eg blockchain gives with q/addressbalance/address
if you can see it in satoshi's just divide by 100,000,000 |
|
|
|
All that safety rhetoric is still there, but the key point is that all those wallets and miners have been working on their implementations of segwit long before the release. They don't have to start working on it after the release, they work on it beforehand. Again, no consensus changes to segwit have been made since it was merged except for the deployment start time which is a very easy change. Only local node policy (which can be easily taken care of because that local node policy was already a standard thing for wallets to already be doing) and local changes within Bitcoin Core itself.
same has been said about BU which is actually already running on mainnet for months as a release.. yet the 12 months coding rhetoric, and 6 months grace, 6 months grace, 6 months grace repeated 'safety' concern do you see the hypocrisy delay or else.. but rush core activation.. screw pools own local needs..instead 95% by christmas, beat your chest, get it done now now now why so desiring a pre-new year activation.. hmm? why not just let pools flag it when THEY ARE CONFIDENT. why not atleast be calm and say hopefully by spring 2017 again emphasis: why wishing for rushing to 95% yet argue other proposals should take a natural long time to get 95%. |
|
|
|
This thread escalated quickly into a word war between core and the big blockers. While I do support both movements and could see the advantages of both, I do like to see Segwit and then the Lightning Network be implemented first. I just think avoiding a hard fork for as long as possible as a safety measure must be the path to follow.
I am excited for 0.13.1, let's all hope everything all goes as planned and as smoothly as possible. From a speculator's standpoint, the potential for the Lightning Network is more promising and exciting for me.
my only criticism is this hypocritical 9 days to attain 95% and then the month to keep 95% to activate before the christmas new year period. yet cores code is not set in stone yet. even 3 days ago it has changed. other proposals have had a RC running on mainnet right now and for months, code is fixed in stone for their concept.. yet core proposal doesnt even have an RC that is actually running on mainnet. or fixed in stone for others to confidently make their diverse implementations of. pools need to change alot. and while the code is still tinkering with even days ago. its silly to try suggesting activation before the new year. but strangely 9 days after RC is available(code set in stone) is hypocritically acceptable time for others to make their own diverse implementations based on cores RC next month. afterall there is no point using cores 2 month old code, thats outdated already. also to keep tweeking it daily to match the tinkerings. and then told 'all is fine rush it, rush it rush it,' but simultaneously core have been saying it will take them a year to code something similar whats already an RC of other proposals followed by 6 months for others to make their own diverse versions after cores version becomes an RC..(before activation can even occur) its has all been a bait and switch double-standard hypocrisy. afterall where is all the safety rhetoric about grace period time for others to make diverse implementations that meet the rules even smart people should not be shouting "now now now" simply to uphold their old "safety concerns" |
|
|
|
99% of the issues are all due to user error. The vast majority of those being unconfirmed transactions because people do not set proper fees. There have been very few legitimate bugs and those bugs are of low severity, just minor nuisances. Those bugs are also fixed very quickly when reported.
so ignore the 1% because rush rush rush.. got ya ok lets put my waffle into a simple question.
knowing it requires 95% over a month. where start of month needs to be at 95%, throughout month, and end of month needs to be 95% (3831 of 4032blocks)
It only requires 95% over one retarget period, starting on November 15th. and i said for a activation pre christmas requires the retarget period to begin at the latest november 24th.. thus only giving 9 days to go from 0-95% to then be constant 95 for the period. remember you replied to me about people who wanted a pre-christmas activation. so i was showing the requirements needed to get it. which i see you avoided answering as a bad thing. but subtly suggesting people just just run it and trust it works are you saying mining pools should drop their "legacy" (nodes as you call it) at the latest november 24th and use only core 0.132 from november 24th because its safe to all rush to run before christmas? honest answer please
What are you even asking? In order to signal segwit support, they have to stop using their legacy nodes and use segwit capable ones. If there is a "rollback" (which is impossible without a hard fork), then they have previous versions they can use unless they are so stupid that they don't use a VCS. even without signalling support. pools can run a node on the side to ensure it can import/export keys, ensure theres no trojans, send tx's to see if they get rejected. again before flagging. even without making a block. (imagine it usernode to usernode). use actual bitcoin transactions in combination with the segwit signing procedure to see if it reveals bugs when using real bitcoin transactions. as oppose to the false transactions on testnet. this can be done without activation. to trule see how it interacts with 'legacy' nodes within the real blockchain (im talking tx relay not block creation) there are many other tests that can be done onchain without having to actually activate it. but still do things onchain i do love how you are brushing possible tests that can be done purely to push the rush rush rush rhetoric tested on testnet.. tested on testnet.. tested on testnet..
thats like saying testing it on Clams or other alts... meaningless
it needs testing on bitcoin main net before settling minds can then say its safe to then flag consensus.
so stop thinking it should be active by christmas and atleast settle for atleast spring next year (if people are doing the right thing and checking)
It is impossible to test on the mainnet without it being active. It is tested on the network most analogous to the mainnet which is the testnet. even without signalling support. pools can run a node to ensure it can import/export keys, ensure theres no trojans, send tx's to see if they get rejected. etc etc etc again before flagging. expecting pools to just change from legacy based on "trust" and not doing their own due diligence is a flaw in security. its better to tell people to expect a spring 2017 .. rather then go with people shouting "activate pre-christmas" |
|
|
|
I hope that everyone collaborates and starts mining towards segwit activation as soon as possible and we avoid any idiotic fights like the ViaBTC morons going against it. They put a lot of effort into codding it so it would suck if they delay it because of that.
translate I hope that pools review next months release. tests it onchain and ensures it does everything it should do as standard and able to do what it should BEFORE mining towards segwit activation when confident though devs put a lot of effort into coding it, so it would suck if pools rush it because peer pressure. but rather done due to individual confidence in the code they are using based on their own review, and again not based on "trust" by others. |
|
|
|
I would like to see how you get them to use bank cards. They can hardly know how to use computers.
paper money is becoming unfashionable. i havnt touched it for years. even bitcoin sees itself as if paper money has lost its utility. for the elderly, to teach them how to use a card does not require computer lessons just walk up to a retail counter and when they tell you the total, wave this plastic card over a machine (NFC card) like its a magic wand. it saves counting your pennies and worries of accidentally handing the shop the wrong money. even things like an elderly bus pass is simple enough. just wave it infront the person and your done if the retailer requires a pin most pensioners already know how to use an ATM, not rocket science |
|
|
|
for every sell there is a buy.
I dont think you understand how markets work, because only the bid column counts, if there are no buyers you cannot liquidate your wealth into equal amount of value in other currency. So a deep bid column is critical. If people are selling, the bid column gets thinner, and as a result price usually drops to (ask+bid)/2 levels. So a whale selling is a big deal, because if nobody buys up the excessive ask orders, then the price will go down. It is a powerful form of veto. its a powerful DISCOUNT DAY. .. temporary price drama.. sellers lose due to price drop, buys gain due to discount.. infact id take my buy orders off the market and let them drop it and then buy even cheaper. now for the big picture. its just temporary price drama.. Past: person A had it.. future: person B has it.. overall bitcoin has not been destroyed, there are stil 16m coins in circulation. all that has changed is whos hand it is in..
second part.
exactly my point. if the rich want power over bitcoin they need to get involved and actually be part of the consensus. you have proven my point.
blockstream investors get a vote by being part of blockstream and thus have a connection to the nodes.
but just standing on the sidelines not even having a real tie to security of bitcoin has no power.
$1mill funded address vs $0.10 funded address does not matter. it does not cause more hashing power to magically protect the network more. or less.
what does protect the network is the diversity in getting involved with the network by being part of the peer to peer(node) security
do not confuse the tx peer to peer spending. with the network peer to peer security. they are 2 separate things.
hoarding coin in an address does not affect difficulty. does not affect hashing blocks does not affect consensus.
rich people cant just proclaim their wealth. they actually have to DO something
Of course, I am sure people who have > 500,000$ in bitcoin host their own node, and broadcast their transactions from there. It would really be a small cost to for that security. Especially if they are investors, they probably invest in other businesses, that host nodes as well. So a whale owning bitcoins, and investing it in many places, is good for bitcoin, and makes the node count grow. but just holding 200k in coins. has no power alone.. it does not improve security if 1 person has 200k coins or 100 people have 2k coins.. actualy being a node and actually doing something more then holding makes you worthy of having a say of the network. If you hold 10 billion$, you can buy a lot of shares in a bank and have enormous influence. In bitcoin if you hold 100 BTC, you are rich in some people's eyes.
just having $10bill but not buying shares.. makes you powerless so yes if you have money you can buy alot of shares/ have alot of NODES to gain influence.(though this can be deemed a sybil attack) again just having funds in a bank does not make you own the bank. you have to be part of board of share holders again just having BTC in address does not make you own network. you have to be part of consensus of nodes I am sure most rich people have shares in the banks they hold their money in, there is no reason to not have a stake in your own financial protection. Same with bitcoin, rich people host nodes, hire programmers , fund audits of code, ,etc... and they should use the nodes as the vote. not just waving a public key in the air. |
|
|
|
|
Show Posts
