Bitcoin Forum
January 24, 2020, 05:48:17 AM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 [288] 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 ... 873 »
5741  Bitcoin / Bitcoin Discussion / Re: SegWit (26.2%) vs Bitcoin Unlimited (28.5%) on: March 13, 2017, 11:35:18 AM
I should imagine other niceties, such as IBD improvements will be an 'on the back-burner' issue until the future network direction is resolved.

an idea...

IBD concerns are less about time of IBD but actually of..
(subtle difference of psychology(nodes function-ability vs users utility))
time to get it synced to have a full UTXO set to see their uptodate imported key balance and actually start spending.

by simply (much like a liteclient) downloading a UTXO set first as a temporary measure. it then allows people to see their upto date "balance" to then start spending. making the IBD still important, but in practice something that becomes more of a background matter and atleast not have people "waiting".

then as the IBD works in the background. it just makes any changes to the UTXO as it gets updated.

then IBD becomes less practically tiresome to the user
5742  Bitcoin / Bitcoin Discussion / Re: Blockstream is nothing more than a $70M blockchain takeover attempt on: March 13, 2017, 08:45:15 AM
I will agree that the governance decision should be made more transparent but both miners and development team are guilty of this

we need to return to the mindset that we do not need a governance of DEVS

nodes are the boss.
pools are the secretary
devs are the workers

people have forgotten that what node they run dictates the rules of bitcoin by majority.
instead they have sheep slept themselves into what DEVS preach is what peoples should run.
instead they have sheep slept themselves into what DEVS have bypassed should be blamed on who they bypassed it to.(core 'soft fork it to miners then blame the miners')
(never to blame a dev, but give the devs the kingdom at the same time)

TO ALL:
if you think that core is king. then you have already centralised yourself into making core take over what was an open network. while pointing the finger at someone else.

tl;dr (to long, didnt read)
if you are running core simply because you love blockstream CTO maxwell. but never actually read the code. and instead just had 'trust and admiration' then you are the problem not the solution
5743  Bitcoin / Bitcoin Discussion / Re: Gavin to Satoshi, 2010 -- "SOMEBODY will try to mess up the network (...)" on: March 13, 2017, 07:09:06 AM
bitcoins consensus, is that of the nodes first pools second.

Then why is there "proof of work" ?
And why is nobody Sybil-attacking the node count ?

If "nodes are the boss" and it is damn easy to outnumber the existing nodes with a tiny fraction of the amount of money it takes to be a miner making a block, why are all these stupid Chinese mining, and are they not setting up whole datacenters of millions of nodes ?

Why do you even think that Satoshi used proof of work ?


because people can spot a sybil attack and actively ban nodes running on things like amazon servers.
there have been attempts in the past. and people spot them.

as for PoW.
node=boss
pools=secretary

if pools do not show good proof of their work, and collated data that comply to nodes rules, nodes reject it.
and guess what. pools "work" does get rejected quite often
https://blockchain.info/orphaned-blocks

a pool could have 99% of the hashrate.. but if it only had 1% of node count. does not mean the pool changes the nodes rules. it just means SUPER HIGH clusterf*ck of orphans.

this is why 50% of pools are undecided about certain bitcoin plans. because they are unofficially waiting to see what nodes support, to reduce orphan risks.

5744  Bitcoin / Bitcoin Discussion / Re: Bitcoin and the whole Cryptocurrency market: UPUPUPUP? Reality-check! on: March 13, 2017, 06:46:48 AM
However I would like to hear what crypto-veterans think about the recent increase in Bitcoins- and Altcoins total market cap. Is it growing too much, are we in a bubble?

first of all
bitcoins total MARKET cap is meaningless and speculative 'estimation of desire' not an actual 'backed up by' financial figure, so its a bubble number...
yep, it is

bitcoins "price" is not ascertained by looking in all the fiat bank accounts of bitcoin exchanges, totalling up the fiat cap(hoping to see 16billion) and than attributing it to bitcoins 16mill coins to get to the "billions" of bitcoin MARKET cap.

bitcoins "price" is ascertained by looking seeing just what supply and demand there are of just a few hundred thousand(or less) coins that actually sit on exchange orderlists "price value" A bitcoin at.. and then separately.  take that "price value" of a bitcoin and multiply it by the 16mill coins(not on exchanges)

in short
there are NOT 16billlion dollars in bank accounts to back up the 16mill coins to actually give a real 1000:1 swap value of bitcoin to fiat of $1000each.

so imagine just a couple hundred thousand coins wanted to sell out and take all the FIAT(far far far less than billions).  the bubble of 16billion, bursts
5745  Bitcoin / Bitcoin Discussion / Re: Gavin to Satoshi, 2010 -- "SOMEBODY will try to mess up the network (...)" on: March 13, 2017, 06:27:23 AM

hashing power is only a signpost, a best guess, as to what the consensus really is.


I said this somewhere else, but defining the word "consensus" without having it referring to a genuine phenomenon, is a useless exercise.  Consensus is a phenomenon.  Not something you can define as "what should be" or "the will of the people" or any other abstract definition, devoid of relationship to reality.

bitcoins consensus, is that of the nodes first pools second.

CORE (not pools, not BU not some random guy,, but core) BYPASSED bitcoins built in consensus. and literally handed the vote to only pools.

this does not mean pools(hashing power) have the ultimate vote on bitcoin...
just the ultimate vote on pushing segwit into taking over bitcoin

segwit is a total rewrite that then makes it even easier to bypass the real bitcoin consensus by making it even easier to keep giving pools the vote (by going soft)
5746  Bitcoin / Bitcoin Discussion / Re: Blockstream is nothing more than a $70M blockchain takeover attempt on: March 13, 2017, 06:14:02 AM
This will get interesting, if a big company or a bank start to target the Core developers. Will they sell out like Mike Hearn?

cough
hyperledger
cough

oh wait is that blockstream i see in hyperledgers "members" list..
https://www.hyperledger.org/about/members
hyperledger.org/wp-content/uploads/2016/08/hl_blockstream-300x184 dot png
hang on isnt hyperledger managed by IBM and linux partnership...

so knowing blockstream is in the hyperledger banking cartels hyperledger project..
ask yourself the question about certain core developers (maxwell, Matt corallo, rustyrussel, etc)


wait i seem to have not emphasised something, or people didnt get the hint..


5747  Bitcoin / Bitcoin Discussion / Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB) on: March 12, 2017, 05:55:31 PM
knowing that ultimately (due to not preventing native key use) segwits only real promise is a fee discount(for the segwit key volunteers)
causes fungibility issues between which tx types cause preference or not(sigop,malle armed+ expensive or disarmed +cheap)

where people will have preference over which type of funds they receive/they prefer to deal with, based on which keys are used.
eg native(starting 1) becomes nasty and segwit(starting 3) becomes 'good money' people will not want to risk funds coming from a 1address

where not only uses start having thier preference but pools do too. where by if you know ur dealing with funds coming from native key may end up taking longer to confirm, or rejected to never confirm if pools start ignoring native keys. etc

aswell as the things jbreher  mentioned
5748  Bitcoin / Bitcoin Discussion / Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB) on: March 12, 2017, 05:40:48 PM
To summarize the last discussions: Would that be an acceptable base for a "real" BIP?

1) Segwit as first measure;
2) adopt DooMAD/Garzik/Upal proposal (10%+ or 10%- voting when conditions are met), modified by adding a "upper limit"
3) for the first year, a 1,5 MB upper base limit (equivalent to ~3 MB maximal "block unit" size, for now)
4) for years 2-5, a 3 MB upper base limit (equivalent to 6-12 MB [worst case] maximal "block unit" size)

all that coded into a single BIP/pull request, to make it attractive for "big blocker" miners to accept it.

(I hope the terminology is OK)
3 and 4.. = spoon feeding numbers by devs hard writing the limits and needing users to download new versions (if a dev team even rlease the limit).
if the last 2 years are anything to go by.. forget it.. 2 years SO FAR to debate just getting a 2mb REAL limit even when all devs admit 4-8 is safe so the 2015 2mb compromise was actually ok all along....
we cant keep having these "please dev release a version that has X" debates
and we cant even have users set limit and release to public in their own repo due to "its just a clone of core but not peer reviewed REKT it"

instead
each node could have a speedtest mechanism. it start-point is when it sees a new height block. its end-point is after it has validated and relayed it out.
then over a scale of 2016 blocks it combines the times to get a total score.(recalculated every 2016 blocks) that way it can flag its capability.
thn we can see what is capable

that way the network can know safe capable growth amounts without spoon feeding and 2 year debates.

then below the network limit (capability) upper level:
preference lower level:
also at GUI (options tab) and rpc-console(debug) level.. or even a downloadable .ini file patch USERS can change the settings themselves without needing to recompile each time their independant client. or having to wait for devs to spoonfeed it.
which is adjustable by consensus.



5749  Bitcoin / Bitcoin Discussion / Re: About Bitcoin Foundation on: March 12, 2017, 02:55:57 PM
When Satoshi left the scene, some people thought it would be a good idea to have a governing body or a central organization that could speak

with governments about Bitcoin. They were also supposed to arrange big events where Bitcoin is discussed and promoted, but most of that money

went into huge salaries for the people "working" for the BF. { even the secretary got a huge salary}  Angry

dont forget the mightyduck child actor turned fund syphoner brock.
once he joined.. it was game over for the BF
5750  Bitcoin / Bitcoin Discussion / Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB) on: March 12, 2017, 01:55:41 PM
lauda.

take no offense by this..(think of this as a genuine question, requiring your critical thinking cap to be worn)
but are you thinking that a quadratic sigop attack is just about limiting sigops to not cause validation delays when a solved block is relayed.
..
because thats how im reading your thought process on your definition of DoS attack


have you thought about this as a DoS attack:
those limits which you think are defending validation time attack of solved blocks. can actually be used as an attack by filling a block

EG if a block in v.12 only allowed 20ksigops for the block and 4k sigops per tx... it only takes 5 tx to fill a block. and not let anything else in.
EG if a block in v.14 only allowed 80ksigops for the block and 16k sigops per tx... it only takes 5 tx to fill a block. and not let anything else in.

thus a native key user can with just 5 tx stop other tx's getting in. and thus all segwit promises cant be met.
no boost to blocksize as no segwit tx's adding to the block.

rmember im not talking about delay in validation times of propagation after block is solved. im just talking about filling blocks (mempool attack leaving everyone waiting)



so knowing that the segwit 'activation' does nothing to disarm native keys.
meaning
blocks can stay at 1mb. (either with as little as 5 native(sigopsbloatfill) or thousands of natives(databloatfill))
malleation and sigops are not disarmed.

so effectively.. what does segwit actually offer that is a real feature that has real 100% guarantee promise
5751  Bitcoin / Bitcoin Discussion / Re: Open Letter to GMaxwell and Sincere Rational Core Devs on: March 12, 2017, 12:14:34 PM
so trainwreck wants to halt developmnt and the have core set up as the regulator to stop anyone else from development..


and he doesnt think thats centralising the project as a FIAT. and only allow the coins to be openly distributed (via contracted LN services that require counterparty signing (banks))

....
45 pages of failed attempts to try nashifying people.. just to attempt to make people(wrongly) think that centralising bitcoin into a controlled centralist currency is good?

seriously!!

looks like brain washing to me
'if i throw economists quotes at a crowd 800 times people will think they need to be controlled by economics and code that becomes closed off and regulated by core.. rather than grow and be revolutionary open code currency beyond the mindset of FIAT
5752  Bitcoin / Bitcoin Discussion / Re: How the fork will happen if a fork happens on: March 12, 2017, 04:28:07 AM
ok guys.

after the 20 minutes of you playing with double your allotment of coins..

..
think passed the selfish greed of the 20 minutes of swapping the coins.

now genuinely think. which will keep bitcoin utility alive and which is just empty promises that only achieve something if you dance around for months

choose what version you prefer based on the actual long term abilities it would bring EVERYONE. not just the few
5753  Bitcoin / Bitcoin Discussion / Re: How the fork will happen if a fork happens on: March 12, 2017, 03:38:48 AM
many people may not like the core approach, but they're also practical enough to recognise that they're the ones with the skills. and most everyone else would love to get rid of the cancer that is chinese mining cartels.

you do know real consensus is about the nodes..

you do nore core actually avoided that and intentionally chose to give pools the only vote. which nodes officially cannot veto
think about that for a while.

dont jump back to defend core.

think about who gave the pools the voting power.

imagine it the other way. nodes first and pools not allowed to vote until nodes reached X% first
5754  Bitcoin / Bitcoin Discussion / Re: Blockstream is nothing more than a $70M blockchain takeover attempt on: March 12, 2017, 03:19:16 AM
We need a new consensus mechanism for Bitcoin improvements.

consensus works

the problem is. CORE BYPASSED consensus and INTENTIONALLY only gave pools the vote. rather than nodes then pools.
5755  Bitcoin / Bitcoin Discussion / Re: About Bitcoin Foundation on: March 12, 2017, 01:44:19 AM
It does not regulate Bitcoin. It can't. Its objectives include promoting Bitcoin.
It largely became irrelevant because it was more interested in lobbying with governments rather than spending money on protocol development.

it done neither successfully, just pretended the majority of members funds were being used for those purposes while they syphoned alot out while doing the minimum
5756  Bitcoin / Bitcoin Discussion / Re: About Bitcoin Foundation on: March 12, 2017, 01:34:29 AM
the BF
was originally envisioned to be a place where people can get info. collaborate on projects, organise meetups social events and also fund dev teams.

it was hoped they would have got into going to help governments, legal agencies understand bitcoin better, and ensure governments didnt get too heavy handed with bureaucracy of regulating the fiat<->btc exchanges..

bitcoin itself is not in any countries/government jurisdiction.

but people are.
and businesses using bitcoin could be regulated. especially ones also handling FIAT. such as exchanges. so although you cant regulate bitcoin. businesses working at the edges between bitcoin and fiat can be played around with by governments.

the BF was not intented to ever "regulate" bitcoin or control bitcoin but be pretty much be the noticeboard of bitcoin information.

but they just milked the members dry and walked away.
5757  Bitcoin / Bitcoin Discussion / Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB) on: March 11, 2017, 11:14:06 PM
No, you misunderstand this completely. This is absurd. You can create a TX with 20k sigops maximum, you just can't do this with Core. You're confusing policy and consensus rules and you're misread the code. See this for example: https://github.com/bitcoin/bitcoin/pull/8438

this is your mis understanding
the 20k limit (old v0.12) is the BLOCK LIMIT for sigops
the 4000 is the TRANSACTION limit
meaning a malicious spammer can make 5 TX of 4,000 sigops in v0.12 without and FILL THE BLOCKS sigop limit (no more tx's allowed)

the 80k limit (v0.14) is the BLOCK LIMIT for sigops
the 16000 is the TRANSACTION limit
meaning a malicious spammer can make 5 TX of 16,000 sigops in v0.12 without and FILL THE BLOCK sigop limit (no more tx's allowed)

as for your link - https://github.com/bitcoin/bitcoin/pull/8438
Quote
Treat high-sigop transactions as larger rather than rejecting them

meaning they acknowledge they are allowing transactions to be more quadratically used to attack.

they simply think that its not a problem. but lets say in the future. things move forward. if they then made it 32000sigops per tx. and 160,000 per block. still thats 5 tx per block and also because a native malicious user will do it .. the TIME to process 5tx of 32,000 compared to last years 5tx of 4000 will impact...



the solution is yes increase BLOCK sigop limits. but dont increase TX sigop limits. keep it low 16,000 maybe but preferably 4000 as a constant barrier against native key malicious quadratic creators.
meaning if it was 80,000 a malicious user has to make 20 tx to fill the blocks 80,000 limit. instead of just 5..
and because its only 4000X20 instead of 16,000X5 the validation time is improved
but they havnt
5758  Bitcoin / Bitcoin Discussion / Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB) on: March 11, 2017, 10:37:42 PM
No, you misunderstand this completely. This is absurd. You can create a TX with 20k sigops maximum, you just can't do this with Core. You're confusing policy and consensus rules and you're misread the code.

admit there is a 2 tiered system. not the word twisting
5759  Bitcoin / Bitcoin Discussion / Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB) on: March 11, 2017, 10:28:23 PM
sigop attack
v0.12 had a 4000 sigop per tx limit (read the code)
v0.14 had a 16000 sigop per tx limit (read the code)

so now check the code.
https://github.com/bitcoin/bitcoin/tree/0.14/src
core 0.14: MAX_BLOCK_SIGOPS_COST = 80000;
core 0.14: MAX_STANDARD_TX_SIGOPS_COST = MAX_BLOCK_SIGOPS_COST/5;
meaning
core 0.14: MAX_STANDARD_TX_SIGOPS_COST = 16000
You almost made me fall for this.. I was too tired to check whether your numbers were true or not myself right away. That '80000' number is the Segwit number, i.e. it is scaled for the 4 MB weight. 80 000/4 = 20 000. Now if you apply 'MAX_BLOCK_SIGOPS_COST/5;' on this number, you get.. 4000.  Roll Eyes

i used 0.12 as an example of how many quadratics were permissible prior to segwit
and
i used 0.14 as an example of how many quadratics were permissible post segwit
prior: 4000
post: 16000

but in actual fact it is not v0.14 =4000 prior segwit its actually still 16,000 prior segwit (for pools using these uptodate versions EG 0.14 today)
check the code
5760  Bitcoin / Bitcoin Discussion / Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB) on: March 11, 2017, 10:18:52 PM
So does this mean a soft fork bypasses consensus?
No. Soft forks are backwards compatible

Note that this requires believing that making nodes that currently operate in a trustless manner suddenly dependent upon others for security fits the definition of 'backwards compatible'. I think that definition of 'backwards compatible' is ludicrous. YMMV.

something we can agree on.. needing segwit nodes as the 'upstream filters' (gmaxwell own buzzword) is bad for security. plus its not "backward compatible"

i prefer the term backward trimmed(trimmable), or backwards 'filtered' (using gmaxwells word) to make it clearer old nodes are not getting full validatable blockdata
not a perfect term. but atleast its slightly more clearer of what segwit is "offering" compared to the half truths and half promises and word twisting to offset giving a real answer.
Pages: « 1 ... 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 [288] 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 ... 873 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!