Bitcoin Forum
November 24, 2017, 04:19:56 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
  Home Help Search Donate Login Register  
  Show Posts
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 41 42 43 44 45 46 47 48 49 50 51 ... 241 »
1  Bitcoin / Development & Technical Discussion / Re: Payment No. 1: A Closer Look at the Very First Bitcoin Transfer on: November 07, 2017, 05:13:12 AM
/tx/0437cd7f8525ceed2324359c2d0ba26006d92d856a9c20fa0241106ee5a597c9]look at when those 50 bitcoins were mined to that address[/url] you can see that it came from block #9, and blocks 1 through 14 were mined a day before the bitcoin software was even released (meaning, technically, bitcoin had a 700 BTC premine!).

wtf.

Block 1 has a timestamp of 2009-01-09 02:54:25.   The announcement of Bitcoin's release is timestamped Thu Jan 8 14:27:40 EST 2009, which is more than 7 hours before block 1.


Please fix your post before we have to endure more years of people repeating unsupported speculation and outright untruths about the history of Bitcoin.

Quote
None of the other super-early Nakamoto bitcoins were ever spent.
You have no idea which if any other blocks he mined, -- the only reason you think you do is due to garbage "scholarship" like your own that can't even manage to compare two dates.
2  Bitcoin / Development & Technical Discussion / Re: Simplicity new language for blockchains on: November 01, 2017, 12:51:34 AM
SegWit introduced script versioning so maybe they will be able to deploy Simplicity using that -- which means without a hardfork. But I guess the jury is still out on that one, otherwise they would have explicitely mentioned that in the whitepaper.

::sigh::  People think weird stuff.   The paper does not talk about Bitcoin integration in any detail, as it is massively premature for that.


But adding a new script system is a softfork, it's always been a softfork. It's pretty much the most softforky thing you can imagine, and moreover it's already been done before!  P2SH replaced Script with a nested copy of Script..  In that case the nested thing was the same as the outer thing, but there was no technical reason it couldn't have been different.


3  Alternate cryptocurrencies / Altcoin Discussion / Re: SegWit2x seriously losing support? on: October 14, 2017, 01:30:29 AM
Unfortunately, much of the #NO2X crowd still doesn't seem to understand backward compatibility. Many of them continue to repeat the falsehoods that "soft forks are backward compatible" and "BIP148 was backward compatible." The reality is that soft forks can be incompatible and that BIP148 was very likely to be incompatible.

Thanks for actually being thoughtful, though I think it is a little more subtle than you suggest:  BIP148 would have been backwards compatible IF and Only if hashrate became compatible with it.  The people arguing that it was compatible were not, I think, trying in any way to be dishonest but rather were pretty convinced that hashrate would be compatible with it when it activated (regardless of this view being justified) and to whatever extent they had doubts any failure they would attribute to hashrate not doing what it was supposed to do (regardless of this view being justified...).

I think this is an unreasonable risk and to this day I don't understand why quite a few other people thought it was an acceptable one.  But, on the other hand, they were right that hashpower would (effectively) go along with it.

Every other point I agree with, in particular your comments on the timeline of it.  I think though that I would conclude that they took a gamble and won, elsewhere we might applaud them with tremendous foresight as we often do for people successful primarily through chance... Smiley  OTOH, what they were gambling with was the safety and stability of a shared resource that we all count on...

The intervention of 2x unfortunately substantially eliminated one of the main payoffs proponents of BIP148 probably anticipated:  Rejecting the notion that miner forced capacity hardforks were something we needed to respond to on an immediate basis, thus allowing us to make more progress with less drama.  Maybe we'll be there after November.

I think the thing we should worry about isn't recriminations about BIP148 but what are reasonable expectations for consensus upgrades to Bitcoin.  I don't think it's reasonable to expect them to happen, generally, on a time frame of less than years.  It certainly isn't the case for internet infrastructure protocols like BGP, which are easier to upgrade than Bitcoin...  If a chance is well understood and widely supported, then sure Bitcoin can deploy them faster, but I think our base expectation should be years.   I think this is the fundamental disconnect that fed a lot of fuel to the short timeframe of BIP148.

4  Bitcoin / Development & Technical Discussion / Re: Trojan - SegWit2x on: October 13, 2017, 10:13:36 PM
Did you see the last post/response? Seems like a legit answer:
Quote
jgarzik replied 9 days ago edited
This is a privacy feature. See discussion at PR #109 for more.

This feature defaults to advertise (privacy=off).

Users may optionally disable advertising (privacy=on).

There is historical precedent with Internet browsers: https://stackoverflow.com/questions/7975996/why-does-internet-explorer-9-report-mozilla-in-useragent

Users also rightly requested privacy features like this due to past attacks:

I wonder why Jeff Garzik would tell such a transparent lie.  It only seems like a legit answer if you don't know how things work. Although he has locked the discussion there so no one else can point this out, nothing stops us from discussing it over here.

All his nodes continue to send subver: "Satoshi:1.15.0"  to everything that connects to them, trivially identifying them.  A a result his change has no privacy gain what-so-ever and serves exclusively to undermine the anti-partitioning logic in the Bitcoin node software; leaving users open to unwanted connections that reduce their safety and reliability. This fact couldn't have been missed, especially since the explicitly cited "Bitcoin Classic" identified itself exclusively via subver.

[FWIW, because I'm calling Jeff out on a serious breach of ethics here I think it's important that he have an opportunity to respond, so I am also emailing him a link to this discussion. Edit: Done]
5  Alternate cryptocurrencies / Altcoin Discussion / Re: SegWit2x seriously losing support? on: October 13, 2017, 06:29:55 PM
And BIP91
Actually, BIP91 predated that NYA entirely and was written as a tool for miners to avoid a BIP148 introduced split.

BTC1 adopted it (with some prodding by its author) and also kept its signaling the same, forever obfuscating the activation.  All of the miners I've spoken to were running segsignal (BIP91) and not 2x.

the Segwit guys
Were never involved with the "NYA" at all.

It's like your neighbors making a deal among themselves to divide up your home and assets... and now people are calling you out for reneging on an agreement that you never agreed to!
6  Alternate cryptocurrencies / Altcoin Discussion / Re: SegWit2x seriously losing support? on: October 13, 2017, 04:52:36 AM
And a couple hours later, we see Blockchain.info double down in support of Segwit2x. They basically issued a repeat of Xapo's statement. They will consider the strongest chain to be "Bitcoin" regardless of anything else, and will not support the minority chain in the long term (though they will likely make it available for withdrawal).

But in one sense it is the weakest possible support short of outright opposition.

It is effectively saying "we will do whatever other people do"...  So if you have a dispute between two groups, one saying "We'll do what other people do" and another group saying "We absolutely positively will not do thing-B but will instead do thing-A"  ... what do you think is going to happen?

In the presence of a considerable part of the community that won't follow B2X under almost any condition bc.i's statement is not really all that supportive.

Quote
Quote from: Kyle Torpey
While everyone was worried about #bitcoin mining centralization, @blockchain was processing 40% of on-chain transactions.
Is the above true?
It's something that blockchain claims but I am fairly confident that it has no basis in reality. They base the claim on how many transactions are submitted through their API, but many people pick up random transactions from the network and submit it to their API because it has, at times, been the only way to make transactions reliably display on their site, because their nodes are sometimes down.  Transactions generated by their wallet have been historically distinctive in a number of ways-- they are not generating anywhere near that number of transactions on the network.
7  Bitcoin / Development & Technical Discussion / Re: Should Address expiration time be added to BIP-173 ? on: October 11, 2017, 06:25:16 AM
* We seem to have a minor problem in the ecosystem with people aggressively deploying unreviewed draft proposals.

It can be difficult in a decentralized system to control the behaviors of others.

"To enjoy freedom we have to control ourselves."

Unfortunately the propensity for people to run off and deploy things without review and discussion with drive a mixture of low quality defacto standards and less inclusive and transparent design work.

Complaining about it a bit is a tool for progress, reminding people to control themselves.  No one need control the behavior of others.
8  Bitcoin / Development & Technical Discussion / Re: Should Address expiration time be added to BIP-173 ? on: October 08, 2017, 08:24:11 PM
Unfortunately the suggestion isn't timely-- it was made after several parties had publicly deployed BIP173*.  It also has a number of unanswered questions (range and resolution, how do you address that you can't go backwards from a SPK to an expiration...).

I think it's a good idea in general, but I think it will need to wait for the future.

* We seem to have a minor problem in the ecosystem with people aggressively deploying unreviewed draft proposals.
9  Bitcoin / Development & Technical Discussion / Re: If Bitcoin at protocol level is Great Firewalled, what are the options? on: October 04, 2017, 11:36:13 AM
In terms of just getting it across, I'm pretty sure we've got this. (obviously I'm not going to post all the details because that would needlessly escalate the cat and mouse.)  I'm aware of at least three radically different bypass mechanisms that are already in place (none of which involve anything as pedestrian as VPNs or Tor, though both these things exists and will also help bridge Bitcoin and and out of china).  Fortunately, Bitcoin's ongoing bandwidth requirements are relatively low and this opens many options.

But getting around a firewall is only one problem... if Bitcoin is banned in china it will be much harder for people to use it there even if they technically can.  This would be unfortunate.  Especially on top of the already near total absence of nodes in china. (last I checked there were only about 50 externally reachable actual nodes).
10  Bitcoin / Development & Technical Discussion / Re: Potential SHA256 Mining Speedup (2.3%) on: October 04, 2017, 11:33:44 AM
FWIW early termination has been used by miners since at least 2010.
11  Bitcoin / Development & Technical Discussion / Re: libsecp256k1 as a library/dll/etc on: September 26, 2017, 11:13:38 PM
Libsecp256k1 works fine with no dependencies at all.  You're having dependency issues because you're bypassing the build system and doing something horrible.  Read the fine instructions.  Otherwise it's like drilling into someone's head and then complaining that you have to provide infrastructure to keep the blood circulating or they stop being able to give you advice. Smiley

> mbedTLS will build without any external dependencies, it has its own MPI functions and supports secp256k1 primitives

And is probably not even remotely constant time for it and is probably also super slow...
12  Alternate cryptocurrencies / Altcoin Discussion / Re: 2X on: September 26, 2017, 05:18:17 PM
well ok, fair enough, but your reply does not seem to answer why you would not 2x, excepting as to a reference to "stability" without more.
Other people already had. I was clarifying the innovation point and nothing else.


[the sake of showing commitment by precedent to some block size increase, which appears to be reasonable given the size of HD vs cost decrease and bandwidth cost decrease.
What "decrease"?.... on state of the art hardware at both times the initial sync of Bitcoin increased by 50% in the last 6 months.  This has a material impact on people's willingness to run nodes-- an uncompensated act which is essential for Bitcoin's survival as a secure decentralized system.

Quote
Also (while I don't really agree with the word spam) it would allow 1/2 the fees
Twice the space doesn't mean one half fees, it means almost zero fees against the same demand. Half the fees would generally be achieved by a few percent more capacity.

Quote
much more costly for spammers to spam the blockchain.

A spammer must pay the fee of each transaction they displace for every block they displace it. Increases in blocksize in excess of demand just radically reduce their costs by resulting in very low fees.  A lager block never lowers the price to displace a transaction for a spammer.

Quote
To address the point of stability, does 2MB really threaten stability? if so how.
The best prior research we had showed that 2 to 4MB was the largest arguably safe amount even while ignoring safty margins, state attacks, initial synchronization, etc.   2X is _NOT_ 2MB, it is 4 to 8MB.
13  Alternate cryptocurrencies / Altcoin Discussion / Re: 2X on: September 25, 2017, 10:20:42 PM
speed of technological development
We do in terms of _real_ technological development, but not fake marketing crap... and not at the expense of stability and security.

Compare, Bitcoin moving to innovative second generation error protected addresses w/ BIP173  vs  ethereum still behind bitcoin 0.1 without a strong safe to use address system.

Or ethereum validation being so slow that its impractical to sync-up a full node anymore, pushing almost all eth users onto SPV-like security for their initial sync, while Bitcoin sync tx/s speed is orders of magnitude faster and keeps getting faster.
14  Bitcoin / Development & Technical Discussion / MOVED: 2x is the end of bitcoin as we knew it. Coinbase, US, banks are friends on: September 25, 2017, 09:52:04 PM
This (non-technical) topic has been moved to Bitcoin Discussion.

https://bitcointalk.org/index.php?topic=2206674.0
15  Bitcoin / Bitcoin Discussion / Re: 2x is the end of bitcoin as we knew it. Coinbase, US, banks are friends on: September 25, 2017, 09:51:16 PM
The longest chain is real bitcoin.
That isn't how _any_ version of the software release by Satoshi or any version ever after worked. That isn't how Bitcoin is described in the whitepaper either.  You're just regurgitating a broken model of Bitcoin pushed by people trying to take it over like Ver and BU-- who all quickly abandoned that approach when they found it wasn't working for them.

16  Bitcoin / Development & Technical Discussion / Re: Just confriming, segwit or segwit2x is going ahead on BTC? on: September 25, 2017, 06:31:34 PM
what would happen if BCH activated segwit....? just to in your face segwit.....2x and also take the market

Seems pretty unlikely, heh.  BCH supporters made a pretty huge song and dance about how SegWit supposedly wasn't part of Satoshi's vision and isn't "true" to Bitcoin, so there'd be an inordinate quantity of humble pie to swallow if they went down that route.  It's too much of a marketing U-turn to take it seriously.
BCH already incorporates part of segwit-- BIP143, the segwit signature scheme they've just renamed it "safesigs" and present it like it's their own brilliant invention. They're working on merging BIP173 (the error protected base32 addresses we created) but renaming it "cashaddress"... Sense a pattern here?

They've been going on about 'flextrans' which contains exactly the same design feature about segwit that they've thrown so much "not Satoshi's vision" mud about-- that new transactions don't commit to past signatures (a necessary criteria for fixing malleability).

They've gone on about "schnorr signatures" but their implementation there is just our prior abandoned code with the copyright headings removed and their own names added.

Don't make the mistake that honesty or technical merit are even considerations in their marketing. For all it matters for their marketing there is no u-turn so long as they don't admit it.  If you can tell that they are full of crap you aren't in the bcash target audience.

Now the interesting point is that 2Xcoin is going after the same unsophisticated audience, splitting that market.
17  Bitcoin / Bitcoin Discussion / Re: Scenario > Bitcoin goes to 100. How will that affect you ? on: September 24, 2017, 02:27:46 AM
I saw the thread title and figured it would be a necopost of a 2011 thread. Smiley
18  Bitcoin / Development & Technical Discussion / Re: A replacement Alert System should be considered to promote updates as necessary on: September 19, 2017, 05:10:25 AM
but bitcoin software is a special case as consensus rule changes require mass spontaneous upgrades
No it doesn't, in fact a decenteralized system cannot change like that. If bitcoin can be forced into "mandatory mass upgrades" then it has failed.

Moreover, well constructed changes in consensus rules are detected and responded to by existing software:

(And not just at the change, but in advance too!)



Quote
I don't really appreciate the tone here, that's not warranted.
I apologize for offending, but you appear to be wading in somewhat uninformed and telling other people what they should do. This is very insulting.  I don't mean to offend, but with your approach you are going to get a blunt response.

Quote
Also, I didn't imply a centralised world,
Perhaps you didn't intend to, but a world where we depend on trusted parties with special secret keys that have special powers is that kind of world.

Quote
original post. Forums, reddit, mailing lists are all centralised forms of communication to some degree. All of those suggested alternatives to an alert/notification system require a level of trust. They are not trustless.
And none are official, people use all of them and many more.  There are singular methods of communication that are highly controlled but communication between people is not.

Quote
Yes, this justification applies equally to a client alert/notification system.
It does not, because a message displayed on your screen commanding urgent and immediate action does not provide a timeframe for public review and communication to take place.

Quote
Multisignature is better described as semi-decentralised.
It depends on a trusted authority, the that the authority is a (perhaps informal) corporation rather than a natural person doesn't change the fact that such a system has a fixed center. Not only should users not want to depend on one, prudent parties don't want to be one because of the generation of completely uncompensated risk. (It becomes attractive to compromise or even kidnap key holders in order to generate false notices; no one pays us to take on risks like that so we want.  The kind of people who wouldn't care about that are the kind of people who on no account should you ever trust with it...)

Quote
This would be my preliminary proposal for a "best practice" notification system:

You will have more luck with proposals if you first demonstrate empathy and a high degree of understanding. I don't feel that you are doing that here. In particular, the claims that consensus systems require sudden/unexpected changes or that we're currently not able to have users detect consensus rule changes -- when we already have mechanisms for this which work.
19  Bitcoin / Development & Technical Discussion / Re: A replacement Alert System should be considered to promote updates as necessary on: September 19, 2017, 02:08:50 AM
Without some kind of carefully crafted notification, there will always be users who never ever update. It feels like stagnation is built into this system and it will never be overcome.
It sounds like to me that you're making assumptions which are simply not true, then fixating on particular solutions.

People do upgrade, this is a fact and we've seen it quite clearly in practice.  If you want software to nag users when it's really old, it could do that independent of there being any alert system.

Quote
So the concern is that if you or any other developer with access to an alert system is compromised,

"with access to" -- instantly you begin by just _presuming_ a centralized hierarchical world with privileged parties that have power over others.

Quote
I guess my response would be, doesn't that concern also apply to users simply downloading the software?
No, only _new_ users that downloaded it when it was compromised; not everyone already out there.

Quote
You could counter that by saying that users can check the source code, but the reality is apart from some very select people, users aren't reviewing source code,
Most users do not, a few do. If the few that do find problems, they can sound alarms; protecting others (see the prior point).

Quote
prevent malicious developers or compromised developers exerting control.
Multisignature is still trusted and centralized.

20  Bitcoin / Development & Technical Discussion / Re: A replacement Alert System should be considered to promote updates as necessary on: September 19, 2017, 01:08:34 AM
I see what you're saying, but I'm still not convinced and am going to remain in disagreement. (That's okay, can't agree on everything.)
Kinda matters when you're presuming to tell other people what to do.

Quote
Why not have an informative window prior to installation of the update? Explaining these very things, with something like a quick executive summary:

Code:
This update contains XXXXX, some users may not wish to update, **you do not need to update**.
If you do not agree you are welcome to continue using the previous version.
Please click cancel and continue using your current client

Because this requires the source to be honest about XXXXX.  In other words, it requires trust.  We are philosophically opposed to building systems which have an ongoing and realtime trust requirement both out of concern for the security of our users but also as a factor in our own personal safety.
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 41 42 43 44 45 46 47 48 49 50 51 ... 241 »
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!