sg

[Anonymous]

adg

[1714800224]

1714800224

[1714800224]

1714800224

[1714800224]

1714800224

[ByteCoin]

You'll never believe it but I typed a big long reply and then lost the whole thing out of preview!

However... if there is whatever number of ins, and two outs (one to recipient, one for change) how is that transaction identified later?

The transaction is identified by the hash as you say below.

They both show the same hash, and I understand that they have different 'scriptPubKey' on their way into the first hash in the out, but how do you identify that when they are used on a tx_in?

That's what the index is for. I'm pretty sure they don't HAVE to have different scriptPubKeys. I wonder whether this corner case has been tested but it's probably fine.

Are they hashed together to get the corresponding scriptSig?

They are not hashed. One is appended to the other and then parsed as a Forth-like (ie stack based) script. The link you quote actually explains it quite well. OP_DUP for example is a human readable translation of the actual opcode (158 I think). The tables in the link show suceessive stages of how operands are pushed onto the stack, popped off the top, operated on and the results pushed back. The opcodes are specified in a big enum in script.h

Couldn't you fill up the first 50kb forcing everyone to pay a transaction on every block this way?

Yes this is a known problem mentioned in a recent previous post of mine. People minting coins have an incentive to do this as it costs them nothing and the return in the long run for any of them for doing so is positive.

Two computers running simple scripts sending each other pennies all day long as long as there is a balance... it would also make the block huge.

Transaction fees discourage this but if no transaction fees are included and the transactions are individually not too large then they just hang around in everyone's memory until they close the client. Another known attack mentioned in that previous post of mine. I presume that a large single transaction requiring fees but including none will be rejected and forgotten from the current client.

ByteCoin

[theymos]

I changed "combined" to "concatenated" on the wiki page.

regarding prioritized transactions and fees.

Transactions are never really "prioritized" based on fee (though they probably should be). Some are temporarily disallowed if their fee is too small, and they'll be included in a later block. In these cases I guess a higher fee would be prioritization, but generators don't look at all of the queued transactions and sort them by fee.

[ByteCoin]

Some are temporarily disallowed if their fee is too small, and they'll be included in a later block.

I think that only happens if the current block is over 50kb already. Otherwise I think it's just accepted. I might be wrong - if I am, please point out in the source where recieved transactions are checked for the appropriate fees.

I searched the source for "GetMinFee(" and it seems onlyto be called in BitcoinMiner and CreateTransaction. This would lead me to believe that a miner can attempt to hash a block with some arbitrarily large transactions in it and, if it finds a hash of sufficient quality then that block will be transmitted around the network and accepted by all clients without demur. The size of the block might be limited by any size limits of the buffer for receiving transactions and blocks from the network.
Anyway, that's another possible method of attempting to store the latest Lady Gaga video in the block chain!

ByteCoin

[theymos]

I searched the source for "GetMinFee(" and it seems onlyto be called in BitcoinMiner and CreateTransaction. This would lead me to believe that a miner can attempt to hash a block with some arbitrarily large transactions in it and, if it finds a hash of sufficient quality then that block will be transmitted around the network and accepted by all clients without demur. The size of the block might be limited by any size limits of the buffer for receiving transactions and blocks from the network.
Anyway, that's another possible method of attempting to store the latest Lady Gaga video in the block chain!

Yes; transaction fees are ignored by AcceptBlock. This is by design, as it allows competition for fees. ArtForz never charges fees, in fact.

I think that only happens if the current block is over 50kb already.

Your transactions would be delayed if you're using an old client (before the fee rules were updated) and send a transaction over 25KB without a fee.

[ByteCoin]

Yes; transaction fees are ignored by AcceptBlock. This is by design, as it allows competition for fees. ArtForz never charges fees, in fact.

If some behaviour is "by design" it tends to imply that the result is either good or at least ok. I was making the case that this behaviour is bad, is a flaw and should be changed. I presume you disagree. Could you explain why? ArtForz is essentially enabling the adverse behaviour I outlined.  

I think that only happens if the current block is over 50kb already.

Your transactions would be delayed if you're using an old client (before the fee rules were updated) and send a transaction over 25KB without a fee.

 I don't think you're right. I believe you can send a 25K byte transaction if the resulting block size is below 40k bytes for example. If I'm wrong, quote the code that forbids it.

In my previous post I should have replaced 50kb with 40kb to be correct.

ByteCoin

[theymos]

If some behaviour is "by design" it tends to imply that the result is either good or at least ok. I was making the case that this behaviour is bad, is a flaw and should be changed. I presume you disagree. Could you explain why? ArtForz is essentially enabling the adverse behaviour I outlined.  

The generators are the ones who have to store the block chain and do the proof-of-work, so they should be the ones who set the price. In the "transaction fee" wiki article, I wrote:

In the far future, different rules about transaction fees among generating nodes will probably create a clear choice between fees and transaction speed. For example, you might choose to spend 2% for a guaranteed spot in the next block or 0.01% for the transaction to be sent in a few hours.

This is a desirable situation -- a true free-market payment processing system. Anything else would be equivalent to price fixing, which would cause the system to fail.

It'll never go above 1MB/block, in any case, as above this limit blocks are rejected.

I don't think you're right. I believe you can send a 25K byte transaction if the resulting block size is below 40k bytes for example. If I'm wrong, quote the code that forbids it.

In my previous post I should have replaced 50kb with 40kb to be correct.

Code:

        // Transactions under 25K are free as long as block size is under 40K
        // (about 11,000bc if made of 50bc inputs)
        if (nBytes < 25000 && nNewBlockSize < 40000)
            nMinFee = 0;

[ByteCoin]

The generators are the ones who have to store the block chain and do the proof-of-work, so they should be the ones who set the price.

No. EVERYONE stores the block chain (at the moment). Why should a generator be able to inflict a large block on everyone just because he generates a hash?

I don't think you're right. I believe you can send a 25K byte transaction if the resulting block size is below 40k bytes for example. If I'm wrong, quote the code that forbids it.

In my previous post I should have replaced 50kb with 40kb to be correct.

Code:

        // Transactions under 25K are free as long as block size is under 40K
        // (about 11,000bc if made of 50bc inputs)
        if (nBytes < 25000 && nNewBlockSize < 40000)
            nMinFee = 0;

As far as I can see, the code above vindicates me and means that you were mistaken.
You said

Your transactions would be delayed if you're using an old client (before the fee rules were updated) and send a transaction over 25KB without a fee.

I said that this only occurred if the block size was over 40k bytes (which I revised down from 50k)
You seemed to disagree.

ByteCoin

[theymos]

No. EVERYONE stores the block chain (at the moment). Why should a generator be able to inflict a large block on everyone just because he generates a hash?

That won't always be the case. When simple payment verification is implemented, it won't matter at all to most people how large blocks are.

Generators are the ones running the network and bearing the cost of doing so, so they get to set the rules.

I said that this only occurred if the block size was over 40k bytes (which I revised down from 50k)
You seemed to disagree.

Look at the code... "If the block size is under 40KB, transactions over 25KB are not free." Old clients have higher limits for free transactions, so they will send even 50KB transactions without fees, and these will be delayed because new clients will never include them.

[ByteCoin]

Look at the code... "If the block size is under 40KB, transactions over 25KB are not free." Old clients have higher limits for free transactions, so they will send even 50KB transactions without fees, and these will be delayed because new clients will never include them.

Oh my goodness! You're right! How embarassing!

ByteCoin

[ByteCoin]

So, if the block size is over 40KB, ALL transactions in that block would require a transaction fee?

(Let's hope I get it right this time) Until the block size is 50k bytes transactions below 3k bytes are free. That's where the 50 came from in my previous post where I got it wrong. Most transactions are below 3k.

So if someone sent out 500 tiny transactions with no fees to get the block over that limit... those would stay there until they are accepted by someone not requiring fees?

In the absence of people like Artforz who hash without fees, I believe that the tiny unfeed transactions would be incorporated into the blocks 50k bytes at a time. I imagine it's first come-first served for inclusion into blocks. If it's more probablistic or even intelligent then it makes this attack more difficult.

Wouldn't that then also make all other transactions hang as well if they didn't include a fee? Or, require everyone else to pay a fee?

I believe so , yes. This is precisely the point I was making in one of my recent previous posts.

I think the viability of various denial of service attacks is acknowledged.

If you have found a problem, please email or private-message Satoshi, or post here (besides possible network denial-of-service attacks-- only email about those if you have a brilliant idea for how to prevent them...).

ByteCoin

[theymos]

The transaction fees however, are a little more concerning. How active is the test network? I am thinking about hopping on there and testing this out. It seems a little troubling with how small of an amount it would take, to make the block size unacceptably large at even 0.01 transactions. You would only need 2 BTC to start really creating lots of file size on each block. It doesn't look like it would ruin the network, it just may become a serious inconvenience.

So, if the block size is over 40KB, ALL transactions in that block would require a transaction fee? So if someone sent out 500 tiny transactions with no fees to get the block over that limit... those would stay there until they are accepted by someone not requiring fees? Wouldn't that then also make all other transactions hang as well if they didn't include a fee? Or, require everyone else to pay a fee?

The first transactions in a block are "locked in" to whatever rate they were accepted at.

Block sizes 40-50 KB allow free transactions under 3 KB. Most transactions are smaller than this. Above 50KB requires fees on all transactions. Any that don't have fees must wait until the next block. Transactions are included on a first-seen basis.

The effect of spam would be the delaying of all transactions that don't pay a fee. ArtForz (30% of the network) is running without any fees, and old clients have much higher free limits. It'll be hard to fill up everything; creating transactions is not computationally free. Since there are so few people on the test network (4 right now), I would just do the test on the real network. The worst-case scenario is everyone's transactions are delayed for a little longer. This might interest you:
http://bitcointalk.org/index.php?topic=567.0

ArtForz might screen out spam transactions if they become a problem. It's probably pretty easy to detect: deprioritize all transactions that draw coins from a very recent transaction. This kind of manual handling is probably how this kind of thing will be dealt with a few years down the line, when all big generators are using custom clients.

[MoonShadow]

I changed "combined" to "concatenated" on the wiki page.

regarding prioritized transactions and fees.

Transactions are never really "prioritized" based on fee (though they probably should be). Some are temporarily disallowed if their fee is too small, and they'll be included in a later block. In these cases I guess a higher fee would be prioritization, but generators don't look at all of the queued transactions and sort them by fee.

They don't currently, but is there any reason that they couldn't?  If that was a common sorting rule for much of the network, in a future with much bitcoin traffic the everyday man running the Bitcoin client to heat his house in Siberia could 1) help the network at no additional cost to himself, 2) set his client to not require fees like ArtForz does and 3) still have a decent chance at collecting an additional fee from some major player who desires to have a quick confirmation.  So the end result would be fee-less transactions for the common man when the network has the time, with the ability to make a 'buck' off of those who can afford quick service; automaticly.

I think what ArtForz is doing is a positive thing, but there is no reason to expect that he (or others like himself) will continue to do so indefinitely.