From a layman's point of view (I'm not a coder) I vote yes, because until now I can see only advantages. If someone of the anti-segwit faction can point me to a text where the disadvantages of Segwit are explained in layman's terms, be welcome!
But I am also in favour of a conservative block size increase which takes into account the worldwide average upstream internet bandwidth growth. Because I think while for real micropayments (<10 USD) off chain solutions like LN might be better, for payments with a little higher amounts I prefer the blockchain.
hmm another guy using the latest script buzzword "conservative" d5000 you do realise the 'fee's and penalties of LN.. you do realise the confirmed tx maturity after LN settlement.. (CLTV aka 3-5 business day funds unavailable) you do realise the confirmed tx revokes after LN settlement.. (CSV aka chargeback penalty) they have already estimated that to open a channel for 10 days requires 0.006btc fee to be deposits to cover all the costs/possib penalties of using LN $4 just to use the LN service. LN has a niche for some users, but is not the solution for all users. even the bitcoin usage stats of 'days destroyed' revealed not everyone is spamming the network multiple times a week.. but core got those stats removed from known public websites to hide that and pretend everyone is spending funds hourly to need LN its techy but if anyone want to read.. scroll down on the link to the 'results' and see their excel sheet of all the penalties and costs of use they intend to have https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-November/000648.html |
|
|
|
|
most people with internet will pay for internet whether a full node or not.
so dothebeats $36 a month is $36 a month no matter if he play games, watches porn or is a full node..
also he says he uses a gaming computer thats always online 24/7 anyway.. so electric is no different.. because he already leaves it on already without being a full node. so there is no extra expense..
meaning it costs no more, nothing, ziltch.. for dothebeats to be a full node
whats next..
?try to include his house rent/mortgage as a factor..?
?hire a family member as a node 'administrator'..?
to try adding on fake costs
|
|
|
|
i disagree. it is not a civil war unless we make it one.
currently we are waiting for the miners to decide on the acceptance or denial of SegWit (the proposal they are signalling- BIP141 IIRC)
and users have only nodes to voice their opinion and there are only ~5000 nodes and lot more users. so i want to know out of the 929828 members on bitcointalk and ~2 million daily visits and more other places how many want, don't want or even have no idea about BIP141
and as i said in OP, this the results will just be results.
(so far 126 times read and only 7 votes!)
you do understand segwit right?? you understand that although when confirmed in a block old nodes dont fully validate the tx. but instead blindly look passed it..('compatible backwards' cough cough) BUT before confirmation because it appears as signatureless tx (anyonecanspend) old nodes can cause issues. this is why 0.14(the implementation with p2wpkh and p2wsh key generation wallets) wont be released before activation. and then after activation, 0.14 wont connect with non-segwit nodes for relaying unconfirmed transactions to avoid the silly things that happen at unconfirmed relay level. they could connect to old nodes and just relay old transactions. but lets be honest segwit-node users wont bother doing all the setting changes to mix and match tx's. so will just connect to segwit nodes to make things simpleyes after tx are passed by segwit nodes to a segwit accepting pool, they will then relay block data out to all nodes new and old.. but due to the unconfirmed tx relay part. segwit will divide the network at unconfirmed tx relay level segwit done as non network consensus node activation is going to cause issues.. but core wont tell you about this until after its activated as a strongarm motive for everyone to jump onboard at a rapid pace to join their nodes. or be left ignored. (changing the network) technically its all the 'same network' (due to all nodes connecting to a pool), but the nodes become more biased to only communicate with their own kind. where it becomes more work for a pool to send out 2 different variants of a block. --witness  again core will try to advertise the need to get nodes to upgrade to gain more connections and be more part of their side of the network (although in their half truth twisting of words is one network) this is why it should have been a proper network consensus rather than a emulated consensus of just the pools, so that by being a full network consensus before pools, allows the nodes to be ready and fully compatible rather than just SPV compatible to segwit as you can see by segwits own guide. if not upgrading they want you to set up another node to 'filter' your unupgraded node through a segwit node (facepalm) when sending old tx's but you wont receive new tx's. it also allows segwit nodes to be the controller of what becomes a 'valid block' or not. rather than the old node doing independent checks https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/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. Because the newer node knows about the segwit changes to the consensus rules, it won’t relay invalid blocks or transactions to the older node—but it will relay everything else. When using this configuration, please note that the older node, if it uses Bitcoin Core defaults, will not see transactions using segwit features until those transactions are included in a block. Configuration:
For the newer node, start it normally and let it sync the blockchain. At present, you cannot use a pruned node for this purpose because pruned nodes will not act as relay nodes. You may optionally start the newer node with either or both of the following command line parameters so that it treats the older node as special (these options may also be placed in Bitcoin Core’s configuration file): -whitebind=<addr> Bind to given address and whitelist peers connecting to it. Use [host]:port notation for IPv6 -whitelist=<netmask> Whitelist peers connecting from the given netmask or IP address. Can be specified multiple times. Whitelisted peers cannot be DoS banned and their transactions are always relayed, even if they are already in the mempool, useful e.g. for a gateway 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): -connect=<IP_address_or_DNS_name_of_newer_node>  |
|
|
|
there could be a lot of people that want both or undecided because people are stupidly dividing the communiity by thinking consensus should be ignored and it should only be a one or other decision.. your pool is just going to be a biased civil war whos on whos side vote. rather than a community consensus open choice. |
|
|
|
Banks already have safe deposit box where anyone can put anything valuable that may also include bitcoin paper wallet. Its better not to tell them your bitcoin address, they may report it to government and they may charge you in the name of tax.
An address is not enough to prove an ownership. You could show an address in the bank and then say it doesn't belong to you. How would they prove it?  You'd need a private key, and showing the key to anyone is like giving them your money. If someone gained access just for a few seconds and managed to take a picture of it, or swipe it in front of a camera, your money's gone. you dont show the private key..!! you sign a unique message and pass them the signature to show proof |
|
|
|
|
put in another option.
"yes but only with real consensus onchain scaling beyond the one time boost"
|
|
|
|
but bitcoiners are too paranoid to share their private keys with banks, no matter how safe they are
... says "karpeles" lol who the real karpeles has hundreds of thousands of coins of people that stupidly handed them over to him |
|
|
|
What's the difference between what you just mentioned and people using a cryptocurrency that's made by the banking system and governments ? It wouldn't make any difference as you are not the one controlling. It also wouldn't make sense , banking system wants to control users and while having your private keys stored on the bank , you could have a copy at your home etc... It simply not gonna work as It won't be possible for them to freez , limit your account etc..
by banks having full control of funds they end up storing it in cold store reserves and only offering database mysql balances to customers to pla around with (like exchanges like coinbase have now) by using LN commercial hubs. the hub has code that can even after settlements(onchain withdrawal) get confirmation, prevent funds for being spent (CLTV maturity) for hours/days .. and then while maturing allow chargebacks (CSV revokes). yep LN is trying to emulate banking services (and banking headaches) yep LN becomes like a bank. which is where people compare it to a paypal2.0. blockstream want paypal2.0 |
|
|
|
Because keeping private keys (by yourself) is troublesome, one of bank's services in the future will be keeping private keys for customers. They won't need to create their own currencies if they can convert enough of the population over using this system.
The customer visits bank and is provided a "bank account" which is a managed address on the bitcoin blockchain. The customer can still have personal addresses, but this address will be secured and guaranteed by the bank and have attached banking services.
thats your "theory" the actual reality is blockstream will be the LN hub that holds peoples funds in a multisig of them having 50% permission of funds, so they can 'manage' and set penalties. banks already are investing in blockstream and blockstream have to develop LN commercial hub service to repay bankers investment through the LN fee's. but banks wont actually integrate bitcoin as a bank service direct.. banks wont handle bitcoin. they are going to have their own fiat 2.0 called hyperledger sidechains. also why oh why are people actually advocating to turn bitcoin into a permissioned service that is tethered to banks. indirectly via investment. deluded to want banks to hoard peoples funds directly... seriously!! wake up |
|
|
|
You don't mention that Unlimited split network if it reaches only 51%.
you have no clue, try reading the code. run simulations. research and learn best unbiased option
a real consensus release where core include dynamic blocks and segwit.
starting with 2mb base 4mb weight.
If segwit solves the scalability issue then there's no nessesary to make dynamic blocks. What for? Just to gratify 3 weepers? it doesnt. segwit is a one time temporary boost of tx count, that only boosts if people use segwit keys. later that boost is taken away when future core features re-bloat the blockchain. again try reading the code. run simulations. reseach and learn. LN (later feature) is not a be alll-end all solution. its just a side service that puts peoples funds into permissioned contracts. these contracts are not suitable for everyone. but i hazard to guess you care and are more imagining the profits you can make from being a hub(commercial service), rather than thinking about bitcoins permissionless no barrier if entry ethos |
|
|
|
|
best unbiased option
a real consensus release where core include dynamic blocks and segwit.
starting with 2mb base 4mb weight.
where nodes upgrade and show desire for and then at a certain point. pools then vote for when they see that nodes can validate their blocks
meaning pools dont see the big risks if they see node majority acceptance.
that way everyone gets what they want
and brings core back onto a level playing field with the network.. rather then the dictator path they want.
decentralised diverse consensus driven code updates is what bitcoin should be about. not dictator dev driven code that bypasses consensus.
|
|
|
|
Every hardfork without overwhelming support can cause a network split.
and thats why all consensus using proposals have gone with "overwhelming support" before even thinking of activating. also for the silly people comparing it to ethereum. ethereum was not a consensus proposal it was a intentional split. (some call a bilateral split)where by extra code was added to intentionally ignore the opposition rather then find mutual agreement. google: ethereum --oppose-dao-fork no other bitcoin implementation wants an intentional split. but some devs on segwits side want those not supporting segwit to split away. by calling anything not supporting segwit an altcoin... even though the nodes not supporting segwit are actually running on the mainnet so are not an altcoin (showing how misinformed and desperate segwit enthusiasts are getting)
core actually advised non segwit supporters to intentionally split.. non supporters laughed and refused What you are describing is what I and others call a bilaterial hardfork-- where both sides reject the other. I tried to convince the authors of BIP101 to make their proposal bilateral by requiring the sign bit be set in the version in their blocks (existing nodes require it to be unset). Sadly, the proposals authors were aggressively against this.The ethereum hardfork was bilateral, probably the only thing they did right-- again only core, who have stated core would do an intentional split to get segwit added, if things got desperate enough 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.
the real funny part.. if it reached 90%.. instead of activating it and just causing a bit of TEMPORARY consensus orphan drama risk.. they would prefer to split the network.. (foolish knee jerk plan) core do not trust or want consensus, its why they decided against nod consensus and instead skipped to a fake (consensus emulating) pool vote |
|
|
|
So then why do you advocate for an artificial limit upon the size of a single transaction?
the most simplest answer because 1tx of 1mb.. holds up ~2499tx on average for getting into a block |
|
|
|
Paper wallet is a very secure method of storing bitcoins offline. But its main problem is storing without damages. For that, I found a solution;
If you have Printer in your home, Scan your bitcoin paper wallet as JPG image OR PDF and save it in a new folder.
Next step is convert this folder as rar OR zip file with password. Then store in your Memmory card, Pendrive, Memmory card OR personal computer. It never become damaged.
We can extract these files whenever we want. Then we can take prints if needed.
you can still burn. step on. smash with hammer. you can hand it to a kid who can snap off the usb end from the plastic cover  lose out of your pocket. thief stealing it. connect it to a computer with a virus. electric shock. lightning strike, car accident, the list goes on. .. separate note.. having a paper wallet has its own utility.. putting it on digital media or a PC is no longer paper wallet.. emphasis on the word paper |
|
|
|
when in fact they, personally, just desperately needed Bitcoin hobbled by a split in order to promote their altcoin investments.
lol your the one that wants to split the network.. no one else What you are describing is what I and others call a bilaterial hardfork-- where both sides reject the other. I tried to convince the authors of BIP101 to make their proposal bilateral by requiring the sign bit be set in the version in their blocks (existing nodes require it to be unset). Sadly, the proposals authors were aggressively against this.The ethereum hardfork was bilateral, probably the only thing they did right-- and also hows your monero and hows meeting your contractual obligations in blockstream to get the next tranche of fiat from investors oh and hows the satoshi roundtable meeting with the hyperledger guys, going all as planned? and as funny as it was for you to try and find a different bip that took many months to activate.. to pretend segwit is on track.. i can show a chart from your own colleague that shows another bip that got accepted far sooner.. to show segwit is not on track.. bip 112 took only 2 months to get to 100%. yet segwit is at its second month and still at only ~25% |
|
|
|
i personnally am not bothered by the wait, i was just stating that, as of this moment, the only issue created by block chain size is the initial setup of full wallet, by this i am implying that there is no problem, as not many people need that full node on their pc. those that want to run the node should expect some time to be used. you want to start a new domain, you expect a possible 24 wait for DNS propagation. technical aspects to all project take longer than the standard use version
and my reply was that you can have the cake and eat it. rather than having the implementation useless until syncing. thus holding people up and the sync becomes not discrete and noticable enough to frustrate you can be a full node and not have to wait. simply by devs releasing a implementation that emulates a litenode instantly while it discretely syncs in the background, unnoticed because its no longer a hindrance to utility. So could something like this be one way to solve the issue of node count that the community has expressed concern over recently? I'm not well versed in what happens when you run a node and how a lot of the technical aspects affect other portions, but this could be one way to maintain node numbers in my opinion, assuming that you can take the blockchain from the node and sync it to the wallet. ---my reply below is about an earlier concept that deals with the problem of a node waiting to sync. as i said. it would be a full node. this extra code to grab the utxo set from its connected peers first. and then syncs the blockchain second. its not an electrum node with a few tweaks. its a full node with a couple tweaks so seeing as it would be a full node, with all rules. and also as it syncs it is checking the data like all full nodes. all that changes is that its actually able to spend funds at syncing from block 0 instead of waiting for block 420k+ to be properly usable. its not like electrum or other lite wallets that rely on a central server. my idea is a proper full node but just things in a different order.. grabbing utxo data from nodes, probably safe to get utxo from all connections to have multiple opinions. and then build the blockchain after. thus solving the long wait where users have to wait for the node to build its own utxo set ---to address morantis's new scenario about one source of data that multiple softwares can use. you could set up a bitcoin Deamon on the data store. and then get other 'client' software to RPC call the data from it but then its not really what i would call a full node anymore for the 'client' implementations |
|
|
|
|
cant you just have a bitcoin node set up to be an electrum server. and the the other users in your intranet, just use electrum to connect to your 'server'
other people have already got other local wallet systems that API call specific servers to grab the unspent data required to locally make a tx on their own system away from the 'server'
..
may i ask why do you want to have a 'full node' that doesnt have its own full dataset..
is it so you can sybil attack by having hundreds of 'full nodes' appearing on the network but only having one data store or is there a specific reason for requiring a fullnode without having the data locally.
|
|
|
|
|
his 'chainwork' is him just buzzwording terms to make it sound less like satoshi designed bitcoin and all the variables are words he decided on.
secondly its to do with bringing the buzzwords inline with his future sidechains that use the same variable so they are all 'compatible'
|
|
|
|
yep thats another option. like i said a few food items that are internationally recognised and a few electrical items try to get away from just being just a bitcoin<->fiat site. as thats not really highlighting bitcoins separation from fiat
Yeah, I wasn't discrediting your idea (it's pretty good imo), just adding that Big Macs are a common good to do price comparisons with  Now, it would be better if Big Macs could actually be purchased with Bitcoin ofc. Aside from that, in your previous post, you mentioned that troll boxes could de-rate the website in question. How so? By having a troll box, your website doesn't automatically become a 'crackpot website', since the website itself isn't affiliated with anything said in the troll box. Poloniex has one, wouldn't call them a crackpot website. [/quote] but poloniex is not really top of the list of exchanges.. even with hundreds of different currencies.. its not as popular/professional as some of the others that actually have less trading features, but dont have a troll box. for instance btc-e didnt really get 'profesional' many people treated it as the joke site compared to mtgox bitstamp back in 2012-2013 yea it was popular. but for the wrong reasons. so although the OP could add a troll box, it may make people sign up to chat on it. and be 'popular' people will think of the site as being a chatroom with a price ticker. rather than a price comparison site with a chatroom it all depends on what path the OP wants to take the site. and the goals he wants to achieve |
|
|
|
|
Show Posts
