Bitcoin Forum
June 26, 2024, 07:28:15 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 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 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 [970] 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 ... 1473 »
19381  Bitcoin / Bitcoin Discussion / Re: 21 millions bitcoin in question on: November 28, 2016, 01:56:50 AM
Who is proposing this? I have not seen any serious proposal which proposes any sort of change to the monetary supply (except for BIP 42). Do you have a link to a source?

rusty russel of blockstream LN fame wants to first introduce millisats into LN. and later change bitcoins measure to comply with LN.



19382  Bitcoin / Bitcoin Discussion / Re: 21 millions bitcoin in question on: November 28, 2016, 01:04:47 AM
one thing to know

its not 21million rule, thats just named that for the human mind to put the real rule into a less coded, less mathematical concept average joe can understand without their mind exploding, buzzword.

it does create 21million btc. but you have to understand HOW

the rule is actually:
each block reward was 5,000,000,000 units of measure from block 0 to block 210,000(50 btc per block for 210,000blocks)
totalling 1,050,000,000,000,000 units of measure in circulation (10.5million btc)

then it halves for the next 210,000 blocks.
meaning
each block 210,001-420,000 reward was 2,500,000,000 units of measure 210,000(25 btc per block for 210,000blocks)
releasing 525,000,000,000,000 units during this period (5.25million btc)
totalling 1,575,000,000,000,000 units of measure in circulation  (15.75million btc)

then it halves for the next 210,000 blocks.
meaning
each block 420,001-630,000 reward is 1,250,000,000 units of measure 210,000(12.5 btc per block for 210,000blocks)
releasing 262,500,000,000,000 units during this period (2.625million btc)
totalling 1,837,500,000,000,000 units of measure in circulation (18.375million btc)

and every 210,000 blocks the reward halves, releasing half as much and so on and so on until no more units of measure are rewarded

thats whats wrote in code.
which calculates in the year 2140ish each block will only make 1 unit of measure per block.. and then thats it. no more.


bringing the total ever made to just about 2,100,000,000,000,000 units of measure
more precisely 2,099,999,997,690,000 units of measure (20,999,999.9769btc (~21million btc)

the rarity is that at best it can be split up into 2.1quadrillian parts

however human minds dont like big numbers. so the user facing GUI treats
a unit of measure has been called a satoshi (singular 'sat' for short, plural 'sats' for short)
1 unit of measure as 1 sat
100 sats as 1 bit
100,000,000sats as 1btc or 1,000,000 bits
1,250,000,000sats as 12.5btc or 12,500,000 bits
2,500,000,000sats as 25btc or 25,000,000 bits
5,000,000,000sats as 50btc or 50,000,000 bits
and ofcourse
2,100,000,000,000,000sats as 21million btc or 21,000,000,000,000 bits



the main premise is bitcoin would only make 2.1quadrillian sharable units ever. and that was a hard rule no one should change as its an economics rarity thing


now.. here is the thing.. although the code is measured in sats and only the GUI / human brain sees btc..
some banker paid devs are actually trying to play with the units of measure that will be rewarded to mining pools.

EG
instead of:
1,250,000,000sats, being rewarded per block they want
1,250,000,000,000 millisats

code form
1,250,000,000units of measure.. becomes
1,250,000,000,000units of measure

meaning 1000 more units of measure (1000x more split-able and shareable(less rare)) which also extends the minimum life expectancy to change from the year ~2140 to ~2180

this trick is done by although at code level making there be 1000 more units of measure. they still want to play with peoples heads by:
1,250,000,000,000 millisats is a btc.

and
1 unit of measure is a millisat
1,000 units of measure is 1 sat
100,000 units of measure is 100 sats or 1bit
100,000,000,000 units of measure is 1btc or 1,000,000,000 bits

they are hiding the split-ability, separability, (destroying/diluting rarity) by moving how many units of measure is declared a bitcoin.

and yes this is being done by developers funded by bankers



here is another thing,
them same banker paid devs want to mess around with the halving mechanism and even make the individual blockrewards adjustable as a punishment for wanting more transaction capacity in said block
like this https://github.com/maaku/bitcoin/commit/ad4c77f1ff2c370f67538e01fd082d231b57f2d0
19383  Bitcoin / Bitcoin Discussion / Re: Scaling Bitcoin. Is consensus achievable? on: November 28, 2016, 12:06:46 AM
a system where the other person can trick the system and chargeback in that week........ = same as visa - worse than wire transfer
Show, how the system can be tricked.

your scenario using outdated concept already has.. but ill explain in easy steps based on your outdated scenario
you can read previous pages.. but here step by step.

1. do you agree that LN uses multisig. where 2 parties co-sign agreed tx data. if yes read on, if not, research and come back later
Quote
step 1: two people communicate together and agree to open a multisig to start a channel.

step 2: they both independently fund the multisig with their amounts. ONCHAIN.

step 3: they agree to the terms of who owes what. initially agreeing to whatever they deposit they get back.
hint 1: the funds cannot be spent in a multisig without both signatures
TXID:AB3
In:3abcdeklmn987654321 val:5btc (originally A(X) deposit)
In:3abcdeklmn987654321 val:5btc (originally B(Y) deposit)
Out script1: if relevant(1abcdefghij123456789 A(X) val: 5btc); if irrelevant(1klmnopqrs987654321 B(Y) val: 5btc)
Out script2: if relevant(1klmnopqrs987654321 B(Y) val: 5btc); if irrelevant(1abcdefghij123456789 A(X) val: 5btc)

maturity 1000 blocks

step 4: and both sign the same tx data.
hint 1: the funds cannot be spent in a multisig without both signatures
TXID:AB3
In:3abcdeklmn987654321 val:5btc (originally A(X) deposit)
In:3abcdeklmn987654321 val:5btc (originally B(Y) deposit)
Out script1: if relevant(1abcdefghij123456789 A(X) val: 5btc); if irrelevant(1klmnopqrs987654321 B(Y) val: 5btc)
Out script2: if relevant(1klmnopqrs987654321 B(Y) val: 5btc); if irrelevant(1abcdefghij123456789 A(X) val: 5btc)
Signature (A(X) signed inputs and output to agree)
Signature (B(Y) signed inputs and output to agree)
maturity 1000 blocks

step 5: B(Y) decides to give A(X) say 4BTC, they agree and they BOTH SIGN
hint 1: the funds cannot be spent in a multisig without both signatures
hint 2: both signing = both seeing a copy to be able to sign
hint 2: they both agree there should be a harsh penalty rather then getting what they deposited back
hint 2: in your scenario they now decide to not having matching data. but both sign each others tweaked tx data

A(X) creates and signs this. making A(X) lose out if not moral
TXID:A5
In:3abcdeklmn987654321 val:5btc (originally A(X) deposit)
In:3abcdeklmn987654321 val:5btc (originally B(Y) deposit)
Out script1: if relevant(1abcdefghij123456789 A(X) val: 9btc); if irrelevant(1klmnopqrs987654321 B(Y) val: 10btc)
Out script2: if relevant(1klmnopqrs987654321 B(Y) val: 1btc); if irrelevant(1abcdefghij123456789 A(X) val: 0btc)
Signature (A(X) signed inputs and output to agree)
maturity 1000 blocks

B(Y) creates and signs this. making B(Y) lose out if not moral
TXID:B5
In:3abcdeklmn987654321 val:5btc (originally A(X) deposit)
In:3abcdeklmn987654321 val:5btc (originally B(Y) deposit)
Out script1: if relevant(1abcdefghij123456789 A(X) val: 9btc); if irrelevant(1klmnopqrs987654321 B(Y) val: 0btc)
Out script2: if relevant(1klmnopqrs987654321 B(Y) val: 1btc); if irrelevant(1abcdefghij123456789 A(X) val: 10btc)
Signature (B(Y) signed inputs and output to agree)
maturity 1000 blocks

step 6: they both hand eachother a copy and sign their counterparts version
hint 1: the funds cannot be spent in a multisig without both signatures
hint 2: both signing = both seeing a copy to be able to sign
hint 3: doing this invalidates previous TX (step 4)

A(X) created, now B(Y) signs, B(X) KEEPS aswell as the other one below
TXID:A6
In:3abcdeklmn987654321 val:5btc (originally A(X) deposit)
In:3abcdeklmn987654321 val:5btc (originally B(Y) deposit)
Out script1: if relevant(1abcdefghij123456789 A(X) val: 9btc); if irrelevant(1klmnopqrs987654321 B(Y) val: 10btc)
Out script2: if relevant(1klmnopqrs987654321 B(Y) val: 1btc); if irrelevant(1abcdefghij123456789 A(X) val: 0btc)
Signature (A(X) signed inputs and output to agree)
Signature (B(Y) signed inputs and output to agree)
maturity 1000 blocks


B(Y) created, now A(X) signs
TXID:B6
In:3abcdeklmn987654321 val:5btc (originally A(X) deposit)
In:3abcdeklmn987654321 val:5btc (originally B(Y) deposit)
Out script1: if relevant(1abcdefghij123456789 A(X) val: 9btc); if irrelevant(1klmnopqrs987654321 B(Y) val: 0btc)
Out script2: if relevant(1klmnopqrs987654321 B(Y) val: 1btc); if irrelevant(1abcdefghij123456789 A(X) val: 10btc)
Signature (A(X) signed inputs and output to agree)
Signature (B(Y) signed inputs and output to agree)
maturity 1000 blocks

step 7: many many many trades like steps 5,6 happen where values change hands.. making previous txs irrelevant
hint 1: the funds cannot be spent in a multisig without both signatures
hint 2: both signing = both seeing a copy to be able to sign
hint 3: doing this invalidates previous TX
lets say they are at TXID:A200   TXID:B200 making A4-199  and B4-199irrelevant

step 8: B(Y) kept A6 (step 6), initially you think thats crazy right. but B(Y) broadcasts it

step 9: B(Y) lets it get confirmed

step 10: B(Y) uses the revoke code on the A6 Out script1 to then make the output spendable to him instantly before maturity expires
19384  Bitcoin / Bitcoin Discussion / Re: Scaling Bitcoin. Is consensus achievable? on: November 27, 2016, 10:42:59 PM
you literally talk about a chargeback method where bob can get funds destined for alice, then suddenly say its impossible
That's not chargebacks, but punishment for theft attempt. One party takes all funds from the channel only if another party tries to use an outdated state to steal funds.

and why do you think banks do charge backs.
seriously.

think about it.. your topic is about scaling. where you are thinking that LN is the solution. will the whole community use LN and not care about onchain?

no

a system where funds are locked for a week after settling. where they cant be spent....... = worse then merchants/customers get from accepting visa/paypal
a system where the other person can trick the system and chargeback in that week........ = same as visa - worse than wire transfer
a system that

at the moment some of those issues that you are trying to disguise are being weeded out and thrown out. hense your out of date.
however there are still some issues even with the latest concept.

i think you should let go of the tight grip you have on last May. go read the mailing list, go check out IRC. if you prefer google. use the search tools and set it to only 1 month ago.
get yourself upto date..

oh and yea. the article writer.. is not a coder, his speciality is politcs and history.
it may help you to actually create a multisig and actually see the things you can do with a multisig. play around. go to a testnet and do some stuff. learn more about it.

for instance the many other penalties LN dev's are dreaming up on one banker funded team.. vs the other concepts that are just doing ethical and dual signed mutually assured version of LN. where CODE ensures no risk no loss.

you can usually spot the banker paid devs who thing economic penalties are the answer. and holding funds ransom for days is the answer

move passed the May2016 article, it will help you

have a nice day
19385  Bitcoin / Bitcoin Discussion / Re: Scaling Bitcoin. Is consensus achievable? on: November 27, 2016, 10:11:05 PM
Another output is also recorded on the chain, there no way to spend it except 2 ways defined by it's script.

and by going by your scenario. during that week it can be "charged back" to bob (Y) going by your scenario
no "charge backs" are possible

you literally talk about a chargeback method where bob can get funds destined for alice, then suddenly say its impossible

but im loving how your changing the theory..
im guessing you need to update yourself

anyway. you can continue theorising with old concepts. while i continue looking into the latest stuff that has overcome some of the issues your OLD concept had.

goodluck though
have a nice day
19386  Bitcoin / Bitcoin Discussion / Re: Scaling Bitcoin. Is consensus achievable? on: November 27, 2016, 09:55:49 PM
lol

your article is out dated. its actually time stamped may 2016.

also even if you believe its current try reading it fully.. learn multisig.
Quote
Building Block #3: Multisig

have a nice day
19387  Bitcoin / Bitcoin Discussion / Re: Scaling Bitcoin. Is consensus achievable? on: November 27, 2016, 07:59:57 PM
Here is a Point for those that can think.

If segwit does actually manage to get activated.

And people use LN for the majority of their transactions, and stay off the Blockchain.

Do you think the mining pools have already figured out less transactions on the blockchain means less fees for them to collect.
Especially when they need to survive off of transaction fees only and no more BTC are created. Less than 5 Million BTC left to mine.
LN will take money out of the BTC miners pocket.  Wink

 Cool

core devs dont care about bitcoin. they want everyone offchain so they can throw the onchain tx sky high to make people hate bitcoins blockchain.
then push people over to hyperledger..

core devs spend most of their time working on the hyperledger.. by core devs i mean the PAID devs.. not the 90 unpaid interns that just spellcheck the code.
pieter wuille - paid by blockstream - team leader segwit - also programs bankers hyperledger
Rusty Russel - paid by blockstream - team leader LN - also programs bankers hyperledger
matt corralo - paid by blockstream - main committer - also programs bankers hyperledger
greg maxwell- paid by blockstream - main committer - also programs bankers hyperledger

i could name more
19388  Bitcoin / Bitcoin Discussion / Re: Scaling Bitcoin. Is consensus achievable? on: November 27, 2016, 07:58:28 PM
You can read this series of articles. I learned this design from there.

I made bold part of the quote which is closely related to your concerns.

i see your failure.
1. outdated. may 2016
2. belief that alice and bob have separate(slightly differing) copies (um thats the opposite of the bidirectional buzzword)

in simple terms
its one transaction data they BOTH agree on and both treat as most relevant and both keep
EG (ignore the addresses they are random letters and numbers obviously)

Txid
In:3abcdeklmn987654321 val:5btc (originally A(X) deposit)
In:3abcdeklmn987654321 val:5btc (originally B(Y) deposit)
Out: 1abcdefghij123456789 val: 9btc (goes to A(X))
Out: 1klmnopqrs987654321 val: 1btc (goes to B)
Signature (A(X) signed inputs and output to agree)
Signature (B(Y) signed inputs and output to agree)
lock: now+9d23h58m

where they simply change the out values to who deserves what and then sign together to enforce it.
a tx wont get into a block without both signatures.
so both need to sign the same copy

thats the whole point of multisig. (buzzword bidirectional)

obviously with the out which goes to A can be a script that can halt A from being able to spend it straight after its confirmed
obviously with the out which goes to B can be a script that can halt B from being able to spend it straight after its confirmed

but its one transaction not 2 transactions.
its not about A holds one tx in their favour
its not about B holds one tx in their favour

they both hold the same relevant tx at the same time.

however if they keep a channel open that surpasses the locktime(onchain) set up when opening the channel EG
20 blocks after.. the malicious user can look at their LN history and grab a tx from the say 1-19 relevance ago. and that too would also now be relevant because they went passed the deadline.
which is the case not just for recent concepts but the outdated concept you dragged up from may2016

in your concept. there is a 1000CSV block delay even after its in the blockchain (much like blockreward coinbase tx has 100 block delay)
however the failure of that is simple.
your article says it
Quote
CSV, instead, uses relative time. Once a CVS-output is recorded on the blockchain, it takes a specific amount of blocks from that point on before the bitcoins can be spent again.

having a week CSV delay(1000 block) that can be interrupted by another person broadcasting a more relevant tx.. fails
because the LN outputs are already on the blockchain when alice (x in your other scenario) closed the channel.

also another fail is because although on the blockchain. it cant be spent untill it matures in a week. thus like banks... its not "available balance" which then is worse than Visa because visa settles in 2 days.

and by going by your scenario. during that week it can be "charged back" to bob (Y) going by your scenario

see the social issues with that.. funds not being spendable for days..and chargebacks possible!!

thats why other concepts are doing the opposite. having relevance time locks within LN to close a channel sooner and getting it broadcast sooner and simply opening a new channel if the 2 parties want to continue transacting


19389  Bitcoin / Bitcoin Discussion / Re: Scaling Bitcoin. Is consensus achievable? on: November 27, 2016, 06:20:51 PM
You only need ~70% of the hash to have a successful hard fork, so it is odd SegWit is pushed for more.
No. You need 95%.
A True Hard Fork only requires 70% , because you want enough hash to make sure the 30% can not 51% attack your new chain.  Wink

ok clear the matter up.

at any majority. the orphan game will eventually sort it self out.
at a low majority say 55%. it might take a many blockheights where half is disagreeing and the orphan rate is say 65 blocks of 144 have a corresponding orphan..
headache nightmare .. headache nightmare .. headache nightmare
mining pools will be screaming. nodes will be syncing and losing sync.. bad for everyone.. but deemed temporary drama as eventually it leads to one chain and the minority left unsynced.
retailer merchant guidance: wait upto say 100 confirms before fully trusting a tx

at a low say 70%. it might take a many blockheights where a third is disagreeing and the orphan rate is say 42 blocks of 144 have a corresponding orphan..
blah blah same thing. a bit less screaming, but lots of crying still while the orphan drama sorts itself out
retailer merchant guidance: wait upto say 70 confirms before fully trusting a tx

at say 85%. it might take a few dozen blockheights where inder a quarter  is disagreeing and the orphan rate is say 20 blocks of 144 have a corresponding orphan..
blah blah same thing. not screaming, but not much crying while the orphan drama sorts itself out, but not happy
retailer merchant guidance: wait upto say 45 confirms before fully trusting a tx

at say 95%. it might take a a couple blockheights where a few is disagreeing and the orphan rate is say 7 blocks of 144 have a corresponding orphan..
not as bad and miners could live with a slight risk elevation compared to the usual 1-2% a day they usually put up with.
retailer merchant guidance: wait upto 10 confirms before fully trusting a tx

usual daily 1-2% risk advises waiting upto 6 confirms
19390  Bitcoin / Bitcoin Discussion / Re: Scaling Bitcoin. Is consensus achievable? on: November 27, 2016, 05:13:03 PM
The concept I'm talking about works the following way:
Let's say current channel state is: 5 BTC belong to X, 5 BTC belong to Y. But among previous states there is one where 9 BTC belong to X and only 1 BTC belong to Y. X likes the older state much more. So he broadcasts it. The transaction that he broadcasts spends the original 2 of 2 output and creates 2 new outputs: 1 BTC immediately goes to Y, and another output is created, let's call it o2. o2 can be spent in 2 different ways. First: X can spend it after 1000 blocks are mined on top of the block where o2 was created. Second: Y can spend it at any moment if, besides signature, he also provides preimage of a certain hash. Since Y already has this preimage, otherwise he would refuse to update state of channel, he can immediately spend o2, thus taking all 10 BTC from the channel. Friendly pool can't help X, because it takes 1000 blocks before o2 can be spent in way preferable for X.

^ wrote to try showing how X cant attack but reveals Y is now the attacker
which is another attack vector.

cant you see the attack vector..
dont think about X doing the 9btc.. for X to gain.. thats then everted by Y(your hope of scenario outcome)

think about Y broadcasting th X9Y1... triggering X so Y can then get 10btc
lets say Y broadcasts X's 9btc. to then allow Y to broadcast the tx that gives Y the whole 10btc

anyway theres many concepts throwing about. and many attack vectors in each.
the bip u quoted is not strong enough on its own and actually makes one person gain.

not really a moral/equal paradigm like some other concepts i have seen
Y can't broadcast that transaction because he doesn't have it.

you do know that multisigs needs 2 signatures.
you do know that to agree to what you call a "commitment" both parties need to see and agree to it.

so if your saying Y cannot transmit X's preferred tx because Y has never seen it, been handed it or knows of its existance.. then im guessing whatever LN concept you are viewing has far more weaknesses.

i made the bits bold that you mention.. first bold bit.. an old state.. im assuming for practical reasons Y did infact see that state earlier in the day/weeks when it was relevant. so by seeing it, would have (lik any malicious user) kept a copy of it. then as shown by the second bold part its assumed Y is involved to signing the commitments by seeing the commitments..

reason being both SHOULD be signing together.. so my last paragraph is highlighting even your scenario assumes this to be true..
so im not sure why last post says Y never had first state
19391  Bitcoin / Bitcoin Discussion / Re: Scaling Bitcoin. Is consensus achievable? on: November 27, 2016, 04:26:13 PM
im trying not to use buzzwords or over complex things so other readers can understand the fundamentals.

as for the individual spends within LN, they too need to do some things.
the 'secret exchange' in practice does not work. hense the need for the locks aswell.

EG (your concept version)
 i could have a direct connection to a pool and have bribed them to put my tx into a block the exact moment the lock is released.. so when i send X in the last second. you think your Y would over ride it. the problem is that your Y transaction has to relay around the network and sit with the other high fee paying blocks in mempool before a pool accepts it into a block.. which after seeing the mempool bloat this week might be 2 hours.
where as mine gets in. making yours invalid.

thats why locktimes are needed too.

but hey there are many LN concepts, i just hope the one your viewing is not going to ignore using inner locktimes of descending order.. otherwise thats a weakness of that concept
The concept I'm talking about works the following way:
Let's say current channel state is: 5 BTC belong to X, 5 BTC belong to Y. But among previous states there is one where 9 BTC belong to X and only 1 BTC belong to Y. X likes the older state much more. So he broadcasts it. The transaction that he broadcasts spends the original 2 of 2 output and creates 2 new outputs: 1 BTC immediately goes to Y, and another output is created, let's call it o2. o2 can be spent in 2 different ways. First: X can spend it after 1000 blocks are mined on top of the block where o2 was created. Second: Y can spend it at any moment if, besides signature, he also provides preimage of a certain hash. Since Y already has this preimage, otherwise he would refuse to update state of channel, he can immediately spend o2, thus taking all 10 BTC from the channel. Friendly pool can't help X, because it takes 1000 blocks before o2 can be spent in way preferable for X.

^ wrote to try showing how X cant attack but reveals Y is now the attacker
which is another attack vector.

cant you see the attack vector..
dont think about X doing the 9btc.. for X to gain.. thats then everted by Y(your hope of scenario outcome)

think about Y broadcasting th X9Y1... triggering X so Y can then get 10btc
lets say Y broadcasts X's 9btc. to then allow Y to broadcast the tx that gives Y the whole 10btc

anyway theres many concepts throwing about. and many attack vectors in each.
the bip u quoted is not strong enough on its own and actually makes one person gain.

not really a moral/equal paradigm like some other concepts i have seen
19392  Bitcoin / Bitcoin Discussion / Re: Scaling Bitcoin. Is consensus achievable? on: November 27, 2016, 02:24:21 PM

I'm not sure if I understand you right. But it seems to me that you mean, that each consecutive pair of commitment transactions (those that aren't broadcast under normal circumstances) occurring on the channel must have shorter locktimes, so that later ones could be confirmed sooner than earlier ones?
If so, that's not the case. All commitment transactions produce outputs that may have the same time lock of say 1000 blocks, beginning from the block which includes parent commitment transaction. Commitment transactions are invalidated not thanks to newer commitment transactions have shorter timelock, but through exchanging secrets, whose hashes are exchanged at the beginning of state update. So at any step each party has only 1 commitment transaction that can be safely posted to the network, that's the latest transaction. All previous transactions are invalidated because should say X posts one of those transactions, Y can immediately take all funds form the channel.

im trying not to use buzzwords or over complex things so other readers can understand the fundamentals.

as for the individual spends within LN, they too need to do some things.
the 'secret exchange' in practice does not work. hense the need for the locks aswell.

EG (your concept version)
 i could have a direct connection to a pool and have bribed them to put my tx into a block the exact moment the 1000 block lock is released.. so when i send X in the last second, its in.
you spot mine and think your Y would over ride my X. the problem is that your Y transaction has to relay around the network and sit with the other high fee paying blocks in mempool before a pool accepts it into a block.. which after seeing the mempool bloat this week might be 2 hours.
where as mine gets in. making yours invalid(double spend attack).

thats why locktimes are needed too. to delay mine from being acceptable.

the bip you referenced may have exampled a 24 hour revoke time. but in practice.. users wont accept that.
also that can be attacked/abused in atleast 3 ways.

but hey there are many LN concepts, i just hope the one your viewing is not going to ignore using inner locktimes of descending order.. otherwise thats a weakness of that concept.


19393  Bitcoin / Bitcoin Discussion / Re: Scaling Bitcoin. Is consensus achievable? on: November 27, 2016, 01:39:02 PM
That's not the case with CSV, which is already adopted on mainnet.

Quote
Scriptable relative locktime provides a predictable amount of time to respond in the event a counterparty broadcasts a revoked transaction: Absolute locktime necessitates closing the channel and reopen it when getting close to the timeout, whereas with relative locktime, the clock starts ticking the moment the transactions confirms in a block. It also provides a means to know exactly how long to wait (in number of blocks) before funds can be pulled out of the channel in the event of a noncooperative counterparty.
https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki

yes
i just called it a laymens term of relevant gap/grace period (dont get hung up on my 10minute arbitrary number i used),
the old mechanism "in number of blocks" (as you quoted)
new concepts are using seconds instead. so instead of saying blockheight. or seconds. i for easy explanation for the scenarios said 10 minutes.. but the 10 minutes is not important. its just a demo purpose random number


the point is: gap simply wont be 1 second as that can be abused, much like in paypal everyone waits till the final second to push their bids)

the gap between acceptable bids needs to be more then one second. due to onchain issues about relay-propagation times and other factors
also i factored in that say the gap was 3 seconds. every time a person doesnt use LN for 3 seconds thats one possible lock wasted.
also i factored in that say the gap was 3 seconds. every time a person uses LN in milliseconds that takes away 3 seconds of utility

meaning its not an unlimited amount of transactions right up to the ONCHAIN nlocktime, there are actual limits to LN


to add to this..

in practice.. using say the middle graph (of my last post)
or
"which means if in milliseconds a hub does 259200 tx's  it now has to close within 7 days of opening" (scenario of post previous to that)

even though a onchain timelock wont allow the close session to be allowed/confirmed onchain until:
middle graph agreed tx(close session) reached 2hours 10 minutes
259200tx agreed tx (close session) reached 10 days 10 minutes

it still closes at:
middle graph 40 minutes - but just not confirmed onchain for another 1 hour 30 minutes (after 2 hours from opening due to onchain lock)
259200tx agreed tx 7 days - but just not confirmed onchain for 3 days. (after 10 days from opening due to onchain lock)

in short .. users are waiting hours or days unable to use LN at all, because all (inner LN) locks are used up. where users cant keep spending and the funds are not released onchain.. basically leaving users left in limbo.

meaning practically the channels SHOULD close earlier to not leave users in limbo. hense my gripe that channels should be able to close earlier.


from what i can see is in concept as their 'work around'
while users are in limbo between the LN inner lock being used up and the onchain locktime (scenario1:1h 30mb, scenario2: 3days)
users are persuaded to make a second channel using different funds (while initial funds are locked) to restart using the service while the limbo time of first session expires.

19394  Bitcoin / Bitcoin Discussion / Re: Scaling Bitcoin. Is consensus achievable? on: November 27, 2016, 12:15:47 PM
simple illustration


lock= 2 hours
left graph: user spends every 10 minutes
spend at 10th minute - lock release at 1hour 50min
spend at 20th minute - lock release at 1hour 40min
spend at 30th minute - lock release at 1hour 30min
spend at 40th minute - lock release at 1hour 20min
spend at 50th minute - lock release at 1hour 10min
cant use as realtime and locktime release lock is soon
end result lock-in was 2 hours but had to close in an hour - tx processed 5 out of 12

middle graph: user spends every 5 minutes
spend at   5th minute - lock release at 1hour 50min
spend at 10th minute - lock release at 1hour 40min
spend at 15th minute - lock release at 1hour 30min
spend at 20th minute - lock release at 1hour 20min
spend at 25th minute - lock release at 1hour 10min
spend at 30th minute - lock release at 1hour
spend at 35th minute - lock release at 50min
cant use as realtime and locktime release lock is soon
end result lock-in was 2 hours but had to close in 40 minutes - tx processed 7 of 12

middle graph: just once
spend at   Xth minute - lock release at 1hour 50min
time passes locktime release lock is soon
end result lock-in was 2 hours but had to close in at 1 hour 50 minutes - tx processed 1 of 12
19395  Bitcoin / Bitcoin Discussion / Re: Scaling Bitcoin. Is consensus achievable? on: November 27, 2016, 11:19:48 AM
if we went with LN's rhetoric of never needing to close channels.. then bitcoins mainnet is never needed once funds are deposited.
Mainnet is still needed, even if channels never closed, because without possibility of emergency closing, channels effectively lose state. It's like nuclear deterrence. Nuclear weapons have great impact on international relations, even though never used.

rationally LN should regularly close channels.
Could you please elaborate. Why LN needs to frequently close channels?

locktimes
EG say the locktime is  now+864000seconds (10days) 1480244302+864000seconds = 1481108302
LN does not stay active for 10 days
every transaction within LN uses a lock to keep latest relevance
in conception
tx z: unlock 1481108301
tx y: unlock 1481108300
tx x: unlock 1481108299
which means if in milliseconds a hub does 86400 tx's  it now has to close within 9 days of opening
which means if in milliseconds a hub does 172800 tx's  it now has to close within 8 days of opening
which means if in milliseconds a hub does 259200 tx's  it now has to close within 7 days of opening

also the secret is although being conceived that locktime of +864000 seconds means 864000 transactions are possible. its not
firstly. to secure relevance, there needs to be a gap between locks. so that the most relevant(x) doesnt time out and the next irrelevant(y) becomes relevant again due to there not being enough time to broadcast X before Y's time becomes relevant.

its going to end up that locktimes will be 10mins plus, to give a relevance 'grace' period.
eg
tx z: unlock 1481072302
tx y: unlock 1481036302
tx x: unlock 1481000302

meaning only 1440 transactions are possible in 10 days.

i used 10 days as a simple number because it displays limits clearly. but you might be saying well onchain lockin can be set to say 2 years.
i would counter that with the more complicated maths of hubs.. where by in the fantasy land of the 'visa comparable' scenarios or the 'one world currency' scenarios people are propagandising as to why LN is essential. that instead of happily processing just say 500 transactions per channel
for some day trader/gambler in 10 days.. a hub will be processing hundreds of thousands to millions of transactions (visa/oneworld scenario)

so although a 2 year lock effectively means upto 105120 LN tx (with relevance grace) over 2 years.. a hub will use up all of them 105120 locks very very fast.

eg. imagine onchain only copes with 4500 tx.. but at first LN is chosen by 10%. (450 tx)
yes LN free's up 450 tx no longer being onchain.

but now within LN 450 tx are done every 10 minutes instead of onchain. meaning the 2 year locks are used up within a fortnight due to the hub and spoke/multihop model

in short. if lock was set to 2 years. and 105120 were done in lets say 5 minutes. the channel needs to close in 5 minutes of opening and a new channel opened for 2 years

the benefit is obviously 105120tx are aggregated down to a final and single tx onchain. where bitcoins main net does see all the swaps of 105120tx and only sees 1tx of (laymens: final balance outputs)
but requires users to then re open a channel again which becomes a headache in a hub model
19396  Bitcoin / Bitcoin Discussion / Re: How bitcoin is good for enterprise ? on: November 27, 2016, 01:45:02 AM
legal tender (fiat) if in a bank account. is tied to regulations. the regulations are tied to the government of the location.
moving legal tender across borders can be a headache.

bitcoin however can be treated as:
a weightless asset reserve (like a gold reserve but without needing a lorry or muscles to move it.. without vaults and armed guards to secure it)
a tax haven
personal 'trust fund'
travellers cheque

things you can do with bitcoin:

declare baskets of 0.00xbtc as shares/bonds of stock. (research coloured coin)
set up a trust where 2 parents/trustees can sign, and then fund it by anyone/anytime they like to then pay out to beneficiary  (research multisig)
used as a global payment. eg all remote workers are paid xbtc a fortnight. thus not having to use different banks to pay different countries

what are other possibilities:
remittance markets
new/expanding industries: consulting, ASIC manufacturing, training, conventions, etc

employment expansion:
IT, customer service, trainers, designers, manufacturers etc

efficiency gains:
retailer: no chargebacks, no creditcard processing subscriptions, no 'card decline', etc
homeless: having a QR code paper sign allows them to accept electronic payment. not just metal pennies
unbankable: able to store value even if a bank refuses due to no ID or bad credit

businesses:
automating manufacturing by robots making/packaging as soon as payment seen on blockchain. so less need for staff
accounting/auditing more transparent. less need for staff
no need to securely store customer creditcard info, meaning less servers, less data protection headaches

are are many more. its just bitcoin is still in the 'innovation' category. all possibilities have not been recognised/thought of yet.
19397  Bitcoin / Bitcoin Discussion / Re: New SegWit stats? on: November 27, 2016, 01:05:42 AM
So let me see if i understand you correctly, now we are able to process 1MB of transactions every 10 min, after the upgrade we will be able to process 2.1MB of transactions every 10min. Which as you agree is a capacity increase, yet somehow it doesn't equate to scaling because babies can't run marathons.
Yes how can the rest of the world not understand that logic, the only reasonable explanation is a conspiracy by the big bankers.

You'd have a much better argument just straight up saying that you don't consider manual increases of throughput as scaling, and what YOU mean by scaling is AUTOMATED scaling e.g. where block size can be  adjusted unlimitedly up by the protocol i.e. BU. And your logic on why LN is not a solution to scaling, is most people think of scaling in terms of throughput/tps e.g. how many transactions can be made with BTC. Where your definition of scaling is the the size of the blocksize data structure in C++

See how easy that was, no that we agreed on terms there's no need to argue anymore  Grin

word games..

4mb not= 4x capacity
4mb not= relevance to capacity
the 2.1mb = capacity increase
the 2.1mb = relevance to capacity

LN should not be the compulsory end game solution to capacity scaling. it should just be an open choice/service on the side.

easy enough, and i only used silly analogies due to the person i reply to having silly analogies in the past. so i was trying to speak on their level
19398  Bitcoin / Bitcoin Discussion / Re: Scaling Bitcoin. Is consensus achievable? on: November 27, 2016, 12:42:58 AM
i think the debate above has got out of hand where the term "fractional reserve" has the issue

one person lets call him (CB) thinking of it as the traditional meaning of if 10 is deposited then a bank can create 10 new money.
the other person call him (K) thinking. deposit 5 each (10 total). and do a craig wright to get 29.6 where collateral (trust of value) becomes value

EG
in a channel between X,Y they deposit 10 publicly on the blockchain to open the channel
X and Y 'spend' the 10 to another active channel user Z
asking Z to not use LN but to use Z's onchain balance address to pay 4.9 each to X,Y ONCHAIN and Z keep the 10 offchain, to spend later


X: i have control of 10 in LN, i have 4.9 personally ONCHAIN too. this is my 14.9 collateral. i can sign a message to my personal 4.9 and a message as part of the LN 10.
now give me a government grant,VC money up to 14.8

Y: i have control of 10 in LN, i have 4.9 personally ONCHAIN too. this is my 14.9  collateral. i can sign a message to my personal 4.9 and a message as part of the LN 10.
now give me a government grant,VC money up to 14.8

they receive VC funding to 29.6btc. where infact X, Y have ZERO LN collateral. and only 9.8 personal collateral.

fractional reserve is not just about money CREATION like (CB) thinks. its also about faking collateral you don't have or moving funds around, to profit from something that you dont have

now lets get back ontopic of scaling bitcoin
19399  Bitcoin / Bitcoin Discussion / Re: [News]WHY AGAINST SEGWIT AND CORE? Mining investor gives his answer on: November 26, 2016, 11:22:49 PM
Personally I'd like to see some research on what effect 4mb weight blocks would have on further centralization, but that's what i foresee most likely to happen.

the 4mb bloat has been evaluated.
the main cries over the last few years why anything above 1mb was bad was things like
"not everyone has fast internet"
"chinese firewall"
etc

yet all that has been debunked and tests were done that 8mb is acceptable.. but 4mb was deemed the very safe amount to handle for now as acceptable bloat.
"chinese firewall"
yes thats right. while the west was crying that it cant go above 1mb due to chinese firewall.. the east (inside the firewall) all laughed and said what a stupid doomsday. nothing about the chinese firewall has issues with it and data can be so much more than 4mb


"not everyone has fast internet"
tell that to the millions of people in africa doing skype videocalls. then millions of people uploading to youtube. millions doing livestreaming, whilst online gaming...

so devs now backtracked doomsday and happily said upto 4mb bloat was acceptable.


yet still keeping tx baseblock data at 1mb..

i cant wait until they backtrack the 1mb baseblock dooms day when they finally see its just a orphan risk scenario.. hense the need for super high majority consensus to mitigate orphan risk.

the 'it causes altcoin' doomsday is FUD. because oppositions need EXTRA added code to intentionally IP/USERAGENT BAN connecting to certain nodes.. just like ethereum intentionally split '--oppose-dao-fork'
without adding an intentional ban list of IP/useragents. the connected nodes just have an orphan battle on a single chain, they dont keep 2 chains alive for eternity they orphan the minority
high majority consensus means low risk of orphans. and leaves the minority never syncing.. thus again no second chain. just minority left unsynced


as for the "linear/quadratic" doomsday.
easy.

if sigops is causing issues... limit sigops.
there is no rational reason for one person to need to do 500-20000 sigops. so limit the number of sigops a tx can have.
aswell as ensuring validation times are not used as a DDoS, the extra benefit is we will not see a block with just 1tx sized at 1mb with hefty amount of sigops to churn through..
19400  Bitcoin / Bitcoin Discussion / Re: wow ,almost 30,000 unconfirmed trans on: November 26, 2016, 05:38:56 PM
In other words, could there be a blacklist of Bitcoin addresses?
That sets a very dangerous precedence and I would be against that. However, miners are able to do that should they choose to.

much easier rule is not use fees to delay transactions
or blocking addresses

 but transaction maturity.
EG like blockreward maturity of 100 confirms

transactions cant be respent for atleast an hour and dropped out of mempool if someone tries to repeat spend in every block.
atleast it stays more inline with 'priority' than using a fee war to sort out things
Pages: « 1 ... 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 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 [970] 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 ... 1473 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!