Bitcoin Forum
December 04, 2016, 08:40:55 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Poll
Question: Will you support Gavin's new block size limit hard fork of 8MB by January 1, 2016 then doubling every 2 years?
1.  yes
2.  no

Pages: « 1 ... 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 [1266] 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 ... 1560 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1804276 times)
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
June 02, 2015, 01:30:48 PM
 #25301

If memory serves 2013 hardfork was more a "dependency" bug imho. Client with ver <= 0.8.0 cant's store block bigger than 512KB due to a Berkeley db default misconfiguration. It could have happened with any other external tool used by the client.
The bug wasn't nearly so deterministic. Whether or not a particular block would trigger the bug depended on the runtime history of a particular node (when they started downloading blocks, how many orphans they had observed, etc) meaning that binary-identical versions of Bitcoin Core running on machines with identical hardware could exhibit divergent behaviour based on them connecting to different peers at different times.

In that regard what do you think about the plan to isolate the consensus code in a separete library?
Would have been a good idea to do from the beginning. I'm not sure if the existing code can be cleaned up well enough to make a meaningful difference.
1480884055
Hero Member
*
Offline Offline

Posts: 1480884055

View Profile Personal Message (Offline)

Ignore
1480884055
Reply with quote  #2

1480884055
Report to moderator
1480884055
Hero Member
*
Offline Offline

Posts: 1480884055

View Profile Personal Message (Offline)

Ignore
1480884055
Reply with quote  #2

1480884055
Report to moderator
1480884055
Hero Member
*
Offline Offline

Posts: 1480884055

View Profile Personal Message (Offline)

Ignore
1480884055
Reply with quote  #2

1480884055
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480884055
Hero Member
*
Offline Offline

Posts: 1480884055

View Profile Personal Message (Offline)

Ignore
1480884055
Reply with quote  #2

1480884055
Report to moderator
1480884055
Hero Member
*
Offline Offline

Posts: 1480884055

View Profile Personal Message (Offline)

Ignore
1480884055
Reply with quote  #2

1480884055
Report to moderator
Natalia_AnatolioPAMM
Full Member
***
Offline Offline

Activity: 154


View Profile WWW
June 02, 2015, 01:35:18 PM
 #25302

Bitcoin XT is a poison pill for all the newbs and unwary, certain bug fix commits that went into Core have already been omitted. Both Hearn and Andresen have been covertly anti-privacy from day zero, paying it only lip service when pressed. Don't trust it. Not to mention it is poorly maintained and totally untested. I can't believe I'm reading such a mad approach being championed on these pages ... it's like a twilight zone episode wtf are you people thinking !!! following Pied Pipers now?

wish there was a thanks button on BCT

same with me

Earn money when BTC crashes - join BTC-E PAMM
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 02, 2015, 02:12:56 PM
 #25303

Bitcoin XT is a poison pill for all the newbs and unwary, certain bug fix commits that went into Core have already been omitted. Both Hearn and Andresen have been covertly anti-privacy from day zero, paying it only lip service when pressed. Don't trust it. Not to mention it is poorly maintained and totally untested. I can't believe I'm reading such a mad approach being championed on these pages ... it's like a twilight zone episode wtf are you people thinking !!! following Pied Pipers now?

wish there was a thanks button on BCT

same with me

he posts the same BS over on Reddit.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 02, 2015, 02:23:31 PM
 #25304

Wladimir van der Laan, who seems to be Gavin's appointed lead for the project now, is "weakly against in the near future" because the solution seems to delay better ones. Seems he'd go along if it came down to a fork:

Quote
I understand the advantages of scaling, I do not doubt a block size increase will *work* Although there may be unforseen issues, I'm confident they'll be resolved. However, it may well make Bitcoin less useful for what sets it apart from other systems in the first place: the possibility for people to run their own own "bank" without special investment in connectivity and computing hardware.

see, this is where i think the devs understandably relate to the wrong fundamental unit of the system; the full node as opposed to the user.

no, the individuals bank is not the full node, it's the user and his wallet.  yes, to a degree, the security of that wallet depends on full nodes and miners but fundamentally it's the user and his wallet and why so much emphasis is placed on it via security R&D and specialized wallet implementations.  MetCalfe's Law applies to the user base.  that base will only grow via access to easy, cheap, reliable tx's.
Adrian-x
Legendary
*
Offline Offline

Activity: 1330



View Profile
June 02, 2015, 04:57:55 PM
 #25305

Bitcoin XT is a poison pill for all the newbs and unwary, certain bug fix commits that went into Core have already been omitted. Both Hearn and Andresen have been covertly anti-privacy from day zero, paying it only lip service when pressed. Don't trust it. Not to mention it is poorly maintained and totally untested. I can't believe I'm reading such a mad approach being championed on these pages ... it's like a twilight zone episode wtf are you people thinking !!! following Pied Pipers now?

wish there was a thanks button on BCT

same with me
It's not that black and white, I think everyone has learned more since the bad idea of "green" listing and being able to use money to track child porn.

Those stupid ideas are not death sentences, they are warning signals they are examples of why we need to constantly pay attention to maintain Bitcoin.

Gavin and Mike have moved on it seems and so long as I'm not the benevolent dictator Mike H would like I'm happy to see debate and the majority direct Bitcoin.

My understand is flexible and I won't hesitate to drop XT if it's moving in the direction of adding tracking features and educate the majority.

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 02, 2015, 05:30:20 PM
 #25306

if you doubt that everyone in the world will ever get an internet connection, here you go:

http://www.technologyreview.com/news/537956/emtech-digital-project-loon-head-details-how-the-balloons-interact/
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
June 02, 2015, 05:31:25 PM
 #25307

i read about this here one time but i don't fully understand it nor the implications, not being a coder.

a spec is a written, detailed, normal language description of how the protocol works, is that correct?  wouldn't the current developer's guide qualify as something similar?

where as the code is what actually executes within the operating system and carries out the protocol rules?

and why NL, do you believe it would've prevented what we have going on now?
The Bitcoin Core is in such bad shape that fully specifying its behaviour is indistinguishable from impossible.

You could say this is Satoshi's fault. What we now call Bitcoin Core started out life as a prototype and evolved into its present condition - it is not an engineered piece of software.

Yes the Bitcoin core evolved in a convoluted and non-ideal manner, but I think the reason we have a situation where "the code" = "the specification" is more basic. Even if the Bitcoin core code was well designed, we would still be in the same situation where the code is the specification.

The reason is in a distributed system such as Bitcoin, there is no rule enforcer. i.e. a centralized entity with the power to tell the distributed system when it is not functioning according to spec.

The result is if the majority of nodes run a common set of code, that code becomes the specification even if the code deviates from the spec. The majority will follow that deviation, because it is the code they are running. If you think about it, that is exactly what a hard fork is. A hard fork is a majority of nodes agreeing to deviate from the existing specification. This holds true whether the hard fork was intentional or if the hard fork was unintentional (due to a bug).

Since the majority of nodes in the beginning ran the bitcoin core, that core became the spec, and any other implementation that deviated from the core would be kicked out of the system.

I think the best course of action would be to acknowledge that the prototype has served its purpose and retire it in favour of treating a non-prototype codebase as the reference implementation for which a specification can be written.

Even if we did this, and put a large amount of open effort into creating the a new perfect core, we would still have the above issue. That core would be the specification if the majority ran it, including all of it's unknown bugs.

The problem is that there are two very different things in play here:

  • How humans think the Bitcoin protocol behaves
  • What Bitcoin Core actually does

There is no case where a divergence between these two things is good. It means that despite years of effort Bitcoin Core is in some ways still a black box capable of surprising behaviour instead of predictable behaviour.

We have no guarantee that Bitcoin Core is self-consistent (like it wasn't in March 2013). Due to the way that code was written, it's likely that we never will have such a guarantee.

The only way out of this mess is to deprecate Bitcoin Core in favour of more-specifiable implementations as rapidly as possible.

If Bitcoin Core (and derivatives) were a minority of the nodes in the network, then the next time one of Bitcoin Core's surprises manifested it would be a problem that a minority of the network would need to fix instead of newly-discovered behaviour that the entire network would need to implement.

And that there is the solution IMHO, we need two things.
  • A clear specification, and
  • A situation where there are many separate individually developed cores run on the network, where no one core represents a majority of nodes

If you have those two things, then if any core has a bug, it is up to that core to fix itself to adhere to the spec. Without both, then we are back to the situation where a bug becomes the spec, no matter how well engineered the core is.  
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 02, 2015, 05:47:03 PM
 #25308

i read about this here one time but i don't fully understand it nor the implications, not being a coder.

a spec is a written, detailed, normal language description of how the protocol works, is that correct?  wouldn't the current developer's guide qualify as something similar?

where as the code is what actually executes within the operating system and carries out the protocol rules?

and why NL, do you believe it would've prevented what we have going on now?
The Bitcoin Core is in such bad shape that fully specifying its behaviour is indistinguishable from impossible.

You could say this is Satoshi's fault. What we now call Bitcoin Core started out life as a prototype and evolved into its present condition - it is not an engineered piece of software.

Yes the Bitcoin core evolved in a convoluted and non-ideal manner, but I think the reason we have a situation where "the code" = "the specification" is more basic. Even if the Bitcoin core code was well designed, we would still be in the same situation where the code is the specification.

The reason is in a distributed system such as Bitcoin, there is no rule enforcer. i.e. a centralized entity with the power to tell the distributed system when it is not functioning according to spec.

The result is if the majority of nodes run a common set of code, that code becomes the specification even if the code deviates from the spec. The majority will follow that deviation, because it is the code they are running. If you think about it, that is exactly what a hard fork is. A hard fork is a majority of nodes agreeing to deviate from the existing specification. This holds true whether the hard fork was intentional or if the hard fork was unintentional (due to a bug).

Since the majority of nodes in the beginning ran the bitcoin core, that core became the spec, and any other implementation that deviated from the core would be kicked out of the system.

I think the best course of action would be to acknowledge that the prototype has served its purpose and retire it in favour of treating a non-prototype codebase as the reference implementation for which a specification can be written.

Even if we did this, and put a large amount of open effort into creating the a new perfect core, we would still have the above issue. That core would be the specification if the majority ran it, including all of it's unknown bugs.

The problem is that there are two very different things in play here:

  • How humans think the Bitcoin protocol behaves
  • What Bitcoin Core actually does

There is no case where a divergence between these two things is good. It means that despite years of effort Bitcoin Core is in some ways still a black box capable of surprising behaviour instead of predictable behaviour.

We have no guarantee that Bitcoin Core is self-consistent (like it wasn't in March 2013). Due to the way that code was written, it's likely that we never will have such a guarantee.

The only way out of this mess is to deprecate Bitcoin Core in favour of more-specifiable implementations as rapidly as possible.

If Bitcoin Core (and derivatives) were a minority of the nodes in the network, then the next time one of Bitcoin Core's surprises manifested it would be a problem that a minority of the network would need to fix instead of newly-discovered behaviour that the entire network would need to implement.

And that there is the solution IMHO, we need two things.
  • A clear specification, and
  • A situation where there are many separate individually developed cores run on the network, where no one core represents a majority of nodes

If you have those two things, then if any core has a bug, it is up to that core to fix itself to adhere to the spec. Without both, then we are back to the situation where a bug becomes the spec, no matter how well engineered the core is.  

that's helpful tho i'm alittle confused about a couple things.

when you say different "cores", you mean like Bitcoin Core & btcd?  i thought everyone was referring to them as different "implementations" of the bitcoin protocol?

so is a spec a generalized description written in plain language that is supposed describe what the protocol does from a practical standpoint and thus acts like a broad ruleset to which different cores or implementations are to adhere?
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
June 02, 2015, 06:00:06 PM
 #25309

Since the majority of nodes in the beginning ran the bitcoin core, that core became the spec, and any other implementation that deviated from the core would be kicked out of the system.

I think the best course of action would be to acknowledge that the prototype has served its purpose and retire it in favour of treating a non-prototype codebase as the reference implementation for which a specification can be written.

Even if we did this, and put a large amount of open effort into creating the a new perfect core, we would still have the above issue. That core would be the specification if the majority ran it, including all of it's unknown bugs.
What we should aim for is at least three full node implementations in the wild, with no single implementation having majority usage.

Also, a clear spec with extensive testing of each implementation's correctness.

As soon as we make a transition away from a monoculture (one implementation has a majority), we'll have an upper bound on the severity of likely chain forks. If 1 of n implementations disagrees with the other (n-1), then it's clearly a bug in that particular implementation that should be fixed.

The worst case scenario is a bug that causes more than one implementation to diverge at the same time, but that's no worse than what we've already been through in the past and the odds of that happening can be continually reduced with a good QA program.
Adrian-x
Legendary
*
Offline Offline

Activity: 1330



View Profile
June 02, 2015, 06:10:54 PM
 #25310

i read about this here one time but i don't fully understand it nor the implications, not being a coder.

a spec is a written, detailed, normal language description of how the protocol works, is that correct?  wouldn't the current developer's guide qualify as something similar?

where as the code is what actually executes within the operating system and carries out the protocol rules?

and why NL, do you believe it would've prevented what we have going on now?
The Bitcoin Core is in such bad shape that fully specifying its behaviour is indistinguishable from impossible.

You could say this is Satoshi's fault. What we now call Bitcoin Core started out life as a prototype and evolved into its present condition - it is not an engineered piece of software.

Yes the Bitcoin core evolved in a convoluted and non-ideal manner, but I think the reason we have a situation where "the code" = "the specification" is more basic. Even if the Bitcoin core code was well designed, we would still be in the same situation where the code is the specification.

The reason is in a distributed system such as Bitcoin, there is no rule enforcer. i.e. a centralized entity with the power to tell the distributed system when it is not functioning according to spec.

The result is if the majority of nodes run a common set of code, that code becomes the specification even if the code deviates from the spec. The majority will follow that deviation, because it is the code they are running. If you think about it, that is exactly what a hard fork is. A hard fork is a majority of nodes agreeing to deviate from the existing specification. This holds true whether the hard fork was intentional or if the hard fork was unintentional (due to a bug).

Since the majority of nodes in the beginning ran the bitcoin core, that core became the spec, and any other implementation that deviated from the core would be kicked out of the system.

I think the best course of action would be to acknowledge that the prototype has served its purpose and retire it in favour of treating a non-prototype codebase as the reference implementation for which a specification can be written.

Even if we did this, and put a large amount of open effort into creating the a new perfect core, we would still have the above issue. That core would be the specification if the majority ran it, including all of it's unknown bugs.

The problem is that there are two very different things in play here:

  • How humans think the Bitcoin protocol behaves
  • What Bitcoin Core actually does

There is no case where a divergence between these two things is good. It means that despite years of effort Bitcoin Core is in some ways still a black box capable of surprising behaviour instead of predictable behaviour.

We have no guarantee that Bitcoin Core is self-consistent (like it wasn't in March 2013). Due to the way that code was written, it's likely that we never will have such a guarantee.

The only way out of this mess is to deprecate Bitcoin Core in favour of more-specifiable implementations as rapidly as possible.

If Bitcoin Core (and derivatives) were a minority of the nodes in the network, then the next time one of Bitcoin Core's surprises manifested it would be a problem that a minority of the network would need to fix instead of newly-discovered behaviour that the entire network would need to implement.

And that there is the solution IMHO, we need two things.
  • A clear specification, and
  • A situation where there are many separate individually developed cores run on the network, where no one core represents a majority of nodes

If you have those two things, then if any core has a bug, it is up to that core to fix itself to adhere to the spec. Without both, then we are back to the situation where a bug becomes the spec, no matter how well engineered the core is.  

thanks nicely put, this also addresses the concerns and lack of trust many have of Gavin and Mike having proposed unpopular or inappropriate ideas in the past, ultimately it preserves the protocol and doesn't empower developers to change it but does encourage cooperation in addressing problems, this gives me confidence again.  

marcus_of_augustus poison pill is only a concern if we are switching Core for XT, but that's not what is happening, in fact I see Core under influence by Blockstream as the poison pill, but we are in fact distributing development, and moving the spec from Core to the majority, be there only 3 competitors at this time.

The irony, is we are seeing political positioning to maintain centralization, and the politicians are arguing that their version of centralized power is needed for decentralization.

I'm with Gavin on this one lets decentralize the gate keepers and preserve the network of users.  

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
Fabrizio89
Hero Member
*****
Offline Offline

Activity: 833


View Profile
June 02, 2015, 06:39:17 PM
 #25311

It's all about that Greece

https://1broker.com/m/r.php?i=2479
Trade stocks, commodities, currencies with bitcoins! Up to 200x Leverage.
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
June 02, 2015, 06:48:58 PM
 #25312

that's helpful tho i'm alittle confused about a couple things.

when you say different "cores", you mean like Bitcoin Core & btcd?  i thought everyone was referring to them as different "implementations" of the bitcoin protocol?

Yes, different implementations. That is better wording.

so is a spec a generalized description written in plain language that is supposed describe what the protocol does from a practical standpoint and thus acts like a broad ruleset to which different cores or implementations are to adhere?

Yes, a spec should be a plain language description on what is and is not valid. Even this can become complicated, but it serves a design point for any implementation. But as I said above, the spec alone is not enough. Even if you have a written spec, but there is a single implementation that is used by the majority, the implementation would trump the spec if a non compliant bug came up.
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
June 02, 2015, 06:59:05 PM
 #25313

Since the majority of nodes in the beginning ran the bitcoin core, that core became the spec, and any other implementation that deviated from the core would be kicked out of the system.

I think the best course of action would be to acknowledge that the prototype has served its purpose and retire it in favour of treating a non-prototype codebase as the reference implementation for which a specification can be written.

Even if we did this, and put a large amount of open effort into creating the a new perfect core, we would still have the above issue. That core would be the specification if the majority ran it, including all of it's unknown bugs.
What we should aim for is at least three full node implementations in the wild, with no single implementation having majority usage.

Also, a clear spec with extensive testing of each implementation's correctness.

As soon as we make a transition away from a monoculture (one implementation has a majority), we'll have an upper bound on the severity of likely chain forks. If 1 of n implementations disagrees with the other (n-1), then it's clearly a bug in that particular implementation that should be fixed.

The worst case scenario is a bug that causes more than one implementation to diverge at the same time, but that's no worse than what we've already been through in the past and the odds of that happening can be continually reduced with a good QA program.

That sounds like an ideal plan. Not sure how to put it into action though. The current blocksize debate if anything shows how the current devs have conflict of interests in even considering this as a direction.

One option is to start with a move towards adoption of multiple implementations before making the "spec". If Bitcoin XT and btcd both gained enough adoption vs. the Satoshi client that all three were below 50% of the network, then we would now have a situation where a bug in the Satoshi client was no longer the spec, and the Satoshi client would have to quickly bug fix itself to adhear to the XT and btcd majority (and same for XT and btcd).

This situation would then force the drafting of a real specification. With one dominate implementation the need for a spec is diminished. But with several implementations the need for them to draft what is agreed becomes quite strong.
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
June 02, 2015, 07:03:22 PM
 #25314

The irony, is we are seeing political positioning to maintain centralization, and the politicians are arguing that there version of centralized power is needed for decentralization.

It is highly ironic isn't it....

Humans as a species seem to love leaders and centralized decision making, we must be wired for it. Every example of a decentralize economic & political system that humans have organized (early US, early Rome are two examples) have been short lived and degenerated into the inevitable command and control organization model. But that's a different topic.
smooth
Legendary
*
Offline Offline

Activity: 1246



View Profile
June 02, 2015, 07:57:19 PM
 #25315

The result is if the majority of nodes run a common set of code, that code becomes the specification even if the code deviates from the spec. The majority will follow that deviation, because it is the code they are running. If you think about it, that is exactly what a hard fork is. A hard fork is a majority of nodes agreeing to deviate from the existing specification. This holds true whether the hard fork was intentional or if the hard fork was unintentional (due to a bug).

if the code is the specification then the code can't deviate from the specification. What happens if the code fails to converge to consensus is that the specification/code is proven to be broken, in which case the majority is forced to accept a change to the specification if they want to have a consensus system. In other hard-fork cases the majority may choose to accept a change, but it isn't forced.

Agree with Justus about multiple implementations.



justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
June 02, 2015, 08:24:19 PM
 #25316

One option is to start with a move towards adoption of multiple implementations before making the "spec". If Bitcoin XT and btcd both gained enough adoption vs. the Satoshi client that all three were below 50% of the network, then we would now have a situation where a bug in the Satoshi client was no longer the spec, and the Satoshi client would have to quickly bug fix itself to adhear to the XT and btcd majority (and same for XT and btcd).

This situation would then force the drafting of a real specification. With one dominate implementation the need for a spec is diminished. But with several implementations the need for them to draft what is agreed becomes quite strong.
Imagine if Bitcoin Core/XT, btcd, libbitcoin, BitcoinJ, Toshi, etc. all got together to make sure there was a common test suite that was a strict superset of all the relevant unit tests in each codebase.

The next step would be for each implementation to make sure to add any missing consensus-related tests to their own repositories. Repeat the process as necessary.

After all that was done, you could use the test suites as the basis of a spec.

Organizing that is something useful that Bitcoin Foundation could have done, instead of... whatever it was they did.
Odalv
Legendary
*
Offline Offline

Activity: 1064



View Profile
June 02, 2015, 08:58:43 PM
 #25317

One option is to start with a move towards adoption of multiple implementations before making the "spec". If Bitcoin XT and btcd both gained enough adoption vs. the Satoshi client that all three were below 50% of the network, then we would now have a situation where a bug in the Satoshi client was no longer the spec, and the Satoshi client would have to quickly bug fix itself to adhear to the XT and btcd majority (and same for XT and btcd).

This situation would then force the drafting of a real specification. With one dominate implementation the need for a spec is diminished. But with several implementations the need for them to draft what is agreed becomes quite strong.
Imagine if Bitcoin Core/XT, btcd, libbitcoin, BitcoinJ, Toshi, etc. all got together to make sure there was a common test suite that was a strict superset of all the relevant unit tests in each codebase.

The next step would be for each implementation to make sure to add any missing consensus-related tests to their own repositories. Repeat the process as necessary.

After all that was done, you could use the test suites as the basis of a spec.

Organizing that is something useful that Bitcoin Foundation could have done, instead of... whatever it was they did.

Huh

Bitcoin is protocol. -> valid chain of blocks filled with transactions
Carlton Banks
Legendary
*
Offline Offline

Activity: 1470



View Profile
June 02, 2015, 08:59:51 PM
 #25318

Agreed on all this formalise the spec talk, but this could only be another big (and possibly another fractious) debate at this stage of bitcoin's development. If you can get every interested party in the bitcoin development arena to agree, at this stage in the project, I'd be impressed. It would be best overall though, genuine marketplace for implementations. And a marketplace for forking too, but that's clearly coming anyway at some point or other, better to embrace it and keep the barriers to entry low.

Vires in numeris
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
June 02, 2015, 10:12:10 PM
 #25319

Agreed on all this formalise the spec talk, but this could only be another big (and possibly another fractious) debate at this stage of bitcoin's development. If you can get every interested party in the bitcoin development arena to agree, at this stage in the project, I'd be impressed. It would be best overall though, genuine marketplace for implementations. And a marketplace for forking too, but that's clearly coming anyway at some point or other, better to embrace it and keep the barriers to entry low.

Let's not forget that the fact it is near impossible to get agreement on changes, is a very strong feature of Bitcoin. Wink
iCEBREAKER
Legendary
*
Online Online

Activity: 1498


Crypto is the separation of Power and State.


View Profile WWW
June 02, 2015, 11:10:41 PM
 #25320

I'm working for Nick Szabo.

Quote
Szatoshi will back Back and Maxwell.

enough with the hints, spill the beans please.

The beans were spilled a long time ago, but most people (including StarbucksDoc apparently) weren't paying attention:

Quote
The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy.  -David Chaum 1996

The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy.  David Chaum 1996
Fungibility provides privacy as a side effect.  Adam Back 2014
"Monero" : { Private - Auditable - 100% Fungible - Flexible Blocksize - Wild & Free® - Intro - Wallets - Podcats - Roadmap - Dice - Blackjack - Github - Android }


Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016
Blocks must necessarily be full for the Bitcoin network to be able to pay for its own security.  davout 2015
Blocksize is an intentionally limited resource, like the 21e6 BTC limit.  Changing it degrades the surrounding economics, creating negative incentives.  Jeff Garzik 2013


"I believed @Dashpay instamine was a bug & not a feature but then read: https://bitcointalk.org/index.php?topic=421615.msg13017231#msg13017231
I'm not against people making money, but can't support questionable origins."
https://twitter.com/Tone_LLT/status/717822927908024320


The raison d'être of bitcoin is trustlessness. - Eric Lombrozo 2015
It is an Engineering Requirement that Bitcoin be “Above the Law”  Paul Sztorc 2015
Resiliency, not efficiency, is the paramount goal of decentralized, non-state sanctioned currency -Jon Matonis 2015

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016

Technology tends to move in the direction of making surveillance easier, and the ability of computers to track us doubles every eighteen months. - Phil Zimmerman 2013

The only way to make software secure, reliable, and fast is to make it small. Fight Features. - Andy Tanenbaum 2004

"Hard forks cannot be co
Pages: « 1 ... 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 [1266] 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 ... 1560 »
  Print  
 
Jump to:  

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!