Bitcoin Forum
October 20, 2017, 09:14:33 AM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 [33] 34 35 36 37 38 39 40 »
  Print  
Author Topic: ...  (Read 59319 times)
RoadStress
Legendary
*
Offline Offline

Activity: 1610


View Profile
August 30, 2015, 01:49:47 AM
 #641

Well the same way you get satoshis right now. You either mine yourself or find someone that can provide you with them.

Yeah, that seems quite easy. Why didn't I think of that? [/sarcasm]

Don't worry. There will be a market for those satoshies for sure.

Estimates of people who own some bitcoin range from 3'000'000 (Coinbase, BCI claims) to 300'000 (me).  The latter is my estimate of how many people own at least 1 BTC; together, those users own 99% of all bitcoins in existence.  

So, how many bitcoiners do you think know enough about the bitcoin protocol to understand how they can get get their transactions executed in one chain only; and know how to do that without messing up their wallet file; and can obtain a few satoshis that were mined after the fork; and are interested in handling split coins; and can find buyers who can also do all of that; and are dumb enough to buy coins that may die in a few days?

Those that have coins in Coinbase or other third-party wallets will execute their transfers on the fork that the third-party will choose. They will not have the option to taint their coins to make a transfer on the other fork because they will not be able to do it using a third-party wallet.

Also if a hard fork occurs you can be damn sure that there will be announcements everywhere and also the third-party wallet provider will let their users know about the hard-fork and what to do. It sounds logic to me to do that. You make it sound like the sky will fall, when in reality it will not fall. Take a xanax and chill.

Yes, I have observed already that, for the fanatic bitcoiner, *every* detail of bitcoin is a feature; and *everything* that happens is "how the system works".  

Sorry, but it is a bug that the coins on each branch may or may not be moved independently, with most clients being unable ot understand or control what is happening.

Hackery is what you propose to do: move coins independently on the two branches by tainting them with coinbase coins, and sell the version you think will die to anyone fool enough to buy them, or to anyone naive enough to not understand what he is buying.   The 100 block delay was probably meant to discourage that kind of hackery after forks -- soft, hard, or accidental.

It is your opinion and you are free to have one. But don't act surprised if people laugh at your opinions when it comes to Bitcoin knowledge.

Correct.  More precisely, any UTXOs that were created before the fork exist and can be used on both branches.  If you try to move them without tainting, they will be moved on both branches, to UTXOs that are still untainted.  Once you get hold of some satoshis that were mined on one branch (either one), you can first move all your old UTXOs on that branch to new UTXOs, with tainted transactions, and then you can move again the same old UTXOs to still other UTXOs with untainted transactions, that will be executed only on the other branch (because on the first one those outputs are already spent).  

Finally we agree on something.

iCEBREAKER is a troll! He and cypherdoc helped HashFast scam 50 Million $ from its customers !
H/w Hosting Directory & Reputation - https://bitcointalk.org/index.php?topic=622998.0
1508490873
Hero Member
*
Offline Offline

Posts: 1508490873

View Profile Personal Message (Offline)

Ignore
1508490873
Reply with quote  #2

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

Posts: 1508490873

View Profile Personal Message (Offline)

Ignore
1508490873
Reply with quote  #2

1508490873
Report to moderator
1508490873
Hero Member
*
Offline Offline

Posts: 1508490873

View Profile Personal Message (Offline)

Ignore
1508490873
Reply with quote  #2

1508490873
Report to moderator
canth
Legendary
*
Offline Offline

Activity: 1442



View Profile
August 30, 2015, 02:01:03 AM
 #642

Yes, the only "XT" blocks mined thus far are actually from a FakeXT node.  Slush must be a gambler!   Cheesy

So much for canth's pompous "I for one don't believe" opinion.

Apparently, nobody (especially Slush) cares what canth does or does not believe.   Grin

Oh boo hoo, let's all cry about slush's "deceitful indication of larger block support" (which was "a likely scenario" after all).   Cheesy

By fake, I mean advertising accepting BIP101 blocks but in fact rejecting them, which Slush it not doing. Anyone that runs NotXT might as well be running NotBIP101 on core since it's the exact same deceitful practice. It doesn't help demonstrate support for alternative BIPs; it might help fracture the network in January. I know you're not dumb enough to have ignored the game theory - anyone that runs NotXT is gambling with everyone's money without any upside.

Slush isn't running XT or NotXT.  Slush's present nodes will in fact reject >1MB blocks.  Slush is spoofing, as has already been explained here:

Quote

How am I ignoring the game theory?  I already explained why/how NotXT exacerbates the risk for defections to XT, by minimizing its chances of success.  And OrganOfCorti mathed the hell out of that, leaving no doubt those brave enough to accept XTcoins are going to have a bad time.   Smiley

What is it that you don't get? Slush is indicating support for >1MB blocks via XT/BIP101. Since no version of XT or only-bigblocks or Core will accept >1MB blocks prior to January 2016 then it doesn't matter that he hasn't updated to XT or BIP 101 mining prior to then. Is your point that the NotXTers will move to BIP101 or XT in January 2016? That seems to not quite be in the spirit of NotXT.

I read the OrganOfCorti comments - he used numbers ranging between 0.16 and 0.21 of fake voters. That's fine - if it's a small number of fakers then it doesn't matter. The more the fake votes increase, the better the chance for 'premature activation'. Go ahead...run NotXT - gamble away, but you sure can't take the moral high ground.


iCEBREAKER
Legendary
*
Online Online

Activity: 1806


Crypto Rules Everything Around Me


View Profile WWW
August 30, 2015, 02:45:14 AM
 #643

Quote

How am I ignoring the game theory?  I already explained why/how NotXT exacerbates the risk for defections to XT, by minimizing its chances of success.  And OrganOfCorti mathed the hell out of that, leaving no doubt those brave enough to accept XTcoins are going to have a bad time.   Smiley

What is it that you don't get? Slush is indicating support for >1MB blocks via XT/BIP101. Since no version of XT or only-bigblocks or Core will accept >1MB blocks prior to January 2016 then it doesn't matter that he hasn't updated to XT or BIP 101 mining prior to then. Is your point that the NotXTers will move to BIP101 or XT in January 2016? That seems to not quite be in the spirit of NotXT.

I read the OrganOfCorti comments - he used numbers ranging between 0.16 and 0.21 of fake voters. That's fine - if it's a small number of fakers then it doesn't matter. The more the fake votes increase, the better the chance for 'premature activation'. Go ahead...run NotXT - gamble away, but you sure can't take the moral high ground.

Moral high ground?  When did that become an issue?  This is war, not an ethics symposium!   Tongue

Corti demonstrated a small number of fakers is unlikely to matter immediately, but because XT features a perpetual election even low probabilities manifest eventually.

Your hand-waving "it doesn't matter that [slush] hasn't updated to XT" objection sounds like imaginary_username, who likewise fails to understand

Quote
If you're only pretending to run a version of bitcoin that has BIP101 implemented by changing your header version, that is spoofing, regardless of what your intentions are.

The header version is supposed to show that your nodes will actually accept a >1MB block as per BIP101, not that you support the idea of BIP101.


██████████
█████████████████
██████████████████████
█████████████████████████
████████████████████████████
████
████████████████████████
█████
███████████████████████████
█████
███████████████████████████
██████
████████████████████████████
██████
████████████████████████████
██████
████████████████████████████
██████
███████████████████████████
██████
██████████████████████████
█████
███████████████████████████
█████████████
██████████████
████████████████████████████
█████████████████████████
██████████████████████
█████████████████
██████████

Monero
"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
Buy and sell XMR near you
P2P Exchange Network
Buy XMR with fiat
erik777
Sr. Member
****
Offline Offline

Activity: 264


View Profile
August 30, 2015, 05:55:17 AM
 #644

Don't you see how the 'dictator' arguments in FOSS and software forks is a logical fallacy? People exercising their free will but not doing what you want does not equal dictatorship.

This is actually why dictatorship often succeed. They give to "the people" the impression of a choice by encouraging them to exercise "their free will" when they are tired of waiting for traditional issue resolution processes.

This is textbook "why the worst people get on top".

^^-- LIKE

Bottom line, is we need to discuss our current options, before we lose those options. 
erik777
Sr. Member
****
Offline Offline

Activity: 264


View Profile
August 30, 2015, 06:06:03 AM
 #645

Don't you see how the 'dictator' arguments in FOSS and software forks is a logical fallacy? People exercising their free will but not doing what you want does not equal dictatorship.

This is actually why dictatorship often succeed. They give to "the people" the impression of a choice by encouraging them to exercise "their free will" when they are tired of waiting for traditional issue resolution processes.

This is textbook "why the worst people get on top".

If BIP 101 succeeds, what makes you think that I won't be able to switch back to Core or only-bigblocks with a different set of developers? Is Core just going to give up?

For BIP101 to succeed it needs to be merged into Core so I am not sure what you are talking about?


I presume that your concern about XT is that it and BIP 101 succeed without core adopting it, right? Most on this list don't really seem to be worried about that given that miners aren't jumping onboard (yet). If XT were to somehow 'takeover' then my point is that BIP101 would get merged into core since there's no way core would just continue on with <25% hashrate, no coinbase or bitpay, etc.

The point being is that no matter what big blocks BIP ends up being finally adopted, there will be and should be multiple software clients available to end users which makes some sort of dictatorship completely impossible.

That is a positive scenario we are all hoping for, should BIP 101 succeed.  The concern is what % of clients XT will represent in this scenario.  If it is large, then you can only wonder what new "features" will be in it, given Hearn's clear bias for centralized trust-based systems.

Based on Hearn's previous proposals, and his complete control over XT, potential features include:

- Automatic updates
- Redlists
- Blacklists
- Whitelists
- Coin tainting

Muhammed Zakir
Hero Member
*****
Offline Offline

Activity: 560


I prefer Zakir over Muhammed when mentioning me!


View Profile WWW
August 30, 2015, 06:23:56 AM
 #646

Don't you see how the 'dictator' arguments in FOSS and software forks is a logical fallacy? People exercising their free will but not doing what you want does not equal dictatorship.

This is actually why dictatorship often succeed. They give to "the people" the impression of a choice by encouraging them to exercise "their free will" when they are tired of waiting for traditional issue resolution processes.

This is textbook "why the worst people get on top".

If BIP 101 succeeds, what makes you think that I won't be able to switch back to Core or only-bigblocks with a different set of developers? Is Core just going to give up?

For BIP101 to succeed it needs to be merged into Core so I am not sure what you are talking about?


I presume that your concern about XT is that it and BIP 101 succeed without core adopting it, right? Most on this list don't really seem to be worried about that given that miners aren't jumping onboard (yet). If XT were to somehow 'takeover' then my point is that BIP101 would get merged into core since there's no way core would just continue on with <25% hashrate, no coinbase or bitpay, etc.

The point being is that no matter what big blocks BIP ends up being finally adopted, there will be and should be multiple software clients available to end users which makes some sort of dictatorship completely impossible.

That is a positive scenario we are all hoping for, should BIP 101 succeed.  The concern is what % of clients XT will represent in this scenario.  If it is large, then you can only wonder what new "features" will be in it, given Hearn's clear bias for centralized trust-based systems.

Based on Hearn's previous proposals, and his complete control over XT, potential features include:

- Automatic updates
- Redlists
- Blacklists
- Whitelists
- Coin tainting

Maintainer making decisions for all code changed rather than unanimity/consensus.

iCEBREAKER
Legendary
*
Online Online

Activity: 1806


Crypto Rules Everything Around Me


View Profile WWW
August 30, 2015, 07:38:25 AM
 #647

you can only wonder what new "features" will be in it, given Hearn's clear bias for centralized trust-based systems.

Based on Hearn's previous proposals, and his complete control over XT, potential features include:

- Automatic updates
- Redlists
- Blacklists
- Whitelists
- Coin tainting


Bitcoin's CTO calls out Gavin@tla.mit.gov and Heam@sigint.google.mil for being epic shitlords:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010439.html

Quote
[bitcoin-dev] Bitcoin XT Fork
Adam Back adam at cypherspace.org
Wed Aug 19 16:53:13 UTC 2015


It seems to be a recurring meme that BIP 101 is somehow "a solution
put forward" where BIP 100, 102, 103, flexcap, extension blocks etc
etc are not.

That is not at ALL the case, and is insulting (present company excluded).

It is just that no one else is reckless enough to bypass the review
process and risk a controversial hard fork deployment war.  Myself and
many other people warned Gavin a network fork "war" would start (ie
someone would think of some way to sabotage or attack the deployment
of Bitcoin-XT via protocol, code, policy, consensus soft-fork etc.  He
ignored the warnings.  Many also warned that 75% was an optimally BAD
trigger ratio (and that in a hard fork it is not a miner vote really
as in soft-forks).  Gavin & Mike ignored that warning to.  I know they
heard those warnings because I told them 1:1 in person or via email
and had on going conversations.  Others did too.

People can not blame bitcoin core or me, that this then predictably
happened exactly as we said it would - it was completely obvious and
predictable.

In fact noBitcoinXT is even more dangerous and therefore amplified in
effect in creating mutual assured destruction kind of risk profile
than the loose spectrum of technical counters imagined.  I did not
personally put much effort into thinking about counters because I
though it counter productive and hoped that Gavin & Mike would have
the maturity to not start down such a path.

Again any of the other proposals can easily be implemented.  They
*could* also spin up a web page and put up binaries, however no one
else was crazy enough to try to start a deployment in that way.

It is also puzzling timing - with all these BIPs and ongoing
discussion and workshops coming imminently to then release ahead of
that process where as far as I know Gavin said he was equally happy
with BIP 100 or other proposal which ever is best, and on basically
the eve of workshops planned to progress this collaboratively.
Bitcoin-XT is also under tested, people are finding privacy bugs and
other issues.  (Not even mentioning the above 75% optimally bad
parameter, and the damage to community reputation and collaborative
environment that this all causes.)

Very disappointing Gavin and Mike.

I find it quite notable that Gavin and Mike have been radio silent on
the bitcoin-dev list and yet we see a stream of media articles, blog
posts, pod casts, and from what I can tell ongoing backroom lobbying
of companies to run bitcoin-XT without trying AT ALL to offer a
neutral or balanced or multi proposal information package so that
companies technical people can make a balanced informed decision.
That is what the workshops are trying to provide.

Gavin, Mike - anything to say here?

Adam


██████████
█████████████████
██████████████████████
█████████████████████████
████████████████████████████
████
████████████████████████
█████
███████████████████████████
█████
███████████████████████████
██████
████████████████████████████
██████
████████████████████████████
██████
████████████████████████████
██████
███████████████████████████
██████
██████████████████████████
█████
███████████████████████████
█████████████
██████████████
████████████████████████████
█████████████████████████
██████████████████████
█████████████████
██████████

Monero
"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
Buy and sell XMR near you
P2P Exchange Network
Buy XMR with fiat
sAt0sHiFanClub
Hero Member
*****
Offline Offline

Activity: 490


Warning: Confrmed Gavinista


View Profile WWW
August 30, 2015, 03:46:37 PM
 #648

Quote from: Adam_Back
Myself and many other people warned
 Gavin a network fork "war" would start

Is he advocating "Ballot box in one hand, and an Armalite in the other"?

We must make money worse as a commodity if we wish to make it better as a medium of exchange
HarHarHar9965
Hero Member
*****
Offline Offline

Activity: 798


View Profile
August 30, 2015, 04:07:30 PM
 #649

So in simple and quick words, Bitcoin XT has a feature which tracks IP address of the user and although it states that is used for blacklisting purposes, it does go against the very fundamental of bitcoin. Why is the Bitcoin XT project not being discarded by the bitcoin users then? What is making them disregard their privacy and fuel hearn's shitty attitude? WHY
sAt0sHiFanClub
Hero Member
*****
Offline Offline

Activity: 490


Warning: Confrmed Gavinista


View Profile WWW
August 30, 2015, 04:10:58 PM
 #650

So in simple and quick words, Bitcoin XT has a feature which tracks IP address of the user

Ah, no it doesn't.  Simple words are just wrong. Have a read through the thread again.

We must make money worse as a commodity if we wish to make it better as a medium of exchange
uxgpf
Jr. Member
*
Offline Offline

Activity: 42


View Profile
August 30, 2015, 04:47:24 PM
 #651

you can only wonder what new "features" will be in it, given Hearn's clear bias for centralized trust-based systems.

Based on Hearn's previous proposals, and his complete control over XT, potential features include:

- Automatic updates
- Redlists
- Blacklists
- Whitelists
- Coin tainting


Bitcoin's CTO calls out Gavin@tla.mit.gov and Heam@sigint.google.mil for being epic shitlords:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010439.html

Quote
[bitcoin-dev] Bitcoin XT Fork
Adam Back adam at cypherspace.org
Wed Aug 19 16:53:13 UTC 2015


It seems to be a recurring meme that BIP 101 is somehow "a solution
put forward" where BIP 100, 102, 103, flexcap, extension blocks etc
etc are not.

That is not at ALL the case, and is insulting (present company excluded).

It is just that no one else is reckless enough to bypass the review
process and risk a controversial hard fork deployment war.  Myself and
many other people warned Gavin a network fork "war" would start (ie
someone would think of some way to sabotage or attack the deployment
of Bitcoin-XT via protocol, code, policy, consensus soft-fork etc.  He
ignored the warnings.  Many also warned that 75% was an optimally BAD
trigger ratio (and that in a hard fork it is not a miner vote really
as in soft-forks).  Gavin & Mike ignored that warning to.  I know they
heard those warnings because I told them 1:1 in person or via email
and had on going conversations.  Others did too.

People can not blame bitcoin core or me, that this then predictably
happened exactly as we said it would - it was completely obvious and
predictable.

In fact noBitcoinXT is even more dangerous and therefore amplified in
effect in creating mutual assured destruction kind of risk profile
than the loose spectrum of technical counters imagined.  I did not
personally put much effort into thinking about counters because I
though it counter productive and hoped that Gavin & Mike would have
the maturity to not start down such a path.

Again any of the other proposals can easily be implemented.  They
*could* also spin up a web page and put up binaries, however no one
else was crazy enough to try to start a deployment in that way.

It is also puzzling timing - with all these BIPs and ongoing
discussion and workshops coming imminently to then release ahead of
that process where as far as I know Gavin said he was equally happy
with BIP 100 or other proposal which ever is best, and on basically
the eve of workshops planned to progress this collaboratively.
Bitcoin-XT is also under tested, people are finding privacy bugs and
other issues.  (Not even mentioning the above 75% optimally bad
parameter, and the damage to community reputation and collaborative
environment that this all causes.)

Very disappointing Gavin and Mike.

I find it quite notable that Gavin and Mike have been radio silent on
the bitcoin-dev list and yet we see a stream of media articles, blog
posts, pod casts, and from what I can tell ongoing backroom lobbying
of companies to run bitcoin-XT without trying AT ALL to offer a
neutral or balanced or multi proposal information package so that
companies technical people can make a balanced informed decision.
That is what the workshops are trying to provide.

Gavin, Mike - anything to say here?

Adam

Just for completeness, here's the reply.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010496.html
Quote
[bitcoin-dev] Bitcoin XT Fork
Mike Hearn hearn at vinumeris.com
Thu Aug 20 09:00:14 UTC 2015

>
> It is just that no one else is reckless enough to bypass the review process


I keep seeing this notion crop up.

I want to kill this idea right now:

   - There were months of public discussion leading to up the authoring of
   BIP 101, both on this mailing list and elsewhere.

   - BIP 101 was submitted for review via the normal process. Jeff Garzik
   specifically called Gavin out on Twitter and thanked him for following the
   process:

   https://twitter.com/jgarzik/status/614412097359708160

   https://github.com/bitcoin/bips/pull/163

   As you can see, other than a few minor typo fixes and a comment by sipa,
   there was no other review offered.

   - The implementation for BIP 101 was submitted to Bitcoin Core as a pull
   request, to invoke the code review process:

   https://github.com/bitcoin/bitcoin/pull/6341

   Some minor code layout suggestions were made by Cory and incorporated.
   Peter popped up to say there was no chance it'd ever be accepted ..... and
   no further review was done.

So the entire Bitcoin Core BIP process was followed to the letter. The net
result was this. There were, in fact, bugs in the implementation of BIP
101. They were found when Gavin submitted the code to the XT community
review process, which resulted in *actual* peer review. Additionally, there
was much discussion of technical details on the XT mailing list that
Bitcoin Core entirely ignored.
JorgeStolfi
Hero Member
*****
Offline Offline

Activity: 896



View Profile
August 30, 2015, 05:00:59 PM
 #652

Quote
[bitcoin-dev] Bitcoin XT Fork
Adam Back adam at cypherspace.org
Wed Aug 19 16:53:13 UTC 2015

[ ... ]Myself and many other people warned Gavin
a network fork "war" would start (ie
someone would think of some way to sabotage or attack the deployment
of Bitcoin-XT via protocol, code, policy, consensus soft-fork etc.  He
ignored the warnings. [ ... ] People can not blame bitcoin core or me,
that this then predictably  happened exactly as we said it would - it
was completely obvious and predictable.

In fact noBitcoinXT is even more dangerous and therefore amplified in
effect in creating mutual assured destruction kind of risk profile
than the loose spectrum of technical counters imagined.  I did not
personally put much effort into thinking about counters because I
though it counter productive and hoped that Gavin & Mike would have
the maturity to not start down such a path. [ ... ]

The war would not have happened if Adam had not labored so hard to create it.

The NotXT fork and the DDoS attacks on XT nodes may not have been his idea, but
he does seem to think that they were "well done".

EDIT:  There are other options for a higher block limit than full BitcoinXT --
such as a patched BitcoinCore, BitcoinXT with only BIP101, or simply editing
the MAX_BLOCK_SIZE line to raise the limit on a fixed date.  Raising the limit to 8 MB
does not present any demonstrable risk, but avoids congestion and
reduces risks and consequences of spam attacks.  Adam did not start the war
for technican reasons, but only to protect Blockstream's  power grip on
the protocol. 

Academic interest in bitcoin only. Not owner, not trader, very skeptical of its longterm success.
tvbcof
Legendary
*
Offline Offline

Activity: 2296


View Profile
August 30, 2015, 05:09:59 PM
 #653


The war would not have happened if Adam had not labored so hard to create it.

The NotXT fork and the DDoS attacks on XT nodes may not have been his idea, but
he does seem to think that they were "well done". 

The idea of patching a client was something I thought of out of thin air and suggested in the last round of wars near the begining of the year as I recall.

The voting implantation was so laughably simplistic that the attack practically suggested itself.  If that is the design quality of XT under Hearn's benevolent dictatorship, heaven state sponsored judicial system help you guys.

If Adam had never been born I would have fought hard against a hostile takeover and especially one instigated by Mike Hearn.


JorgeStolfi
Hero Member
*****
Offline Offline

Activity: 896



View Profile
August 30, 2015, 05:29:39 PM
 #654

The voting implantation was so laughably simplistic that the attack practically suggested itself.  If that is the design quality of XT under Hearn's benevolent dictatorship, heaven state sponsored judicial system help you guys.

The BIP66 voting was inept too.  It was the ineptitude of the Core devs, not dishonest miners, that caused the two "forks of July" (6-block and 3-block long, respectively) and required broadcasting to all clients the embarrassing alert "everybody had better wait for 30 confirmations for a while".

The BIP100 voting scheme is a joke.

I think that blcokchain voting in general is a stupid idea, but the 75% of the BIP101 voting is not bad.  Any brat can set up NotXT nodes to falsify the node statistics; miners, however, will not want to play games with their revenue.  If they are against BIP101, their interest is to vote against it, to prevent the 75% trigger to happen. Why would they want to trigger a messy fork and then have it collapse?  That is the sort of puerile "cut the nose to spite the face" reprisal that only a Blockstream worker would find amusing...

Quote
If Adam had never been born I would have fought hard against a hostile takeover and especially one instigated by Mike Hearn.

If Adam had not been born, BitcoinCore would probably have lifted the block size limit years ago...

Academic interest in bitcoin only. Not owner, not trader, very skeptical of its longterm success.
canth
Legendary
*
Offline Offline

Activity: 1442



View Profile
August 30, 2015, 05:46:02 PM
 #655

Don't you see how the 'dictator' arguments in FOSS and software forks is a logical fallacy? People exercising their free will but not doing what you want does not equal dictatorship.

This is actually why dictatorship often succeed. They give to "the people" the impression of a choice by encouraging them to exercise "their free will" when they are tired of waiting for traditional issue resolution processes.

This is textbook "why the worst people get on top".

If BIP 101 succeeds, what makes you think that I won't be able to switch back to Core or only-bigblocks with a different set of developers? Is Core just going to give up?

For BIP101 to succeed it needs to be merged into Core so I am not sure what you are talking about?


I presume that your concern about XT is that it and BIP 101 succeed without core adopting it, right? Most on this list don't really seem to be worried about that given that miners aren't jumping onboard (yet). If XT were to somehow 'takeover' then my point is that BIP101 would get merged into core since there's no way core would just continue on with <25% hashrate, no coinbase or bitpay, etc.

The point being is that no matter what big blocks BIP ends up being finally adopted, there will be and should be multiple software clients available to end users which makes some sort of dictatorship completely impossible.

That is a positive scenario we are all hoping for, should BIP 101 succeed.  The concern is what % of clients XT will represent in this scenario.  If it is large, then you can only wonder what new "features" will be in it, given Hearn's clear bias for centralized trust-based systems.

Based on Hearn's previous proposals, and his complete control over XT, potential features include:

- Automatic updates
- Redlists
- Blacklists
- Whitelists
- Coin tainting


You can insert anything in "Xyz developer might introduce [insert here] in the future. It's a strawman argument and it's a waste of everyone's time discussing what someone might do with FOSS since we can all vote with our feet BEFORE that has any effect. It is not possible to force anyone to run specific client code as long as there are alternatives, which there will be. If you're worried about fungibility then please, let's work on useful things like stealth addresses or built-in mixing or gmaxwell's privacy features based on ring signatures.

I assure you that any sort of coin address lists included in a bitcoin wallet software as you've suggested will not happen or they will be soundly rejected by the community. Devs are going to leave the policing up to the coinbases and chainalysises of the world. There's absolutely no reason to include those features in the wallets - users don't want it, miners don't want it and law enforcement doesn't need it.

For the record, I'd jump ship if any of the above happened.

canth
Legendary
*
Offline Offline

Activity: 1442



View Profile
August 30, 2015, 05:51:04 PM
 #656

So in simple and quick words, Bitcoin XT has a feature which tracks IP address of the user and although it states that is used for blacklisting purposes, it does go against the very fundamental of bitcoin. Why is the Bitcoin XT project not being discarded by the bitcoin users then? What is making them disregard their privacy and fuel hearn's shitty attitude? WHY

So let me get this straight, you think that the Tor project is tracking bitcoin users since that's where the IPs are downloaded from? Shh...don't tell anyone but Bitcoin Core has a tracking feature where the first time you launch it, it tracks your IP via the DNS seed too. Better not run that either. Damn centralization! /<sarcasm>

And as far as the IP address prioritization goes, let me ask you this. In the event that you run a node and all incoming connections are full - how do you think that connections should be prioritized? Should new connections be ignored? Should you drop some Tor IP address to make room for other connections? Hearn came up with a prioritization that you don't like - fine. Disable it or come up with something better or run Bitcoin Core or run only-bigblocks. Lots of options and yet you choose to spread misinformation.

canth
Legendary
*
Offline Offline

Activity: 1442



View Profile
August 30, 2015, 05:54:21 PM
 #657


If Adam had never been born I would have fought hard against a hostile takeover and especially one instigated by Mike Hearn.


It's amazing - Bitcoiners out of one side of their mouth talk about decentralization and freedom. On the otherside, they really seem to not like it so much when there's decentralization on the decision and development process. Doesn't that sound strange to you? It's fine that you don't like Hearn or Gavin, but why not just say that? It can't be that you really think that Bitcoin is the Blockstream Company or nothing, do you?

erik777
Sr. Member
****
Offline Offline

Activity: 264


View Profile
August 30, 2015, 06:09:02 PM
 #658

Just for completeness, here's the reply.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010496.html
Quote
[bitcoin-dev] Bitcoin XT Fork
Mike Hearn hearn at vinumeris.com
Thu Aug 20 09:00:14 UTC 2015

>
> It is just that no one else is reckless enough to bypass the review process


I keep seeing this notion crop up.

I want to kill this idea right now:

   - There were months of public discussion leading to up the authoring of
   BIP 101, both on this mailing list and elsewhere.

   - BIP 101 was submitted for review via the normal process. Jeff Garzik
   specifically called Gavin out on Twitter and thanked him for following the
   process:

   https://twitter.com/jgarzik/status/614412097359708160

   https://github.com/bitcoin/bips/pull/163

   As you can see, other than a few minor typo fixes and a comment by sipa,
   there was no other review offered.

   - The implementation for BIP 101 was submitted to Bitcoin Core as a pull
   request, to invoke the code review process:

   https://github.com/bitcoin/bitcoin/pull/6341

   Some minor code layout suggestions were made by Cory and incorporated.
   Peter popped up to say there was no chance it'd ever be accepted ..... and
   no further review was done.

So the entire Bitcoin Core BIP process was followed to the letter. The net
result was this. There were, in fact, bugs in the implementation of BIP
101. They were found when Gavin submitted the code to the XT community
review process, which resulted in *actual* peer review. Additionally, there
was much discussion of technical details on the XT mailing list that
Bitcoin Core entirely ignored.


Just for completeness, here's Peter's reply to Mike

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010497.html
Quote
[bitcoin-dev] Bitcoin XT Fork
Peter Todd pete at petertodd.org
Thu Aug 20 09:13:34 UTC 2015

...

No, I said there was no chance it'd be accepted "due to a number of
BIP-level issues in addition to debate about the patch itself. For
instance, Gavin has never given any details about testing; at minimum
we'd need a BIP16 style quality assurance document. We also frown on
writing software with building expiration dates, let alone expiration
dates that trigger non-deterministically. (Note how my recently merged
CLTV considered the year 2038 problem to avoid needing a hard fork at
that date)"

Of course no further review was done - issues were identified and they
didn't get fixed. Why would we do further review on something that was
broken whose author wasn't interested in fixing even non-controversial
and obvious problems?

The process is to do review, fix issues identified, and repeat until all
issues are fixed.
tvbcof
Legendary
*
Offline Offline

Activity: 2296


View Profile
August 30, 2015, 06:09:41 PM
 #659


If Adam had never been born I would have fought hard against a hostile takeover and especially one instigated by Mike Hearn.


It's amazing - Bitcoiners out of one side of their mouth talk about decentralization and freedom. On the otherside, they really seem to not like it so much when there's decentralization on the decision and development process. Doesn't that sound strange to you? It's fine that you don't like Hearn or Gavin, but why not just say that? It can't be that you really think that Bitcoin is the Blockstream Company or nothing, do you?

Let it be known that I do not like Mike and Gavin.  Signed: ~tvbcof

I'm not talking about on a personal level since I don't know them.  Given their attitudes about certain things as reflected in their actions and activities, I probably would not like them on a variety of personal levels either though.


erik777
Sr. Member
****
Offline Offline

Activity: 264


View Profile
August 30, 2015, 06:42:23 PM
 #660

That is a positive scenario we are all hoping for, should BIP 101 succeed.  The concern is what % of clients XT will represent in this scenario.  If it is large, then you can only wonder what new "features" will be in it, given Hearn's clear bias for centralized trust-based systems.

Based on Hearn's previous proposals, and his complete control over XT, potential features include:

- Automatic updates
- Redlists
- Blacklists
- Whitelists
- Coin tainting


You can insert anything in "Xyz developer might introduce [insert here] in the future. It's a strawman argument and it's a waste of everyone's time discussing what someone might do with FOSS since we can all vote with our feet BEFORE that has any effect. It is not possible to force anyone to run specific client code as long as there are alternatives, which there will be. If you're worried about fungibility then please, let's work on useful things like stealth addresses or built-in mixing or gmaxwell's privacy features based on ring signatures.

I assure you that any sort of coin address lists included in a bitcoin wallet software as you've suggested will not happen or they will be soundly rejected by the community. Devs are going to leave the policing up to the coinbases and chainalysises of the world. There's absolutely no reason to include those features in the wallets - users don't want it, miners don't want it and law enforcement doesn't need it.

For the record, I'd jump ship if any of the above happened.

It isn't completely theoretical when you consider his previous proposals.  He has proposed repeatedly putting central trust-based control into Bitcoin, and he has complete irrevocable control over XT.   Yes, it is possible he won't do all this bad stuff in XT.  But, you have to consider how he could do this BEFORE he does it in order to avoid it, because control is a sneaky thing that can creap in over time.  

Here is a possible plan that could create an irreversible situation, one where you cannot just escape by quitting using XT:

1. Obtains a critical mass of clients.  Let's say 75% of miners are running XT code.
2. Introduces automatic updates for "security reasons".  This will help relieve the pesky decision making progress with upgrades.
3. Introduces ability to identify XT clients.
4. Puts in DoS code based on blacklists and prioritization that are distributed and signed by XT nodes, giving a higher priority to XT connections.  This effectively de-prioritizes non-XT nodes.  Can also easily adds non-XT nodes to lower priority lists (blacklists).  He already put the code into XT, with documented plans to make it utilize more node coordination.  Clearly, the only nodes that are candidates for doing this coordination today are XT nodes, as Core rejected this proposal.  
5. In order to "combat crime", introduces coin tainting (another one of his famous ideas) that can revoke the wealth of those who object, with a negative bias towards non-conforming (non-XT) nodes.

Now, people wake up and realize this is bad stuff.  What happens when you use a non-XT client?  At this point, it is too late to undo.  Technically, you can accomplish all of this without changing the Bitcoin protocol, although this would presumably require different chains and protocols.  With 75% critical mass, however, one could just as easily change the consensus protocol to make it more irreversible.  He's already proved he is willing to do that.  

Yes, there is theory here, as we are talking about a possible future.  Yet, given past proposals to add centralized control to Bitcoin, and his completely control over XT, this is not out of the realm of possibility.  The core risk of Mike's previous proposals which he has become known for is the introduction of central control and trust to our decentralized trust-less Bitcoin.  So, the better question is why would he not use XT to implement his vision?


Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 [33] 34 35 36 37 38 39 40 »
  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!