Bitcoin Forum
January 20, 2020, 03:55:46 AM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 237 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 ... 873 »
5721  Bitcoin / Bitcoin Discussion / Re: BIP100 updated - By Jeff Garzik and Tom Harding on: March 13, 2017, 11:25:15 PM
why are you jackals trying to promote 2 different "Democratic" blocksize proposals at once (this and BU)


is it because user support for BU is so low, despite how many BU nodes you have spread out over so many hosting services
Yeah people shouldn't be allowed to promote more than one thing ... and it should only be segwit Tongue /sarcasm

If core put a pure BIP100 vote option in a release, I'd expect it would happen.
BIP100 did reach 70% before with coinbase comments ... until everyone realised that core had no intention of implementing it.

any dynamic is acceptable to BU, and with for instance. the 5% every 2week max growth. it will take a few years before affecting xt.. so the only one it does affect at activation is core.
(funnily enough a few people have manually taken core and already put in a 2mb+ in their limits to cover any network change and they all run fine on the network)

all core need to do is actually give in and add just the few minimal changes. or be a**hats and orphan&ban the majority if they want to dig their heels in and oppose it.(creating their own altcoin)

i would actually prefer core to have some extra RPC commands or a GUI options tab where users can while LIVE. change settings.
that way users are now slaves to devs digging their heels in by refusing to change something
5722  Bitcoin / Bitcoin Discussion / Re: Bitcoin fork with or without advance notice? on: March 13, 2017, 10:24:37 PM
franky1, Are you running a full node?  If so....what client are you supporting?  Is there any way that we can hedge our bets on the "off chance" of the occurrence of a fork actually precipitating very suddenly?  I mean....I learned something with the ethereum fork....the newer chain gained the support and the older chain lost value....but there was a window there where both had equal value and some took advantage of that situation by acting quickly....What do the tea leaves say here?

i have my own. with a few tweaks.
infact i have core, my own(wrote in different language) bu, classic, bitcoin j and others. i play with them all depending on what im doing/testing

but in short.. if segwit activates.. BU, xt, classic, and al the dozen others 'brands' (if not biasedly banned by blockstreamers) will still get the filtered (trimmed) blocks. but obviously by not having segwit validation. will only be in the hodgepodge of second tier(downstream) part of the network but not fully validating segwit data.. and just relaying native tx's upto segwit upstream nodes..
essntially making BU classic, xt and older nodes just lite wallets.

but if BU, activates.
xt, classic and a dozen other 'brands' will all be ok ALL on same level.(no 2 tier)
 but then core end up seeing orphans and banning nodes to ignore the orphan drama. thus stalling out core, forcing them to either
tweak code to join the majority (give in and raise the block limit).
ban nodes and only white list core nodes to start their minority coin
stay stalled and turn node off

if classic activate
BU xt and a dozen other 'brands' will all be ok ALL on same level.(no 2 tier)
but then core end up seeing blocks it doesnt like .. so orphans and banning nodes to ignore the orphan drama. thus stalling out core, forcing them to either
tweak code to join the majority (give in and raise the block limit).
ban nodes and only white list core nodes to start their minority coin
stay stalled and turn node off



i think the simple solution is for core to:
keep the TXSIGOPLIMIT at 4000.. that way no matter what the blocksize is, malicious TX's dont start making bigger sigops (EG cores 0.14 16,000 rather than 4000 - facepalm)
and core to put in a RPC and GUI options tab where users can reset the blocklimit live...WITHOUT needing devs to give in/spoonfeed.  without needing to recompile.. so that users are more incontrol and adaptable to change without needing devs to decide for them if/when/how.
that way users can change settings at their leisure and become more independent
5723  Bitcoin / Bitcoin Discussion / Re: Blockstream is nothing more than a $70M blockchain takeover attempt on: March 13, 2017, 09:29:33 PM
dino

you do know pools spend too.
exchangees spend too
users spend too..
node users spend too.

your thinking of the end-user USABILITY..
in which case everyone is a user..(in your eyes)

but your not thinking about the underlying code/protocol/network infrastructure of bitcoin

all your grasping is the end user experience.

EG if bitcoin was a bank all your thinking about is the person and an ATM
your not thinking about the behind the scenes stuff..

.. if you are.. you are only comprehending it at a high-school 30second laymens understanding. but not the real function and features that make bitcoin stronger than banks or anything else

if you think that non mining nodes only job is just a data store.. you have been missinformed
5724  Bitcoin / Bitcoin Discussion / Re: Forks are highly important on: March 13, 2017, 09:05:00 PM


..what CODE is best for the long term survival of bitcoin for generations to come mean more then some temporary gesture that is meaningless in a few years.


So you are saying you trust a bunch of idiots that survive off copy-pasting 99% of Core's hard work, then everytime they introduce something they somehow always manage to fuck up:

https://www.reddit.com/r/Bitcoin/comments/5z47f3/it_looks_like_chinabu_developers_forgot_to_add/

Good luck, can't wait to dump BUC in poloniex to get double BTC for free.

are you saying that core are independent.. and that those non BU (but do "99% copying-pasting" and surviving off each other) is not the same. (EG matt corallo has his own repo, luke JR has his own repo. as do many others... are they all bad gys for having their own repo.. including the pools
are you saying that having a repo of your own is the problem because all you care about is core because of its management
are you saying you trust core because its not independent because they only want to work with blockstream devs.
are you saying that no one should take the core code and make tweaks. and instead have to beg blockstream for something
are you saying that if a core release has not been completely rewritten and only adjusted slightly. that suddenly its an altcoin(eventhough it runs on bitcoins mainnet as other implementations do)
are you saying that independent devs cannot do anything unless gmaxwell is involved and where it has to have gmaxwells wishes complied with.



personally i think pruning is stupid. once pruned you cant be part of the full node syncing mechanism.
you might aswell just run a litenode.
allowing a node to be no witness and pruned should be treated as third tier nodes and not categorised as a full node.

i can think of many things core have not done. or even things core have done that have caused big issues (sipa's 2013 leveldb mega orphan event)
devs are not perfect.

and only code matters.
people should decide what node to use on the abilities and features the code allows or doesnt allow.
in my eyes segwit is an empty gesture of half promises that opens up new attack vectors
5725  Bitcoin / Bitcoin Discussion / Re: Forks are highly important on: March 13, 2017, 06:34:46 PM
blame blame accuse accuse

1. jihan only manages 15% and of that 15% not all of it is actually his.
2. your forgetting the ~50% undecided either way
.. so trying to blame a few small numbers as the reason why segwit is only achieving 26% is a laugh.(segwit is at 26% not 85%)
3. core CHOSE to avoid node support first then pool support second by going soft. dont blame who core allowed to vote. blame core for making them the only voters.
.. because smart pools wont activate /flag unless they know that the nodes can cope/accept the changes. so even without official vote, pools will wait for node acceptability(to avoid orphans and ensure that people accept their version of blocks to atleast spend the rewards)
.. thus core have literally shot themselves in the foot thinking they can get 100% dominance without REAL full network consent by going soft.
4. if core done a node first pool second. whereby a OVER say 75%-95% nodecount triggers a pool vote. the pools would have been more confident.

but
5. even if you think its just about votes. you need to remember WHY they vote. segwit is not perfect, core devs are not gods, they are human and can come and go..

..what CODE is best for the long term survival of bitcoin for generations to come mean more then some temporary gesture that is meaningless in a few years.
5726  Bitcoin / Bitcoin Discussion / Re: Bitcoin fork with or without advance notice? on: March 13, 2017, 06:08:56 PM
anyone can download a copy of a node and then with a friend. set the 2 nodes to only talk to each other and then change the rules as they see fit.
this is called making an altcoin.

many people have done this and no one cares because its just an alt.

however if you want the network to follow you. you need the majority of the networks consent.
you can set the announcement for 1 week, 1 year 5 years etc(whatever). but if your changes/desires do not meet the desires of the others on the network. they will not follow you.

the current bitcoin debates are trying to get network majority consent or they simply wont bother.
yes segwit may want to split off and ban ~75% of the pools using UASF even if the 'vote' is only around ~25% by this october.

but they then become a minority altcoin. which is less secure and can be attacked by the majority. where by it takes longer for blocks to be solved. the blocks are spammed and many blocks get orphaned.

this is why both sides are hoping for a majority to reduce risks of orphans, hash attacks, spamming and sybil attacks


5727  Bitcoin / Bitcoin Discussion / Re: Blockstream is nothing more than a $70M blockchain takeover attempt on: March 13, 2017, 05:32:14 PM
Nope.  Nodes don't mean anything.
summary of my post below for all the TL:DR people
dinofelis you are just talking about end user experience of just spnding coins. you have not talked about the integrity, security, consensus of bitcoins self regulation of protecting the coins.

by having diverse nodes and INDEPENDENT DEVS makes it less likely for corruption of the rules aswell as avoiding the physical location attack, the more diverse the nodes get

i think you need to learn about bitcoin consensus and the protocol, beyond just the end-user experience




long explanation
what you are talking about is NOT about how bitcoin works at the consensus level nor the job of what the nodes do
your talking about the millions of users that rely on third parties services to not need full nodes for all the millions of 'users'.

essentially your talking about users. not the bitcoin security network protocol.

i agree 6millionish current users dont need to run a node just to spend coins. bt that has nothing to do with how the network functions.
all your doing is explaining that users can rely on middlemen, if they wanted to. rather than be an active part of the self regulating node network.

but thats where your now talking about users becoming reliant on middle men. rather than the network rules.



what your not taking into account are that all these lite/web wallets and market services are third parties.. but they need to communicate to full node network.
even pools run a node.
so whether your emailing a pool, or api submitting a tx via a webwallet or litewallet... the tx has to sit in a mempool and meet the rules that the majority of nodes can accept. otherwise that tx wont exist.
its either rejected at mempool/relay level due to not meeting the rules. or rjected after being in the block if the node network decide the block attributes the pool used dont meet the node networks rules.



what you are forgetting is what the full node network actually does.

firstly.
again, you are right the 6mill+ users dont need full nodes. as lite and webwallets can act as the middlemen talking to a server that has the full node talking to the network.

secondly.
spending coins does not mean damned all to nodes or pools.
if you want to push a TX to ETH.. ETC wont care. data is data
ETH or ETC dont get giddy with excitement more if im spending 100000 coins and less excited if your only spending 1 coin..
data is data. tx vale is meaningless to the block/rules.

BUT

what matters is what atleast 50% (preferable as close to 95% as possible) of nodes can agree on to reduce the risks of orphaning blocks.
for instance. ALL the pools worked on ETH.. but no exchange eth node, no localbitcoin eth node and no fiat OTC private trader used ETH nodes.. then the ETH miners cant spend their coins because no one there to buy them.
those blocks and coins are just invisible to the network of ETC.

so pools will follow the NODES rules of what the nodes will accept
firstly AND more importantly follow the nodes rules otherwise the block gets orphaned and the pools reward coins dont exist so the pool has wasted time making a block that ends up in the trash.
secondly
so pools can spend their reward with exchanges that see the blocks they created

you even admit it yourself users need to make sure which chain their third party service is communicating with(or who thy are emailing to). otherwise you might aswell be emailing your transaction to the Clams network(an altcoin) rather than the bitcoin network.

your entire scenario has nothing to do with network security or integrity of validating the data. or how blocks are either accepted or rejected, it is just talking about surface layer coin USAGE, not the underlying code/protocol/security of bitcoin.


yes all coin users can just rely on third party services to handle the messages, api,emails on the users behalf. and the network can have just 1  pool node in the network
but then thats centralising the network where the pool can make changes and the users are then subject to that change.

however by having many nodes and many pools. ensures that changes do not occur as easily and the nodes and pools become accountable to eachother whereby changes can only occur due to mutual consent(consensus) or risk having the blocks rejected if they do not meet the nodes rules.



i know you are going to rebut that there could be a altcoin that is just the pools node running things. and then having many offchain communication methods like API to the websites and lite clients and email addresses.

but now users are completely reliant on one entity setting the rules for itself. which.. just makes it corruptible and nothing more than FIAT. but without the regulations.

..
bitcoin doesnt need regulators because the diversity of the network self-regulates. thats the beauty of it.

and to be ontopic.
if all nodes were running core. and all pools were running core. then there might aswell just be 1 pool node and a huge bunch of API calls to all the services(from a rule changing prospective).
because the only benefit of distributing the chain is not about protecting the rules, as such. because core can change the rules.

but purely about not having a physical location attack to take them offline.
5728  Bitcoin / Bitcoin Discussion / Re: SegWit (26.2%) vs Bitcoin Unlimited (28.5%) on: March 13, 2017, 11:48:16 AM
When a proposal wins a vote, it becomes dominant. BUcoin won't survive the markets, the vast majority of commercial and private players actually using Bitcoin are publicly rejecting it

only the "markets" that are VC funded by DGC, http://dcg.co/portfolio/
which are in blockstreams pocket

hence why BTCC is the loudest pool supporting segwit..and flagged segwit support within minutes of the october start, rather than take the time to assess things first... oh look DCG->BTCC
5729  Bitcoin / Bitcoin Discussion / Re: SegWit (26.2%) vs Bitcoin Unlimited (28.5%) on: March 13, 2017, 11:39:43 AM
Where are the BU privacy solutions, like Confidential Transaction or Mimblewimble?

maybe bloating up a tx from say 450bytes to 1.4kb by adding commitments is less important than keeping transactions lean.
maybe mimble and other 'confidential' matters should be left for second layer solutions like LN or sidechains. and to keep bitcoin lean is more practical

Where are the new more efficient tx encoding formats?
well if core want to change tx encoding for minimal tx efficiences, but then bloat tx's with in-efficient bloating commitments for the sake of confidentiality. results in no beneficial efficiency trade-off.

thus by just keeping things lean actually becomes more efficient, than the bait and switch of gaining then subtracting efficiency.
5730  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
5731  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
5732  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.

5733  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
5734  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)
5735  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..


5736  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
5737  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.



5738  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
5739  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
5740  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
Pages: « 1 ... 237 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 ... 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!