 Show Posts
|
|
Pages: « 1 2 3 4 [5]
|
Sorry, I like to disagree
Just disagreeing with people who are more knowledgeable and experienced than you is not going to result in your enlightenment. It will, however, result in you getting ignored. Retep's advice was correct. There are standards transaction types. Non-standard transactions are not generally relayed or mined. The use of standard transaction types protects the network against dos attacks and makes it harder to trigger currently unknown bugs and makes it easier to fix bugs when found. And of course miners care about scripts— they must validate them, and if a script triggers a forking bug they'll lose their income. If you'd like to experiment with novel transaction types, I strongly recommend using testnet as the standard transaction behavior is not enforced there and you can also mine your own blocks if you find the existing testnet miners are not being cooperative. An "easy to use" tool for what you're asking for is not possible— writing your own scripts is fundamentally not easy. In fact, the only thing "easy" to do with custom scripts is to create unspendable outputs and burn coins. Perhaps one is possible for what you actually want, but you didn't describe what you're trying to accomplish. I try to accomplish the (easy) possibility to create "non-standard" transactions. If I would call your words true, then only 3 (or 2?) kinds of txout-scripts should appear in the valid blockchain. Here are the statistics for the currently 31 different (by opcodes) kinds of txout scripts in the block chain for the accumulated 3 blk000?.dat files (so you see the growth): blocks=188529(0) bytes=2097361271 TAs=4855613 max_ta=1322 max blk_sz=499261 max out=2002 deposits=11167813 21 effectively different deposit_scripts. Counters: 452733 10712112 3 5 1 1 23 2 601 2042 15 1 1 1 4 182 2 77 2 1 4 total size of script_table: 4085 size of script_heap: 243760137 blocks=210965(0) bytes=2097295438 TAs=9549590 max_ta=1871 max blk_sz=499273 max out=2793 deposits=22202677 27 effectively different deposit_scripts. Counters: 687794 21509087 3 5 2 7 23 2 985 4206 15 1 1 1 4 182 2 325 2 1 4 1 1 1 1 1 20 total size of script_table: 4099 size of script_heap: 475068995 blocks=215171(2) bytes=534251343 TAs=10728759 max_ta=1633 max blk_sz=496810 max out=1183 deposits=24980532 31 effectively different deposit_scripts. Counters: 711025 24263192 3 5 2 7 23 2 986 4602 15 2 1 1 4 182 2 337 2 1 4 1 1 1 1 2 78 46 2 1 1 total size of script_table: 4120 size of script_heap: 531679902 21696089 redeemed deposits 3284443 available deposits in blk00*.dat So, please consider these facts, not the (undocumented) and not-well known wishes of developers.  The big size of the script table is due to a lonely script of size 4006 (3rd position, occurs 3 times) -- else it would be at neglectable 114 bytes of total size. ... are not generally relayed or mined.
How to you know and decide this? Do you control or advice the miners? And of course miners care about scripts— they must validate them
Interesting. There seems much more (power/influence) in the hands of miners than to me and most in the public BTC-users known .... I also wondered why the mining capability of the bitcoin-client was turned off (not only for inefficient I believe). .... the standard transaction behavior is not enforced there
Is there undocumented enforcement code in bitcoind? I wonder what would happen if the miners' special programs would no longer work (block generation value too low, not enough fees, fun is doomed by rational thoughts) and no common mining-able client is in use by the normal users? |
|
|
|
|
My two cents:
Currently the US-government has liabilities of a bit more than 15*10^12 $, say roughly 10^13 $.
Taken all of the other liabilities world wide, I guess their sum is limited by $ 10^14.
Moreover I believe all sums of every money availible (converted to US-$ units) is < 10^15 $ at every past point of time.
So if you like to be precise on the level of 0.01 US-cent, you need an integer range up to 10^19.
Hmm ... 2^64 = 1.84...*10^9. Wow, critical close if everybody would use BTC for his business! ;-)
smtp
|
|
|
|
Edit your original post, there is the subject field which can be edited. Try it here.
I gave it a try: There I can only change/edit the Subject of the message, not of the (total) Topic! smtp Thanks. It works. It changes the Subject of the message AND of the Topic. smtp |
|
|
|
Edit your original post, there is the subject field which can be edited. Try it here.
I gave it a try: There I can only change/edit the Subject of the message, not of the (total) Topic! smtp |
|
|
|
Yes. See the big edit button on the right corner?
Which edit button? I quested for the Subject (title) of the Topic not its contens! smtp |
|
|
|
|
Is there a possibility to modify/change the subject of a topic for its starter/creater?
Thx, smtp
|
|
|
|
there is a set of standard transaction types that the network supports - any transaction other than that isn't easy to get into a block.
Sorry, I like to disagree: Only a miner decides which transaction he likes to put in the just new found block. And I doubt that he will disgard (mostly) any transaction not of these only 3 "standard" types! :-) Honestly, he will not pay any interest of the script instructions but keep an eye for transaction fees. smtp |
|
|
|
As far as I know there isn't any easy to use software to create special transactions. When I've done it I've just edited the raw hex bytes produced by the raw transactions API.
THIS (the above cited first sentence) I only asked for: an existing (half-way user-friendly) program. Well, you may input hexadecimal data (for script code), but dislike all the time to use external (selfwriten?) code to compute the correct hashs, not to mention to compute the correct signatures needed in the txin- and txout-scripts. This should done by this program (like bitcoind or bitcoin-qt). So you may think as e.g. like an interface feature to bitcoin(qt)-client - if one would like/had it there. smtp |
|
|
|
|
Hi
Are there bitcoin-applications available which support the bitcoin-qt/bitcoind typical interface/transfers, but also support the possibility to define own/special txin-scripts and txout-scripts in each new transaction? Of course in this case I like that the application handles my private and public key accordingly to give me the correct hashes, resp. signatures which I may insert in the self made txin and txout scripts of the corresponding transaction.
smpt
|
|
|
|
In the blockchain there appear a few certain deposit-scripts: 0x73 0x63 0x72 0x69 0x70 0x74 (nemonics as OP_IFDUP OP_IF OP_2SWAP OP_VERIFY OP_2OVER OP_DEPTH) which were not redeemed. I wondered about this crazy script, but it triggered the question: if an OP_IF (or OP_NOTIF) is not closed by an OP_ENDIF inside a script, is the whole script then surely invalid or is this not necessarily invalid?
It is invalid (at least since bitcoinclient version 0.3.23). This answer (and many other insights) I got by carefully studying the file src/src/script.cpp of the bitcoinclient-0.7.1 distribution. Meanwhile I used my information to update, correct and make more complete the wiki-page https://en.bitcoin.it/wiki/Script for other newbies. smtp |
|
|
|
Hi I'm not sure why you think that's contradictory? The only difference between the two statements is that I said it must be OP_TRUE, the page says non-zero. Otherwise, they are the same statement. OP_TRUE is identical to the byte with byte value 0x01 = decimal value 1. Your interpretation sounds as if there is a unique "true" value, this one byte value. On the other hand, "true (non-zero)" means every stack-item which value is not 0 is interpreted as true. So if the final top-stack item is, say, 47 this would also be interpretated as true as well as the byte vector of length 3 "0x01 0x00 0x00" which is also not identical to OP_TRUE (but has the same value 1). This is not necessarily intuitive, at least not from the naming. I spent many hours putting a single zero-byte onto the stack and trying to figure out why my script eval was failing certain OP_CHECKMULTISIG scripts. It's because OP_HASH160 obviously gives a different answer for "" (empty-string) than it does a single zero-byte. I see the page now says "put an empty string onto the stack" for OP_0 -- I'm pretty sure that was added after I complained to Gavin about how that is a rather important detail that wasn't documented. My only point was that there are lots of tiny details and they are likely not to be documented well.
I see. Meanwhile I had added a Appendum to this minor point, which indeed critize the naming of the nemonic OP_0. So, have fun Thx, smpt |
|
|
|
If operands are not available for an operator, that means the script is invalid.
So I guess it is THE classical stack-concept and script evaluation always starts with an empty (later always of finite depth) stack. Better not assume anything. For certainty, read the Satoshi code.
You must assume if you have not complete information but wanted to act reasonably.  Could you give me a reference for this what you call "Satoshi code" - at best with a public available URL? I googled already but got only 634 hits and the most promising URL https://bitcointalk.org/index.php?topic=91004.0 I can't understand. Anything that doesn't meet the expectations of the OP-code results in an invalid script.
Okay, this matches grau's statement (assumping that it is evident what all the expectations of a specific Op-code are!). If it checks a signature using the top stack item as a public key, but the stack data does not parse as a public key, return SCRIPT_INVALID
Who does the parsing? I hope not me explicitly, but a (selectable) library function which depends on the run-time environment. :-/ Currently the only nontrivial library I use is the openssl library (libssl3.so.12) for SHA256 and RIPEMD160 hashing, but these functions I could also code to be independent of these library-versions - if I like. If there are no more opcodes to run and the top stack item is not OP_TRUE, return SCRIPT_INVALID (I think I remember that's how it works...been a while...)
This contradicts the URL https://en.bitcoin.it/wiki/Script where is stated in the beginning of the article: A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero).
. So what is correct -- if you remember correctly? # Gavin clarified the effects of OP_0, and OP_1-OP_16.
# OP_0 puts an empty string onto the stack, which evaluates to
# false and is treated by HASH160 as '' (length=zero)
# OP_X puts a single byte onto the stack, 0x01 to 0x10
To be frank, I see here no subtilities. OP_X stands for the range of OP_1 up to OP_16, each pushing 1 byte onto the stack. OP_O in contrast like the whole range of nemonics with the byte values 0 - 75 each pushs 1 item onto the stack , a byte vector of length of its opcode. This sounds to me like independent kind to push data onto the stack (like Op-codes with byte values 76 - 78 a further different kind). Anyway, at least I think I have interpreted the same meaning from the URL https://en.bitcoin.it/wiki/Script like you. Appendum: Hm .... the ugly "subtility" (I would call it an ugly design decision) is that the op-code value 0x50 is a reserved op-code and not the op-code for pushing the byte 0 onto the stack. Maybe one better should have called the nemonic OP_0 OP_Empty to avoid misinterpretation or give it no official nemonic like all the op-codes with byte values <= 75? I dislike to comment or even ask anymore to the replies given, in spite there have been arosen many questions by the following reply-postings from grau & gmaxwell. My feeling is: I have hiten a wasp's nest which is due to the fact, that there exist no (complete) definition of this scripting language only a historic implementation which is used as a reference (including all its bugs, subtilities, environment depending stuff, etc.)  It would be nice if I'm wrong. Maybe the "community" has to wait until serious commercial interests takes place on bitcoin (if anytime) and then surely forks in bitcoin-client script interpretation will result which are incompatible resulting in a mess and much worry -- perhaps the end or the unimportance of the known bitcoin-network. In the blockchain there appear a few certain deposit-scripts: 0x73 0x63 0x72 0x69 0x70 0x74 (nemonics as OP_IFDUP OP_IF OP_2SWAP OP_VERIFY OP_2OVER OP_DEPTH) which were not redeemed. I wondered about this crazy script, but it triggered the question: if an OP_IF (or OP_NOTIF) is not closed by an OP_ENDIF inside a script, is the whole script then surely invalid or is this not necessarily invalid? Thanks all for your informations and help smtp |
|
|
|
Hi I know the only reference for the bitcoin scripting at https://en.bitcoin.it/wiki/Script. There several opcodes define their action depending on the value of the top-stack item. Thus my question: what shall these opcodes do if there is no top-stack item (empty stack)? Or is the stack always assumed to be of infinite depth (assuming always 0 (I guess then) as the initial values of the descending stack-chain) ? Thx for clearifing smtp |
|
|
|
I can't take you out of the jail, but I can explain what we're doing in 0.8.
The first was no longer necessary (else I could not habe posted the previous notice in THIS topic/board) and thx for the later. So, reindexing and the "-loadblock" option in 0.7.1 not only made a new blkindex.dat file but furthermore do a fully validation (including the expensive signature check). I think there is no secret option in 0.7.1 or 0.7.2 to disable the signature verification when using "-loadblock", isn't it? Else a new bitcoin-client user could simple load a valid blockchain from a URL he trusted and simply load it to get this "blkindex.dat" to save MUCH real time -- this was my aim. For history: I deleted the only 6 orphan blocks form my personal blk00*.dat and thus wanted/needed a new blkindex.dat. For 0.8, this is changed completely. There is no transaction index ..... This means this 146 MiB is the only thing that needs to be readily available during block validation, and it easily fits in caches in memory.
This sounds well - I like this idea. I just checked: nearly exactly a 7.5-th of all deposits/txout-channels is not redeemed currently. And I believe this fraction will increase in the future further more. To check/validate a NEW block/transaction, the bitcoin-client gets only this data in RAM is sufficient, but sadly not for my blockparser. Moreover the idea to keep the whole out-scripts in memory is very good because there is only a very small number of effectively different response-scripts - they mainly differ only in different RMD-160-bit hashes for their public key. So, I guess in > 99% a table-no and this 20 byte hash is sufficient data to store the script. I also looked at all the input- and output-scripts and there are only very few effectively different ones -- so your "encoding and decoding the txout data" should be done quick and you can keep the coding-table small -- as long as the number of different out-scripts stay small (as in the past). The bottlenecks are now the crappy block download mechanism (which sometimes stops for several minutes) and signature verification (which is needed in practice, and is several orders of magnitude slower than all the rest combined). The last point can only be critical, if CPU-usage tends to 100% not the waiting time of the bitcoin client. The only checking my blockparser doesn't do is the merkeltree-hash of each block (I was still too lazy to do the coding) and this OP_CHECKSIG (resp. OP_CHECKMULTISIG), but I had read and understood its detailed description on https://en.bitcoin.it/wiki/OP_CHECKSIG. Thus I can't judge how cpu-intensive this OP_CHECKSIG evaluation really is. To be frank - I should add that I had hoped 0.8 would be released as a Christmas present and after this, once more as a New Years present, but my hope faded when I read more on the bitcoin forum. Thus I posted my proposal in the hope it could help to improve the 0.8 version. Thank you for your explanation. Now we can only continue to hope that 0.8 with the new data-structure will be released as reasonable quick as possible. smtp |
|
|
|
Hi If you think this message is the wrong place, place shift it to the correct topic/thread: Please have a look at my posting at https://bitcointalk.org/index.php?topic=15911.msg1422360#msg1422360 regarding "blkindex.dat" and "reindexing" real time speed of the bitcoin client. And if you think it is appropriate, you are free to move it to this (or a better) board/thread. BTW: Thank you for taking me out off the newbie-posting-restriction jail. Regards smtp |
|
|
|
|
Here is my posting/proposal to reason my request -- sorry for the bad style. :-/
Hi
The annoying huge real time to build up the blkindex.dat with the bitcoin-client is the trigger why I finally wrote this posting.
Sadly nowhere is explained neither which exact structure blkindex.dat has, nor
why we need this Berkley-DB-B-tree structure at all and it is extremly slow in
rebuild/updating in our case of bitcoin client.
Indeed I needed more than 23 h to build it from scratch with my 2 GHz Athlon-64 and 4 GB Ram. :-( and almost always the real time is spent by wait-for IO, not
CPU or network-band with limited if you want to catch up to the current blockchain.
Looking at the new bitcoin-client 0.7.99 test-release it looks still similar
slow, see benchmarks at [https://bitcointalk.org/index.php?topic=129861.0].
Thus I totaly agree in "We need to stabilize 0.8 as quickly as is reasonably possible, because people are beginning to avoid 0.7.x due to slowness, choosing instead less secure but faster bitcoin clients." stated by jgarzik in this thread.
I wonder why we need all this overhead-full and version-depending DB-stuff for
using/manipulating the blockchain in the bitcoin client. :-/
Here is an alternative for "blkindex.dat":
Hold the blockchain-indexing data always in memory and organize, it as follows:
Let there be TA-many transactions and DEP-many deposits (response-scripts/out-channels) in all the (valid) blocks in the blockchain.
On 2012-12-27 11:45 UTC we had #blocks= 213849, #TA = 10388275, #DEP = 24173524
The needed data structure consists of 2 tables and 1 heap:
1) A hashtable: we have TA many transactions and this number is steadily growing.
It is not decisive but I choose a hashtable which can store up to 2^26 many
entries (so current fill-factor is < 1/6). Each transaction gets a 4 byte index, e.g.
made up of the lowest 4 bytes of a transaction-hash (or made by xoring the 32 bytes into 4
bytes) anded with 2^26-1 , ==> this is a 2^28 byte sized table, which each entry is either 0 or
indexs a further table, called transaction table for simplicity.
2) The transaction table has #TA*(32+2+8) bytes = #TA*42 bytes.
Each entry of this transaction table holds ITS 256 bit doubled SHA-hashed hash = 32 bytes (back-check to the hashtable for index-collision-detection), a 2 byte counter (could be also 4 byte) for number of deposits and an 8-byte pointer into a heap for a specific transaction of a block of the blockchain.
3) the heap of deposit addresses and deposit values has size #DEP*(2*8+8) bytes
Here the explicit value in Satoshis, the address of the script, and the
address of the redeemed script is stored (null address if the deposit is
still availible).
The value of the deposits are pure luxury and could be saved. This value could
also be goten from the address of the script decreased by 8. But I liked to
store this value explicitly (in 8 bytes) and not looked it up each time in the
blockchain.
The size of these 3 structures sum up to about 1285 Mbytes compared to 1481 Mbytes of the current blkindex.dat. The heap and the transaction table grows simply
by appending new data if new blocks are mined and published.
Searching for a transaction given by its 256-bit hashindex happens in constant time (depends only on the fill-factor of the hashtable) -- in contrast any B-tree needs log_2(#TA). Adding a new transaction with its deposits is of course proportional to the number of deposits involved.
Thus the real time needed to access a deposit is constant. There are the rare
events when we want to delete a orphan block and thus removing transactions with their deposits from our data structure. In this case, the needed real time is
at most proportional to the age of the orphan block respectively number of blocks in the part of the forked chain measured in number of deposits containing in the end part of the forked chain.
The average real-time behavior should be at least as fast as the old
"blkindex.dat"-logic, but probably much faster because we need no log_2-searching factor from the B-trees involved.
I implemented this logic/data structure already as part of a blockchain parser
and a total build up of this new "block-index structure" needed 242 sec real
time and 71 sec CPU-time - most time was spend in reading the blockchain from
disc. BTW: I did not optimize the source-code, already the 2nd program version
needs only these 4 minutes. I recall: Compared to more than 23 hours real time of the
bitcoin-client 0.7.1 needed to rebuild the blkindex.dat via "-loadblock" options. :-(
So the only draw back I currently see is a need of 1.28 GB Ram compared to at most 1/5-th (or less?) Ram in the bitcoin-client + 1.5 GB of blkindex.dat disc-space.
Omitting the Satoshi value of each deposit in the data structure and using only
a 2^25 sized hashtable (currently means a factor of 3.23 of total to used entries)
would result in 0.96 (0.13+0.44+0.39) GB Ram. Of course this data structure could be stored also on disk to avoid rebuilding each time the client starts.
The win is a real-time factor decrease of 350 -- and in absolute units from
many, many hours to a few minutes when building up the index data from scratch
in a bitcoin-client or whatever. :-)
I like to hear your thoughts/critics.
BTW: If this is not too much nonsense perhaps a member could make a pointer to this posting in the thread/topic "Experimental pre-0.8 builds for testing" in the "Development & Technical Discussion"-board which is forbidden for newbies like me.
Thanks,
smtp
|
|
|
|
|
Hi
Thanks to a personal email to a developper because after 20-30 mintes of lurcking around and see neither a repüly nor a new-topic button, his reply-email
pointed me to the fact/politics of this newbie posting restriction.
THIS should be made clearly for each new registered account and then also be indicated which boards (or topics) are newbie postable, IMHO!
Greetings
smtp
|
|
|
|
|
