Gold collapsing. Bitcoin UP.

[Bagatell]

[doublepost=1466262982,1466262011][/doublepost]

Can someone explain this:

http://coinmarketcap.com/currencies/monero/

https://kiwiirc.com/client/irc.freenode.net/monero

/u/fluffyponyza is in attendance

edit my bad missed it!

 

[VeritasSapere]

@freetrader I was literally thinking the same thing, the parallels are uncanny. People are even falling along some of the same ideological lines, arguing about how the governance of Ethereum is "supposed" to work. It reminds me of a divide and conquer psychological operation. If there was some outside force that was behind what happened to Bitcoin, creating this divide, it could very well be that same group that is doing this to Ethereum right now. That letter by "the attacker", seems to actually be an attack on Ethereum more then that hack ever was, it is designed to create division within the Ethereum community and disrupt the project.

 

[79b79aa8]

Couldn't someone sue kore dev similarly for implementing a SWSF that preferentially advantages SW tx's and LN over regular, time tested, and honored regular tx's to the tune of 75%? Not to mention all the other changes that arguably change Bitcoin economics and disenfranchise early adopters by shifting Bitcoin's emphasis away from the WP's title of "p2p cash" to "Smart contracting" or even "settlement layer"?

i don't now about suing, but i think the line to hammer is: SWSF is to BTC as DAO is to ETH.

of course there are important disanalogies, but one main, overarching point: can you be reasonably* sure SWSF won't introduce unintended consequences to how bitcoin works? you can? prove it! (and do that before miners lose patience with missing out on tx fees).

*EDIT

 

[Peter R]

@79b79aa8: agreed.

I think the analogy between 'The DAO' and the SegWit-SF might gain some traction here. Bitcoin is first-and-foremost money; the only thing we really need to do is take off the 1-MB training wheels and let her fly. In fact, adding extra complexity could very well be counterproductive.

So I'd be interested in everyone's opinion (maybe even a poll):

Would you prefer to:

1. Implement SegWit now, lift the block size limit later.

2. Implement SegWit and lift the block size limit at the same time.

3. Lift the block size limit now, and put SegWit on hold (perhaps indefinitely).

 

[Bagatell]

@Peter R Done.

https://bitco.in/forum/threads/wall-observer.27/

 

[VeritasSapere]

@cypherdoc I do think the common law principle works here, it is the intention of the law not the letter of the law that matters here. Furthermore we should perceive the governance mechanism supporting the smart contract platform as being a part of this platform, so sure the contracts are not completely immutable contract code because of the possibility of intervention by the governance mechanism, considering the possibility of human error and how the code might not always reflect the intention combined with that we now also have decentralized governance build into the same protocol, that the code in the contracts itself is not immutable when confronted with "consensus" in these rare cases might not be such a bad thing.

 

[lunar]

Good god this drama is endless. Can anyone be really sure there's not some all seeing skynet type AI behind this?

it's a 24 hours a day nonstop livestream dramathon that where viewers get paid to watch and participate.

I feel an attempt on 800 coming on?

 

[satoshis_sockpuppet]

@79b79aa8: agreed.

I think the analogy between 'The DAO' and the SegWit-SF might gain some traction here. Bitcoin is first-and-foremost money; the only thing we really need to do is take off the 1-MB training wheels and let her fly. In fact, adding extra complexity could very well be counterproductive.

So I'd be interested in everyone's opinion (maybe even a poll):

Would you prefer to:

1. Implement SegWit now, lift the block size limit later.

2. Implement SegWit and lift the block size limit at the same time.

3. Lift the block size limit now, and put SegWit on hold (perhaps indefinitely).

As far as I understand Segwit alone isn't really changing Bitcoins principles or inner workings.
If it's just a more logical and cleaner way of organizing block data I think it's a good thing to do eventually.

But I'm against doing it as a soft fork and this discount bullshit. I think a long term planned Hardfork to SW transactions would be good.
Best case scenario imho:
1. Hardfork asap to 2 < blocksize < 8 MB.
2. Combined Hardfork in 2017 or so with Bitpays scheme or Bip101 or no limit at all and Segwit.

Honestly I think the Eth mess gives Bitcoin some more time. So (unrealistic but who knows) if there was a middle ground for a 2 MB + SW HF late this year I think I would be ok with that as well... I don't know how much of Pieters work could be used in that case and I don't know if that's technically feasible. And I don't know if there is a chance for wallets to catch up fast enough.

So from your choices 3, 2, 1 would be my vote.

 

[Inca]

ETH crashing, btc up.

Let's see if double top or an 8 handle chaps

 

[awemany]

Someone is indeed reading manuals for a successful dictatorship: https://www.reddit.com/r/Bitcoin/comments/4ojugo/a_thank_you_to_bitcoin_core_developers/

What's up with all those bootlickers?

 

[bluemoon]

@79b79aa8: agreed.

I think the analogy between 'The DAO' and the SegWit-SF might gain some traction here. Bitcoin is first-and-foremost money; the only thing we really need to do is take off the 1-MB training wheels and let her fly. In fact, adding extra complexity could very well be counterproductive.

So I'd be interested in everyone's opinion (maybe even a poll):

Would you prefer to:

1. Implement SegWit now, lift the block size limit later.

2. Implement SegWit and lift the block size limit at the same time.

3. Lift the block size limit now, and put SegWit on hold (perhaps indefinitely).

My preference is for 3): lifting the blocksize limit now and putting segwit on hold.

I say that on the basis of i) keeping the client simple and ii) letting bitcoin scale as freely as possible now with proven code.

The drawback may be that if some segwit-like change is needed in future we might then wish it had been introduced earlier to allow any development between now and then to incorporate it. I am not really qualified to judge that one, because my views are a layman's, but I'd guess that if segwit were to be introduced, it would probably be easier to do it sooner than later.

However, I do sense a fair degree of confidence among the technically qualified people on the BU/Classic side that freeing bitcoin of the blocksize limit may be all she ever needs. It is on that basis (and being sceptical of Blockstream Core) that I would hold off on segwit.

 

[79b79aa8]

@cypherdoc I do think the common law principle works here, it is the intention of the law not the letter of the law that matters here. Furthermore we should perceive the governance mechanism supporting the smart contract platform as being a part of this platform, so sure the contracts are not completely immutable contract code because of the possibility of intervention by the governance mechanism, considering the possibility of human error and how the code might not always reflect the intention combined with that we now also have decentralized governance build into the same protocol, that the code in the contracts itself is not immutable when confronted with "consensus" in these rare cases might not be such a bad thing.

even if we go along with that, it significantly alters the smart contract story, does it not? the good news (as far as I am concerned) is that the testing ground -- to the tune of USD$60M -- turned out to be etherium, not bitcoin. furthermore, that we now have an important cautionary tale about scripting complexity. satoshi's foresight never ceases to amaze.

 

[Mengerian]

Someone is indeed reading manuals for a successful dictatorship: https://www.reddit.com/r/Bitcoin/comments/4ojugo/a_thank_you_to_bitcoin_core_developers/

What's up with all those bootlickers?

Yeah, very frustrating to read. So many are taking the wrong lesson from the DAO debacle. Eg:

 

[Bagatell]

http://trilema.com/2016/to-the-dao-and-the-ethereum-community-fuck-you/

 

[Norway]

Bitcoin up USD 25, and no comments about it here. The skin is thick here, lol!
EDIT: And now, an all time high since february 2014...

 

[cypherdoc]

isn't that purdy?:

 

[bluemoon]

The most fascinating thing about the DAO hack may be the way it exposes these tensions. To true believers in smart contracts, there is no problem here. The system is fine; the failures -- writing bad code and not anticipating this attack -- were trivial, mere human error.Next time, write better smart contracts and you'll be fine. To those true believers, changing the code after the fact -- even to conform it to almost-everyone's reasonable expectations about how the DAO would work -- would be a betrayal of the smart-contract ideal.

On the other hand, to the humans who read the English descriptions of the DAO and invested their money based on their reasonable expectations, their losses probably do seem like a problem. You can't really base the financial system of the future on computers rather than humans, on trusting to immutable code no matter what happens. Financial systems are supposed to work for humans. If the code rips off the humans, something has gone wrong.

@cypherdoc I do think the common law principle works here, it is the intention of the law not the letter of the law that matters here. Furthermore we should perceive the governance mechanism supporting the smart contract platform as being a part of this platform, so sure the contracts are not completely immutable contract code because of the possibility of intervention by the governance mechanism, considering the possibility of human error and how the code might not always reflect the intention combined with that we now also have decentralized governance build into the same protocol, that the code in the contracts itself is not immutable when confronted with "consensus" in these rare cases might not be such a bad thing.

The DAO was a scheme constructed and promoted by humans to other humans. Like all contracts, it was an agreement for consideration (value) on each side. The performance of a contract may involve a scheme with a number of components or a series of stages, including creating or acquiring various tangibles and intangibles such as pieces of computer code. The DAO was a mechanism constructed by humans to serve human purposes, which its promoters P represented to various As as a means to achieve X. P may try to exclude contract terms the law commonly implies, including liability for defects in the mechanism causing loss or damage to A, but in principle P as the promoter of the scheme is liable to A for the DAO's performance in accordance with the intention of the parties. I don't see how this can be any different than liability in contract or tort for any other contractual failure.

I don't think smart contracts are entirely new. I never played, but I guess Satoshi Dice was a form of smart contract. Players were never just dealing with the code interface, they were acting on a representation by the game's promoters of what it meant to bet bitcoin within the game: representations of odds and payouts. If the code did not reflect those representations it could amount to a fraud.

 

[cliff]

http://trilema.com/2016/to-the-dao-and-the-ethereum-community-fuck-you/#selection-29.59-29.410

^ attacker?

 

[freetrader]

Just looks to me like Popescu wanting people to think of him again. Seems his last 15 mins (the Classic DDOS saga with /u/botneko-chan) already expired.

---

Ah, those dumb /r/btc users... : /s
^ this guy's MO seems to be to spam /r/btc with the noteworthy tweets of Christopher Allen, Principal Architect at Blockstream, which seem to consist mostly of links to other people's original blog posts (like Szabo in the case below). Another fresh example:

https://www.reddit.com/r/btc/comments/4oorsg/christopher_allen_on_twitter_the_are_even_more/

He may have a point, I had honestly never heard of Allen before. Guess that's why I'm one of those dumb /r/btc users who need to be educated.

 

[jbreher]

@79b79aa8: agreed.

I think the analogy between 'The DAO' and the SegWit-SF might gain some traction here. Bitcoin is first-and-foremost money; the only thing we really need to do is take off the 1-MB training wheels and let her fly. In fact, adding extra complexity could very well be counterproductive.

So I'd be interested in everyone's opinion (maybe even a poll):

Would you prefer to:

1. Implement SegWit now, lift the block size limit later.

2. Implement SegWit and lift the block size limit at the same time.

3. Lift the block size limit now, and put SegWit on hold (perhaps indefinitely).

For months now, I've been referring to this as 'The SegWit Omnibus Changeset', as it is embodied as waaaay more than segwit itself. (Even have had a few pick up the lingo).

The concept of calculating transaction ID over the transaction data itself (excluding the signature data) is a good one. But even splitting out the witness data into a separate chain seems like unnecessary fluff to me. Pile on all the other crap (versionbits enabling multiple softforks? really?), and the failure surface is yuuuge.

Give me the core of anti-malleability plus a maxblocksize determined by emergent consensus, and I'm onboard. Enthusiastically.