全 113 件のコメント

[–]gavinandresenGavin Andresen - Bitcoin Expert 28ポイント29ポイント  (5子コメント)

Pieter and Greg are both brilliant, and this is exactly the type of thing that is perfect for deploying and testing on a sidechain before rolling into Bitcoin-proper.

[–]SwagPokerz -1ポイント0ポイント  (0子コメント)

In the future, how are you going to roll such changes into Bitcoin proper when the whole consensus system is massively deployed in a decentralized fashion around the planet?

Consider that even with its ruthless iron fist wrought from hundreds of billions of dollars' worth of centralized and authoritarian monopoly, Microsoft has struggled to displace its own operating system, Windows XP. Even on the advent of Windows 10, its ancient and decidedly inferior predecessor has perhaps around 12% market share.


Bitcoin will be the "Internet of Money", and not just because it will be pervasive, but because it will be a very stable, relatively unchanging system that provides the secure foundation for the BTC token, which the free market can use to run all manner of other, interesting (and even proprietary) systems; innovation is only workable at the edges of the core system, and the only reasonable path toward bringing that innovation directly into the core system will be to evolve and grow an edge experiment until it seamlessly becomes the de facto core itself without breaking nearly anyone's expectations.

Therein lies the fundamental political divide:

  • One party thinks majority dictation means consensus, while the other party thinks consensus means there is no such thing as dictation.

Is Bitcoin about majority rule, or is Bitcoin about the extreme decentralization of power?

[–][削除されました]  (2子コメント)

[deleted]

    [–]kraml -1ポイント0ポイント  (1子コメント)

    I think you are off topic here.

    [–]giulioprisco 14ポイント15ポイント  (9子コメント)

    ELI5 why this is important?

    [–]BitFast 18ポイント19ポイント  (7子コメント)

    more efficient use of multisignature and better privacy

    [–]giulioprisco 1ポイント2ポイント  (6子コメント)

    Thanks. I get more efficient use of multisig, but why better privacy?

    [–]thorjag 16ポイント17ポイント  (5子コメント)

    "The basic idea is to rearrange the script’s conditions into a tree and to only reveal the part that is actually used by the spender."

    Only reveal the public keys used when spending and the rest can stay hidden.

    [–]PotatoBadger 2ポイント3ポイント  (4子コメント)

    Is that an improvement assuming somebody already avoids address/key reuse?

    [–]nullcGreg Maxwell - Bitcoin Expert 5ポイント6ポイント  (1子コメント)

    Yes. Right now multisig constantly discloses your policy to the whole network. Say you are the only 5 of 7 user on the network, now your transactions are distinguishable even if you do not reuse addresses; and everyone knows how many keys they must steal to compromise your addresses. Even if it's not uniquely identifying it can massively reduce your anonymity set (E.g. if there are only three other 5of7 users), and more complex policies are likely to be more unique.

    With checkmultisig obscuring your policy is quite expensive. The key tree approach makes it simpler because the public only learns ceil(log2(tree size)), and doubling the size of your tree with padding adds only about 40 bytes to your signature.

    [–]PotatoBadger 2ポイント3ポイント  (0子コメント)

    That makes perfect sense. Thank you very much!

    [–]mike_hearnMike Hearn - Bitcoin Expert 3ポイント4ポイント  (1子コメント)

    It can be, yes.

    It's worth noting that you can do something very similar today with Bitcoin already using threshold ECDSA:

    https://groups.google.com/forum/#!searchin/bitcoinj/threshold$20ecdsa/bitcoinj/7L-3KuWF1G4/_U_RkLGf4E8J

    [–]nullcGreg Maxwell - Bitcoin Expert 0ポイント1ポイント  (0子コメント)

    Unfortunately the revised scheme there that doesn't require trusted setup requires complex pallier encryption and distributed key generation has still not been implemented. It also requires many round trips, which is bad for usability in many cases (e.g. having to go to and from an offline wallet multiple times).

    I previously suggested (second section) a set of criteria which we can use to evaluate a multi-signature scheme with the mnemonic "AceUp":

    Accountable: After the fact the participants can determine who signed (so if a key is compromised they can take action, or appeal to an external security process.) Checkmultisig has perfect accountability.

    Composable: Given other parties multisig policy you should be able to compose their keys and create a multisig of multisig.

    Efficiency: How much blockchain space and verification time is involved? Checkmultisig is verification time linear in the number of public keys, storage linear in threshold; not great.

    Usable: Does the protocol require anything that harms usability, e.g. many round trip? The one pass checkmultisig is basically ideal in this respect.

    Private: How much does it leak the multisig policy to non-participants (without gratuitous efficiency loss)? This is both a security (e.g. knowing how many keys you need to steal) and an anonymity consideration. Checkmultsig fails this basically completely.

    Native threshold schnorr (which also works in Elements Alpha) and ECDSA fail accountability but have perfect privacy. So far workable non-trusted-setup ECDSA has bad usability, native threshold Schnorr is two-rounds regardless of the threshold size so it's somewhat less usable than checkmultisig, but not terrible. Efficiency wise the plain threshold schemes have perfect (O(1)) efficiency.

    The treesig approach has perfect accountability and privacy is configurable and more privacy is cheap. The efficiency is pretty good, always half the size of a checkmultisig and in some cases enormously smaller. Usability is the same as threshold schnorr. The results are composable if someone gives you the full redeem script.

    There are other schemes that have been proposed, e.g. the polysig scheme I invented give signatures which are O(number of keys which didn't participate, regardless of the policy) which is the size of a single signature if all signers happen to be available. But it's not efficient for few-of-N.

    [–]snooville 22ポイント23ポイント  (1子コメント)

    This is just insane! That's the thing about programmable money. They can keep improving it. Keep on innovating and coming up with new cool stuff!

    [–]EdsterGB 41ポイント42ポイント  (43子コメント)

    I really don't understand why Blockstream get such a hard time on this sub when they consistently deliver innovation like this for Bitcoin.

    [–]PhiMinD 25ポイント26ポイント  (2子コメント)

    Because there are active shills attempting to divide and conquer the community. People are very naive in thinking banks will sit around and watch their business model slip away. Their goal is to rupture the community of the most trusted blockchain in existence so they can offer their own up as a solution.

    [–]gabridome 0ポイント1ポイント  (1子コメント)

    People are very naive in thinking banks will sit around and watch their business model slip away

    The enemy are probably those but I wouldn't swear on which part they have chosen to be their soldiers.

    Their goal is to rupture the community of the most trusted blockchain in existence

    If I would plan to rupture this community I would propose the adoption of an alternative client leading to an hard fork triggered by a 75% adoption based consensus...

    [–]Demotruk 8ポイント9ポイント  (19子コメント)

    It's absolutely great that they do so much for Bitcoin, and they should be recognized for their efforts. That doesn't preclude the possibility that one company with their own interests has too much sway in the development process. Thankfully that's only a problem in a one client project status quo. It will not be such a problem with competing implementations.

    [–]maaku7Mark Friedenbach - Bitcoin Expert 6ポイント7ポイント  (18子コメント)

    There are many bitcoin client implementations. There is and only can be one consensus code implementation. Do you see the difference?

    [–]gavinandresenGavin Andresen - Bitcoin Expert 7ポイント8ポイント  (2子コメント)

    There can be many bitcoin client implementations and many implementations of the consensus code.

    There may be implementation bugs in those many codebases that cause them to lose consensus with the rest of the network-- and we've seen several variations of that even with a SINGLE codebase. Bitcoin Core versions prior to 0.7 could self-fork, even if running on identical hardware. Versions prior to BIP66 roll out could fork on 32-bit versus 64-bit machines.

    The bugs get fixed, and blockchain consensus marches on. I call Core the "reference implementation" and not "The One True Implementation" ....

    [–]gabridome 1ポイント2ポイント  (0子コメント)

    Could we say that there should be one consensus implementation behaviour of the code and that divergences should be fixed ASAP for an healthy bitcoin network?

    [–]jcnike -2ポイント-1ポイント  (0子コメント)

    I agree. Multiple implementations of Bitcoin is healthy for the ecosystem and protocol.

    [–]Demotruk -1ポイント0ポイント  (14子コメント)

    Is that true? In the case when a soft fork is in the process of happening for example, there are different implementations of the consensus rules. One is stricter than the other. But they are both involved in the network consensus mechanism.

    And I believe there are other ways in which the code could diverge but a network consensus still occurs at runtime.

    [–]maaku7Mark Friedenbach - Bitcoin Expert 2ポイント3ポイント  (13子コメント)

    I don't think it would be splitting hairs to say that those are different versions of the same implementation.

    [–]Demotruk 0ポイント1ポイント  (12子コメント)

    Do you believe it's not possible for the network to come to consensus on the longest valid chain with different implementations running on the network?

    The actual issue I was addressing in my comment was that with one project, whatever problems that project has get inherited by the network if those are the only clients they can choose to use. If there are multiple projects, users and miners have a choice. Bitcoin was designed so that the users can come to a consensus even if the developers in one project can't.

    [–]maaku7Mark Friedenbach - Bitcoin Expert 8ポイント9ポイント  (11子コメント)

    No it is not possible, generally speaking. Divergent consensus rules - which naturally happen in multiple implementations - guarantee a fork when the rule is finally triggered.

    Remember when Coinbase used to fork off the network every few months because they used bitcoin-ruby? That's what I'm talking about.

    [–]PotatoBadger 2ポイント3ポイント  (10子コメント)

    First time hearing about those forks, but I'm happy to take your word for it.

    Aren't those forks due to errors in translating the consensus portion of the original client? A full description of the consensus protocol could be written and reimplemented in any complete language, right? It would be challenging to perfectly describe every little quirk, but not impossible.

    [–]maaku7Mark Friedenbach - Bitcoin Expert 8ポイント9ポイント  (9子コメント)

    What happens when Bitcoin Core differs from the description of the consensus protocol?

    The key point here -- which is not obvious -- is that Nakamoto consensus relies on replicatable behaviour across an uncountable number of test cases. For every possible transaction or block there is a definitive, canonical answer for whether it is valid or not (non-deterministic behaviour like 0.7 notwithstanding). The only practical way to encode such a diversity of reference cases is essentially "the output of this X86 program run on any Intel/AMD compatible hardware." The consensus code is the standard. If there was an ISO Bitcoin standard, it would be an assembly dump of libconsensus with references to the Intel architecture manuals.

    It is not, practically speaking, possible to reimplement the consensus code in any other language, because of subtle differences in the behavior of different languages / runtimes. For a simple example, take BIP 42: the original bitcoin client diverged from just about every other implementation in that subsidy reverted to 50 btc after about 250 years. That happened to be a trivial to fix error since it wasn't triggerable until the 23rd century, but it does illustrate a point: Python, Ruby, and Haskell re-implementations of bitcoin copied that subsidy line exactly as it was written in Bitcoin Core, but because of differences in how integer shifting out of range is handled in C++ on Intel/AMD vs defined behaviour in these other languages, that same code compiled in a different language produced a different result.

    The consensus code is the specification.

    [–]PotatoBadger 2ポイント3ポイント  (7子コメント)

    Thanks for the reply!

    I'll admit that "challenging to perfectly describe" was an extreme understatement, but I'd like to think it's possible to describe and translate the consensus protocol. It would be a great exercise in discovering previously unknown quirks such as the one fixed on BIP 42.

    I would be happy to contribute to such an endeavor. The idea of relying on an imperfectly documented consensus library for Bitcoin is a bit unsettling to me.

    [–]shibamint 0ポイント1ポイント  (0子コメント)

    In the and of the day we still flicking switchs, connecting dots and hopping for interoperability ...

    [–]RazsterOxzine 4ポイント5ポイント  (0子コメント)

    Because certain people have investments else where on this site.

    [–]rain-is-wet 1ポイント2ポイント  (2子コメント)

    When the concept of sidechains was first announced this sub went absolutely bat-shit hysterical. Blockstream are hands down one of the most exciting things that has happened to bitcoin. They want bitcoin to succeed as they 100% rely on it to succeed. Duh. The whole blocksize thing is so outrageously overblown. It's a pure political shitfight. Forget it.

    Blockstream rules.

    XT rules.

    EVERYONE DEPLOYING COLD HARD CODE TO TRY AND IMPROVE THIS DOG GAMN SON-OF-A-BADGER RULES

    [–]Cocosoft 0ポイント1ポイント  (1子コメント)

    When the concept of sidechains was first announced this sub went absolutely bat-shit hysterical.

    This is not true at all. Everyone was really excited.
    When it settled down, obvious questions about Blockstreams intent and revenue appeared. People also questioned having core devs in a for-profit company.
    Later on when it became clear that pretty much all of Blockstream's devs (including bitcoin core devs) oppose Gavin's block increase suggestion, the shitstorm came.

    [–]rain-is-wet 0ポイント1ポイント  (0子コメント)

    This is not true at all. Except that yes it was true.

    When BitPay hired core dev Jeff Garzik sentiment was positive. BitPay even said that all major bitcoin companies should hire a core dev. Again, everyone seemed to think that was a great idea. Circle hired Mike Hearn for instance. Great. All bitcoin companies are 'for profit'. None of your points single out Blockstream for doing anything different than companies that were around before them.

    [–]hoffmabc -5ポイント-4ポイント  (0子コメント)

    It's like a policeman handing out ice cream while ignoring a bank robbery.

    [–]d4d5c4e5 -5ポイント-4ポイント  (0子コメント)

    Just because Blockstream happens to produce some good prototype ideas, does not mean that everyone should just roll over and let them control Bitcoin development.

    [–]seriouslytaken 2ポイント3ポイント  (12子コメント)

    Can anyone explain how the honeypot example could work?

    If an attacker found one key, on one sever, they wouldn't have enough information to spend or even know about the multisig prize money. I don't see how this could work as a honeypot.

    Your attacker demographic would also be limited to users who understand multisig raw transactions.

    [–]platypii 8ポイント9ポイント  (1子コメント)

    It's a hypothetical example, so you could also have a hypothetical wallet on there which contains everything the attacker needs to steal the coins. Eg. it would contain the redeem script + private key. So really the attacker is just stealing a wallet.dat and sweeping it.

    [–]GibbsSamplePlatter 3ポイント4ポイント  (0子コメント)

    With the key point that you can figure out machine got hacked.

    [–]kinoshitajona 2ポイント3ポイント  (5子コメント)

    1 of 10000

    The spending tx would reveal which key was compromised, and thus which system.

    [–]seriouslytaken 0ポイント1ポイント  (4子コメント)

    Except to spend from a multisig you need the redeem script. I would think attackers would easily see this as a honeypot.

    Why not just make a public bug bounty.

    [–]maaku7Mark Friedenbach - Bitcoin Expert 5ポイント6ポイント  (2子コメント)

    This trick lets you make the honeypot big enough that it is worth redeeming. Say, 20 bitcoins. Every single machine has full access to the same 20 bitcoins, but which redeem script is used will tell you machine was broken into. So long as 20 bitcoins is more than whatever value the hacker could obtain by quietly keeping the compromised machine, it works as an intrusion detector.

    [–]seriouslytaken -1ポイント0ポイント  (1子コメント)

    Except the redeem script tells you it's an N of M multisig, and your one key won't move those 20 BTC

    Unless you are saying you can use a "fake" redeem script to trick the attacker into thinking it's a 1 of 10,000 multisig

    Though, if I saw a 1 of large number, I'd think honeypot now.

    [–]maaku7Mark Friedenbach - Bitcoin Expert 0ポイント1ポイント  (0子コメント)

    The redeem script is not necessarily indicative that it is a N of M multisig; other policy options are possible. However that is not a relevant point.

    I'm not sure you understand what I was trying to say. It's OKAY if the attacker knows it is a honeypot. The point is that the pot is loaded up with enough bitcoins that the attacker doesn't care that it is a honeypot. They'd rather take the coins.

    Figure out (A) how much you would pay to know that the server was compromised, and (B) how much the attacker values access to your server. Usually A > B. So offer a bond of at least B as a honeypot on the server. Any attacker would rather take the coins, and you profit from knowing your infrastructure is compromised.

    [–]nullcGreg Maxwell - Bitcoin Expert 3ポイント4ポイント  (0子コメント)

    A public bounty for revealing you've compromised a system has no guarantee that it will be paid with Bitcoins instead of a police raid. It takes a leap of faith for the attacker and doesn't provide instant gratification that might overcome a preference to instead keep the host compromised.

    In any case, it's just an example of why a one-of-big might be used, and why accountability in multisig can be important-- in this case one-of-big is also a building block in making efficient K of N.

    [–]nullcGreg Maxwell - Bitcoin Expert 3ポイント4ポイント  (3子コメント)

    You'd simply leave a regular wallet on the system in a usual location. The wallet has the key imported (e.g. has the redeemscript).

    The redeemscript is logically part of your private key for a completely multisig keypair-- it's information required to sign for the public key.

    There is no requirement that this be used with raw transactions. The attacker would just see a wallet with coins in it, they could spend them. If they didn't look carefully they might not even notice they were multisiged. (Though the point of the idea isn't to fool the attacker: they'll usually know full well they are giving away their compromise-- but do so anyways because its more money now than just running a spambot on the host).

    [–]seriouslytaken 0ポイント1ポイント  (2子コメント)

    Ok, but smart attackers would see this as a possible trap

    [–]nullcGreg Maxwell - Bitcoin Expert 0ポイント1ポイント  (1子コメント)

    Sure, it's not perfect. It's basically a bounty for less sophisticated attackers to tell you about their compromise. Advanced persistent threat, state attackers, etc. will likely ignore it.

    The cool thing is that with a one-of-big multisig you can have a rather large bounty for a rather large operation at at not large price. So -- small benefit, small cost. (And if it never gets stolen the cost to you is just the volatility risk of holding the bitcoins)

    [–]seriouslytaken 0ポイント1ポイント  (0子コメント)

    Ok, how about other uses?

    I've been thinking that multisigs can be used for content delivery. As a way to release pubkey data upon spend, where those same keys represent valid licenses to a third party contract....and not actual pubkeys.

    [–]xbt_trader 2ポイント3ポイント  (0子コメント)

    I spoke to the blockstream guys recently, and everything they're working on really makes me excited about where bitcoin is heading!

    [–]platypii 14ポイント15ポイント  (0子コメント)

    Super cool! Keep the science coming.

    [–]Chytrik 13ポイント14ポイント  (0子コメント)

    Computer science at work! Nice work, devs

    [–]waxwing 5ポイント6ポイント  (3子コメント)

    Wow.

    Incidentally here you see another reason why Schnorr signatures are so great ... I recently read somewhere that the only reason ECDSA is the way it is, is because they couldn't use Schnorr due to a patent. So ECDSA is basically just a fudged Schnorr. Another win for intellectual property!

    (not sure where I read it, think it was probably something Adam Back said).

    [–]petertoddPeter Todd - Bitcoin Expert 7ポイント8ポイント  (0子コメント)

    FWIW the patent actually expired a bit prior to Bitcoin's release, but if course that wasn't enough time for a good implementation of schnorr to be developed. :(

    [–]GibbsSamplePlatter 2ポイント3ポイント  (1子コメント)

    That was mentioned in the talk as well!

    [–]waxwing 1ポイント2ポイント  (0子コメント)

    Oh, sorry. Guess I should watch it .. :)

    [–]luke-jrLuke Dashjr - Bitcoin Expert 2ポイント3ポイント  (1子コメント)

    Good to see this written up. :)

    [–]nullcGreg Maxwell - Bitcoin Expert 0ポイント1ポイント  (0子コメント)

    Yea, the proposal is over a year old now I think. But it's now implemented, which is really cool. We're gradually working through the backlog of inventions from before when people weren't working full time on this stuff.

    [–]Trstovall 4ポイント5ポイント  (2子コメント)

    I described something similar in a paper here, in section 7 subsection "opal/in".

    [–]maaku7Mark Friedenbach - Bitcoin Expert 3ポイント4ポイント  (1子コメント)

    I don't see any description of the mechanism... Do you have a write up of that?

    [–]Trstovall 0ポイント1ポイント  (0子コメント)

    Nothing more than what you see there. If you're interested, though, I could send you some code based on the crypto system described in the paper.

    [–]Dremords 3ポイント4ポイント  (0子コメント)

    Totally insane! I did not expect this but i am alays opened for improvements like this one!

    [–]GibbsSamplePlatter 2ポイント3ポイント  (0子コメント)

    Really excited for MAST.

    [–]lclc_ 5ポイント6ポイント  (5子コメント)

    But people in /r/Bitcoin said Blockstream is evil?

    I'm so confused, who should I trust now, the Blockstream developers that deliver awesome stuff all the time or /r/Bitcoin, known for it's deep knowledge on every subject ever existed, especially on block size

    Awesome work guys. I wish I could buy Blockstream shares.

    [–]SwagPokerz 7ポイント8ポイント  (0子コメント)

    I wish I could buy Blockstream shares.

    BTC is pretty close.

    [–]PotatoBadger 2ポイント3ポイント  (0子コメント)

    But people in /r/Bitcoin said Blockstream is evil?

    The most polar are usually the loudest. Please try not to participate in the division.

    [–]2ndEntropy -1ポイント0ポイント  (0子コメント)

    Being evil and developing technology aren't mutually exclusive and one does not preclude the other.

    [–]RocketLLs 1ポイント2ポイント  (0子コメント)

    programmable money will improve to the point of perfection. Nothing can beat it.

    [–]keatonatron 0ポイント1ポイント  (1子コメント)

    In the first example, shouldn't <R> be in the beginning stack (as in <sig> <key 10> <R> Z1 0 1 1 X6 1 K9 0), and remain there until it gets EQUALVERIFY'd?

    I just want to confirm that A) I'm not missing something, and B) it isn't a common thing to leave out of examples like this.

    [–]pwuillePieter Wuille - Bitcoin Expert 1ポイント2ポイント  (0子コメント)

    The first line in the table represents the resulting stack after executing the scriptSig. The scriptSig does not contain the root, only the public key used, the signature with it, and the branch connecting it to the root.

    All the following lines represent pieces of the scriptPubKey being executed, and the scriptPubKey is what contains the root being verified. This is similar to how a normal P2PKH scriptPubKey contains the pubkeyhash, or a P2SH script contains the script hash.

    [–]SwagPokerz 0ポイント1ポイント  (3子コメント)

    That’s over 9,000 times smaller than the equivalent in Bitcoin Script

    I see what you did there.

    [–]JOSEPH208 -5ポイント-4ポイント  (1子コメント)

    not better privacy IMO

    [–]nullcGreg Maxwell - Bitcoin Expert 4ポイント5ポイント  (0子コメント)

    Then you've failed to understand something; unfortunately you've provided nothing but your opinion-as-fact, so I don't know what explanation needs improvement!

    [–]anonymau5 -5ポイント-4ポイント  (0子コメント)

    That man in the thumbnail is most definitely on the juice.