Topic: bitcoin/application/user-program supporting own scripts available? - page 2. (Read 2883 times)

This reduced-sanity mode is there to allow a part-time on-line/part-time off-line operation. You'll need to come up with a better sanity checking that doesn't require full-time on-line operation and doesn't create orphaned sub-chains when coming up online after a downtime.

Your statement from yesterday
prompted this question.

Obviously we understand "sane" much different. And a time stamp, say < 30 sec off the true time should be very easily available for every miner PC-user.
If I remember correctly the variation is up to 15 min, but everybody can see this in the block chain himself. You can sometimes notice blocks form the future or blocks which are younger than their predecessor if you looking for new dropping in blocks.
This nonsense I don't call sane. Look at recent blocks 214091 & 214092 and this is not a very extrem example. :-(

BTW: For my original question, I think either I will have to help myself (writing own code - the first guy replying in this thread pointed me to these raw transaction API since 0.7 I did not knew) or stop having interest in for a while - I got tired here by your kind of "helpful" answering / commenting - this what I can check easily is often wrong, looks more to me that you are talking either without knowing the facts or don't care them, or don't care of correct/precise wording. Excuse my frankness.

Regards,
smpt

I'm actually not aware of any non-trivial miners right now that don't filter at all, even luke is somewhat selective.

The fact that it doesn't work for most transactions most of the time is in no way incompatible with there being a small number of oddball ones. Miners and people with relationships with miners have no problems. Some miners routinely use odd transactions for their own purposes or amusement. There is one pool that will mine a broader subset of them, if you include the right fees and directly hand the transaction to them. Some of the odd ones in the chain are from me, in fact... and, while I have no idea what tool you're using to count scripts there, I expect its not quite canonizing hard enough to only return 3, even if all there were were standard transactions.

It's not something I decided, it's how it is— though for good reason.
After a fashion, I do.

Because the evil syndicate wills it. cough. uh. No, the integrated mining is still there, the knob is just hidden in the GUI but its visible and you can enable it from the command-line or in the config file.  But it's so slow to mine via cpu that you might expect to get one block on 3GHz cpu in about 135 years (and many people expect the difficulty to rise another 10x in the next few months, so 1350 years).  People were showing up very angry and confused that their cpu had been pegged at 100% for weeks and they didn't have a coin to show for it.  Sane mining using a gpuminer works exactly the same as it always has, and nothing has been hidden or changed about that.

Personally I'd like to see mining promoted in reference software— in the form of something with gpu/fpga/asic support and a GUI which promoted the lottery aspect of it a bit, with blinky lights, flashing numbers, and graphs and a best attempt so far gauge.  But it's all UI work, which isn't stuff I do.. and I doubt anyone considers it a priority right now. With it promoted as an unlikely chance hopefully people would be less surprised when they weren't rolling in the bitcents.


I can't figure out what even prompted you to ask that question. The software is open to all and the behavior we're talking about is well known and well documented, and considering that it was put in after a script handling bug exposed a vulnerability it hasn't been terribly controversial. If you're just trying to provoke angst with your antagonistic responses: troll elsewhere.

There is a protocol rule that limits the timestamps to fairly sane values.

There are nodes that intentionally relay non-standard transactions, and there are miners that intentionally mine them.  But most nodes won't relay them, and most miners won't include them.

This just spring to my mind -- IF I create unspendable (or even spendable!) outputs and burn coins in the former case THEN  a miner must have been cooperative as I expected and everything is fine. I also could send you my coins in contrast to  burn them, the later lose would be lesser to me.

BTW: Miners should be forced to put not obviously wrong time stamps in the new found block-headers, IMHO -- clients could simply not accept these blocks as valid.

smtp

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.
How to you know and decide this? Do you control or advice the miners?
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).
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?

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.

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

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

Look into the Raw Transactions API first, but be careful, it's easy to screw up and accidentally lose your coins with it. Test whatever you are doing on testnet first. What are you trying to do exactly?

As for creating fully custom txin-scripts and txout-scripts, if you've read the "Scripts" page on the wiki you might not already realize that 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. 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.

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