Quote from: d5000 on May 23, 2017, 10:41:34 PM

Ah, thanks, didn't know that it was that trivial (I wrongly thought that the "maximum block size" and "maximum transaction size" were connected in some way).

Is this included in the miners' proposal? If Lerner is one of the developers contributing to that solution (I read RSK Labs is participating), then it should be the case. Is there already publicly viewable source code for the "agreement update"?

If this is the case, I think, the Core supporters should simply (grudgingly) accept the proposal. It's better than an UASF because of the significant danger of a chain split - and it's really not worth it to polarize even more only because of a different timeline (HF in late 2017 or in 2018 ...). They should however try to convince the "consensus group" to change the HF date to a more distant point in the future. It should not be that difficult.

Actually maximum transaction size and maximum block size ARE connected. There are currently no limits on transaction size which means one transaction can be the size of the whole block. To actually restrict it to 1MB requires a fork that makes it part of the consensus rules. Nonetheless since no blocks have been larger than 1MB so far, to do so as part of the hard fork block size increase is the easiest time to implement it. There have been many arguments against limiting transaction size to date based on the censoring concerns in case there was a valid reason to create some kind of massive transaction. I don't have an opinion either way since I don't know how realistic the long term requirement for a >1MB transaction is. Perhaps it could be the collective transactions for one massive company for a day or something, not sure...