|
what i really find funny is companies that have been around for 6 years still being referred to as "start-ups"
|
|
|
|
IMO the current bitcoin mining operation is centralized by the likes of Bitmain and some mining pools. As far as I have read, LN would lower the fee a lot, off-chain transactions would lead to more user privacy, and exchanges would not be prone to hackers. Payment channels/hubs getting centralized is a possibility, you would need a lot of revenue backup to operate hubs and some big players like Coinbase would dominate, but the same thing is happening now. Hard fork is not backwards compatible, and with the rate bitcoin is getting adopted increasing blocksize would be a temporary solution, what happens when limit is reached, another hard fork? Segwit alone is not a scaling solution, LN is. If it could be said that LN would lead to centralization then it is not wrong to say that bigger blocks would lead to centralization simply because only a few miners would be able to afford to run full nodes, centralized entities.
As a user, I do not see why not LN. I am not against bigger blocks, but LN could be the permanent scaling solution. Using temporary solutions and letting bitcoin users go through periods of uncertainty would be bad to the community as a whole. The prolonged scaling debate and increased fee has already affected bitcoin, alts have increased in value during this time, continuing this would be illogical.
LN does have a niche.. but if you actually look beyond the utopian propaganda illusion and see it for what it is. its not a solution for everyone. so dont be under the impression that LN is the solution... its just a OPTION. as for the bigger blocks kills miners.. LOL miners just use ASICS, which connect to pools.. an ASIC does NOT have a hard drive. an asic does not handle the blockchain, an asic does not validate transactions. miners dont have any worries about the blockchain. all they get is a few hundred bytes of data. that the asic re-hashes a few trillion times a second and then sends out a solution thats only a few hundred bytes long.. not megabytes, not gigabytes.. as for nodes.. the fact that most dynamic proposals (if using real network consensus) would grow only when the majority of nodes accept such change.. then its not going to cause issues. what is going to cause bigger node dilution issues is all the prunned/stripped/filter node crap that (using torrent analogy) means there is less seeds of full data for other nodes to leach from |
|
|
|
this week has proved one thing
89% pool agreement flagging is possible
segwit alone only got 10% in the first week and stalled around the 34% average of 6 months
2mb and segwit getting 89% in a week just goes to show all the chest beating from a particular group refusing to code 2mb was just wasting time. if only they released a 2mbsegwit in summer 2016 alot of drama could have been avoided
Your last paragraph is misleading. The 89% is not signaling 2mb first. They are signaling segwit first, and there is some contingency regarding the 2mb aspect of it, but don't mislead with your attempt to spin what is actually being signaled. By the way, a lot of us understand the whole ambiguity of this situation - in that some of the folks within the segwit2x are in fact wanting to argue that 2x is a given, when the only part that seems to be a given is the seg wit portion.. As already stated many times in this thread, the 2x part is contingent upon passage of time, code writing, testing and consensus.... the consensus component of the 2x, that you and some other big block nutjobs seem inclined to do, should not be assumed. 34% signalled from november2016-now for segwit first.. and 2mb at some unknown time in the future(no promise/hope) now a new proposals has within just one week got over 89% signalling for segwit AND 2mb within 3 months of segwit. meaning the desire for 2mb exists and the majority is happy to have it activated within 3 months. though i agree there is a major difference between "flagging" and "handling".. meaning the 89% may flag purely to get segwit activated but only a small percentage may have the actual codebase running to cope with the 2mb part. (EG they just running core 0.14.x while false flagging for segwit2x just to get segwit active. but then backtrack during the 3 month grace of 2mb) but thats something i highlighted in a few messages that got deleted. so it seems the only way to avoid deletion is if i word things a certain way. Edit: seems one of my messages didnt get deleted now we just have to see if we can get nodes to download it (once its finalised and reviewed for RC) to then get a NODE consensus... for pools to have confidence that if they made such blocks.. the nodes wont still be running old code to reject blocks bigger than (1*1000*1000).
what people seem to forget is its not simply about waving a flag in a block.. its about consensus of nodes actually running code rules that allow bigger base blocks and consensus of pools creating bigger base blocks.
at this moment the empty sybil flag waving will just cause segwit to activate, but no guarantee of base blocks over (1*1000*1000) being accepted because from bitnodes stats, it shows no one is actually running the segwit2x (btc1) codebase to enforce it
i just wonder how many blocks are waving flags.. but not running the actual implementation that has the code. thus basically sybil flagging
real funny part is
all these bips pushing hard to "activate" segwit..
but no one will be able to actually make a segwit transaction when activated...
there will be delays and excuses of why people have to wait for blockstream to code a version which allows the segwit keypair wallet function on mainnet
so dont expect utopia on activation day.. plenty more drama after that of getting people to download yet another version after activation and then the cluster f**k of drama of getting people to move funds from legacy keypairs over to segwit keypairs
|
|
|
|
I'm just curious. What if bitcoin and any other alts market fall and you invested all your money into this. Would you rather do Panic Selling? and How would you compensate all your losses?
im highly invested. any time i see a price crash announcement.. i laugh and then say "discount day" |
|
|
|
having to lower my standards... | franky1 | Weak | no | no | Better than nothin | Weak | acceptable | prefer | no |
[tr]
[td]franky1 [/td]
[td][glow=red,2,300]Weak[/glow][/td]
[td][glow=red,2,300]no[/glow][/td]
[td][glow=red,2,300]no[/glow][/td]
[td][glow=#00BB44,2,100]Better than nothin[/glow][/td]
[td][glow=cyan,2,100]Weak[/glow][/td]
[td][glow=yellow,2,300]acceptable[/glow][/td]
[td][glow=yellow,2,300]prefer[/glow][/td]
[td][glow=red,2,300]no[/glow][/td]
[/tr] even though i reduced my standards.. its just the cludginess of the bips related to segwit.. the empty promises/ half gestures.. and still reliance of devs controlling when the next blocksize increase occurs (meaning endless debates lasting a couple years) its like they offer you a spoon of sugar but then put a fly on top |
|
|
|
Kleiman was in and out of hospital many times .. including times where 'satoshi' was healthily writing code and posts online, thus cant be the same person. kleiman was heavily interested in investigating and identifying people and was a government man.... 'satoshi' was interested in a non government non identity.. thus cant be the same person the 'trust' kleiman set up for craig wright (the only 'claim' of linkage) was quickly debunked via proof that the trust only contained PUBLIC keys(anyone can copy) and was only (falsely)validated using a signature that is public knowledge(pre-existing) and part of the blockchain and nothing to do with 'millions of coins' but a transaction PUBLICLY visible in the blockchain that anyone can copy and paste. in short the 'signature' amounts simply to someone doing a search for an existing signature and then claiming its proof of identity to millions of things that a certain identity might be linked to. to which if i done something similar, i could simply do  thank you google and 1 second of efforti am bill gates i own everything from microsoft or medical cures so can we drop the klieman/wright myth. as thats drama that got debunked 1-2 year ago if the only requirement to being satoshi is having said signature MEUCIQDBKn1Uly8m0UyzETObUSL4wYdBfd4ejvtoQfVcNCIK4AIgZmMsXNQWHvo6KDd2Tu6euEl13VT C3ihl6XUlhcU+fM4= we are all satoshi |
|
|
|
|
old news
research: hyperledger
|
|
|
|
|
this week has proved one thing
89% pool agreement flagging is possible
segwit alone only got 10% in the first week and stalled around the 34% average of 6 months
2mb and segwit getting 89% in a week just goes to show all the chest beating from a particular group refusing to code 2mb was just wasting time. if only they released a 2mbsegwit in summer 2016 alot of drama could have been avoided
|
|
|
|
You talk about importance of node numbers enforcing certain rules not for the first time, but how you know what nodes are economicaly important and what are basically worthless? Or you really believe 1 node = 1 vote  theres many aspects to it.. theres many reasons for having a distributed decentralised network of nodes. things like (using torrent as an analogy) if your connected to 8 seeds and need to sync(your the leacher for now) and the seeds have 4 nodes of 485,000 blocks but another 4 nodes have 484000 blocks. your going to grab data from the 485,000 nodes as you define that as the most complete list. however you find out that the 485,000 nodes are on the old rules you end up orphaning them blocks and banning the nodes.. leaving you only seeing the 4 nodes with a height of 484,000(new rules) as that becomes the new visible highest height (complete chain) so its not the case of just relying on one source of data... nodes prefer to have multiple sources that way if one source is 'wrong' they can grab data elsewhere.. so its important there are multiple sources of data, and that the majority of those multiple sources have the same rules as you do.. thats why its best that there are more then just 70 nodes all run just by merchants. but there are 'backup's too. which helps put less strain on the merchant nodes needing to be seeds because people can grab data from other locations, should a merchant get shutdown or ddosed or just over strained by too many leachers trying to connect to merchant nodes. .. once you grasp the need for the decentralisation of the data.. you then can move on and grasp why its best that those decentralised diverse brand nodes also agree to the same rules as a majority, to avoid orphan drama. .. once you grasp that. you realise by having your node agreeing to the merchant rules you can spend with that merchant because they see your tx. also to flip the argument, if the merchant see's its only getting bad data and the majority of the community is agreeing to other rules.. the merchants would treat the most popular chain as the main chain. and the bad data least popular nodes as the alt. thus its not a sheep follow merchants who follow pools.. its about symbiotic relationship of consensus of everyone finding something agreeable. .. having grasped that..you can then move on and grasp that bitcoin is revolutionary because it doesnt rely on everyone just leaching off of one pool of data but each node validates independently which makes the network stronger and less vulnerable to central-point-of-attack vectors. it also allows sharing of data to not put a strain on a central point.. it also ensures no central point decides the direction.. .. things would /could go very wrong if everyone was a leacher to just lets say 70 nodes all colluding to a single cartel. and this is why consensus only moves the network forward when independant people agree that the new rules that are in benefit to the community.. by the community having nodes that have the most reliable chain that is acceptable to the majority. The only support/acceptance I find reliable is the statements from companies, and there seem enought SegWit2x support/acceptance from the important companies to guarantee 2MB. The only question remains whether there going to be split if 1MB gets enough holdout support.
signing a PDF is one thing.. changing a few bytes in a flag is one thing. but in the end the nodes should only flag when they actually have the code to handle what they are flagging. otherwise its an empty gesture that falls flat on itself when 'activation' occurs. EG lets say 80% want X and flag it,, but 75% actually are running A. X gets activated(false pretence). but then a clusterf**k of orphans because 75% are rejecting the activated rule. because they dont have the code to handle the new rule. they just waved a flag. |
|
|
|
|
instead of just making a node and telling people the possibilities and then letting it wonder free in an open decentralised manner.. the ICO concept is very much different
unlike bitcoin, which never began as a ICO, nor organised by a 'company' who made promises(contracts) to hand X premined coins you customers Y over a term...
i see ICO's becoming regulated just like 'shares' are.
ICO's will be hit by bureaucracy of the 'founders' home country. all because of how organised and centralised the concept of ICO is.
that said. most ICO's are just crap coins, so treat them like penny share trading if your gonna risk it.
best advice is. only waste amounts you are willing to lose.
EG if you normally spend $20 on a evening take-out/fast food, which naturally/literally ends up in the toilet 6 hours later.. make urself a sandwich instead and use that $20 on an ICO.. that way you never 'lose' (british pun: never loo's)
|
|
|
|
Segwit2x doesn't have a codebase or dev support last I checked. Unlimited has both of those (inb4 "but it's buggy", etc.).
segwit2x does have a codebase https://github.com/btc1/bitcoin/https://github.com/btc1/bitcoin/blob/segwit2x/src/consensus/consensus.hsegwit2x now has code for a 2mb base block 33 if (!BIP102active(nHeight, fSegwitSeasoned)) 34 return MAX_LEGACY_BLOCK_SIZE; 35 36 return (2 * 1000 * 1000); 37 } ... which activates 3 months for th 2x after segwit 13 static const unsigned int BIP102_FORK_BUFFER = (144 * 90); .. but not really a Release Candidate so its highly possible the pools flagging for segwit2x are not running the codebase so all the flag waving of blocks is still kind of 'sybil' (empty/fake gesturing). so things are still up in the air. Remember that miners don't trust Core at all after they breached the Hong Kong agreement.
the hong kong/ late 2015 consensus round table meetings funded and sponsored by barry silbert.. is the same 'agreement' as segwit2x but atleast there is some code available. now we just have to see if we can get nodes to download it (once its finalised and reviewed for RC) to then get a NODE consensus... for pools to have confidence that if they made such blocks.. the nodes wont still be running old code to reject blocks bigger than (1*1000*1000).
what people seem to forget is its not simply about waving a flag in a block.. its about consensus of nodes actually running code rules that allow bigger base blocks and consensus of pools creating bigger base blocks.at this moment the empty sybil flag waving will just cause segwit to activate, but no guarantee of base blocks over (1*1000*1000) being accepted because from bitnodes stats, it shows no one is actually running the segwit2x (btc1) codebase to enforce it p.s only reason i rant/repeat myself. is due to the biased censorship deleting my posts to hide the facts, so i end up having to repeat things just for the hope that some posts get missed out in the deletions so that they actually get read.. because alot of the facts just get deleted. i would repeat myself alot less in topics if it wasnt for moderation deletions |
|
|
|
|
a reference client should not be decision making.. but having a client that allows adaptability, and includes things as default when a consensus is reached.. not the other way round.
|
|
|
|
It s called core.
What kind of core is not central?
One which openly allows people to contribute. There is a core team of devs within Bitcoin Core, but they don't create absolutely everything. The best way to make Bitcoin Core less centralised is to participate yourself.
There can easily be a different group of devs in the future, but if that's how you view centralisation then they will be just as "centralised" as Bitcoin Core is now. Couldn't have said it better myself... As I think someone previously said in this thread, developers are only "external" to Bitcoin. Adding more developers or removing more developers won't necessarily have an effect on the "centralization" of Bitcoin. many have tried to 'contribute' but found their commits declined because it does not follow the path agreed at the late 2015 BScartel meeting. the only commits that usually get accepted by 'independents' are spell checks or minimal error correcting. anything in regards to rule changes /upgrades, have to follow the BScartel decision |
|
|
|
blah
nope.. sorry but its devs that end up controlling things.. you only think pools have control because the DEVS programmed their implementation to avoid consensus and allow pools to be the vote. however pools are limited by the rules laid out by the implementations .. these rules are programmed by the DEVs .. in short. imagine if pools with the heighest hash power all decided one day they would make blocks using sha-3 guess what happens.. the nodes reject the blocks yep even if pools had exahashes more than any opposition, the blocks they make would get rejected. pools do not set the rules. devs do. and its the devs who have been trying hard to point the fingers at pools rather then themselves. EG luke JR programmed segwit to be pool initiated and it back fired, luke thought that h and his bscartel could easily buy the pools favour in the form of many all inclusive weekend parties.. but it didnt work so then devs decided to make proposals of POW nuking, mandatory activations.. but then try to hid that they are involved. .. in a better future.. what should happen is a 'reference' client has blocksize setting adjustable at runtime and the ability to download patches for bips. then the network as a whole can just flag what is desired by showing what features/settings are enabled..without a 'reference' client steering in only one direction based on what the devs of that client think is best EG no more 'lets make a office word package that in 2000 only has embolden text, then later underline.. but instead a wordpad where you can have it all and choose what you prefer. and have the ability to download new font packs(smart contract script) without demanding of the main software supplier having to have it bundled in when they deem fit |
|
|
|
bitcoin has never failed, the blockchain has always been working, nodes are up and running and spread across the globe, no exchange has ever suspended bitcoin wallet to investigate!
you seem to forget the 2013 Berkeley->leveldb event involving the issues with the locks. that caused alot of drama, including a period of time exchanges halted deposits/withdrawals to avoid issues until the drama was over. there is no point pretending something is perfect utopia and preaching utopia to the already converted. what is best is to accept there have been issues and there are issues and to learn from them and to fix them. EG some state that core is perfect and has no issues.. if this were true there would be no need for segwit or schnorr or increasing blocksizes or other things. |
|
|
|
|
good to see an implementation finally showing the main block size increase... and with a ~3 month from now activation.
seems i should keep my eye on updates daily, rather than sporadically(few times a month/when they announce RC versions)
im guessing things like this can change peoples opinions if all the other 'brands' followed suite with the same commits..
lets wait and see
........
i just wonder how many blocks are waving flags.. but not running the actual implementation that has the code. thus basically sybil flagging
|
|
|
|
No use supporting a coin that are not accepted for payment everywhere.  thats what matters most.. many people think its about price.. long term its about what bitpay / coinbase offer as the coin thats acceptable to their merchant tools/shopping cart API as for the exchanges.. pretty much all the coins will be on all the exchanges You are making contradictory statements (as always) It is no use supporting the coin which doesn't get traded (read listed) at major exchanges (and Coinbase is nowhere near being one). If we compare the impact of exchanges versus merchants on Bitcoin price, the latter will suck heavily as you yourself say ("pretty much all the coins will be on all the exchanges"). It should be obvious that most of Bitcoin value comes via exchanges, so Coinbase, Bitpay (or any other payment processor, for that matter) with their shopping cart API's will be utterly irrelevant if exchanges refuse to support a certain coin im not being contradictory at all, i just see things layers/dimensions deeper than most as always you think 'value' means price but value is utility anyone can have a coin with a large market cap anyone can cause a swing in the price but if you went to use bitcoin to buy something real.. and found out that the merchant tools (shopping cart) was using a different chain.. then your stuck with a coin that cant buy real things. .. as for the exchanges, most exchanges will offer swaps between the different chains.. thats where exchanges get their profits. from people doing swaps .. ok lets simplify it for many people instead of thinking about price of bscoin(segwit) bitcoin(legacy/classic) bitmaincoin(bitmains alt) and the fight for price. imagine coinbase, bitpay, purse, gyft and other real world purchase utility flipped to use litecoin for real world goods purchasing now imagine the impact of merchant services deciding a certain coin for utility.. and let that play into your scenarios.. knowing it has nothing to do with which 'bitcoin' has biggest price.. once you do that and come to that realisation.. and ran a few cause/affect scenario's... simply replace the word litecoin for any of the bitcoin upcoming forks.. and realise the same applies. its not due to 'price' but due to utility and decisions of services |
|
|
|
|
best thing is.. im guessing u do alot of sigcampaigns.. so instead of taking a daily /weekly withdrawal.. let your balance pile up and take a fortnightly/monthly withdrawal
(wording it in fiat terms to dismiss petty knitpick of random use of satoshi amounts which meanders away from the concept discussion)
EG if you make $1 a day stop asking for $1 a day and instead ask for $28 every 4 weeks
then when you get it ull have one unspend output of $28 instead of 28 outputs of $1..
to then use as a single input when you want to spend it
|
|
|
|
There is no single "Segwit2x" proposal that you can clearly point to.
i have to agree with theymos all the 'promises' of increase to a 2mb base block miss out on actually including code that actually includes a 2mb base block thus all same half gestures/ empty promises since 2015 |
|
|
|
Discussions should be as neutral and transparent as Bitcoin itself.
Updated the OP with some greater depth into the various proposals.
yet BU/EC: This is Bitcoin Unlimited or "Emergent Consensus", a proposal for miners and nodes to declare the size of blocks they are willing to accept. The reasoning for this proposal is outlined here. EC is not a BU branded 'product' BU brand call theirs 'Adjustable Block-size Cap' (ABC) commonly people call EC 'dynamic blocksize' which again is not a BU product seems by making EC a BU option. you will get people to basiedly not vote for EC it purely because YOU branded it as BU, knowing peopl will respond 'oh no i read on reddit that its bad bad bad' other implementations totally unrelated to BU use EC |
|
|
|
|
Show Posts
