Bitcoin Forum
September 24, 2020, 01:40:08 AM *
News: Latest Bitcoin Core release: 0.20.0 [Torrent]
 
  Home Help Search Login Register More  
  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 »
1  Economy / Speculation / Re: Gentlemen, buy your Bitcoins while you can still afford them. on: November 16, 2011, 09:11:04 PM
Bitcoin is potentially illegal by design.

To quote a certain alt-coin designer, "tough titties".
2  Bitcoin / Development & Technical Discussion / Re: OP_EVAL proposal on: November 08, 2011, 09:36:52 PM
I think you slightly misunderstand me here. I definitely can see multisigns being fairly user-transparent and friendly.

256+ "exotic" transaction types ? not so much. But I guess it is best to start discussing the issue when a lot of "exotic" stuff starts popping up.

As long as exotica goes to a separate addresstype and Auntie can keep sending coins the old way, oblivious to the "pro stuff", I am okay.
3  Bitcoin / Development & Technical Discussion / Re: OP_EVAL proposal on: November 07, 2011, 10:18:56 PM
Well, Gavin explained in #bitcoin-dev that the plan is actually to have two addresstypes, one for "vanilla" old-timer transactions, and another as catch-all for "advanced" OP_EVAL stuff, which is something I am quite fine with.

Now, the transaction type pluralism is mildly disturbing. People manage to terribly screw up (and whine) with just one transaction type exposed to them and supported on all client soft, I can only imagine the magnitude of chaos when there is a whole load of divergent transaction types with affinity to a particular type of wallet software.

Good thing BTC is not a corporation. We'd have to hire entire India and most of Ukraine for tech support Cheesy
4  Bitcoin / Development & Technical Discussion / Re: OP_EVAL proposal on: November 07, 2011, 08:16:20 PM
I'd still prefer "new and brave" transactions to use a different address format though.

Then every merchant will have to update clients whenever users want to use a new transaction type. With OP_EVAL, a merchant could keep running the same version for years (assuming there are no bugs) and still send transactions using the latest scripts.

Pardon if I am being slow, but does OP_EVAL allow for crafting new and wonderful transaction type through RPC ?

I thought that every new exotic transaction implemented by this way will still require one to implement it in the code and compile...

It also improves decentralization, since there will be no need to coordinate assignment of address version numbers. (And there are only 256 address version numbers to assign -- too few to cover all scripts.)

Quite frankly, the implications of having more than 10 (let alone more than 256) distinct transaction types, each with unique "quirks" in operation, are disturbing.

The GUI will end up being like a fighter jet cockpit, for one.

I'd still like to have at least two distinct address forms, one for "simpleton" transactions (like what we have now), another for everything else, just to make demarcation between "basic" functionality and "advanced user features" more explicit. Because you know, people have trouble grokking Paypal interface (and bitcoin GUI), and having them away from getting involved with complicated 5-party signing schemes until they really know what they are doing would be wise.
 
People who request an OP_EVAL transaction will know exactly how many extra bytes it will take to redeem the transaction. They shouldn't be surprised by fees.

With all due respect, you overestimate the average user.
5  Bitcoin / Development & Technical Discussion / Re: OP_EVAL proposal on: November 07, 2011, 06:57:09 PM
Ah, now IC the rational core of the concern, no need to bother theymos Smiley

However... How does the receiver get to know what his fees will be like ?

Let's say I want you to send me an escrow-OP_EVAL transaction. I want you to send, like... oh, 5 BTC.

It would be very unkosher if there would be no way for me to know in advance what fee to expect "on my end" after the escrow authority signs stuff (oh noes, it ated 3 BTC out of 5!  Cheesy )

I expect it'll be dependent on the size of the transaction needed to use the OP_EVAL output. That has to be known in advance, otherwise you can't create a spendable OP_EVAL output. Of course, the actual fees will depend on the democratic (well, more or less) decisions from the miners.

Well, as long as it essentially ends up being dependent on something deterministic - like "output"'s size, it should be fine.

I'd still prefer "new and brave" transactions to use a different address format though.
6  Bitcoin / Development & Technical Discussion / Re: OP_EVAL proposal on: November 07, 2011, 12:52:01 PM

Actually, I am quite disturbed with implications of shifting the burden of fees to the receiver (as transaction fees are at least partially dependent on conditions that only the sender is exposed to, such as for instance whether the sender's balance is made up of a bajillion of tiny 0.5 BTC inputs)

I'll PM theymos so that he can convince me without turning this topic into a rehash of something he might have already discussed and explained in detail

With OP_EVAL, the fees for inputs will stay with the sender, while the fees for the output are moved to the receiver (who'll pay them when he uses them as inputs). So what OP_EVAL does is make everyone responsible for their own stuff.

Ah, now IC the rational core of the concern, no need to bother theymos Smiley

However... How does the receiver get to know what his fees will be like ?

Let's say I want you to send me an escrow-OP_EVAL transaction. I want you to send, like... oh, 5 BTC.

It would be very unkosher if there would be no way for me to know in advance what fee to expect "on my end" after the escrow authority signs stuff (oh noes, it ated 3 BTC out of 5!  Cheesy )
7  Bitcoin / Development & Technical Discussion / Re: OP_EVAL proposal on: November 07, 2011, 12:35:38 PM
    This addresses theymos' concern that senders shouldn't be burdened with extra fees from longer scriptPubKeys. Instead, for more complex transactions, the scriptSig is longer which means that the owner of the address bears the cost of potentially increased fees.[/li][/list]

    Actually, I am quite disturbed with implications of shifting the burden of fees to the receiver (as transaction fees are at least partially dependent on conditions that only the sender is exposed to, such as for instance whether the sender's balance is made up of a bajillion of tiny 0.5 BTC inputs)

    I'll PM theymos so that he can convince me without turning this topic into a rehash of something he might have already discussed and explained in detail


    Addresses for arbitraritly complex transactions are fixed forever. No more new address types need be introduced.

    In my very humble opinion, giving "new and exciting" types of BTC transactions a different address type (either as "catch-all" for all innovative transactions or have a separate address type for each "officially supported" new transaction type,) to avoid confusion and help people grok new and fairly complicated functionality more easily.

    Methinks that different addresses for exotic transactions will actually increase usability, especially for "the kind of person" who only lives in GUI and won't touch the  user manual Smiley unless ABSOLUTELY necessary
    8  Alternate cryptocurrencies / Altcoin Discussion / Re: What do alt coin developers think about BIP 11/12/13 ? on: November 07, 2011, 12:31:39 PM
    First and foremost, I'd like to say that I like multisign on general principle and invite people to try out various ways of doing it on GG (it allows nonstandard by default).

    However, I doubt that multisign in its most classical "(n+1) escrow" scenario is just as useful as it is usually portrayed to be, and I am convinced that lack of it is not a massive barrier to adoption.

    As for op-eval specifically, I am quite worried about moving the fee burden to the receiving end of the transaction, as it seems to me that it would make the "unpredictable transaction fee" blight worse, but I think I'd best discuss this with Theymos - he's quite a smart guy, so it is possible that he is right, shifting fees to receiver is awesome, and he will convince me to that effect.


    Multisign sounds like a huge benefit. As far as I'm aware every company that does Internet banking currently needs 2 signatures to transfer money. One from the finance guy who actually works out what to send to who and one from management who should verify the finance guy isn't transferring the money to his personal account.

    It seems to me that since any reasonable company with more than one man involved Smiley and a wallet teeming with hundreds of thousands of bitcoinses would have the machine the wallet resides on pretty buttoned up and gapped, so the rules regarding necessity for multiparty approval of transactions can be enforced on the level of "walletbox" authentication (with possible reasonabl-ish requirement of at least one decision maker to be physically present at the walletbox office if the sum is really huge)

    So lack of multisign is hardly an adoption boundary (besides, AFAIK, painpal, libreserve, pecunix et al don't explicitly allow multiparty confirmation as well, and that does not seem to hamper their adoption all that much).

    If anything, finding a way to split private keys in a manner that several different devices would have to cooperate to create a "normal" BTC transaction would be closer to what a corporate "multiparty validation" entails.

    Lower trust escrow and "wallet lockdown" services are kind of neat, but not "we need it NOW or else" kind of neat.

    P.S.:
    It would be also neat to have a separate address format (different addressversions or perhaps even a new-ish address format specially for "exotic" stuff).

    It would be also neat to have frugal (as in, puts only a little bit of info into the blockchain) transaction earmarking as well as intra-network messaging (incidentally, those are two things I hope to eventually implement in Tenebrix since they are needed for a website-less laundryStrong Transaction Decorrelator system)

    P.P.S.: Personally, I love Gavin's Hidden Send, but sadly this type of custom transaction has turned out to be DOA. I would really love to see it (or a functional equivalent) to "come back", maybe with some nifty improvements (a man can dream right? Wink ) but that would likely require a large (and dangerous) scripting language overhaul...
    9  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANNOUNCE] Tenebrix, a CPU-friendly, GPU-hostile cryptocurrency on: November 07, 2011, 12:30:41 PM
    Where did lolcust go?  Not seen a post in some time?

    I am quite alive and messing around with things (some TBX related, some plain IRL related).
    10  Other / Archival / Re: EDITED TITLED: Solidcoin 2.0 GPU CUDA Nvidia Miner by MaGNET in Alpha Test on: October 24, 2011, 09:31:10 PM
    Perhaps evil, evil BTCEx could hack the workstation with the magical miner code Wink ?
    11  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANN] Tenebrix Faucet on: October 24, 2011, 09:30:18 PM
    When does the loundry service go up?

    TeneBrix are now very low at exchange so I started picking up a bunch today, again Smiley
    It's a nice coin to trade, already trippeled just by selling / buying last week.

    Currently, there are a few things that need to be implemented first, specifically coin burning and sidechannel comms (which, hilariously enough, will be useful for things other than laundry, especially as long as long as coin is cheap)
    12  Other / Archival / Re: delete on: October 23, 2011, 10:47:39 AM
    Next Big Hobby:
    Cryptothingie necromancy
    13  Alternate cryptocurrencies / Altcoin Discussion / Re: [ANN] Tenebrix Faucet on: October 23, 2011, 07:31:32 AM
    Moving site to new host, please stand by
    14  Alternate cryptocurrencies / Altcoin Discussion / Re: Who is a Coinhunter Sockpuppet? on: October 22, 2011, 04:11:02 PM
    I am Satoshi and this is my favorite thread on bitcointalk forum
    15  Other / Archival / Re: delete on: October 21, 2011, 08:24:08 PM
    So as I originally stated I think the most PROBABLE scenario is that we continue to have exponential growth for near term.  Any economic model should be based on the most probable scenario don't the collapse of civilization as we know it.

    So my assumptions about your beliefs are wrong but the reality is even worse... you are only planning on the now and current and not something viable for hundreds of years and hopefully longer....  I don't let the short term now greed and impulse factor cloud my judgement that the world needs something better that will last well beyond my lifetime.  Making a buck now is great but giving something that gives my great great grand children a better chance at a good economic future and freedom is far greater.

    With all due respect, planning thirty years ahead is problematic to the point of intractability.

    Planning for hundreds of years ahead borders on  delusional - consider the world of 1911, and you will realize that our not so ancient past is more alien to us that most "alien civilizations" contrived by science-fiction authors (even good authors), and this process is accelerating.

    It is not unlikely that our grandchildren will be almost incapable of relating to us and our concerns due to changes in lifestyle and psychology (the inverse will also be true)
    16  Bitcoin / Pools / Re: BTCGuild and it's relation to DDoS attackers on: October 21, 2011, 07:37:48 PM
    Replied in the relevant thread, but one question though - do solidcoin (and hypothetical bot-buddeh) estimations account for behaviors associated with pig blocks trusted nodes ?

    Anyway, methinks it would be best to wait and see, just gotta not to forget to check SC2 hashrate if / when next DDoS spree happens...
    17  Alternate cryptocurrencies / Altcoin Discussion / Re: SC2 Diff drop related to the recent attacks on Bitcoin pools? on: October 21, 2011, 06:19:03 PM
    That would require working on custom miner code (or some very contrived workaround), which in case of SC2 would mean either reverse engineering or convincing CH to provide source.
    18  Alternate cryptocurrencies / Altcoin Discussion / Re: SC2 Diff drop related to the recent attacks on Bitcoin pools? on: October 21, 2011, 06:08:17 PM
    oh cmon u virgin pie fekr.... cmon lolcust.... I give u the most credit out of the arse-sputum that is the dregs of the bitcoin pool as you actually seemed to create a CPU chain... once you were given the idea that is..... cmon tough guy speak up an leave your german slurs at the door eh?

    why is it that someone should invest in a "hackers" play-thing.... also.... how goes the experiment? you were meant to report back to the bitcoin core on your findings.... well? share!

    Errrr... are you having a stroke ? Please seek medical attention Cheesy
    19  Alternate cryptocurrencies / Altcoin Discussion / Re: SC2 Diff drop related to the recent attacks on Bitcoin pools? on: October 21, 2011, 05:02:58 PM
    Or maybe it just changed its embarrassing miner id Wink...
    20  Alternate cryptocurrencies / Altcoin Discussion / Re: SC2 Diff drop related to the recent attacks on Bitcoin pools? on: October 21, 2011, 04:52:20 PM
    More like coinspiracy  Cheesy
    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 »
    Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!