Bitcoin Forum
December 03, 2016, 10:08:44 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   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 »  All
  Print  
Author Topic: Ultimate blockchain compression w/ trust-free lite nodes  (Read 68525 times)
aaaxn
Full Member
***
Offline Offline

Activity: 126


View Profile
May 26, 2013, 08:15:42 PM
 #321

What doesn't make sense?  Outputs and scripts is how bitcoin works.
Well it is how bitcoin works, but if you consider making major changes anyway (I was referring to jtimon post) I think this should be changed too because it is not optimal system architecture.
1480802924
Hero Member
*
Offline Offline

Posts: 1480802924

View Profile Personal Message (Offline)

Ignore
1480802924
Reply with quote  #2

1480802924
Report to moderator
1480802924
Hero Member
*
Offline Offline

Posts: 1480802924

View Profile Personal Message (Offline)

Ignore
1480802924
Reply with quote  #2

1480802924
Report to moderator
1480802924
Hero Member
*
Offline Offline

Posts: 1480802924

View Profile Personal Message (Offline)

Ignore
1480802924
Reply with quote  #2

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

Posts: 1480802924

View Profile Personal Message (Offline)

Ignore
1480802924
Reply with quote  #2

1480802924
Report to moderator
LvM
Full Member
***
Offline Offline

Activity: 126


View Profile
May 26, 2013, 09:17:23 PM
 #322



I think its important that everybody understand this and I didn't see anyone explaining it in general terms.

The Blockchain is a distributed computer file system containing a double entry accounting ledger. Each transaction has two sides which you may be familiar with from accounting: input and output OR debits and credits. However, a major difference is that bitcoin forces a debit(input) to exist for every credit(output).  Storing all of this takes a lot of space. extra explaination

This proposal will continously "balance the books." In accounting, when you close out the books for the quarter all of the debits and credits are summed, and the difference between the two is entered as a "balance" transaction. Because we know that bitcoin forces every credit(output) to have a debit(input), we only have to keep track of all credits(outputs) that are not claimed by a debit(input) to obtain the balance of each address.

The proposal is for a system to store the references to these unspent outputs in a data structure for quick downloading. It doesn't suggest how this tree would be updated efficiently, or how you would quickly grab all of the unspent outputs belonging to one address. This is under discussion.

@galambo
Yes. Its really important that everybody understands what you write about accounting!

But the Bitcoiners don't know anything about accounting, nothing about the balance of money payed and received. So they ignored from the very beginning all basic GAAP obstinately.

Instead all is filled with and buried behind the jargon and lingo of cryptologists, i.e. logically secondary questions.

They don't even know how to manage the Size of the ever growing BTC blockchain in the future  
https://bitcointalk.org/index.php?topic=109467.0;all

Quote
In accounting, when you close out the books for the quarter all of the debits and credits are summed, and the difference between the two is entered as a "balance" transaction.

Correct! That's also called "carry-over".

Carry-overs need just ONE entry to transfer the last balance of each account into a new database,
leaving all previous (thousands or millions!) transactions in an "archiv"
(where there can easily be found if really needed - normally almost never again).

Normally this year-end closing and "carry-overs" are done annually (and legally prescribed).

In BTC this could be done more often, i.e. always if there are "too many" transactions in the database making it too large for effective usage by clients.

Using this everywhere quite normal way of bookkeeping the actual "blockchain" could easily be kept small and handy and would not be bloated ad infinitum.

Impossible, complete nonsens, to keep all transfers over say 5, 10, 100, 200... years in ONE always transferred and read database.
But I see in BTC nowhere any usable solution for this from the very inception foreseeable issue.

For a correct and efficient GAAP-conform accounting only the (slightly changed) transaction records are needed
Details decribed here: https://bitcointalk.org/index.php?topic=211835

"Blocks"

Another, but smaller problem are the "blocks" and their "miners" wanting more and more undefined amounts of money also for transactions.

First designed to produce new BTC the creation of blocks indeed is thought to continue ad infinitum!! Even if all 21 Mio BTC are created.
Might be due to the present but in the long run totally unusable database structure,
not easy but unavoidable to change!!

BTC violates GAAP, result a MESS  https://bitcointalk.org/index.php?topic=211835.0
Anforderungen an eine PROFESSIONELLE BTC-Anwendung https://bitcointalk.org/index.php?topic=189669
BANKGEHEIMNIS mit BTC gleich NULL!? https://bitcointalk.org/index.php?topic=188383 Antwort: Ja, wenn man nicht höllisch aufpaßt.
LvM
Full Member
***
Offline Offline

Activity: 126


View Profile
May 26, 2013, 09:21:57 PM
 #323

@Jtimon, aaan

Ripple indeed seems (at least as they describe it) to be MUCH better structured than BTC.
Could be taken as model or prototype for a new BTC!!

Like any other accounting system Ripple also does not need and have these "blocks" and their "miners".
They instead produced all their 100 billion Ripples aka XRP in advance and kept them for themselves.

"The Ripple founders created the initial Ripple ledger with 100 billion XRP. The founders gifted a for profit company called Opencoin 80 billion XRP. Opencoin intends to give away over 50 billion XRP. The remainder will be used to fund Opencoin operations, which include contributing code to the open source network and promoting the network."

https://ripple.com/wiki/Introduction_to_Ripple_for_Bitcoiners

But that's also just another reason why I do not really trust the Ripplers in the moment.
See also glitch003: https://bitcointalk.org/index.php?topic=179677.0;all

BTC violates GAAP, result a MESS  https://bitcointalk.org/index.php?topic=211835.0
Anforderungen an eine PROFESSIONELLE BTC-Anwendung https://bitcointalk.org/index.php?topic=189669
BANKGEHEIMNIS mit BTC gleich NULL!? https://bitcointalk.org/index.php?topic=188383 Antwort: Ja, wenn man nicht höllisch aufpaßt.
LvM
Full Member
***
Offline Offline

Activity: 126


View Profile
May 26, 2013, 09:26:07 PM
 #324

So we cannot but hope, that BTC will very soon be improved basically.

As BTC newbie having still enormous problems to understand the really weird details I cannot help to rewrite the code, sorry.

But an expert like Etotheipi (author of Armory, the best BTC client at all) certainly could do it almost alone
(instead of wasting his precious time with his proposed workarounds for clients only).

The main problem for experts seems IMHO not the code, but the "community",
esp. "markets" like MtGox etc. and services like blockchain.info, blockexplorer.com... having to readjust their codes accordingly.

But the new GAAP-conform code would be much shorter and clearer than the present one, a clumsy mess already at the lowest level.

BTC violates GAAP, result a MESS  https://bitcointalk.org/index.php?topic=211835.0
Anforderungen an eine PROFESSIONELLE BTC-Anwendung https://bitcointalk.org/index.php?topic=189669
BANKGEHEIMNIS mit BTC gleich NULL!? https://bitcointalk.org/index.php?topic=188383 Antwort: Ja, wenn man nicht höllisch aufpaßt.
maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
May 26, 2013, 10:13:39 PM
 #325

LvM, I suggest you reread this proposal and contemplate it's structure. It is much closer to what you are proposing than I think you understand it to be. I suggest you also look into why bitcoin is structured the way it is (addresses != accounts), as there are good reasons for that too. Then I suggest that you make another thread detailing your proposal, as we are wandering significantly off topic.

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
LvM
Full Member
***
Offline Offline

Activity: 126


View Profile
May 27, 2013, 12:47:45 AM
 #326

LvM, I suggest you reread this proposal and contemplate it's structure. It is much closer to what you are proposing than I think you understand it to be. I suggest you also look into why bitcoin is structured the way it is (addresses != accounts), as there are good reasons for that too. Then I suggest that you make another thread detailing your proposal, as we are wandering significantly off topic.

@maaku

You did not even try to understand what I wrote?
The fact that BTC has no GAAP conform accounts is exactly the problem I mean and explained.

But do what you like or better:
do what you have todo after collecting thanks mainly @evoorhees >156 BTC for the first 3 months of your adventurous efforts.
Around 15.000,00 USD. Bravo!

https://bitcointalk.org/index.php?topic=204283.0;all
http://blockexplorer.com/address/13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP

BTC violates GAAP, result a MESS  https://bitcointalk.org/index.php?topic=211835.0
Anforderungen an eine PROFESSIONELLE BTC-Anwendung https://bitcointalk.org/index.php?topic=189669
BANKGEHEIMNIS mit BTC gleich NULL!? https://bitcointalk.org/index.php?topic=188383 Antwort: Ja, wenn man nicht höllisch aufpaßt.
LvM
Full Member
***
Offline Offline

Activity: 126


View Profile
May 27, 2013, 12:52:15 AM
 #327

@maaku

Will be very interesting if the result of your efforts is more than just a workaround, making things even more confusing,
not really solving the underlying fundamental problems I gratis Cheesy explained solely from the financial point of view.

As normal in those superficially solved workaround and muddle through cases the same or equal problems will arise.

I made this experience again and again with my own code.
So this could become a lifetime job for you!
Congratulations! Cheesy

BTC violates GAAP, result a MESS  https://bitcointalk.org/index.php?topic=211835.0
Anforderungen an eine PROFESSIONELLE BTC-Anwendung https://bitcointalk.org/index.php?topic=189669
BANKGEHEIMNIS mit BTC gleich NULL!? https://bitcointalk.org/index.php?topic=188383 Antwort: Ja, wenn man nicht höllisch aufpaßt.
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
May 27, 2013, 12:58:59 AM
 #328

Bitcoin at its core is not an accounting system, it is a currency. It implements this through its own ledger-like mechanism, though one that doesn't quite exactly match what we expect from a ledger. And I believe that doesn't matter.

Accounting is something you do at the "payment level", not at the "currency level". Dollars have no built-in way to track historical balances, and I don't think anyone considers that a shortcoming. We can keep track of credits and debits regardless.

I'm sure that with all developments at the wallet software (multiple clients, payment protocol, ...), it's perfectly possible to create a GAAP-conformant system, or at least one that easily integrates with accounting systems.

I don't think discussion about that belongs in this thread though - this is about solving a low-level scalability problem, not about how we manage high-level use of it.

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
Sukrim
Legendary
*
Offline Offline

Activity: 1848


View Profile
May 27, 2013, 07:57:56 AM
 #329

Also the "accounting solution" only helps as long as there are transactions like "1..n inputs pay to 1..n outputs". Bitcoin can have vastly more complex standard transactions and even more complex nonstandard transactions.

If you want to have a good accounting system, please start by improving ABE (the alternative block explorer) to actually even handle all currently existing transactions on the block chain and assign an account to each of them. Good luck with that.

https://bitfinex.com <-- leveraged trading of BTCUSD, LTCUSD and LTCBTC (long and short) - 10% discount on fees for the first 30 days with this refcode: x5K9YtL3Zb
Mail me at Bitmessage: BM-BbiHiVv5qh858ULsyRDtpRrG9WjXN3xf
aaaxn
Full Member
***
Offline Offline

Activity: 126


View Profile
May 27, 2013, 09:51:43 AM
 #330

Also the "accounting solution" only helps as long as there are transactions like "1..n inputs pay to 1..n outputs". Bitcoin can have vastly more complex standard transactions and even more complex nonstandard transactions.

If you want to have a good accounting system, please start by improving ABE (the alternative block explorer) to actually even handle all currently existing transactions on the block chain and assign an account to each of them. Good luck with that.
Yes, bitcoin can have a lot of complex transactions which falls in 2 categories (not exclusively):
- things that are needed by 0.00001% of users
- things that must be blocked because it would bloat blockchain too much
LvM
Full Member
***
Offline Offline

Activity: 126


View Profile
May 27, 2013, 10:26:34 PM
 #331

Bitcoin at its core is not an accounting system, it is a currency. It implements this through its own ledger-like mechanism, though one that doesn't quite exactly match what we expect from a ledger. And I believe that doesn't matter.

Accounting is something you do at the "payment level", not at the "currency level". Dollars have no built-in way to track historical balances, and I don't think anyone considers that a shortcoming. We can keep track of credits and debits regardless.

I'm sure that with all developments at the wallet software (multiple clients, payment protocol, ...), it's perfectly possible to create a GAAP-conformant system, or at least one that easily integrates with accounting systems.

I don't think discussion about that belongs in this thread though - this is about solving a low-level scalability problem, not about how we manage high-level use of it.

@Pieter Wuille

I would rather say, that "accounting systems" and "currencies" are completely different things.
They cannot be compared or treated/used somehow alternatively as you insinuate.

Accounting is for all currencies including BTC exactly the same!
For details see GAAP, not even mentioned once in the whole wiki.

https://en.bitcoin.it/w/index.php?search=GAAP&button=&title=Special%3ASearch

In BTC its really easy.
We have to deal only with a very tiny and very easy partition of GAAP,
i.e the logically really quite simple payment system only.

A ==>> B, B ==> C etc.

But basics forgotten, totally ignored at lowest levels can hardly be repaired on higher levels, here the level of users/clients.
Going that way the self inflicted basic problems are perpetuated and increased, see the endless exploding blockchain (which easily could have been avoided by carry-overs not even thought about, see GAAP).

So I can't help but hope and insist that all efforts are concentrated and invested in the BTC level itself and not wasted in workarounds installing a complicated parallel system for things that should and could much easier be done on the lower level.

Muck out all stuff and bestow BTC itself (not the clients) with a small and professionel, fast working payment system, simply and quickly usable by each client and THEIR accounting/bookkeeping systems !!

Brevity is the soul of wit. Cheesy
The more code and stuff the worse.

Small is beautiful !! Cheesy

BTC violates GAAP, result a MESS  https://bitcointalk.org/index.php?topic=211835.0
Anforderungen an eine PROFESSIONELLE BTC-Anwendung https://bitcointalk.org/index.php?topic=189669
BANKGEHEIMNIS mit BTC gleich NULL!? https://bitcointalk.org/index.php?topic=188383 Antwort: Ja, wenn man nicht höllisch aufpaßt.
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
May 27, 2013, 10:38:13 PM
 #332

I completely disagree.

Yes, Bitcoin is exactly the same as other currencies in this respect. But we don't track serial numbers of dollar bills we get, do we? So why would we do accounting based on the currency?

Bitcoin transactions are only low-level and potentially complex movement of coins. For accounting, you don't care about individual coins. A real-world payment may be settled by several Bitcoin transactions, or a single Bitcoin transaction may be used to fullfill several payments. But nobody needs to care about this.

You don't care how transactions between business identities are settled. You don't care which coins or dollar bills are used, only between which entities they move. Stop seeing Bitcoin as a ledger - even though many wallet clients show it as such - it is not a ledger of "payments", but of "coin movements".


aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
aaaxn
Full Member
***
Offline Offline

Activity: 126


View Profile
May 27, 2013, 11:04:48 PM
 #333

I completely disagree.

Yes, Bitcoin is exactly the same as other currencies in this respect. But we don't track serial numbers of dollar bills we get, do we? So why would we do accounting based on the currency?
Gold coin doesn't need serial number, does it?

Bitcoin transactions are only low-level and potentially complex movement of coins. For accounting, you don't care about individual coins. A real-world payment may be settled by several Bitcoin transactions, or a single Bitcoin transaction may be used to fullfill several payments. But nobody needs to care about this.

You don't care how transactions between business identities are settled. You don't care which coins or dollar bills are used, only between which entities they move. Stop seeing Bitcoin as a ledger - even though many wallet clients show it as such - it is not a ledger of "payments", but of "coin movements".
So why exactly simulate things that nobody cares about?
maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
May 28, 2013, 03:02:04 AM
 #334

Bitcoin transactions are only low-level and potentially complex movement of coins. For accounting, you don't care about individual coins. A real-world payment may be settled by several Bitcoin transactions, or a single Bitcoin transaction may be used to fullfill several payments. But nobody needs to care about this.

You don't care how transactions between business identities are settled. You don't care which coins or dollar bills are used, only between which entities they move. Stop seeing Bitcoin as a ledger - even though many wallet clients show it as such - it is not a ledger of "payments", but of "coin movements".
So why exactly simulate things that nobody cares about?

That may be a valid discussion to have. But it's best done elsewhere: we are now very off topic.

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
LvM
Full Member
***
Offline Offline

Activity: 126


View Profile
May 28, 2013, 11:38:53 AM
 #335

@maaku: We are not "off topic" at all.
Proposed workarounds are the place to discuss the reasons for their (wrongly assumed) necessity.

BTC violates GAAP, result a MESS  https://bitcointalk.org/index.php?topic=211835.0
Anforderungen an eine PROFESSIONELLE BTC-Anwendung https://bitcointalk.org/index.php?topic=189669
BANKGEHEIMNIS mit BTC gleich NULL!? https://bitcointalk.org/index.php?topic=188383 Antwort: Ja, wenn man nicht höllisch aufpaßt.
LvM
Full Member
***
Offline Offline

Activity: 126


View Profile
May 28, 2013, 11:43:37 AM
 #336

And yes,
I know that some BTC "Heroes" won't even hear evident, irrebuttable facts based on pure logic and thousand year old GAAP.

Its hard to concede we were sailing on the wrong ship all the time, isn't it.

BTC violates GAAP, result a MESS  https://bitcointalk.org/index.php?topic=211835.0
Anforderungen an eine PROFESSIONELLE BTC-Anwendung https://bitcointalk.org/index.php?topic=189669
BANKGEHEIMNIS mit BTC gleich NULL!? https://bitcointalk.org/index.php?topic=188383 Antwort: Ja, wenn man nicht höllisch aufpaßt.
aaaxn
Full Member
***
Offline Offline

Activity: 126


View Profile
May 28, 2013, 11:48:13 AM
 #337

And yes,
I know that some BTC "Heroes" won't even hear evident, irrebuttable facts based on pure logic and thousand year old GAAP.

Its hard to concede we were sailing on the wrong ship all the time, isn't it.

I think it is pointless trying to convince fellow bitcoiners that their baby is poorly designed. Maybe you should support one of alt coins which plans to do exactly as you say?

https://bitcointalk.org/index.php?topic=195275.0
or
https://bitcointalk.org/index.php?topic=169204.0
LvM
Full Member
***
Offline Offline

Activity: 126


View Profile
May 28, 2013, 12:09:40 PM
 #338

And yes,
I know that some BTC "Heroes" won't even hear evident, irrebuttable facts based on pure logic and thousand year old GAAP.

Its hard to concede we were sailing on the wrong ship all the time, isn't it.

I think it is pointless trying to convince fellow bitcoiners that their baby is poorly designed. Maybe you should support one of alt coins which plans to do exactly as you say?

https://bitcointalk.org/index.php?topic=195275.0
or
https://bitcointalk.org/index.php?topic=169204.0

@aaaxn
Thank you! Will check it when my time allows.

BTC violates GAAP, result a MESS  https://bitcointalk.org/index.php?topic=211835.0
Anforderungen an eine PROFESSIONELLE BTC-Anwendung https://bitcointalk.org/index.php?topic=189669
BANKGEHEIMNIS mit BTC gleich NULL!? https://bitcointalk.org/index.php?topic=188383 Antwort: Ja, wenn man nicht höllisch aufpaßt.
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
May 30, 2013, 09:54:06 PM
 #339

While still talking about the ledger vs UTXO, I'll try to stay close to the context of this proposal, maybe the ones that prefer a ledger can be statisfied with little changes.
Let's try.
Let's look, for example, at this transaction: http://cryptocoinexplorer.com:4750/tx/8b1afc9aa2ca96c846dce3a47d577068e5f722961eff036b5792756eef28e2a0
The full public key of 18dTnNqj396jL9U98RHYEyJX2TSw6Ku7Gd and the signature is repeated in this transaction, isn't it?
We can modify the UTXO dictionary to avoid this redundancy.

The UTXO dictionary stores (scriptPubKey, balance)

But if he stored a ledger (address/scriptPubKey, balance), you would only need to sign once for 18dTnNqj396jL9U98RHYEyJX2TSw6Ku7Gd in the tx above.
Note that I'm considering an UTXO enforced by the chain and not an altchain.
The "default script" of just showing the public key

Code:
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

Could be assumed and ommitted, replaced by this:

Code:
scriptPubKey: <pubKeyHash>
scriptSig: <sig> <pubKey>

But then you would need to indicate explicitly how much you want to spend from the address in the input.
The transaction above would not have had to reference each input individually, it would only have included the address, an amount to substract, the public key and signature. Well, and the sequence number or equivalent for that address. I prefer a hash of the last transaction spending from that address. Otherwise you need to remember empty addresses ast sequence numbers forever.

Basically, this (paying to an address substracting from another address) would be the general case and the "pay to script" or contract, would be the special case. I think Ripple must do something like this for their ledger and their contract scripts.

Does this make technical sense before we start discussing whether a currency is in itself an accounting system and other philosophical matters?

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
May 30, 2013, 10:07:08 PM
 #340

While still talking about the ledger vs UTXO, I'll try to stay close to the context of this proposal, maybe the ones that prefer a ledger can be statisfied with little changes.
Let's try.
Let's look, for example, at this transaction: http://cryptocoinexplorer.com:4750/tx/8b1afc9aa2ca96c846dce3a47d577068e5f722961eff036b5792756eef28e2a0
The full public key of 18dTnNqj396jL9U98RHYEyJX2TSw6Ku7Gd and the signature is repeated in this transaction, isn't it?
We can modify the UTXO dictionary to avoid this redundancy.

The UTXO dictionary stores (scriptPubKey, balance)

But if he stored a ledger (address/scriptPubKey, balance), you would only need to sign once for 18dTnNqj396jL9U98RHYEyJX2TSw6Ku7Gd in the tx above.
Note that I'm considering an UTXO enforced by the chain and not an altchain.
The "default script" of just showing the public key

Code:
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

Could be assumed and ommitted, replaced by this:

Code:
scriptPubKey: <pubKeyHash>
scriptSig: <sig> <pubKey>

But then you would need to indicate explicitly how much you want to spend from the address in the input.
The transaction above would not have had to reference each input individually, it would only have included the address, an amount to substract, the public key and signature. Well, and the sequence number or equivalent for that address. I prefer a hash of the last transaction spending from that address. Otherwise you need to remember empty addresses ast sequence numbers forever.

Basically, this (paying to an address substracting from another address) would be the general case and the "pay to script" or contract, would be the special case. I think Ripple must do something like this for their ledger and their contract scripts.

Does this make technical sense before we start discussing whether a currency is in itself an accounting system and other philosophical matters?

I was a little conflicted on this topic.  I see the "elegance" of just using raw scripts.  But I didn't like the idea that multiple forms of the same "effective" address required separate lookups.  For instance, the same address can be used in the "DUP HASH160 <Addr160> EQUAL CHECKSIG" as well as "<PubKey> CHECKSIG".  And maybe "<message> DROP <pubKey> CHECKSIG".  Or "<message> DROP DUP HASH <Addr160> EQUAL CHECKSIG".  In fact, I don't even have a good way to go search for those message scripts unless I know the message in advance.  It would require a good old-fashioned full-UTXO-set-search, which was something we were hoping to avoid with this whole discussion.

But it's also not feasible to capture all script types that are single-sig spendable.  Adding new "standard" script type representations to the UTXO tree later will require a hard-fork.  Perhaps this is a reason not to have things like "<message> OP_DROP", or it's a reason to be more intelligent about how we represent scripts in this tree.  This is why I was conflicted...

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 [17] 18 19 20 21 22 »  All
  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!