Bitcoin Forum
April 27, 2024, 09:56:40 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 [904] 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 ... 1463 »
18061  Bitcoin / Bitcoin Discussion / Re: Bitcoin Master guide on: February 06, 2017, 09:03:00 PM
This is misleading:
"About 0.5% to 2% of blocks in one day will get orphaned."

Since this is a disussion about transactions, it seems to imply that 0.5% to 2% of transactions per day that are confirmed will become unconfirmed.

agreeing with danny that ultimately there is a 0.5%-2% BLOCKS get orphans.
but to clarify
so those tx's in that block do return to being unconfirmed which is a temporary issue because sooner or later they are added to a new accepted block.

however there is a
as said in previous post (on a good no drama day) in 0.004% or 0.25% chance of the tx not being added to the next block for either malicious reason or unintentionally struck off by how the network works.
example of where transactions are not added to the next block could be causes such as
Different peers can have different transactions in their memory pool.
plus other factors

so the ultimate worry(in regards to transactions) is alot less than 2% and far less than 0.5%(these numbers are about blocks, not tx's). and more so in the 0.004% risk area.  not ever getting confirmed.



"at least 12 blocks for high-value transactions"
Twelve confirmations?!  That's ridiculous. I'd trust a $10 million transactions with someone I didn't trust at all with only 5 ro 6 confirmations.

also agreeing with danny..
in a normal no drama day (no new soft/hard fork event activation or high orphan rate)
6 is usually the maximum.

the only possibly time to think about waiting 2 hours (12 blocks+) would be when something controversial (high orphan count) is occuring, which is usually only a once every couple year event, so it should not be wrote as if its a normal expectation.. to think about daily...
 but maybe wrote as a sidenote to people to expand the confirms they usually wait for if the blockchain is in the middle of a hard/soft feature upgrade that appears to be controversial on the activation day

kind of like saying..
you dont need to boil your water every to want a drink, but if you have precious children you could wait for the water to boil if you worry about their health. but maybe when there are some water pipes being replaced in the water network every couple years, then get more concerned about doubling your efforts
18062  Bitcoin / Bitcoin Discussion / Re: Bitcoin Technology on: February 06, 2017, 08:27:31 PM
It could be a good idea.

It just would make too many eternal unconfirmed transation pending, I don't know if there is any problem with this for the system.

nope because they are dropped unless there is only a couple hours left.
also CLTV allows confirmation and then locks funds from being unspent after (like the block rewards 100 confirm maturity)

thus mempools wont fill up with tx's waiting a day.
people either pay up to get priority.
or
their come back later and rebroadcast when matured/aged
or
they use ln as a voluntary service.
18063  Bitcoin / Bitcoin Discussion / Re: 1MB block size forever is just silly on: February 06, 2017, 08:22:03 PM
And since only 5% of the nodes and a minority of the miners support BU, core should win?

neither side wins..
rules stay the same until consensus is met.

learn consensus
18064  Bitcoin / Bitcoin Discussion / Re: Is Roger gonna tell us he made a simple transaction that cost a fortune again. on: February 06, 2017, 08:15:17 PM
That said, the include fee-rate is 'Fee / KB 0.00362056 BTC' which translates to ~362 satoshis/byte. This is ~3 factors higher than the recommended fee-rate. Fun fact: With Segwit, such a transaction would require a smaller fee rate than the equivalent transaction creating 187 outputs.

fun fact
segwit is not active
fun fact
segwit if activated will only offers the discount if the funds were actually using a p2wpkh addresses...
fun fact
not everyone will use them
18065  Bitcoin / Bitcoin Discussion / Re: 1MB block size forever is just silly on: February 06, 2017, 08:09:13 PM
who wants to keep blocksize at 1mb? I was under the impression bitcoin was meant to scale.

Increasing block size wont scale anything. You get scaling when two processes can work in the same time without waiting on the other.

With blockchain it would mean two or more blocks could be mined in the same time without waiting or depending on each other.

Increasing block size or decreasing block time increases throughtput but doesn't increase scaling.

 The only one valid next block concept prevent true scaling , as all miners/stakers need to synch on the next block, and cant "advance" The blockchain each on their side.

learn consensus
there would be only one chain. and NODES decide the rules... not pools, not devs.

one chain that the limits change when NODES signal they can cope (meaning no 'datacentre by midnight/gigabyte by midnight' doomsdays)
then pools secondarily start making blocks to the size the node consensus agrees to.

anything that the nodes dont consent to because devs have bypassed consensus would get orphaned.
less consent
(lower consent=more orphan/rejects - but ultimately one chain once temporary drama subsides)
(higher consent=less orphan/rejects - but ultimately one chain once temporary drama subsides)
18066  Bitcoin / Bitcoin Discussion / Re: Bitcoin Technology on: February 06, 2017, 07:56:04 PM
segwit does not solve intentional spam, malicious users just wont use p2wpkh keys
segwit does not solve intentional quadratics,  malicious users just wont use p2wpkh keys

LN does not solve intentional spam, malicious users just wont use LN hops or hubs.

the only way i can see that will sort out the fee war and the intentional real spam, without much drastic action is to introduce a new "priority formulae" that actually does a proper job of sorting out the spammers from the normal users




And the spammers sorted out with this formula couldn't use Bitcoin? Banned of Blockchain?

The spammer sorted out would be the address, and this person can create another address and spam again a transaction and again with many other new addresses.

what if there was a formulae that NEVER gave priority unless someones funds were aged atleast a day or they added a CLTV maturity period of a day.
also where the more bloated their transaction was or the more they wanted to bypass the 1day delay to respend sooner would cost them dearly

EG where those genuine/moral users that want to spend more then once a day can save some costs using the voluntary side services such as LN.
while leaving malicious intentional spammers who would refuse to use LN as it doesnt serve their malicious intent, left waiting or paying alot
18067  Bitcoin / Bitcoin Discussion / Re: 1MB block size forever is just silly on: February 06, 2017, 07:50:26 PM
first please learn the difference between consensus and bilateral splits.
That has no relevance to my post. You are either a very bad troll or you've become delusional.

Let's get back to topic, shall we?
Pretty impossible with people like mr. 'franky1', as you can see above.

this topic is about bitcoin blocksize growth.. which is about consensus... you can meander your posts into being about personal attacks all you like.
you can fake it all you like that your the victim,
but atleast spend 30 minutes learning about bitcoin.
learn consensus vs bilateral

18068  Bitcoin / Bitcoin Discussion / Re: Can we trust bitcoin long term with BUcoin type hard forks menacing around? on: February 06, 2017, 07:46:15 PM
The majority (Core) wants to make the BU fork.... Makes sence

here is the blockstream CTO demanding non-core implementations split. and him proving they dont want to. the same blockstream CTO also thinks splits are good
What you are describing is what I and others call a bilateral 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--

here is a blockstream defender with no clue about how bitcoin works, or knows the term consensus. sounding desparate to try getting non-core nodes to split.
So hurry the fuck up and get your fork over with, the constant droning of your lies is not worrying or irritating, it's just boring.

No-one's interested, DO YOUR FORK. You've got the hashrate, do your fork.

and now lets get back to the blockstream paid core devs.. they are are only 'team' that bypassed real hard consensus to give miners the power.. no other team have done this.
only blockstream paid devs decided giving miners ultimate power was good.by going soft. yet they cry like they are the victims
18069  Bitcoin / Bitcoin Discussion / Re: Can we trust bitcoin long term with BUcoin type hard forks menacing around? on: February 06, 2017, 07:31:22 PM
so much fake propaganda, but soo litte proof they understand the basic concepts of consensus.

those defending blockstream are getting desperate.

all i ask is they learn the world consensus. and understand that the community want consensus. its only the blockstream defenders that want the network to split.

it is only the blockstream defenders happily giving the power to miners

Quote
firstly learn consensus agreement vs bilateral split.

too many times people only speak of the best case scenario of soft and the worse case of hard.(they know why they do it!!)
but effectively the only difference between soft and hard is who gets to vote to activate..

soft.. pool votes nodes dont.
hard.. nodes vote then pools.

but in both soft and hard. both can have consensus, both can be controversial and both can have bilateral

softfork: consensus - >94% pools no banning/ignoring of minority. result: small 5% orphan drama then one chain. minority unsynced and dead
softfork: controversial - >50% pools no banning/ignoring of minority. result: long big% orphan drama then one chain. minority unsynced and dead
softfork: bilateral - intentionally ignoring/banning opposing rules and not including them. result: 2 chains

hardfork: consensus - >94% nodes, then >94% pools no banning/ignoring of minority. result: 5% orphan drama then one chain. minority unsynced / dead
hardfork: controversial - >50% nodes, then >50% pools no banning/ignoring of minority. result: big% orphan drama then one chain. minority unsynced / dead
hardfork: bilateral - intentionally ignoring/banning opposing rules and not including them. result: 2 chains

to make an actual altcoin you need to do more then just make bigger blocks or send an erroneous transaction.. as that just causes rejects/orphans.

you need to actually make the nodes ignore the opposing data and nodes so that they are not sticking to the same data. and instead walk in opposite directions

high agreement = less orphans/rejects
low agreement = more orphans/rejects
but if you have another clause to avoid rejecting or even seeing the opposition. then you are risking creating an altcoin

core fans and paid devs are the only ones asking about splitting the network. no one else
18070  Bitcoin / Bitcoin Discussion / Re: Bitcoin Technology on: February 06, 2017, 07:25:54 PM
segwit does not solve intentional spam, malicious users just wont use p2wpkh keys
segwit does not solve intentional quadratics,  malicious users just wont use p2wpkh keys

LN does not solve intentional spam, malicious users just wont use LN hops or hubs.

the only way i can see that will sort out the fee war and the intentional real spam, without much drastic action is to introduce a new "priority formulae" that actually does a proper job of sorting out the spammers from the normal users


18071  Bitcoin / Bitcoin Discussion / Re: 1MB block size forever is just silly on: February 06, 2017, 07:21:54 PM
There isn't a good proposal yet that:
1) Doesn't give the miners too much power.
2) Or which is very hard to game.

AFAIK it is stated somewhere that the general consensus long term is a variable block size, but that requires a lot more research and testing.

first please learn the difference between consensus and bilateral splits.

then you will realise soft or hard both have best case consensus and both have worst case bilateral.

when mentioning hard. in simple terms is NODES first then pools follow
when mentioning soft. in simple terms POOLS first then NODES follow(if they choose to want to become fullnodes again)

soft gives pools too much power.
hard does not give pools too much power.

please learn the basics. it doesnt require knowledge of C++ to learn these basic concepts and terms. which makes things easier for you.
it has been months since i first asked you and your buddy to learn the basics which should have taken 20-30 minutes to grasp.

why are you not bothered to learn about bitcoin?
18072  Bitcoin / Bitcoin Discussion / Re: 1MB block size forever is just silly on: February 06, 2017, 07:06:12 PM
So hurry the fuck up and get your fork over with, the constant droning of your lies is not worrying or irritating, it's just boring.

CB yet again falsely suggesting non-core want to fork

last month it was
"no its dangerous they should not fork" - they never were going to anyway
now this month
"hurry up and fo a fork" - they never were going to anyway.

please learn consensus CB.
18073  Bitcoin / Bitcoin Discussion / Re: 1MB block size forever is just silly on: February 06, 2017, 06:54:26 PM
It's really simple: don't turn up into Bitcoin, proposing to change the parts of Bitcoin that keep Bitcoin safe, then accuse the original Bitcoiners of tribalism when they dare to voice opposition! You're retarded if you really believe this nonsense
Quite ironic, isn't it?

Great idea: try to start a tribe.... inside a pre-existing tribe, then label the dissenters as invaders. These people are past immoral

so
satoshi qt the original tribe.. then in 2013 another tribe within the pre-existing tribe starts, call it core.. which then tribals off again in 2014 as blockstream.. with 'white chief poking-bear' as tribal leader
then label the dissenters (those that are not core /blockstream but were old qt) as the invaders is immoral.

i think CB doesnt understand the word ironic, otherwise he would realise he is defending the immoral tribe he tries to describe.

why is it blockstream defenders play the victim card by doing the exact thing they point at others. especially when its obvious that al they care about is tribal leaders and not the whole bitcoin community
18074  Bitcoin / Bitcoin Discussion / Re: 1MB block size forever is just silly on: February 06, 2017, 11:36:52 AM
Scaling 100% off-chain runs in stark contrast to the underlying principles of an open and permissionless system.  Users won't stand for it and won't allow it to happen.

Hmmm, the only off-chain system currently proposed is permissionless. So, WTF are you talking about? Oh yes, that's right, you're talking about incredibly subtle anti-Bitcoin propaganda, like you always do. Roll Eyes


Do you think that if you repeat "Lightning is Banking 2.0" a million times, it will magically become the truth?

here goes CB failing to grasp the basics of multisig..
if you need someone else to sign a transaction.. say hello to 'permission'
also
if you need a hopper to agree to be part of a payment.. say hello to 'permission'
meaning its no longer permissionless.

lastly due to the costs of 'hops' vs 'hubs' it will naturally turn into people saving funds by using hubs.

oh and CB, please learn CLTV maturity (resembles 3-5 business day delay for end user experience)
oh and CB, please learn CSV revoke (resembles chargebacks for end user experience)
18075  Bitcoin / Bitcoin Discussion / Re: 1MB block size forever is just silly on: February 06, 2017, 11:30:31 AM
there goes CB yet again throwing down the

not verbatim: 'bitcoin mainnet should not scale onchain because billions of users by midnight.'
its much like saying in the 1900's cars should not be built because billion cars by midnight..

firstly. rational thought.
bitcoin wont have billions of users overnight. infact bitcoin wont have billions of users over decades.

a rational thing to think of is about 5% of the world adopting bitcoin naturally OVER DECADES
meaning it can scale.

if people think bitcoin is going to be the 'one world currency' and no other currency is going to exist then say goodbye to freedom of choice and say hello to bitcoin just becoming as corrupt as the IMF

instead think of it as just rationally taking a good healthy spot as one of the top 5 "nations"(communities)
think of it as being an open choice to have as a secondary currency to their own national currency.

then realise it wont happen overnight.
18076  Bitcoin / Bitcoin Discussion / Re: No big reduction in full node operation cost under Lightning Network future on: February 06, 2017, 04:06:35 AM
anyway back to the topic at hand.

here is another possible thing.. if we imagine a high take up of people wanting to be locked into LN for genuine reasons

imagine you are a multiple spender and you want to use LN.
you are not going to rationally see any benefit to run a full node all day long.

you will end up using a possible LN lite-node. that just holds the utxo of the addresses you are part of (you and counterparty)
diluting the full node count because less people use/touch mainnet 24/7 anymore



bitcoin core. meant to be a full node.. but offers pruned, no witness and selective black/whitelisting of nodes including turning on/off listening mode.

meaning instead of just running with full data. they are allowing nodes to cut off supply to other nodes, thus diluting the amount of full nodes to seed/sync data from. because they either refuse to connect or they dont hold all the validatible data.

which again is another failure of all these features causing less real full nodes.. and just a mis-tangled network of 'relay' nodes downstream from the upstream FIBRE network as the real full auditors (blockstream centralised network)

which itself can cause less people to want to be full nodes because although their pc can cope with it. they dont see the real gain/need
18077  Bitcoin / Bitcoin Discussion / Re: No big reduction in full node operation cost under Lightning Network future on: February 06, 2017, 03:25:13 AM
But wasn't a transaction layer built on top of Bitcoin in the cards? Well there it is. Segwit will make it possible for a layer to be built on top of Bitcoin and make it better. Now they are trying to block it? Read the pros and cons franky1 posted. You may agree or disagree with it but what LN gives the users is a choice to go for offchain or onchain transaction depending on their needs.

LN should be a voluntary service for those who NEED to spend multiple times an hour/day/week.
but keep in mind.
malicious spammers will
1. avoid using LN when repeat spending every block, because their obvious intention is to spam onchain so why use LN.
2. avoid segwit p2wpkh tx's when they make bloated quadratic tx's because their obvious intention is to spam onchain so why use segwit keys.
3. avoid segwit p2wpkh tx's when they want to malleate because their obvious intention is to spam onchain so why use segwit keys.

so segwit and LN is not solving malicious user spam. it is just solving ethical users to have a service to help the network.

in short intentional spammers will still do what they do. and so segwit and LN does not solve malicious users

the reason people are blocking it. is because it doesnt stop malicious users. but blockstream are doing this crap under false pretenses to try pushing ethical and honest people into their centralised commercial public permissioned hubs. (because they know private permissioned LN hops are more expensive). because blockstream need to start generating revenue to make returns of $90m+ to investors

halting true onchain growth to force ethical moral people into LN hubs is not good for ethical/moral people if the real intention is just about blockstream messing with bitcoin for financial gain
18078  Bitcoin / Bitcoin Discussion / Re: No big reduction in full node operation cost under Lightning Network future on: February 06, 2017, 01:58:57 AM
What exactly is the problem here now? are we debating only about 2 options here LN & segwit?
@franky1, seems like you are not even sure which side to pick or which option is the answer.
Could you tell me the final solution and not list pros and cons?

LN as a SIDE service. much like using coinbase merchant tools, bitpay merchant gateway, xapo or bitgo multisig/escrow store...
it has a niche but we should not be considering LN as the solution to scaling.

LN's technical issue preventing public release is not actually the need for segwit. LN's issue is the 're-use address dilemma', which still needs to be solved

we NEED onchain natural growth for the majority of users to appreciate the true meaning of bitcoins ethos



sidenote if LN does fix its address re-use bug(main concern)
then we can start thinking about the whole how do we get people to be rational. EG if they are wanting to spend more than once a day, they can use LN. but if using it infrequently they stick to the bitcoins mainnet. without being hit by huge costs. for the rare once a day/week/month use

im currently running scenarios about different 'priority' formulae that favours lean transactions and transactions that dont spend often
some scenarios/formulae im looking into including using CLTV maturity as a way people gain 'priority points' if they CLTV maturity lock their funds for ~24 hours to show they dont want to spam every block. where costs are incurred if they want to bypass a once a day spend without using LN.
thus mitigating most spam and costing people if they are desperate for that odd occasion of needing to spend a couple times a day without using LN
18079  Bitcoin / Bitcoin Discussion / Re: Why is fee still high (6000 unconfirmed transactions) on: February 06, 2017, 01:57:07 AM
We are predicting values above $2000

if the only thing that concerns you is the FIAT price of $2000, as your exit target. your missing the whole point of bitcoin.
18080  Bitcoin / Bitcoin Discussion / Re: No big reduction in full node operation cost under Lightning Network future on: February 06, 2017, 01:28:40 AM
The only way to scale anywhere notable at a global level and provide a fast service for cheap fees is through Lightning Network. Trying to achieve this task by raising the blocksize is objectively a losing game, and only leads to node centralization.

Lightning Network might help scale transactions per user (assuming it can be made to work); it doesn't really help scale the user base.  That's the point of the graphic.

Imagine the small-block super success scenario where we soon have 500 million people using bitcoin and a 1 MB block size limit.  Each of those 500 million people need at least one unspent output and probably more like ten or fifty or so to achieve acceptable privacy.  

(500 x 10^6 users) x (10 outputs/user) * (40 bytes / output) = 200 GB UTXO set size

Don't you think it would be bizarre to worry about "1 MB blocks" making it difficult for people to run nodes on low-cost hardware if that same hardware needs a UTXO database at least 200 GB in size?

Personally, I want to allow Bitcoin to continue to grow freely like it did for the first seven years of its life.  But for those of you who think we need to "constrain" it to keep the cost of running a node low, at least be consistent: if you're going to worry so much about the size of blocks, shouldn't you be even more worried about the size of the UTXO set?  Don't you think it's odd that LN is being promoted as a solution to allow bitcoin to scale its userbase when the truth is that it (assuming it can be made to work) really only helps scale the number of transactions per user?


to summarise this post.

imagine alice has 2btc in a standard p2pkh address unspend (1AliceAddress : 2btc -unspent)
imagine bob has 2btc in a standard p2pkh address unspend (1bobAddress : 2btc -unspent)

when going into LN
all that changes is the address holding it.

thus alice has 2btc in a LN p2wsh address unspend (3AlicebobmultisigAddress : 2btc -unspent)
thus bob has 2btc in a LN p2wsh address unspend (3AlicebobmultisigAddress : 2btc -unspent)

its still 2 unspents whether on people own personal permissionless addresses or in a multisig permissioned address



rationally we are not going to get 500million people over night, nor 7billion people.
today we only have 0.026% of the population. rationally we should be thinking that 5% of the world population may use bitcoin (making bitcoin one of the top 5 nations) but this wont happen over night, expect natural slow adoption over DECADES.

even if we get to less, say 0.05% of world population. knowing that there are 200 countries in the world still makes bitcoin as good as a nation.

but if we have 5% in a few decades thats more like 500mill(total world pop gets to 10bill) at most realistic TOP expectation.

remember. there are old people in the 99% club that are going to just stick to fiat. because they cant cope with technology
remember. there are children that are just not old enough to have a bank account.make an income
remember. there are unemployed/disabled people that are reliant on fiat social security so they dont have any disposable income to throw at bitcoin

so only expect 5% at most world adoption. which is still higher than world adoption of gold as a asset store, emphasis happening over DECADES, not night.



in short we should not halt natural growth now. using fake fear of 'billions by midnight' . allow natural onchain growth to begin so that it can scale over DECADES, naturally, rationally. and done so by the node consensus. not dictatorship king devs spoon feeding
Pages: « 1 ... 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 [904] 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 ... 1463 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!